Internet Engineering Task Force Mike Pierce
INTERNET DRAFT Artel
Expires October, 2002
Don Choi
DISA
April 2002
Requirements for Assured Service Capabilities in Voice over IP
draft-pierce-sipping-assured-service-02.txt
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 a
http://www.ietf.org/ietf/lid-abstracts.text
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Pierce Expires October 2002 [Page 1]
Internet Draft Requirements for Assured Service in VoIP April 2002
Copyright Notice
Copyright (c) Internet Society 2002. All rights reserved.
Reproduction or translation of the complete documents, but not of
extracts, including this notice, is freely permitted.
Abstract
Assured Service refers to the set of capabilities used to ensure that
mission critical communications are setup and remain connected. This
memo describes the requirements for such capabilities in support of
specific networks such as those used by the US military and
government.
Table of Contents
0. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High Level Requirements . . . . . . . . . . . . . . . . . . 5
4. Functional Requirements . . . . . . . . . . . . . . . . . . 5
4.1 Precedence Level Marking . . . . . . . . . . . . . . . . . . 5
4.2 Authentication/Authorization . . . . . . . . . . . . . . . . 5
4.3 Preferential Treatment . . . . . . . . . . . . . . . . . . . 6
4.4 Diversion if Not Answered . . . . . . . . . . . . . . . . . 6
4.5 Notifications to Preempted Party . . . . . . . . . . . . . . 6
4.6 Acknowledge by Preempted Party . . . . . . . . . . . . . . . 6
4.7 Protection of Signaling Information from Disclosure . . . . 7
4.8 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Current Situation . . . . . . . . . . . . . . . . . . . . . 7
5.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 IntServ/RSVP . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.5 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Possible Approaches . . . . . . . . . . . . . . . . . . . . 9
6.1 Precedence Level Marking . . . . . . . . . . . . . . . . . . 9
6.2 Authentication/Authorization . . . . . . . . . . . . . . . . 10
6.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.2 Authentication Procedures . . . . . . . . . . . . . . . . 11
6.2.3 Authorization Procedures . . . . . . . . . . . . . . . . . 11
6.3 Preferential Treatment . . . . . . . . . . . . . . . . . . . 11
6.4 Diversion . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.5 Notification to Preempted Party . . . . . . . . . . . . . . 12
6.6 Acknowledge by Preempted Party . . . . . . . . . . . . . . . 12
6.7 Protection of Signaling Information . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 13
7.1 Authentication/authorization of User Access . . . . . . . . 13
7.2 Security of Signaling Information . . . . . . . . . . . . . 13
7.3 Security of Routing Data . . . . . . . . . . . . . . . . . . 14
Pierce Expires October 2002 [Page 2]
Internet Draft Requirements for Assured Service in VoIP April 2002
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16
0. Changes
01 Indicated informative material which would not be a part of final.
Moved some to Annex.
02 Removed material to draft-pierce-sipping-pref-treat-examples-00
and draft-pierce-sipping-assured-service-arch-00.
Added requirement to maintain records of use of service.
1. Introduction
Throughout many decades of evolution of the telephony network and its
supporting protocols, there has been a need to provide special
services to a limited subset of the users and calls within a network
or domain in order to ensure completion of important calls. Examples
of this need have been in support of emergency traffic for natural
disasters, network restoration traffic, and high priority traffic in
a military network. Provision of the required capabilities with the
signaling protocols and within the switching systems has been defined
in a number of national and international standards, most notably a
service referred to as Multi-Level Precedence and Preemption as
defined in an American National Standard [T1.619] in the US and in
corresponding ITU-T Recommendations [I.255.3, Q.735.3, and Q.955.3].
In addition, a service called High Probability of Completion (HPC)
was defined in [T1.631] and, most recently, two ITU-T Recommendations
define the requirements for the International Emergency Preference
Scheme (IEPS) [E.106] and the International Emergency Multimedia
Service (IEMS) [F.706].
Other drafts submitted to the IETF have addressed aspects of MLPP and
IEPS. Some of these are [Polk1], which discusses some of the possible
solutions for MLPP within IP; [Folts], which presents the functional
requirements, features, and objectives for the Emergency
Telecommunications Service (ETS); and [Carlberg], which provides a
framework for IEPS for telephony over IP.
MLPP was the solution to providing Assured Service capabilities
within the circuit switched environment. It is essential that
equivalent Assured Service capabilities are defined and implemented
for the packet-based, connectionless environment of the Internet, and
specifically SIP. Without these capabilities, SIP can not be used for
those applications which require such capabilities, and is less than
optimal for many other uses.
This memo builds on these references and identifies the specific
requirements for Assured Service capabilities in support of these
specific types of environments. The term "Assured Service" is used
Pierce Expires October 2002 [Page 3]
Internet Draft Requirements for Assured Service in VoIP April 2002
to refer to the required capabilities, rather than the previous terms
of MLPP or IEPS, since the envisioned set of capabilities and
protocols to achieve them are not expected to be the same as those
previously defined services.
Although these requirements are derived from previous military and
government applications, many of the same requirements and
capabilities may be applied for non-military or government networks,
for example, in support of commercial network restoration efforts. A
presentation in the TEWG at London [Ash] demonstrated real-life
situations from the past in which total network failures required
extensive efforts, presumably including communication via other
unaffected networks, to bring the affected network back on line. If
one considered a situation in which the very network which had failed
was needed to carry the network management traffic required to get it
back on line, it would be hard to imagine how it could ever be
brought back up in the face of overwhelming customer attempts.
Capabilities would be required to give priority to the network
management traffic, even to the extent of blocking all non-emergency
traffic for a period of time.
2. Background
In the circuit switched environment, specific circuits or channels
were used for each call. These were typically 64 kbit/s channels
which were a part of a TDM transmission structure. Later developments
used packet/cell based transport instead of dedicated 64 kbit/s
channels, however, the effect was the same. There was still a
dedicated transport capacity assigned for each call.
Assured Service in the circuit switched environment may be provided
by one or more of the following techniques. Note that the
capabilities included within IEPS [E.106], are included here for
reference but not dealt with further in this memo. They are further
dealt with in [Folts]:
- Giving priority to return of dial tone (IEPS).
- Marking of signaling messages for better handling, for example,
being last to be dropped in case of congestion in the signaling
network (HPC).
- Extra routing possibilities for higher priority calls. (IEPS)
- Exemption from restrictive management controls (IEPS) such as
hard-to-reach codes and code gapping.
- Reservation of specific facilities (trunks) for higher priority
traffic (IEPS).
- Higher priority calls may preempt existing lower priority calls,
causing the network to release the lower priority call to free
Pierce Expires October 2002 [Page 4]
Internet Draft Requirements for Assured Service in VoIP April 2002
up resources for immediate reuse by the higher priority call
(MLPP).
Identification of traffic authorized to use one or more of these
techniques may be via the following methods:
- Calls placed from physical lines or devices authorized for its
use
- Calls placed to specific telephone numbers or blocks of numbers
- Entry of a special ID code and PIN from any telephone device
3. High Level Requirements
While the existing requirements and capabilities have been developed
with the circuit switched environment in mind, many are directly
applicable to the packet environment and specifically the Voice over
IP application being defined using SIP. Some of the capabilities need
to be adapted or modified for application in the packet mode
environment. In addition, there will likely be new techniques which
can be defined specifically for the SIP case.
At a high level, the Assured Service requirements can be stated as
the need to ensure that mission critical voice-mode calls get set up
and remain connected.
4. Functional Requirements
The functional requirements for Assured Service being detailed here
are specifically those needed to support the US government
requirements, primarily for the military environment. This memo
concentrates on those portions mentioned in Section 2 which are
derived from the requirements for MLPP as defined in [T1.619].
Many of these requirements are the same as, or very similar to, those
of the IEPREP work as described in [Baker].
The basic requirements can be defined as follows;
4.1 Precedence Level Marking
It must be possible for the originator to select and signal one of
five precedence levels for a call, with the call defaulting to the
lowest if none is specified. It must be possible to carry this call
associated precedence level though the IP network. It must be
possible to deliver the originally signaled precedence level to the
called party.
4.2 Authentication/Authorization
Pierce Expires October 2002 [Page 5]
Internet Draft Requirements for Assured Service in VoIP April 2002
It must be possible to verify that the calling party is authorized to
use the Assured Service and the requested precedence level value and
to take the appropriate action if the calling party attempts to use a
higher level. The preferred action is to reject the call, and send an
indication of the reason to the caller.
4.3 Preferential Treatment
It must be possible to provide preferential treatment to higher
precedence calls in relation to lower precedence calls. Examples of
preferential treatments are:
- reservation of network resources for precedence calls
- usage of higher Call Acceptance limits for higher precedence
calls
- preferential queuing of signaling messages based on precedence
level
- preferential queuing of user data packets based on precedence
level
- discarding of packets of lower precedence call
- preemption of one or more existing calls of lower precedence
level
- preemption of some of the resources being used by a call of
lower precedence level
- preemption of the reservation of resources being held for other
traffic
Possible methods of providing Preferential Treatment using the
provisions of this memo, as well as other existing IETF protocols,
are described in [Pierce1].
4.4 Diversion if Not Answered
If a precedence call (one higher that the lowest level) does not
answer within a designated time or the called party is busy with a
call of equal or higher precedence such that an indication of the new
call can not be given to the intended called party, the call must be
diverted to a predetermined alternate party. In general, this must
operate similar to a normal "Call Forwarding on No Answer" service.
4.5 Notifications to Preempted Party
All preempted parties must be provided with a distinct notification
informing them that their call has been preempted.
4.6 Acknowledge by Preempted Party
Pierce Expires October 2002 [Page 6]
Internet Draft Requirements for Assured Service in VoIP April 2002
When an existing call is preempted for delivery of a higher
precedence call to the same party, after the party is notified that a
new call is being presented, the party must acknowledge the
preemption before the new call is connected. That is, there must be a
positive acknowledgement before any audio information is transferred
in either direction.
4.7 Protection of Signaling Information from Disclosure
Although protection is not actually an integral part of the Assured
Service functionality, it is specifically identified here since this
capability is always required in those networks which are assumed to
be the primary users of Assured Service.
It is required that sensitive information not be made available to
non-secure portions of the network or to any non-secure network
through which the traffic passes. It is also important that it not be
accessible by users connected to the network. This non-disclosure
requirement especially applies to information which is used to
control link state routing protocols based on knowledge of the
current traffic load at each precedence level on each route.
Further, it is desirable that the precedence information regarding
each call (as well as the other information such as calling/called
party identity) be protected from disclosure to the greatest extent
possible.
4.8 Accounting
Proper administration of the Assured Service capability requires that
use of the service can be reviewed after the fact for potential
abuse. Therefore, it is required that appropriate records be kept of
calls made, including the calling and called parties identity, time
of the call, and the precedence level used. This is similar to the
requirements for accounting (for billing purposes) for other services
in a commercial environment.
5. Current Situation
Current support for Assured Service within various IETF defined
protocols and ongoing initiatives is not considered to be sufficient.
5.1 IPv4
Although support for the traditional five precedence levels was
included in the TOS field of IPv4 from the earliest days, support for
this field is not universal, and it only provides packet level
priority. It does not provide call setup priority or control of call
retention.
5.2 DiffServ
Pierce Expires October 2002 [Page 7]
Internet Draft Requirements for Assured Service in VoIP April 2002
Within DiffServ, Assured Forwarding defined in RFC 2597 provides four
classes and three drop precedences for each class. One of these
classes would be used for the signaling messages for session
establishment and release. It is unknown if there has been any
proposal to utilize multiple drop precedence levels for various
signaling messages, as is being done with the equivalent call control
messages in ISUP for SS#7.
Expedited Forwarding defined in RFC 3246 is intended for voice, but
it treats all such voice packets the same. It does not define
multiple drop precedences as AF does.
5.3 IntServ/RSVP
Although RSVP includes mention of preemption of existing reservations
in favor of other higher priority ones, it does not provide detailed
procedures for doing so. In principle, it should be straightforward
to do so. However, it is not believed that the procedures required
for establishment of a path using RSVP, and the additional procedures
that would be necessary for preemption of an existing path, would
allow this to be useful for the provision of Assured Service
capabilities to individual calls.
5.4 MPLS
Since MPLS is fundamentally a means to emulate circuit-mode operation
by establishment of a "path" which then functions like a
"connection", the principles of priority and preemption could be
applied to the setup and retention of this path the same as they are
in the circuit-mode environment. RFC 2702 describes the requirements
for such capabilities as applied to "traffic trunks". However, it
uses the term "traffic trunk" to refer to a facility which is
established to carry an aggregate of traffic, i.e., many telephone
calls. This is the equivalent of a "trunk group" in standard
telephony terminology [T1.523]. Because of the extensive procedures
that are required to establish and remove such a Label Switched Path,
it is believed that this prevents MPLS from being used to setup paths
for individual calls.
MPLS may be applicable for the establishment of the equivalent of
dedicated trunk groups between switching entities (if such entities
were to exist in the SIP network architecture). Each of these "trunk
groups" or "traffic trunks" could exist to support a specific
precedence level of traffic between two points and could be setup
using the procedures defined in [RFC3212] or those in [RFC3209].
These documents allow the signaling of the required five levels of
precedence as well as separate setup and holding priorities.
5.5 SIP
SIP [RFC2543] defines four tokens for priority levels to be used to
control call setup, however, they do not equate to the levels
required for Assured Service. It should also be noted that no
Pierce Expires October 2002 [Page 8]
Internet Draft Requirements for Assured Service in VoIP April 2002
explicit ordering of these four defined values (emergency, urgent,
normal, non-urgent) can be found.
The proposed Resource Priority Header [Polk2] provides for the five
precedence levels required for per call marking.
Security is discussed in the revision to RFC 2543 [SIP-2543bis], but
it has been recognized in various Working Group discussions that
security for all aspects of call control needs to be considered in a
unified manner. Security for each individual component of call setup
and release can not be designed separately.
The procedure being proposed for authorization of call set-up and
media allocation [SIP-CALL-AUTH] appears to be too time consuming to
expect it to occur each time a user attempts to place a telephone
call, especially a high-priority one. The probable delay in
establishing this authorization would be contrary to the goals and
requirements for Assured Service. Use of this type of procedure would
require that preferential treatments also be applied to all message
interactions and proxy processing of the sequence of messages
required for the authorization. Overloads of the proxies responsible
for the Call Authorization would prevent or unacceptably delay setup
of the high precedence call.
6. Possible Approaches
The following identify possible approaches to meeting the
requirements stated above. This section is included in the draft to
stimulate discussion on ways of meeting the requirements, but is not
expected to be included in the final version when it is advanced
toward RFC status.
6.1 Precedence Level Marking
The approaches to be used for precedence level marking may need to be
different for each of the following cases:
A. Individual call setup:
There needs to be a definition of a field to be carried in SIP which
identifies the precedence levels of 0-4 of the call setup. Currently,
the US military uses five values which have specific meanings (as
currently defined in MLPP) and the standard may reflect these
meanings. However, it is preferable to provide easy support for other
network applications which utilize a different number of levels or
different meanings.
The specification may allow more than 5 levels. There is no need for
the 65k levels defined in [RFC2751] nor is there currently a
requirement to carry the separate preemption and defending priorities
of [RFC2751] or the separate setup and holding priorities proposed in
Pierce Expires October 2002 [Page 9]
Internet Draft Requirements for Assured Service in VoIP April 2002
[RFC3212] and [RFC3209].
[Polk2] is expected to result in a specification which satisfies this
requirement.
B. Packet forwarding:
To support preferential treatment on the packet transfer level, the
current lack of priority levels in Expedited Forwarding PHBs of
DiffServ will need additional capabilities to provide the required
functionality. Just as Assured Forwarding includes multiple drop
precedences for each class, there should be multiple drop precedences
for EF, which is intended for voice. In fact, voice transport is more
tolerable to dropped packets than many of the intended uses of AF
classes.
(It should be emphasized again that such multiple "drop precedence"
levels for EF would not provide an actual priority forwarding
mechanisms per packet, e.g., priority queuing of some packets ahead
of other within that EF class, just as there is no such capability
included within the AF PHB definition.)
In order to provide the required preferential treatments for the five
call precedence levels, it is required to provide five corresponding
drop precedence levels for the voice packet handling.
C. Trunk group establishment:
For MPLS, RFC 2702 defines the idea of a "traffic trunk" for which a
priority may be signaled by the label distribution protocol in order
to establish telephony "trunk groups". If LDP is used for label
distribution, the priority defined in [RFC3212] should be used. If
RSVP is used for label distribution, the priority defined in
[RFC3209] should be used.
It should be noted that the traditional definition of a "trunk group"
does not include the notion of a "priority" associated with a trunk
group. The priority is only associated with individual calls placed
on that trunk group. It is possible that the routing logic could
reserve a trunk group for higher priority traffic, but this is also
not the normal application, since it wastes facilities during periods
when very little high priority traffic exists and it can not support
the heavier load of high priority traffic when conditions cause such
a high volume.
6.2 Authentication/Authorization
This draft uses the following definitions from draft-ietf-aaa-
transport-05:
Authentication: The act of verifying a claimed identity, in the form
of a pre-existing label from a mutually known name space, as the
originator of a message (message authentication) or as the end-point
Pierce Expires October 2002 [Page 10]
Internet Draft Requirements for Assured Service in VoIP April 2002
of a channel (entity authentication).
Authorization: The act of determining if a particular right, such as
access to some resource, can be granted to the presenter of a
particular credential.
6.2.1 Architecture
In many other cases besides call setup for Assured Service it is also
necessary to perform authentication and authorization. Appropriate
security mechanisms have already been defined which may be used.
Refer to draft-pierce-assured-service-arch for a discussion of the
architecture required to support the authentication/authorization
requirements.
6.2.2 Authentication Procedures
It is essential that a framework for security for SIP be established
that allows a security association to be established between a user's
terminal and their dedicated SIP proxy at the time of an initial
registration. This initial registration, which includes
authentication, may require an extensive number of messages and
interactions with numerous network elements, including a Policy
Server, and may require a rather large time as a password is
verified. This registration and authentication would normally be done
when a terminal is turned on, activated, or places the first call.
This reduces the need to apply preferential treatment procedures to
the authentication process.
For the purpose of Assured Service provision, as with other SIP-based
services, it is expected that Authentication may be performed based
on the entry of an ID and password or the use of terminal resident
biometrics (e.g., iris scan) so that permission to use the services
can be associated with an individual, not a device. Once registration
is done, this permission is then associated with the device.
6.2.3 Authorization Procedures
Authorization per call must consist only of added fields/information
within the normal messages used for basic call setup as defined in
[SIP-2543bis].
6.3 Preferential Treatment
The preferential treatments would not be standardized unless they
require signaling between network elements. Currently, most
treatments envisioned are local matters within a proxy or router.
Consideration of preferential treatments depends on the case:
A. Per call:
Pierce Expires October 2002 [Page 11]
Internet Draft Requirements for Assured Service in VoIP April 2002
Preemption of existing calls, if done, would require coordination
between network elements, and therefore protocol standards,
especially if distinct actions are expected to reserve the preempted
resources for setup of the higher precedence call.
It is not expected that network initiated preemption of calls
(sessions) within the IP environment will be necessary. Instead,
sufficient preferential treatment can be provided by applying higher
call admission control limits and lower drop precedence procedures to
higher precedence calls. Examples of these procedures are shown in
draft-pierce-sipping-pref-treat-examples-00
B. Packet Level:
Current capabilities of DiffServ, with additional code points for
drop precedences, will provide the necessary preferential treatments
regarding packet transfer, including indications of discard
priority.
C. MPLS/RSVP Paths:
There should be no need for preemption of MPLS/RSVP established
traffic trunks (trunk groups) as described in [RFC2702] and
[RFC2205]. The required capability should be provided by mechanisms
to reduce the traffic engineering limits placed on lower priority
trunk groups (even by reducing to zero) to allow the capacity to be
used for the establishment of higher priority calls in other traffic
engineered traffic trunks.
6.4 Diversion
Diversion should be based on procedures that are developed for a Call
Forwarding on No Answer type service. However, it should not be
dependent on a timing performed by the original called party. Again,
this must be a function of the terminating proxy.
6.5 Notification to Preempted Party
Notification to the preempted party should follow whatever is done
for notifications for any network-initiated release. Since it is
expected that actual call preemption will only be needed in the
circuit mode environment, the gateway between it and the IP
environment should deal with such preemption by application of the
required notification (in-band) to the IP side.
6.6 Acknowledge by Preempted Party
Acknowledge by the preempted party (before connection of a new call)
should follow whatever is done for normal call presentation, that is,
the new call must be acknowledged before any audio is transferred in
either direction between end users.
6.7 Protection of Signaling Information
Pierce Expires October 2002 [Page 12]
Internet Draft Requirements for Assured Service in VoIP April 2002
See Section 7.
7. Security Considerations
7.1 Authentication/authorization of User Access
Discussions within SIP are beginning to identify the need to
authenticate/authorize all access to capabilities, since virtually
any function could be misused resulting in harm to the network or to
other users. Because Assured Service is intended to provide an
authorized user with better service than other users, including the
potential of actually preempting resources, it is even more important
to authenticate/authorize the user's access to the Assured Service
capabilities.
[SIP-2543bis] describes the use of a stateless challenged-based
mechanism for authentication in which a proxy server or user agent
may challenge the initiator of a request to provide assurance of
their identity. For real-time needs such as placing telephone calls,
especially those for which Assured Service capabilities are being
applied, such a challenge-based system will likely be too slow, or
would itself be hampered by the very network condition which requires
Assured Service be applied. Pre-establishment of security
associations is required, in order to allow for the timely exchange
of security information needed to perform authentication/
authorization of individual actions.
7.2 Security of Signaling Information
The need to protect signaling information from disclosure is
independent from the provision of Assured Service. Military/
government networks have long been built on the premise that such
information needed to be protected. Bulk encryption of signaling
links (as well as the user data channels) between secure switches
provided much of this protection. In addition, the Signal Transfer
Points of the SS#7 network could be secured against unauthorized
access. It should be noted that commercial networks are now beginning
to recognize the need for the same protection.
In the IP environment, the signaling packets as well as the user data
traverse many routers and could be accessed by unauthorized persons
at any one of them. While the contents of the individual signaling
messages could be hidden by encryption of the request and response
for end-to-end protection of information, the header must be visible
to intermediate routers. It is preferable to not require decryption/
encryption at each router. The approach has been to encrypt the
contents of the signaling message but not the headers which are
needed by the routers. However, the headers themselves may contain
sensitive information such as precedence level and called party
identification.
Pierce Expires October 2002 [Page 13]
Internet Draft Requirements for Assured Service in VoIP April 2002
[SIP-2543bis] describes the transport and network layer security
methods which may be used to protect signaling traffic.
7.3 Security of Routing Data
Of more concern than the information about an individual call is the
information normally needed by Link State routing logic used by an
originating device to select a route though an entire network. Such a
routing function requires knowledge of the state (busy or not) of
various portions of the network. When Assured Service based on
precedence levels is added, this requires that the routing point also
know the current loading of various precedence levels for each
portion of the network. Especially in a large network, this is highly
sensitive information and must not be revealed to unauthorized
network elements.
It should be noted that the constraint-based LSP setup proposed in
[RFC3212] depends on the routing point knowing this information.
8. IANA Considerations
It is not expected that there will be any IANA involvement in support
of Assured Service beyond what is described in [Polk2].
9. References
[T1.523] ANSI T1.523-2001, "Telecommunications Glossary".
[T1.619] ANSI T1.619-1992 (R1999), "Multi-Level Precedence and
Preemption (MLPP) Service, ISDN Supplementary Service Description".
[T1.619a] ANSI T1.619a-1994 (R1999), "Addendum to MLPP".
[T1.631] ANSI T1.631-1993 (R1999), "Telecommunications - Signalling
System No. 7 (SS7) - High Probability of Completion (HPC) Network
Capability".
[E.106] ITU-T Recommendation E.106 (2000), "International Emergency
Preference Scheme (IEPS)".
[F.706] ITU-T Recommendation F.706 (draft), "International Emergency
Multimedia Service".
[I.255.3] ITU-T Recommendation I.255.3 (1990), "Multilevel precedence
and preemption service (MLPP)".
[Q.735.3] ITU-T Recommendation Q.735.3 (1993), "Description for
community of interest supplementary services using SS No. 7 -
Multilevel precedence and preemption (MLPP)".
Pierce Expires October 2002 [Page 14]
Internet Draft Requirements for Assured Service in VoIP April 2002
[Q.955.3] ITU-T Recommendation Q.955.3 (1993), "Description for
community of interest supplementary services using DSS1 - Multilevel
precedence and preemption (MLPP)".
[RFC2205] RFC 2205, "Resource ReSerVation Protocol (RSVP)", September
1997
[RFC2597] RFC 2597, "Assured Forwarding PHB Group", June 1999.
[RFC3246] RFC 3246, "An Expedited Forwarding PHB", March 2002.
[RFC2702] RFC 2702, "Requirements for Traffic Engineering Over MPLS",
September 1999.
[RFC2751] RFC 2751, "Signaled Preemption Priority Policy Element",
January 2000.
[RFC3209] RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
December 2001.
[RFC3212] RFC 3212, "CR-LDP: Constraint-based LSP Setup using LDP",
January 2002.
[SIP-CALL-AUTH] draft-ietf-sip-call-auth-04, "SIP Extension for Media
Authorization", February 2002.
[SIP-2543bis] draft-ietf-sip-rfc2543bis-09, "SIP: Session Initiation
Protocol" (revision), February 2002.
[Ash] draft-ash-mpls-diffserv-te-alternative-02, "Alternative
Technical Solution for MPLS DiffServ TE", Jerry Ash, August 2001.
[Baker] draft-baker-ieprep-requirements-00, "IEPS Requirement
Statement", February 2002.
[Carlberg] draft-ietf-ieprep-framework-00, "Framework for Supporting
IEPS in IP Telephony", Ken Carlberg, February 2002.
[Folts] draft-folts-ieprep-white-paper-00, "Emergency
Telecommunications Service in Next-Generation Networks", Hal Folts,
February 2002.
[Pierce1] draft-pierce-sipping-pref-treat-examples-00, "Examples for
Provision of Preferential Treatment in Voice over IP", April 2002.
[Polk1] draft-polk-mlpp-over-ip-01, "Multi-Level Precedence and
Preemption over IP", James Polk, November 2001.
[Polk2] draft-polk-sipping-resource-00, "SIP Communications Resource
Priority Header", February 2002.
Pierce Expires October 2002 [Page 15]
Internet Draft Requirements for Assured Service in VoIP April 2002
10. Authors' Addresses
Michael Pierce
Artel
1893 Preston White Drive
Reston, VA 20191
Phone: +1 410.817.4795
Email: pierce1m@ncr.disa.mil
Don Choi
DISA
5600 Columbia Pike
Falls Church, VA 22041-2717
Phone: +1 703.681.2312
Email: choid@ncr.disa.mil
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published,
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein are provided on an
"AS IS" basis and 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.
Pierce Expires October 2002 [Page 16]