One document matched: draft-pierce-ieprep-assured-service-req-01.txt
Differences from draft-pierce-ieprep-assured-service-req-00.txt
Internet Engineering Task Force Mike Pierce
Internet Draft Artel
draft-pierce-ieprep-assured-service-req-01.txt Don Choi
June 23, 2003 DISA
Expires December 2003
Requirements for Assured Service Capabilities in Voice over IP
draft-pierce-ieprep-assured-service-req-01.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright
Copyright (C) Internet Society 2003. All rights reserved.
Reproduction or translation of the complete document, but not of
extracts, including this notice, is freely permitted.
Abstract
Assured Service refers to the set of capabilities used to ensure
that 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 government agencies, but
they could also be applied in commercial environments.
Table of Contents
0. Changes............................................................2
1. Introduction.......................................................3
2. Background.........................................................4
3. High Level Requirements............................................5
Mike Pierce Expires December 2003 [Page 1]
Internet Draft Requirements for Assured Service June 23, 2003
4. Functional Requirements............................................5
4.1. Precedence Level Marking.......................................6
4.2. Authentication/Authorization...................................6
4.3. Preferential Treatment.........................................6
4.4. Diversion if Not Answered......................................7
4.5. Notifications to Preempted Party...............................7
4.6. Acknowledge by Preempted Party.................................7
4.7. Protection of Signaling/Routing Information from Disclosure....7
4.8. Accounting.....................................................8
4.9. Call Control Signaling Precedence..............................8
4.10. Interworking...................................................8
5. Current Situation..................................................8
6. Possible Protocol Approaches.......................................9
6.1. Precedence Level Marking.......................................9
6.2. Authentication/Authorization..................................10
6.2.1. Architecture...............................................10
6.2.2. Authentication Procedures..................................10
6.2.3. Authorization Procedures...................................11
6.3. Preferential Treatment........................................11
6.4. Diversion if Not Answered.....................................12
6.5. Notification to Preempted Party...............................12
6.6. Acknowledge by Preempted Party................................12
6.7. Protection of Signaling Information from Disclosure...........12
6.8. Accounting....................................................12
6.9. Call Control Signaling Precedence.............................13
6.10. Interworking..................................................13
7. Security Considerations...........................................14
7.1. Authentication/authorization of User Access...................14
7.2. Security of Signaling Information.............................14
7.3. Security of Routing Data......................................15
8. IANA Considerations...............................................15
9. References........................................................15
10. Authors' Addresses..............................................17
A. Overview of existing priority mechanisms...........................17
A.1 IPv4..........................................................17
A.2 DiffServ......................................................17
A.3 IntServ/RSVP..................................................18
A.4 MPLS..........................................................18
A.5 SIP...........................................................18
0. Changes
This draft was originally submitted under SIPPING. This revision is
being resubmitted to IEPREP in order to ensure that the Assured
Service requirements are considered along with those of the related
IEPS discussions
(SIPPING) -00 Original draft
(SIPPING) -01 Indicated informative material which would not be a
part of final. Moved some to Annex.
Mike Pierce Expires December 2003 [Page 2]
Internet Draft Requirements for Assured Service June 23, 2003
(SIPPING) -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.
(IEPREP) -00
. Updated references.
. Added additional requirements related to preferential treatment
in 4.3.
. Added requirement in 4.8 for accounting records.
. Added requirement in 4.9 that preferential treatment must be
applied to call control signaling as well as to voice packets.
. Added requirement in 4.10 for interworking between Assured
Service and other priority schemes (e.g., IEPS)
(IEPREP) -01
- Updated references
- Moved informative material to Annex
- Clarified requirement statements
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 private networks. 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 the US [T1.631] and, most recently,
two ITU-T Recommendations define the requirements for the
International Emergency Preference Scheme (IEPS) [E.106] and the
International Preference Scheme for Multimedia Service in Support of
Disaster Relief Operations [F.706].
Other drafts submitted to the IETF have addressed aspects of IEPS.
Among these are the framework for IEPS for telephony over IP
[Carlberg].
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.
Mike Pierce Expires December 2003 [Page 3]
Internet Draft Requirements for Assured Service June 23, 2003
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
to refer to the required capabilities, rather than the previous term
of "MLPP" or the related but different IEPS, since the envisioned
set of capabilities and protocols to achieve them are not expected
to be exactly the same as those other services.
Although these requirements are derived from previous government
applications, many of the same requirements and capabilities may be
applied for non-government networks, for example, in support of
commercial network restoration efforts. A presentation in the TEWG
during the August 2001 meeting 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 normally part of a Time Division Multiplexed (TDM)
transmission structure. These transmission channels were almost
always interconnected and switched by Time Division Switching
technology (often referred to as "TDM switching").
Later developments used packet/cell based transport instead of
dedicated 64 kbit/s channels, often coupled with packet/cell-based
switching, 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.
. 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)
- Queuing for network resources (HPC)
Mike Pierce Expires December 2003 [Page 4]
Internet Draft Requirements for Assured Service June 23, 2003
. 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
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.
(While this draft focuses on Voice over IP, there should be a
consideration of the impact/solutions for other media flows which
carry mission critical communication, for example, video and instant
messaging. Most of the functional requirements can be equally
applied to these other media.)
4. Functional Requirements
The functional requirements for Assured Service being detailed here
are specifically those needed to support the US government
requirements. This memo concentrates on those portions mentioned in
Section 2 which are derived from the requirements for MLPP as
defined in the American National Standard [T1.619].
The basic requirements can be defined as follows;
Mike Pierce Expires December 2003 [Page 5]
Internet Draft Requirements for Assured Service June 23, 2003
4.1. Precedence Level Marking
It MUST be possible to assign each authorized user the highest
precedence level they are entitled to use. It MUST be possible for
the originator of a call to select and signal one of five precedence
levels for the call, with the call defaulting to the lowest level 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
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
The provision of preferential treatment MUST be in place before the
need to use it occurs. That is, initiation of the appropriate
measures MUST NOT require manual intervention or configuration of
network entities, for example, establishment of dedicated bandwidth
for high priority traffic. Further, application of preferential
treatment MUST NOT require a significant time delay, even if such
procedures are automatic. A "significant time delay" is considered
Mike Pierce Expires December 2003 [Page 6]
Internet Draft Requirements for Assured Service June 23, 2003
to be any delay noticeable to the calling priority party, for
example, more than a couple of seconds. Preferential treatment
SHOULD NOT be provided through any scheme of dedicated or pre-
reserved bandwidth or resources. In those cases in which such
dedicated bandwidth or resources are used, when such dedicated or
pre-reserved bandwidth or resources have been consumed by the high
priority traffic, further traffic of that same high priority MUST
NOT be provided worse treatment than any of the lower priority
levels.
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 SHOULD 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
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/Routing 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 generally required in those networks which are assumed
to be the primary users of Assured Service.
Sensitive information MUST NOT be made available to non-secure
portions of the network or to any non-secure network through which
the traffic passes. It MUST 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 or through each router.
Mike Pierce Expires December 2003 [Page 7]
Internet Draft Requirements for Assured Service June 23, 2003
Further, the precedence information regarding each call (as well as
the other information such as calling/called party identity) SHOULD
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 MUST be possible for the appropriate records to
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 Call Detail Recording (CDR) for
billing purposes for other services in a commercial environment.
4.9. Call Control Signaling Precedence
It MUST be possible to apply preferential treatment to the call
control signaling, since it competes for the same transport
resources as the voice packets. It is essential that:
. the call control signaling does not adversely affect the voice
(e.g., by introducing excessive packet delay variation due to
extremely long messages).
. the voice traffic does not significantly delay important call
control signaling (e.g., by preventing release messages from
getting through).
4.10. Interworking
Assured Service calls MUST interwork with other priority schemes
which are being provided within the same network, such as the one
defined for IEPS [Carlberg]. This includes the following two cases:
- both types of traffic may exist in a single network, for example,
an IEPS call may be originated from within a network which also
supports "Assured Service" calls. Procedures to determine the
relative priority and the resulting preferential treatment are
required.
- a network which provides "Assured Service" needs to support
interworking of calls to and from a network which provides another
scheme such as IEPS as well as another network which provides
"Assured Service". Mapping between the priority values must be
supported.
5. Current Situation
Annex A provides an informative overview of existing mechanisms
within IETF defined protocols for providing various types of
priority.
Mike Pierce Expires December 2003 [Page 8]
Internet Draft Requirements for Assured Service June 23, 2003
6. Possible Protocol 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 are 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 for the call (session)
setup. Currently, MLPP uses five values which have specific meanings
as currently defined in applicable standard [T1.619, I.225.3]) and
the definition of the field in SIP 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 separate preemption and defending priorities
[RFC2751] or separate setup and holding priorities [RFC3212,
RFC3209].
The proposed Resource Priority Header [Resource] is expected to
satisfy this requirement.
B. Packet forwarding:
To support preferential treatment on the packet transfer level, the
current lack of any priority mechanism within the single Expedited
Forwarding class 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.
The proposed MLEF PHB [Silverman] provides this capability.
Mike Pierce Expires December 2003 [Page 9]
Internet Draft Requirements for Assured Service June 23, 2003
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-12 [Aboda]:
. 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 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 [pierce2] for a discussion of the architecture required to
support the authentication/authorization requirements in a network
providing the Assured Service capability.
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
Mike Pierce Expires December 2003 [Page 10]
Internet Draft Requirements for Assured Service June 23, 2003
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. It is not performed for each 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
The procedures for authorization per call MUST consist only of added
fields/information within the normal messages used for basic call
setup as defined for SIP [RFC3261]. It MUST NOT require additional
messages to be added to the call setup sequence.
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:
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 [Pierce1].
B. Packet Level:
Current capabilities of DiffServ, with additional code points for
drop precedences within an EF-type class, will provide the necessary
preferential treatments regarding voice packet transfer, including
indications of discard priority. It will also be necessary to define
new capabilities to provide the necessary preferential treatment for
call control signaling.
C. MPLS/RSVP Paths:
Mike Pierce Expires December 2003 [Page 11]
Internet Draft Requirements for Assured Service June 23, 2003
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 if Not Answered
It is expected that Diversion would be based on procedures that are
developed for a Call Forwarding on No Answer type service. However,
it MUST NOT be dependent on a timing performed by the original
calling or called parties' devices. It MUST be the function of a
proxy serving the called party as shown in the proposed Service
Examples [Johnston].
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 party on the IP side.
6.6. Acknowledge by Preempted Party
Acknowledge by the preempted party (before connection of a new call)
should follow the same general procedures as used for normal call
presentation, that is, the new call must be acknowledged (answered)
before any audio is transferred in either direction between end
users. (Note that this does not refer to the transfer of "media"
between the terminals, only the transfer of actual audio between the
persons using the terminals.)
6.7. Protection of Signaling Information from Disclosure
See Section 7.
6.8. Accounting
This draft uses the following definition from draft-ietf-aaa-
transport-12 [Aboda]:
Accounting: The act of collecting information on resource usage for
the purpose of trend analysis, auditing, billing, or cost
allocation.
Call detail records (CDR) can be maintained by the proxy, since it
knows which users are authorized to place Assured Service calls and
knows when they do. Since not actually done to support billing
functions, it is not expected that a record of call duration is
required.
Mike Pierce Expires December 2003 [Page 12]
Internet Draft Requirements for Assured Service June 23, 2003
6.9. Call Control Signaling Precedence
Adequate precedence (and preferential treatment) can be provided to
call control signaling, with respect to user data carried by EF, by
utilization of a single AF class (single queue) for all call control
signaling. A weighted queue serving algorithm is then required to
guarantee that this queue receives a minimum percentage of the
bandwidth of the outgoing facility, if it needs it, regardless of
the volume of "higher priority" packers (such as voice in an "EF"
queue). It is expected that this percentage for call control
signaling would be less than 5% of the total bandwidth.
To address the situation in which the signaling traffic exceeds the
minimum guaranteed and there is excessive traffic, thereby blocking
some call control messages, the multiple drop precedence capability
of AF must be available. Relative drop precedences for SIP messages
can be modeled on those use in ISUP.
In order to address the other side of the problem - preventing long
call control messages from adversely affecting the performance of
the voice packets - it may be necessary to utilize a packet
segmentation scheme.
6.10. Interworking
Interworking requirements can be met in the following manner:
Within a single network which supports two or more priority schemes,
the network operator MUST determine the relative priority and
preferential treatments to apply. For example, the operator may
decide that the IEPS priority for "Authorized Emergency" will fall
between the Assured Service levels of Immediate and Flash.
At the gateway between two networks which support two different
priority schemes, the operator of the gateway MUST determine and
perform the mapping between the two schemes. For example, for the
priority schemes defined for Assured Service (in the Defense
Switched Network or DSN) and assuming 3 levels (normal, public
emergency, and authorized emergency) for IEPS (in the public
network), the mappings could be:
From DSN To public network
------------ ---------------------
Routine --> Normal
Priority --> Normal
Immediate --> Normal
Flash --> Authorized Emergency
Flash Override --> Authorized Emergency
and
Mike Pierce Expires December 2003 [Page 13]
Internet Draft Requirements for Assured Service June 23, 2003
From Public network TO DSN
-------------------- -------
Normal --> Routine
Public Emergency --> Immediate
Authorized Emergency --> Flash
7. Security Considerations
7.1. Authentication/authorization of User Access
Discussions within SIP continue 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. However, the requirement definitely exists for
all cases, not just Assured Service, therefore the solution is not
unique to Assured Service.
[RFC3261] 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 to 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. Many networks
have long been built on the premise that such information needs 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 have recognized the need for the same
level of protection previously only applied to various government
networks.
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
Mike Pierce Expires December 2003 [Page 14]
Internet Draft Requirements for Assured Service June 23, 2003
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.
[RFC3261] 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 for the Resource
Priority Header [Resource].
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
Preference Scheme for Multimedia Service in Support of Disaster
Relief Operations and Mitigation".
[I.255.3] ITU-T Recommendation I.255.3 (1990), "Multilevel
precedence and preemption service (MLPP)".
Mike Pierce Expires December 2003 [Page 15]
Internet Draft Requirements for Assured Service June 23, 2003
[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)".
[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)", R.
Braden, et al, September 1997
[RFC2597] RFC 2597, "Assured Forwarding PHB Group", J. Heinanen, et
al, June 1999.
[RFC2702] RFC 2702, "Requirements for Traffic Engineering Over
MPLS", D. Awduche, et al, September 1999.
[RFC2751] RFC 2751, "Signaled Preemption Priority Policy Element",
S. Herzog, January 2000.
[RFC3209] RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
D. Awduche, et al, December 2001.
[RFC3212] RFC 3212, "CR-LDP: Constraint-based LSP Setup using LDP",
B. Jamoussi, et al, January 2002.
[RFC3246] RFC 3246, "An Expedited Forwarding PHB", B. Davie, et al,
March 2002.
[RFC3261] RFC 3261, "SIP: Session Initiation Protocol", J.
Rosenberg, et al, June 2002.
[RFC3313] RFC 3313, "Private SIP Extensions for Media
Authorization", W. Marshall, May 2002.
[Aboda] draft-ietf-aaa-transport-12, "Authentication, Authorization
and Accounting (AAA) Transport Profile", Bernard Aboda, January
2003. (in editor's queue)
[Carlberg] draft-ietf-ieprep-framework-04, "Framework for Supporting
IEPS in IP Telephony", Ken Carlberg, et al, March 2003.
[Johnston] draft-ietf-sipping-service-examples-04, "Session
Initiation Protocol Service Examples", A. Johnston, et al, February
2003.
[Pierce1] draft-pierce-ieprep-pref-treat-examples-01, "Examples for
Provision of Preferential Treatment in Voice over IP", Mike Pierce,
et al, June 2003.
[Pierce2] draft-pierce-ieprep-assured-service-arch-01, "Architecture
for Assured Service Capabilities in Voice over IP", Mike Pierce, et
al, June 2003.
Mike Pierce Expires December 2003 [Page 16]
Internet Draft Requirements for Assured Service June 23, 2003
[Resource] draft-ietf-sip-resource-priority-00, "SIP Communications
Resource Priority Header", Henning Schulzrinne and James Polk, June
2003.
[Silverman] draft-silverman-diffserv-mlefphb-01, "Multi-Level
Expedited Forwarding Per Hop Behavior (MLEF PHB", Steve Silverman,
et al, April 2003.
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
A. Overview of existing priority mechanisms
Current support within various IETF defined protocols and ongoing
initiatives is not considered to be sufficient for Assured Services
requirements. This informative Annex details some of these.
A.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.
A.2 DiffServ
Within DiffServ, Assured Forwarding defined in RFC 2597 provides
four classes and three drop precedences for each class. One of these
classes could be used for the signaling messages for session
establishment and release. The multiple drop precedences could be
used for various signaling messages, as is being done with the
equivalent call control messages in ISUP for SS#7. However, AF is
not considered to be appropriate for voice.
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 so there is no way to provide
Mike Pierce Expires December 2003 [Page 17]
Internet Draft Requirements for Assured Service June 23, 2003
preferential treatment to packets associated with higher priority
calls.
A.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.
A.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. 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.
A.5 SIP
SIP [RFC3261] defines four tokens for priority levels (non-urgent,
normal, urgent, and emergency), however, they are not intended to be
used to control call setup nor do they equate to the levels required
for Assured Service.
The proposed Resource Priority Header [Resource] provides for the
five precedence levels required for per call marking.
Security is discussed in [RFC3261] and many drafts, 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.
Mike Pierce Expires December 2003 [Page 18]
Internet Draft Requirements for Assured Service June 23, 2003
The procedure being proposed for authorization of call set-up and
media allocation [RFC3313] 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.
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 assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Mike Pierce Expires December 2003 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:14 |