wdiff draft-polk-mlpp-over-ip-00.txt draft-polk-mlpp-over-ip-01.txt

Internet Engineering Task Force
Internet Draft James M. Polk
Expiration: August 23rd, 2001 May 22nd, 2002 Cisco Systems
File: draft-polk-mlpp-over-ip-00.txt draft-polk-mlpp-over-ip-01.txt

An Architecture for
Multi-Level Precedence and Preemption over IP

February 23rd,

November 21st, 2001

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 Engi-
neering 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 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.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].

Abstract

This document describes how the ANSI specification T1.619-
1992[1] and its extension T1.619a-1994 [2] should be mapped or
correlated or migrated over to either a mixed TDM and IP network
(with Gateways in between) or a pure IP network that requires
the functionality of these two specs as Standard Operating
Procedure.

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2.0 MLPP Overview . . . 2
2.0 Definitions and Conventions . . . . . . . . . . . . . . . . . . 4
3.0 Requirements Motivation for replicating functionality into IP Networks . . . 8
4.0 MLPP Requirements in an IP Infrastructure any Network . . . . . . . . . . . . . . . 8
3.1 General Priority Requirements
4.1 MLPP Precedence. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 General Preemption Requirements
4.2 MLPP Preemption. . . . . . . . . . . . . 10
3.3 End Station Requirements . . . . . . . . . . . . 9
4.2.1 Access Preemption Event . . . . . . . . . . . . . . . . . . . . 11
3.4 End user Requirements
4.2.2 Network Preemption Event . . . . . . . . . . . . . . . . . 11
3.5 Internetworking Device Requirements . . . 12
4.3 MLPP Feature Scenarios . . . . . . . . . . . . . . . . . . . . 12
3.6 Media Gateway (MG) Requirements
4.3.1 Bearer Services Supported . . . . . . . . . . . . . . . . . . . 12
3.7 General Security Requirements
4.3.2 Commonalities of Interest . . . . . . . . . . . . . . . . . . . 13
4.0 IP Infrastructure
4.3.3 Conferences Preset . . . . . . . . . . . . . . . . . . . . . . 13
5.0 IANA Considerations MoIP Requirements and solutions . . . . . . . . . . . . . . . . 13
5.1 Setting Priority to an MoIP Session . . . . . . . . . . . . . . 14
5.2 SDP in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 SIP in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 MEGACO in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5 MGCP for MoIP . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6 Differentiated Services in MoIP . . . . . . . . . . . . . . . . 18
5.7 RSVP in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.8 NSIS in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.9 MPLS in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.10 RTP for MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.11 Gateway Requirements Regardless of Protocol . . . . . . . . . . 20
6.0 Security Considerations. IANA Considerations . . . . . . . . . . . . . . . . 15 . . . . . . 21
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . . 21
8.0 Changes since last version . . . . . . . . . . . . . . . . . . 21
9.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
10.0 References . . . . . . . . . . . . . . . . . . . . . . . 16
8.0 . . . . 21
11.0 Author Information . . . . . . . . . . . . . . . . . . . 16 . . . . 23
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.0 Introduction

This

The intent of this document describes how the ANSI specification T1.619-
1992[1] and its extension T1.619a-1994[2] should be mapped or
correlated or migrated over is to either a mixed TDM introduce an Architecture for Multi-
Level Precedence and Preemption (MLPP) into the IP network
(with Gateways realm. MLPP was
originally written to create "a prioritized call handling service" [1]
in between) combination with ISDN supplementary services. MLPP has two very
simple concepts for voice (Real-Time) communications:

A) setting or marking every session at inception with a pure IP
Precedence level relative to others within a known network that requires
domain; and

B) the functionality end-stations or internetworking devices preempting
lower relative priority sessions in order for higher
relative level sessions to pass or occur during times of these two ANSI specs as Standard Operating
Procedure within
congestion at any point in that known, managed domain,
including to the IP portion of end-station (phone).

This concept has existed for more than a network.

T1.619-1992 describes an ISDN based ability of marking and
tracking each decade, and every (TDM) phone call, from call set-up, to
connection, to completion (hang-up) been deployed in many
networks throughout a defined Voice
Network. I believe ISDN was originally chosen because of the D-
Channel(s) and its control over associated bearer channels
(usually 1 D-Channel controls 23 bearer channels world for years. It is based, or founded, in a PRI T1
circuit, but can and US
Government network requirements. It is take down an augmentation service to ANSI's
ISDN [21,22,23,24]. This document is the BRI circuit (two B-
Channels first attempt, though incomplete
at 64kbps and one 16kbps D-Channel). In this marking
and tracking time, at bringing those specialized functionalities of every single phone call, MLPP from a
more traditional world voice communications delivery practice into the network becomes
priority "aware" of which phone calls are important and which
are not. Which phone calls have priority IP
realm.

MLPP over others, and which
do not. There are 5 levels of defined Priority given to every
phone call. Under normal operating conditions of an T1.619-1992
enabled Voice network, no calls ever dropped, IP, or prioritized
greater than others that would cause anything to occur to those
lessor Prioritized calls because there are no network
bottlenecks, no congested interfaces, MoIP, shall specific as many IETF Standards and no call flow problems.

But this isn't always the case. Certain environments require the
ability practices
as possible. The intend here is not to prioritize calls over others in those network
situations that bottlenecks occur and are deemed "important"
phone call reinvent anything that need already
exists. However, certain functionalities in IETF Protocols will require
adjusting, or extending, to get completed even if it means
disconnecting an existing, pre-established call somewhere within fit the network.

T1.619-1992 was written for networks MLPP model that have will be laid out
within this type of
requirement. To have multiple levels of priority for all voice
calls document to satisfy the requirements and experiences of the ability
trained user of MLPP in the time past.

Most of need, to preempt voice calls
that are deemed less important than others in order to get
those fewer, more important calls through the network to their
intended destination. This specification has been called MLPP,
for 'Multi-Level Precedence specifications and Preemption' ever since its
original publication in 1992. The Clarification document T1.619-
1994[2] merely clarifies some errors concepts stated here for MLPP were taken
from the original ANSI specification T1.619-1992 [1] and added some minor functionality, but didn't
change the essence of the original specification.

I am going to use the words 'Precedence' its supplement T1.619A-
1994 [2]. Still other specifications and 'Priority' inter-
changeably throughout the remainder of this ID.

Why is this document concepts stated here needed in are from ITU
Q.735.3 [19]. Any remaining details and concepts attained from documents
came from the IETF?

Because these certification materials which all products must tested
against to achieve MLPP enabled networks were built. And they compliance and interoperability status [17,18].
There are a few concepts mentioned here that were
sometimes built very big, by anyone's standards. One closed
network I know attained from inter-
viewing users and testers of has 800+ Class 5's in it, MLPP for example; that's
fairly large guidance of how this MLPP-concept
might be enhanced with the additional capabilities that IP and fairly complicated, IP-based
services brings to offer.

This document will state its scope, to include what will and it will not be fairly
difficult to migrate to our current love: Packets. IP packets to
covered here. It will define all the terms as best as possible due the
readers might not be more specific completely familiar or savvy with our area the IETF and its
languages, but from more of focus in a telephony background where MLPP lives today.
This document will then define the IETF.

So, there needs network feature and functions necessary
to be compliant with existing MLPP networks. This is as much a migration from background
and education, or level-setting, as anything. This section will detail the
known behaviors each component of an ISDN based, PBX based,
TDM based Voice infrastructure MLPP network must do under explained
circumstances and scenarios.

The next section will get into the IP realm of MoIP. Please notice the
convention change. Within this document, MLPP shall refer to a partial ISDN/PBX/TDM based
infrastructure the tra-
ditional GSTN-based MLPP network and partial IP-based infrastructure, or just
completely all components and requirements;
whereas, MoIP shall refer to an its IP based infrastructure with MLPP capabilities.
No functionality can counterpart. That Counterpart
shall be lost near in functionality, but this transition or build out.

Conventional wisdom sez that in order for consumers isn't exactly an apples to move apples
conversion from one 'thing' or 'habit' topology to another, it requires another. Some things will change. Some
functionality will be done a different way, some will be enhanced, and
some functionality will not exactly be replicated. The circuit switched
world has some form advantages, such as maintaining state of
motivation to do a circuit end-to-
end, that new 'thing' or 'habit'. In IP doesn't have easily. As best as possible, the telephony
case, it's usually document shall
point out where a functionality is enhanced, duplicated, or how far
replication falls short.

Next there will be an IANA Considerations section to the case IANA group for
registration of mappings, which shouldn't occur here as this new idea costs is not a whole
lot less (possibly
Standards Track document. This section will be followed by the security
considerations section which states all the security problems enacting
this document should cause. No normative language should be within this
section, but here there shall be the remaining caveats not previously
covered within this document, with less functionality) or it has a whole
lot some reminders, but more functionality (possibly costing more). But none general
language here. The details are within the document's main text in previous
sections.

The next 4 sections are: Acknowledgements, the changes since the last
version of document, the references and author's information sections.

After the main body of this document, following the author section, are
the
consumers Appendices, which are connected to empty in this version. These are of importance
as they shall contain the examples sections of network topologies with
certain functionalities present, and others not present, and the details
of how the basic MLPP enabled networks requirements are
paying met within the MoIP part of that
topology. There shall be a dime out different Appendix for each topology and set of their own pockets
protocols present. Within each Appendix, the rules stay the same for these networks,
because they each
MLPP requirement to be explained. There could potentially be an endless
number of Appendices, but the most popular, or most predictable present
set of topologies are utilizing detailed out here. As this functionality only in their
respective work environments. So, if cost isn't a factor
(arguably), functionality is; an all-of-a-sudden-lack-in-
functionality would document progresses, I
expect more and will more examples, or Appendices, to be noticed written, and likely discus-
sion occurs regarding this document, and I�m reminded how certain 'impor-
tant' environments were left out, and but should be included and explained
within this document to be considered more complete.

2.0 Definitions and Conventions

The following is a list of definitions and conventions to used throughout
this document. Note that some of the definitions are either MLPP *or* IP
centric, and might not positively.

This make sense to the other. Advice is taking these
words in the context of the section of this document was they are written with in.

Alternate Party Is another ID in mind endstation which is configured for any
call diversion if the Called device has an inbound
Precedence inbound call while that Called User is
intended to be
actively on a Standards track ID within call/session

Assured Forwarding AF [13] in Diffserv � marks the SIP WG [3] IP Headers with a
codepoint value relating to the expected behavior of
that value throughout a single IP domain on a per hop
basis

DE MLPP defined as the PBX the destination endstation is intended
directly connected to be

Diffserv Differentiated Services [3] � IETF Standard defining
a Priority marking of IP Packets to achieve deter-
ministic behavior through an IP-based network

Domain For MLPP, the smaller, SIP focused aspects set of MLPP that
needed extending subscribers and contiguous
network resources in use at any time supporting those
MLPP subscribers;
For IP, everything within the logical IP boundary
supporting MoIP capabilities in a WG single network

Edge Router ER - A Router at the logical boundary of an MoIP
Domain

End Office Node EN � see EOS

End Office Switch EOS � Similar to a PBX configured to only service
that local community and its needs; it is internal
network controlled; this unit connects all CPE
equipment in that community

Endpoint H.323-based voice device (IP Phone) utilizing only
H.323 Signaling Protocols

Expedited Forwarding EF marking [12] in Diffserv creating a "general" Informational-
based ID could not stipulate or require. In forwarding
queue with no other words, above it, that in which a packet
entering the
intent here is to try queue shall not to solve MLPP be delayed by more than
one packet length/time from any other queue

Gateway converts media provided in one BIG document.
Where would it go, and who would oversee it? I decided type of network to break
it up into several ID's. the
format required in another type of network; the
gateway shall be capable of full duplex audio trans-
lations

GSTN Global Switched Telephony Network � worldwide circuit
switched public telephony network

H.323 ITU originated Peer-to-Peer Multimedia Signaling
Protocol

ISDN Integrated Services Data Network

Label Switched Path LSP � MPLS short fixed length label assigned to
packets upon ingress to an MPLS cloud. This one label
is the larger overview,
general ID, and Informational. In talking what MPLS Routers use to Scott Bradner, he
and I felt it wise make forwarding decisions
on.

Look ahead For Busy LFB � this optional feature has one endstation
prematurely acquiring the path, preempting if
necessary, to create another endstation; this larger ID on an Info track, can occur
any interval before the call/session is actually
placed

Media Gateway See Gateway above � but one side is IP, and submit the smaller Standards Track ID's into is
not; could be analog voice of an IP phone, or it
could be a trunk interface to a PBX

Media Gateway Controller MGC � or Call Agent � the appropriate
WG's server that had acts as
the need control plane for adjustment audio, video, or extensions for MLPP-
specific features and capabilities. SIP was both, or
full multimedia communications

MGCP Media Gateway Control Protocol � IETF Informational
RFC 2705 Client/Server based Call Control Protocol of
media Gateways (Gateways or IP Phones), resulted from
the first I
identified and submitted into; there will likely be many others.
I hope, as Scott does I believe, that each merger of these WG
extensions will be small in nature IPDC and scope, tweaks if you
will. SGCP

MLPP is not the biggest thing to come to networking, Multi-level Precedence and I
don't want to treat it like it is. But there is Preemption [1 & 2] � ANSI
T1.619 and 619A specifications stipulating mechanisms
for marking each voice communication with a customer Prece-
dence level, and defining the requirement (many actually) for these specific features and
functionalities, and the
Preemption of lower Precedence existing sessions
during congestion in talking with customers on both sides favor of
the Atlantic, new higher Precedence
sessions

MoIP MLPP over IP

MPLS Multi Protocol Label Switching [4] � IETF Standard
for using label switching and voice communications will remain separated
until these for the implementation
of label-switched paths over various link-level tech-
nologies, such as Packet-over-Sonet, Frame Relay,
ATM, and LAN technologies

Multifunction Switch MFS - A combination of a End Office Switch (EOS) and
Tandem Switch (TS); having trunking and CPE connec-
tion capabilities are incorporated into an IP-Manageable
infrastructure within one, more economical unit

NSIS Next Steps in Switching � currently a Standards accepted way where multiple
companies can provide products for bid.

2.0 proposed IETF
Working Group to focus on simplifying signaling
within a network vs. a more heavyweight version: RSVP

OE MLPP Overview

Multi level defined as the PBX the originating endstation is
directly connected to

Precedence and Preemption Service Capability
stipulates a The relative priority ranking order of all level assigned to each session

Precedence Call flows
on a hop-by-hop basis through Any call that has a Voice Network Precedence level higher than
Routine

Preempt Notification The notification sent from their
relative beginning Voice device (calling party) to the end
Voice device (called party). Within endstation receiving
the TDM world, these inbound preempting call flows were in a closed circuit switched network to the endstation being
preempted from
a PBX or Tandem Switch their previous call/session

Preempted The audible notification sent to PBX or Tandem Switch. Each
Switch, upon initiation of all endstations who
have been preempted for any reason

Preempting Call Is a higher priority call flow
where there were no available outbound resources or trunks,
preempted with a Precedence level higher than others
on a specified interface at a time of congestion,
including an end-station that is on a lesser priority call flow by seizing

Proxy Server SIP Server [6] that acts on behalf of other Devices
Registrar Server SIP Server [6] that serves as a Registration point
principally for mobility

Response Timer T-sub-K Is started when the
resources network notifies the Called
device of a inbound precedence call; acceptance must
occur by the Called device; the timer is specified in
[1] at from 4 � 30 seconds

Response Timer T-sub-L Is started when an existing external truck circuit LFB information unit is sent
into the network to satisfy
that higher Priority Call. Eliminating establish an open path between
the previous call with-
out giving either Calling endstation and the intended called end-
station; the timer is expected in [1] as from 5 � 20
seconds

RSVP Resource Reservation Protocol � IETF Standard defined
in RFC 2205, for reserving bandwidth from end station a choice or chance
to continue end station, without congestion affecting it once
the call flow path exists

SLA Service Link Agreement � Agreement between two adja-
cent networks on many aspects of how one's traffic
gets treated within the other's network

Switch Packet-based multiport Router intended for internal
network use and not connected between different
networks (owners); here they are Layer 3, or IP-
Header, aware devices that switch determined overridden call.
Typically, an audible tone occurred packets to desti-
nation interfaces based on the inbound caller's
phone receiving Destination address
within a packet

Tandem Switch TS - Only connects to EOS's; is the Preempting call flow. But this only occurred
if primary backbone
of a circuit-switched MLPP Network

Termination The end of a circuit, or in the MEGACO definition,
the end device, a Gateway circuit or IP-based Phone

Transit Router Router or any Layer 3 aware device that caller happened to be is not an
endpoint in the resource communications path, but that was preventing path
travels through it to get to the higher priority call from being completed. In other words,
like destination

User Agent SIP [6] defined as an application which can act both
as a forced call waiting with all user agent client and user agent server

User Agent Client SIP [6] defined is a client application that initi-
ates a SIP request

User Agent Server SIP [6] defined A user agent server is a server
Application that contacts the tones user when a SIP request
is received and such, but that returns a response on behalf of
the user. The response accepts, rejects or redirects
the request.

VPN Virtual Private Network; defined as existing call is among
many devices, but able to communicate with only a
network pre-configured limited number of devices, at
the same time, devices not put on hold, it's disconnected. I don't
know if belonging to this group
within the private network cannot communicate within
either

3.0 Motivation for replicating functionality into IP Networks

Many MLPP-based networks wish to move into the IP realm, yet have opera-
tional features and functions that aspect of the administrators of these networks
deem important/mandatory, and are not willing to set aside in this
migration which aren�t available or defined in IP yet. Accomplishing
certain of these functionalities is similar to fitting a round peg into a
square hole. MLPP spec is desired still or not, circuit-based technology, and should be looked at IP is packet-based. To
accomplish a task that is easy within MLPP, such as Look ahead For Busy
(LFB), which ensures that one phone has a choice perhaps with clear and open path to make a timer
controlling how long the preempted
call waits for to another phone, even though the new call calling phone hasn't started to be disconnected
make the call, and might not for seconds, minutes or hours, makes sense in order to reconnect
the original call; with
that first call being disconnected after an agreed upon
timeframe within this spec.

The networks where MLPP concept was created so exists presently; but that there was feature makes little to
no sense in IP networks where available bandwidth is freely given on a real-time
method of prioritizing voice communications. It was created
back before electronic switching
best effort basis through any internetworking interface at that moment �
much less reserving that bandwidth for future use, if used at all. An
exception does exist in the U.S. Government
"AUTOVON" network. It IP for this example, but it only reserves
bandwidth end-to-end if that bandwidth is designed so available through each transit
Router, and upon set-up of that normal telephone
traffic would symmetrical session that is about to
occur, not cause problems before.

MLPP has very little impact on end devices like the phones because all the
signaling and processing is in the event of EOS, not the phone. Signaling mecha-
nisms that have stateful awareness, and have this resource reservation
feature enabled from the example above have a crisis.

By contrast, great impact on the
processor of that end device (IP Phone) the way the IETF Protocols are
written today. IP has no physical circuit endpoint to map to in a Packetized Voice Network, there will likely
not be fixed these
transit Routers (unlike the EOS or pre-configured outbound circuits waiting for
higher priority call flows TN in MLPP networks); no easy way to occur on a per-MLPP-enabled IP
Internetworking device basis. This presents
reserve a more challenging
problem fixed portion of preemption bandwidth; in a less statically configured Network
Topology. Also, every network device will need fact, these transit Routers
almost never know which packet belongs to have the code
within it which session going through it,
or that any sessions are going through it.

These administrators understand that IP Telephony offers significant
increases in features, functionality and services for all end-users.
However, there has not yet been an effort to make describe this Prioritization and Preemption
determination similar or exactly like architecture
with IP. This document takes that challenge.

4.0 MLPP Requirements in any Network

This section details the Class 5's requirements of today's MLPP networks, without IP and, as best as
can be accomplished, without ISDN or there SS7. Many circuit-switched nomen-
clatures and references (words, not bibliographical) will be weaknesses made due to
MLPP only existing in the IP
Infrastructure that might prevent the proper completion of a
(deemed) very important voice session.

Here circuit-switched world to this point in time. It
is an example using Military Rank as attempt at a conceptual com-
parison:

The lowest level, ROUTINE, would be used generic, yet specific set of network requirements for all normal call
traffic. If a Company commander needed
any network to reach his platoon
leaders, he/she would use the PRIORITY precedence level. If a
crisis arose, normal traffic would be preempted by command
traffic. The lower level command traffic would use the PRIORITY
and potentially the IMMEDIATE precedence levels. The field
grade traffic (brigade, battalion, function as an MLPP compliant network; and division) would use yet not too
specific to the IMMEDIATE, circuit-switched world as to detail Bellcore's Local
Access Transport Area (LATA) Switching Systems Generic Requirements
(LSSGR), FR-64. Where possible, language will exist that attempts to
convey whatever tone or spirit these MLPP references make to these
requirements � for clarity and understanding in some cases FLASH precedence levels.
Communications within the Corps making IP equivalents and Theater commanders would
use FLASH. The President,
solutions for MLPP in a packet environment.

For this to happen, the Joint Chiefs, and some select
theater commanders (e.g. CICNORAD, or CICSAC) would use core MLPP documents [1 & 2] must be referenced in
detail, as well as the
FLASH OVERRIDE precedence. This guarantees (in theory) that documents involving the most important commands (the President forbidding nuclear
launch) would get through even over all other traffic actual testing of any
component for certification of MLPP compliance [17,18,19].

The root specification [1] states that there are two parts to MLPP
conceptually: Precedence and Preemption.

4.1 MLPP Precedence

Precedence means Priority, relative priority to all other calls within
that single domain. It is set or type.

This pre-grading assigned by the calling party at the
beginning of importance is a method of assigning maximum
levels of priority to traffic based call, on user Profile (e.g. what
they are authorized to do). Someone who was authorized to use
IMMEDIATE precedence would normally use ROUTINE unless there
was a legitimate reason to escalate per call basis by that party. Once the
precedence to level is chosen by a higher
level.

ANSI T.619-1992 states caller, it cannot be changed for the 5 levels
duration of Precedence (or Priority)
for MLPP networks as that call. However, the following:

bits Name
---- ----
0000 next call being independent of the
first call, can be made at another authorized level, also chosen by the
calling party.

Precedence Values are:

1 "0000" = "Flash Override" (0)
0001 (highest level)
2 "0001" = "Flash" (1)
0010
3 "0010" = "Immediate" (2)
0011
4 "0011" = "Priority" (3)
0100
5 "0100" = "Routine" (4)

0101 to
1111 "Spare"

There (lowest level)
"0101 � 1111" are actually 16 values/levels possible within the ANSI
spec, but any additional levels will have a preemption func-
tionality below, or less than, "Routine". unspecified

The intent is that above list of precedence levels are listed in order from highest to
lowest; meaning no call SHALL be of higher priority than "Flash Override" is always
in an MLPP domain, the highest "Flash", and so on down to "Routine" as the lowest
level capable within a
MLPP-compliant network.

In any case, a call session able to be signified. "Routine" is for normal, everyday phone calls.
The unspecified values, if ever used, are to have priority levels below
that of any given Precedence level or
value can preempt any "Routine"; none have been utilized to date [17].

The Precedence level levels authorized for a phone are set up for that circuit,
ensuring the user of that phone cannot use a lesser level or
value where network resources are already utilized. If these
call values above what they are equal, then other mechanisms, if any, can react
according to their individual capabilities (e.g. Call waiting).

One very important concept
authorized to keep in mind with anything here, gain access to.

4.2 MLPP Preemption

Preemption is that if network bandwidth or the seizing of otherwise used resources of one or trunks have the
capacity more calls
in order to complete the call, it doesn't matter what the
priority another call in a congestion situation. This is
determined by EOS's or TN's evaluating or comparing the Precedence levels
of *any* call, each will get treated equally.

Key concept: Unless all existing calls outbound on a circuit or a trunk, upon a time of
congestion or no other resources are at their respective maximum
somewhere in the network, available on that same interface, with
the Priority level any
call has doesn't matter in the least.

Preemption can take one of two forms. First, the called party
may next inbound call (set-up) intended to egress that same
interface. One or more resources can be busy with cleared for a lower Precedence higher precedence
level call, ensuring that call which must be pre-
empted in favor the newly available resources.

There are two modes of Preemption: preemption of completing the incoming called device with
another inbound higher Precedence precedence call from the calling party. Second, (Access Preemption), and preemption
within the network resources
somewhere in between the calling and called not involving either party may be satur-
ated with some combination of the preempted call sessions at
all, but at a point of lower Precedence
requested by the calling party and other traffic (data). If the
data traffic congestion (Network Preemption).

MLPP is of some lower priority level (perhaps mandated as having influence with a lower
DSCP value[4]), it should receive less priority single domain based imple-
mentation only . The precedence value set in order one MLPP Domain SHOULD NOT
cross Domain boundaries into another domain and have any preferential
treatment applied to
allow that call. The MLPP Domain-Identifier was included
for this higher priority reason into the ISDN signaling for MLPP service. MLPP compliant
Tandems (TN's) are to look at the Precedence level set within the call session
set-up signaling as well as the domain identifier within that same call
set-up to seize outbound
resources. If there is still not enough available outbound
interface resources, then ensure validity within that network. This prevented leaking of
one or more domain's call behavior into another's. In other words, no preemption
of the lower Precedence
calls any resources shall be preempted to complete occur within a domain as a result of a call into
that domain from outside the higher Precedence call.

There domain, even if both domains are MLPP
compliant networks;

Here are the three characteristics of preemption:

a) Any party whose connection was preempted (whether that
resource was reused or not) shall receive a preemption conditions:

o A distinctive
audible notification. An addition preemption notification can (tone) shall be
provided via some visual indication if possible introduced
into any connection(s) that is to be cleared due to either a Access
or
desirable;

b) Any called network Preemption event;

o The party on the inbound end of an active call that is being pre-
empted by a higher Precedence preempting call shall be required to MUST acknowledge the preemption
that inbound call before being connected connection to
the new calling party, and

c) When there are that call;

o Upon determination of no idle resources, preemption available resources and calls existing on
an interface of lower precedence, the lowest of these lower level Precedence resources shall
occur;

Any call(s) MUST be
cleared in order to complete the higher precedence call;

A call session can be preempted anytime at any time after the Precedence
value precedence level has been established for a
determined to be lower than the existing call and before call clearing has
begun.

If there is a user or IP Voice device that is configured
(somehow compliant with the parameters However, no preemption of any resources shall occur within that
Administrative Domain (AD), and outside the scope a domain
as a result of this
document) to disable the ability to be preempted, a call into that user or
IP Voice phone device will domain from not experience preemption of calls by originating in that
domain, even if both domains are MLPP compliant networks.

A clarification must be stated: higher precedence calls, if the cause provides preferential
call handling throughout an MLPP domain, regardless of preemption would be due
to called party busy condition (e.g. how much higher a
call waiting is enacted
here). However, the user may still experience preemption of
calls due relative to others. For example, a lack of network resources other "Routine" call is equally lower
in precedence level than "Priority", "Immediate", "Flash" and "Flash
Override" as far as preferential treatment in the user's
own access resources [1].

Precedence network is concern.

Having stated that, currently there is no recognized/Standardized method
or mechanism in the case of which one of several lower precedence calls
gets disconnected, where such a condition exists. Only such that the
lowest level gets disconnected first. But if there are not responded more than one such
lower level call existing at a congested interface and a higher precedence
call comes through, determining which lowest level call gets preempted
first is left to by the called party
(e.g. the called party chooses implementer.

An example, if there is a saturated interface with 6 equal bandwidth
connections existing, 1 "Flash" call, 1 "Immediate" and 4 "Routine" calls,
when another "Flash" level attempts to hang up their phone without
taking the call) may have their phone speaker initialized for gain resources out that inbound Precedence interface;
if that new "Flash" call in order to complete is the call;
sometimes regardless if this called party wants same bandwidth as the Precedence
call [1]. An alternative to others (all are
equal in this approach could be to have an
'alternate called party' signaled (e.g. that person's admini-
strator). This mechanism would be situation), then a per Domain decision.

An MLPP call session should automatically be set up with "Routine" is preempted, being the lowest precedence level by default, until the user chooses a
level on that interface. Which one is up to their maximum allowed within that Domain.

3.0 Requirements for MLPP in an IP Infrastructure

Since vendor's product
algorithm. MoIP might want to standardize this mechanism for consistency.

Who the preemption picks to get whacked is not currently a Working Group item from any WG in defined within the IETF, this effort (right now) will not go through
requirements. So it's up to the
process implementers. My thought of a WG in the defining of Requirements first and attain
consensus stateful
timer assigned to each interface that picks either who is on those before proceeding. Hence, this section deals
with the requirements of lowest
level the shortest or longest gets it.

MLPP as I see them now. There could
very well be more, that I am more than open to comment on this
effort from my peers to that end, [1] also established the Alternative Party, and possible inclusion in the
next version of this I-D.

Actually, this draft doesn't have Non-Preemptable
Resources options. The Alternative Party option is a known home (email reflector)
for discussion within the IETF either, and I'd like pre-configured to
that phone-line secondary phone to be
solved by ring in the London meeting. There has been some talk about
placing this along with times where the IEPS efforts of Hal Folts [5] - and
that's certainly possible. That first phone
is being used. This can prevent a worthy effort, and fairly
similar in scope and architecture and complexity.

And to make matter worse, I think it's questionable whether preemption event, even when that new
inbound MLPP
should *only* be written for Voice Communications over call is of higher precedence. The Alternative Party must
answer before the long
run. I see Timer T sub K expires. Additionally, a party of a phone
can preset their phone with the great need to have it focus presently on Voice
sessions (calls), option of 'Non-Preemptable Resources'.
This prevents Access Preemption events, but this should apply to anything that's RTP
based at least, which is does not just voice. And then in the future
when authentication can prevent Network
Preemption events.

The Alternative Party redirect MUST be verifiable to a list of applications valid domain address and Protocols within a IP-Managed network domain, is
RECOMMENDED to them a location which always answers the phone, such as
well (but not yet). Therefore, I believe these requirements
shall be written with Voice as an application in mind,
discussions of this draft should also focus on what should be
included, a
operator or removed, for other applications to take advantage ACD pool of Priority and Preemption.

I will simply put personnel. An additional benefit to the requirements for MLPP over IP in bullet
form Timer T
sub K is that it prevents indefinite diversions when it expires for a
call. The example below give this version mechanism more clarity.

4.2.1 Access Preemption Event

The following is an example of the ID MLPP mandated process for Access-based
Preemption events occur, similar to a flow chart:

Scenario #1: Caller A and categorize them D are on an MLPP call when Caller C calls D

If there is an existing call between two parties (A & D), and a third
party (C) calls into areas D (provided there is no congestion between C & D),
D (at the EOS) first checks the Precedence of scope this new inbound call. If
the Precedence value is equal to or functionality. Keep in mind less than that these requirements
must be adhered to by all devices within of the existing call
between D & A, then C either is returned a single, IP-Managed
Domain in order Disconnect (user busy), or is
diverted to function properly.

3.1 General Priority Requirements

o ANSI T.619-1992 states an alternate party (another phone) if there is one speci-
fied; C is Disconnect (Precedence Call Blocked indication) if one isn't
specified.

If the 5 levels of Precedence (or
Priority) for MLPP networks as call from C has a greater Precedence value than the following:

bits Name
---- ----
0000 "Flash Override" (0)
0001 "Flash" (1)
0010 "Immediate" (2)
0011 "Priority" (3)
0100 "Routine" (4)

0101 A to
1111 "Spare"

There are actually 16 values/levels possible within the ANSI
spec, but any additional levels will have D
call, then a preemption func-
tionality below, or less than, "Routine". The intent determination is that
"Flash Override" made at D (at the EOS) whether D is always
Preemptable. If D is not Preemptable, then an alternate party is looked
for. If there is identified, the highest level capable within call is diverted. If it is not, C is
returned a MLPP-compliant network.

Where ANS.1/binary coding occurs, there must be 4 bits given
to MLPP Prioritization as shown above where 0000 Disconnect (Not Equipped for Preemption). If D is Preempt-
able, the
highest Priority level user and 16 device of D is notified. So is the lowest. This doesn't
match Device A. The
device at D is offered with Call Setup information, while also starting
the TOS or Diffserv bit mapping, so this must be done
somewhere else T sub K timer (defined as being between 4-30 seconds). A Disconnect
is sent to A now, placing it in the packet (of every packet).

Where text coding occurs, Idle state for at least the names associated with moment.
The device at D is waiting for the 5
level user at D to determine 1 of Priority must match 3
possible paths to take:

Path #1 is when nothing occurs until the above order with "Flash
Override" being T sub K timer expires. This
results in a determination if an alternate party was specified by D. If
there is, C is then connected to this alternate party. If not, C's call
is normally set-up into D.

Path #2 is if there is a request from C to Clear the highest, call. This results
in A, C, and "Routine" D being idle now.

Path #3 is when D acknowledges the lowest
known one used.

I acknowledge right now I'm not a coder, BTW.

o It inbound Preemption by C, thereby
accepting the call from C. This stops the T sub K timer. The Call is unclear if this infrastructure should apply
set-up between C to
Instant messaging D.

4.2.2 Network Preemption Event

The following is an example of the MLPP mandated process for Priority yet, but it likely will at
some point

3.2 General Network-based
Preemption Requirements

o Any party whose connection was preempted (whether that
resource was reused or not) shall receive events occur, similar to a distinctive
audible notification [1]. An addition notification can be
provided via some visual indication if possible or
desirable;

o Any called party of flow chart:

Scenario #2: Caller A and B are on an active MLPP call that is being pre-
empted by when Caller C initiates
a higher Precedence precedence call shall be required to
acknowledge the preemption before being connected Caller D

If there is an existing MLPP call between two parties (A & B), and an
unrelated MLPP call to either A or B has a higher Precedence level than
the new calling party,

o When A-B call, the network first checks to see if there are no idle resources, preemption of available
resources for that new call; if there is, everything works as if both
calls were on the
lowest of these lower level same Precedence resources shall
occur;

o How to chose which established session, amongst level with no congestion. But if there
is congestion at any common interface between the probable
many calls A to B and C to
D, there is now a search at that traverse an interface experiencing congestion, for Preemptable resources. If
there is
to be terminated when not, a higher Priority session determination is initiated
through an internetworking device made whether the Call from C is likely a topic needing
discussion. I would vote for
Precedence call. If the session that has existed call from C is not, C is returned from the longest through that interface, meaning per session
timers must be kept either within
network a "Disconnect: Network Resources Unavailable" indication. If the internetworking device
(in COPS [6],
call from C is a Precedence Call, C is returned a "Disconnect:
Precedence Call Blocked" indication. The call remains between A and B
through both cases.

If, however, there are preemptable resources available at the PEP) or shared
interface for calls A-B and C-D, with C-D having a higher Precedence
level than A-B, now A is notified of Preemption (without knowing where
from). At the server/node making same time B is notified of Preemption (also without
knowing where from. The network now releases (disconnects) the policy
decisions for that internetworking device (in COPS [6], amount of
resources in order to have the
PDP, which could C-D call be co-located and is allowed set-up normally.

Under this Network Preemption scenario within MLPP, the amount of
resources necessary for in that
RFC)

o If this call C-D, even if it requires more than one session must be preempted in order
other call to allow
that new high priority session through a congested network
interface, this must be allowed preempted, MUST be made to occur on satisfy the higher precedence
call completion. All necessary lower Precedence level resources MUST be
cleared for any inter-
networking interface within this higher Precedence Call.

4.3 MLPP domain

o Discussion Feature Scenarios

4.3.1 Bearer Services Supported

MLPP [1] is needed to determine if Voice (and possibly
Video) session should be allowed applicable to drown out or starve all
other types the following circuit-mode bearer services:

o Speech
o 3.1kHz audio (video-band data), and
o 64kbps unrestricted data

4.3.2 Commonalities of traffic through any congested network
interface. Interest

The Diffserv WG had similar discussions and I
don't know if an outcome was chosen. Conventional wisdom has Commonalities of Interest (COI) scenario is a configuration within the
MLPP Domain such that a limited amount group of the bandwidth through any interface for
any one application users primarily call each other,
and few others. This group shall have enhanced or Protocol, but that is absolutely reduced treatment of
call attempts within their assigned group. This configuration has the
choice for each domain.

o It of optionally allowing Higher Precedence calls specifically to
another within the group, or this capability is unclear if not allow. Call detail
recording shall record all Precedence call attempts from this infrastructure should apply to Instant
messaging for Preemption yet, but it likely will at some
point

3.3 End Station Requirements type of
group.

4.3.3 Conferences Preset

This section includes the IP devices that start is a preset configured list of attendees to a conference bridge
identified by the MLPP-enabled
communication (IP phones, PC's, Handheld's number and key dialed at the like�)

o Ability originator's station. All
EN, EOS, MFS shall be capable of the End Station to generate RTP sessions simultaneously having 10 such conferences
with
all up to 20 configured endstations for each conference. The ability to
add up to 5 MLPP Priority levels in the Packet headers, whether
that's self signalled (like would be additional participants utilizing Hook-Flash by the case in SIP), or
determined from another Node on initiator
of the network (Server or Media
Gateway Controller) for conference is permitted as well. Each conference shall have a defined Standard (MEGACO [7]) or
Proprietary Control Protocol;

I don't know if
Precedence level set by the initial Priority originator of that conference bridge.
Preemption shall occur as already specified � meaning, conferences bridges
do not get preferential treatment beyond the precedence level should be the bridge
is set to
"Routine" to.

A special condition exists within this functionality, if the originator of
a conference is preempted, the preempt tone occurs for two seconds to all users
attendees, and have them individually raise then the
level within what they are authorized bridge is disconnected to set all. This includes those
who were not, under other condition, subject to if they need to,
or if this aspect is more network controlled a preemption event.

5.0 MoIP Requirements and solutions

Based on logon the previous sections, requirements for what is mandatory and
authentication
optional in any network to be MLPP compliant, here is an overview of the network,
technologies that the IETF offers. What will be mentioned are how certain
protocols shall and shall not be utilized to satisfy the MLPP require-
ments.

Although this is an Informational-Track document defining an Architecture,
this section shall be written as if it was a Standards Track document with
all the associated RFC2119 language mandating this SHALL occur, that user's profile within SHALL
NOT occur, and RECOMMENDED practices that domain controls each, or at least are highly desirable if imple-
mented. This should give the default Priority
level. Discussion on reader a sense of the tone of this should occur to reach consensus.

o Ability to differentiate users Archi-
tecture and allow each user's access
only what is needed to those priority levels they are authorized ensure it is as close to compliance as
possible to
initiate per session (in the current MLPP-ISDN networks, the
level intent of Priority MLPP.

Because MLPP is determined by, principally a symmetrical natured transport, meaning that
traffic is bi-directional and only by, typically almost identical in the color number of the phone; which
packets traveling each direction, this document is for unicast traffic
only. Multicast traffic in MoIP is hardwired to be defined at a PBX interface that later date once the
case and need is
configured at presented to this document's author or if by chance this
effort moves into a certain single MLPP Prioritization level)

o The Preemption audible tone WG, and generator stipulated in [1]
must it becomes subject to that WG's consensus
charter and directions.

MoIP can be built/written broken into each end station

3.4 End user Requirements

This section includes the people themselves that are placing the
Voice (and possibly Video) call sessions for now, but will
likely include the automated initiation several areas of sessions by non-
humanoids soon ;-) But this could fall under whether IM
receives this applicability interest or specialization from
an IETF perspective: Header Marking, Routing, Signaling and/or Call
Control, and Media. A logical migration of MLPP.

o Ability MLPP into MoIP is migrate
towards multimedia communications, while maintaining more or less a
symmetrical communication service in nature. In other words, although now
to uniquely identify themselves include video, it shouldn't yet take on single-directional broadcasts
of a video feed, whether live or recorded. A possibility comes to the MLPP enabled
network mind in order
High Priority announcements to be granted a select few receivers. But this likely
would include multicast transmissions as well, and that is outside the priority choices (this
quickly gets into
scope of this document in its current intent.

Without losing focus on MLPP � that Standard [1&2] specifies two basic
features for a communications session within a compliant Domain:

o Setting the Security aspects discussed below)

3.5 Internetworking Device Requirements

This section includes Layer 2 & 3 switches, Routers Precedence level of each session upon
initiation of that session, and Servers:

o Monitor all Recognizing congested interfaces within each internetworking device
for congestion and resource allocation preempting
traffic for higher precedence traffic

5.1 Setting Priority to an MoIP Session

Presently there are three IETF-based mechanisms for Signaling or
Controlling the Precedence/Priority end-to-end:

o Appropriately self regulate all congestion interfaces
similar SIP (Standard)
o MEGACO (Standard)
o MGCP (Informational only)

Presently there exist two IETF-based mechanisms to set (not signal)
Priority to COPS configurations [6] in which a individual
internetworking device makes decisions either locally (it is
both communications stream from end-to-end � with one more
potentially coming:

o Diffserv [3]
o RSVP [10]
o Potentially coming from the PEP and PDP IETF: NSIS
o others at layer 2

An additional mechanism exists for propagating preferential treatment of
Packet flows, but more in a scenario core-type environment: MPLS

5.2 SDP in MoIP

The extension of this protocol doesn't augment any function specifically
for MoIP. This is specifically for session capabilities exchange nego-
tiation. A domain is either MoIP compliant or as a rule within that
network), to utilizes not. Little is negotiated,
especially at the COPS level.

5.3 SIP in MoIP

The Session Initiation Protocol (SIP) [6] "is an application-layer control
(signaling) protocol for communication creating, modifying and terminating sessions with
one or more participants. These sessions include Internet multimedia
conferences, Internet telephone calls and multimedia distribution."

As a COPS Server Signaling Protocol, this is an ideal candidate for specific traffic instructions down to conveying the session
Precedence level

o When an MLPP session preempts another MLPP session on an
internetworking device, and that internetworking device is
not directly attached from the Calling party to any of the 3 Called party. In SIP
language, one UA includes a Request, General or 4 end users of
either session, it must signal Requires Header-Field in
the end stations initial INVITE message to that were
preempted notifying them of second (or more) UA(s). The existing
Priority Header-Field is for receiver information only, so a new header-
Field is needed. This header-Field can't be a Requires Header-Field, as
SIP UA's will call outside the occurrence(I'm MoIP domain, and this header-Field might
not sure what
Protocol should be used here, but SNMP could be utilized
even if authentication supported, causing either an error or confusion. Either of which is necessary, although its
modification might
not good for successful communications. It can be necessary via an ID)

3.6 Media Gateway (MG) Requirements either a Request Header-
Field with a Response Header-Field returned from the far-end UA, or a
General Header-Field, in which the far-end UA replicates the Header-Field
in the reply.

An Internet Draft has been submitted for this new Header-Field called
Resource Priority Header [15]. This section includes Media Gateways that are ID is not end stations a WG item within the SIP
(it was just submitted). However, it matches the RFC 791 [5] and MLPP infrastructure, but translate either from IP
Precedence levels with one additional level: "Critical/Emergency Call
Priority" (CRITIC/ECP), which is in [5]. This new level is specifically
for situations such as 9/11/01 for Government level Emergency Preparedness
and Response [16]. However, no MoIP users shall have the ability to
some TDM infrastructure (ISDN could mean another MLPP network,
PSTN TDN means from access
this higher CRITIC/ECP level unless they go through the procedures that
all other authorized personnel do when access this Preferential communi-
cations service. The network treatment of such a non-MLPP network):

o If communication set-up is
outside the MG scope of this document for now.

This new ID is connected between an IP-based MLPP network and specifically written loosely for wide appeal. Here, once
that document becomes a non-MLPP network, Working Group Item officially (then RFC) it must set shall
have much more stringent language here to strengthen what it will do in
MoIP domains. More on this is coming versions of both documents.

Under the Priority SIP Signaling model for MoIP communications, the Proxy Servers
[6] SHOULD be the policers or filters of the SIP signaling packets within
the MoIP domain. Redirect Servers [6] can also perform this function.

It's unclear in the MoIP domain whether SIP Registrar Servers [6] will
have as much control as most believe. Registrar Servers aren't required in
order to "Routine" have SIP communications. Their intent was originally for Mobil-
ity, but that incoming call (unless someone clever creates has was a way lost belief in the SIP community for that user quite some
time, until recently when Dean Willis stated that, as WG Co-Chair, the
Registrar Server ought to uniquely identify themselves be renamed to an IP-MLPP
device be clearer to its intent from
inception of SIP. Again, further revisions of this document will have
updates to this sub-item.

Just as with MLPP, it's true with MoIP using SIP: Precedence levels are
set at session initiation and allows CANNOT be altered during a session. Addi-
tionally, the last Precedence level requested for a session does NOT reset
the UA's default to receive higher Priority;
comments here that new level � the Precedence level MUST start at
default without user intervention at "Routine".

The exceptions within the IP world are again welcome)

o If obviously when taking advantage of
what the MG circuit-switched world can't do: Determine who is connected to a known and trusted MLPP-enabled
network (in either direction and determination which making the
session request. Modern user authentication mechanisms can verify who is
outside of
making the current scope call or information transfer. In such cases, with MoIP domain
administrator's permission, the default Precedence level should be allowed
to be user authorized and selected. Future versions of this document), let the
Priority document will
likely have this topic broken out into its own section for thorough
analysis.

SIP UA's MUST allow Access Preemption to occur in MoIP networks. Addi-
tionally, SIP MUST implement Alternative Party redirect (REFER Method);
but this might be one option of the calling party continue (unless your network
has many ways of doing this function.

Conference Bridge Applications could be accomplished through a policy Proxy
initiated INVITE to do something different all parties of that bridge. The list of attendees
could be dynamically set up with a Third Party interface into that Proxy
Server, with the incoming
call request, Precedence level of course)

An example all sessions set at that time prior,
and by an authenticated originator. A mixer can also receive an INVITE for
voice mixing instead of having a UA end device do all this case function.

5.4 MEGACO in MoIP

MEGACO as defined in [9] is a Media Gateway Control Protocol. It consists
of two major parts: Media Gateways (MG) and the transition Media Gateway Controller
(MGC).

Media Gateways translate signals from one type of an MLPP enabled
ISDN network to that another type
of an MLPP enabled IP network. With these
existing networks Both interfaces don't know about the other. In fact, the Gate-
way makes the experience such that both end devices don't know they�re
communicating outside of their native protocol, whatever that might be:
IP, TDM, Audio, Carrier wave, Analog circuitry, ISDN, Digital Trunks, RF
frequency... anything to anything, as long as that Gateway is built for
that.

Media Gateway Controllers control the Media Gateways. The intention of
MEGACO (and MGCP, which is the next section) is to have fair dumb end-
stations and very smart Servers being the size they are, there will be brains for those endstations,
or Terminations.

MEGACO has 8 Primitives or commands:

Add: Adds a mi-
gration from one infrastructure type termination (an endpoint)
Modify: Modifies the properties of a termination
Subtract: Subtracts or disconnects a termination
Move: Moves a termination to another context
AuditValue: Returns the other, maybe not
completely getting ride current values of properties, events,
signals and statistics
AuditCapabilities: Returns the ISDN network for quite some time,
if ever.

There are several other examples possible values of MG networking scenarios, but
I won't list them all here just yet. Suffice properties,
events, signals and statistics
Notify: Allows the media gateway to say, notify the MGC of events
within MG
ServiceChange: Allows MG to inform MGC it is
either going in your network from the IP network to an ISDN network
(which may or may not out
of service

MEGACO MUST allow Access Preemption to occur in MoIP networks. Addi-
tionally, MEGACO MUST implement Alternative Party redirect; but this
might be MLPP enabled) or PSTN point one option of view,
and is either connected many ways of doing this function.

Conference Bridge Applications could be accomplished through the MGC to
all parties of that bridge. The list of attendees and the DSP doing the
mixing could be dynamically set up with a trusted side Third Party interface into that
MGC, with the Precedence level of all sessions set at that time prior, and
by an untrusted side
(as authenticated originator (maybe through a Web interface app).

Further investigation is likely the case in connection needed to any network not MLPP
enabled), or both sides are trusted either in a transition mode,
or through an SLA interconnection. Updated versions of this ID can
have any example of infrastructures interconnectivity ensure MEGACO has the existing mecha-
nisms for simplicity MoIP.

5.5 MGCP for MoIP

MGCP [8] is also a Media Gateway Control Protocol, but one that isn't
Standardized within the IETF, or as anywhere. It is, however, deployed in a
wide range of vendor solutions � significantly more firm example if necessary.

3.7 General Security Requirements

o so than MEGACO. This
is an somewhat ambiguous requirement for as much to do with the
authentication and authorization timing of all End users, this is
likely network specific the Protocol � it was first to some external form the
field, by more than a year. That kind of
authentication such as a SmartCard head start in the VoIP
intensive explosion we�re just starting can put a protocol out in the
market lead for a long time as a Defacto Standard.

MGCP is rooted in the *trusted*
identification combination of each authorized user, granting them access
to resources IPDC from Level 3 Corporation and
SGCP from Bellcore. It has 8 primitives as well as MLPP Priority levels MEGACO:

EndpointConfiguration (EPCF): Instructs gateway about coding char-
acteristics of 'line-side' of the endpoint
NotificationRequest (RQNT): Instructs the Gateway to watch for
specific events
Notify (NTFY): Inform CA when requested events occur
CreateConnection (CRCX): Create a connection to an "Endpoint" inside
the Gateway
ModifyConnection (MDCX): Change the parameters associated with an
established connection
DeleteConnection (DLCX): Delete an existing connection�Ack returns
call
sessions

4.0 IP Infrastructure

Obviously, if [1] statistics
AuditEndPoint (AUEP) and AuditConnection (AUCX): Audit the status of
an "endpoint" and any connections associated
RestartInProgresss (RSIP): Notifies the CA an endpoint (or group of
endpoints) is taken out of service
MGCP MUST allow Access Preemption to occur in MoIP networks. Addi-
tionally, MGCP MUST implement Alternative Party redirect; but this
might be adhered one option of many ways of doing this function.

Conference Bridge Applications could be accomplished through the MGC to but in an IP infra-
structure,
all parties of that bridge. The list of attendees and even in the DSP doing the
mixing could be dynamically set up with a transitionary network (one Third Party interface into that
MGC, with the Precedence level of all sessions set at that time prior, and
by an authenticated originator (maybe through a Web interface app).

Further investigation is
migrating from ISDN enabled needed to IP enabled MLPP), ensure MGCP has the existing mechanisms
for MoIP.

5.6 Differentiated Services in MoIP

[3] was created to provide this in a packet forwarding mode. This involved
creating a lot new function by obsoleting the first 6 bits of
aspects the old Type of how RTP sessions (principally Voice) over IP will
require sometimes significant changes
Service Byte in how networks the IPv4 Header [5]. This new function focused purely on
the Router's forwarding queue and defining behaviors for packets marked a
certain way (with a certain value), and leaving other packet mark values
up to the local administrator to determine the behavior through that
administrator's infrastructure. That's the rub with Diffserv as a primary
mechanism for Precedence level marking of packets in MoIP. [3] states
clearly that packets are
currently configured. Some marked at the edge of these changes will require
Standards to be modified boundary of a Diffserv
Domain with what those authors called an Edge Router. If properly policed,
this ensured proper forwarding and new code to traffic engineering within that domain.
Diffserv has no session awareness, so Preemption of an entire session
would be written from those
Standards into some or clearly impossible based solely on this packet marking mechanism.
Diffserv should be utilized in packet forwarding, but another problem
arises when any packet leaves domain � it gets remarked by that next
domain's Edge Routers. This occurs at will and often today.

Current practice has most implementers of existing network devices VoIP utilizing DSCP 101110 for
EF [12]. This mandates not packet shall precede an EF marked packet in order
to follow [1] to the letter.

Customers that I've talked to have not been willing (so far)
to give away any functionality
forwarding queue of a Router other than an other EF marked packet which
got into the queue before it. MoIP requires a distinction and a difference
in the treatment of packets from [1] one another by session, not application.
Diffserv prioritizes packets, not sessions, in fact has no session
awareness � therefore lack the preemption capability within their networks.
It gets more complicated it of while
using it.

Perhaps a well thought out AF [13] DSCP marking where GETS requirements are included
from [5], because that involves theoretically every phone nothing is marked
EF within the entire domain. This has tremendous potential due the drop
characteristics of the AF classes if thoroughly maintained and
phone line policed
within a domain � which will be daunting at best. AF has the ability to
drop packets in any of the US; 12 queues at predictable rates while not termi-
nating the sessions. Although AF wasn't intended to be used a 12 consecu-
tive queues, but that's for another ID as classes of up to deal with. 3 (AF11, AF12 and AF13 for
example). Below is a list the chart from [13] detailing the codepoint markings
and packet drop characteristics per class:

The RECOMMENDED values of topics the AF codepoints are as follows: AF11 = '
001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = '
010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = '
011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The
table below summarizes the recommended AF codepoint values.

Class 1 Class 2 Class 3 Class 4
+----------+----------+----------+----------+
Low Drop Prec | 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec | 001110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+

The AF groupings AF1X, AF2X, AF3X and AF4X are separate classes that need discussing are
not defined to in order relative to change/
modify/extend/enhance existing IETF Specifications each other. The behavior or treatment
definition is within each class.

Two AF classes could be used within a single MoIP Domain that MUST NOT
have EF marked for Multimedia can appropriately build a L3 MoIP behavior
within a Single Building, Campus or Base. Mapping this AF Behavior
Aggregate (AF BA) properly to enable MLPP
in IP networks. I believe MPLS Label Switch Path (LSP) could extend
this list will get longer with time and
discussion and more detailed Preferential Treatment functionality desired in nature.

o Within MoIP on a wider scale
[28]. The AF DSCP value MUST be set by the Precedence level Request within
the IETF for Signaling Protocols and Media Gateway
Control Protocols, SIP & MEGACO are affected INVITE with the Resource Header, or conveyed by this effort.
Each the MGC in either
MEGACO or MGCP.

In VoIP, but not data transfers, packets can be dropped without loosing a
session, and the degradation will have to (for increase as the strict MLPP compliance) modify
their respective headers to include congestion gets worse,
but the 5 levels stipulated
in 3.1

o RSVP [8] session will stay up with more like bad Cell phone quality instead
of Toll Quality. If communications is important and quality not mandatory so import-
ant, this is a viable option if the session awareness is solved for MLPP, full
preemption in cases of need.

Filtering out EF at layer 3 is harsh and ugly, but might be necessary in a
complementary role with other mechanisms and protocols in MoIP.

5.7 RSVP in MoIP

RSVP [10] in concept has most of what MoIP requires, but few are adopting
it is in the only
bandwidth aware IP Protocol within end device. The end device determines the IETF that can handle
RTP streams that I'm aware of. Without this virtual session
created by RSVP, I'm at bandwidth necessary
for a loss now as bi-directional communication stream and sends a PATH packet out to how any inter-
networking
the destination device will be able to differentiate one RTP
session from another, making Preemption virtually
impossible. Therefore, I believe RSVP

o COPS apparently isn't aware communicating with all supporting internetworking
devices along the way. The destination device would answer the request
packet with a RESV message, with the internetworking devices all along the
way clearing the bandwidth (if available) for end-to-end communications at
a fixed bandwidth. It has a policy co-worker, for lack of both endpoints a better way of an RTP
session, so it for signaling
putting it, in COPS or even making aware of Common Open Policy Service [11] with a defined
mechanism for Preemption occurrence is not yet likely possible

Problem with SIP priority policy element in [9] [25].

Most of the hits against RSVP are regarding Mobility (or lack of support
of), no End-to-Edge reservations and the bis draft [10] one consistent hit RSVP has taken
is that they
modified in the bis draft it's heavyweight nature of implementation. In other words, it's hard to go
code � especially in smaller devices like IP Phones which MoIP must
support. NSIS is supposed to 5 levels from 4, but the
5th level was placed at "less than normal", and doesn't coincide
with the MLPP 5 levels. This might not be a big deal new WG forming for this reason.

RSVP does lack one feature that's minimally utilized: Look ahead For Busy
(LFB) to ensure that a lot
people, but people running MLPP network mandate path between two devices is available for a call in
the existing 5
levels defined future.

5.8 NSIS in [1]. This MoIP

"Next Steps in Switching" is part of what [3] covers, along
with a additional Header-Field "MLPP Enabled", it provides proposed WG within the 5
MLPP levels due IETF to this inconsistency between the two requirements.
This also relieves the SIP WG for making potentially
solve some of the main effort deficiencies of that
WG responsible for complete incorporation RSVP while taking advantage of MLPP into every SIP
based product (at this point). I'm trying not to disrupt WG's as
much as possible.

This section should its
strengths. Many Internet Drafts exist already within that effort. [26]
references specifically RSVP and will have more substance to why it should be modified. More on this
effort will be in the next version of this I-D. But due draft
5.9 MPLS in MoIP

The MPLS concept assigns short fixed length labels to packets at the
ingress to time constraints and an
unforeseen event, this -00 version wasn't as fulfilling MPLS cloud to identify a Forwarding Equivalence Class (FEC)
[4]. This ingress is called a Label Switch Router. Throughout the MPLS
cloud or domain, the labels attached to packets are used to make for-
warding decisions [27].

"MPLS protection" is defined in [28] as
Because MPLS is path-oriented it shall
be can potentially provide faster and
more predictable protection and restoration capabilities in the near future. Comments will also (hopefully) substantially
add and clarify this I-D as it progresses.

5.0 IANA Considerations

This author doesn't believe there are any within this document
at this time.

6.0 Security Considerations

A wise person said once (OK, it was Dave Oran, one face
of our AD's,
and I'm paraphrasing): "End user Security topology changes than conventional hop by hop routed IP systems."

MPLS is not intended for real time sessions
never was that important until the effective a campus solution � which a Base would most
categorically fall into. The use of QoS (priori-
tization) could be realized". This effort is stipulating that
exactly that scenario and Architecture can be and is built in AF BA's mentioned previously, mapped
to the Packet world.

All arguments LSP's of MPLS at the ingress LSR, with whether Dave's statement is exactly correct
aside, I believe there MPLS Protection (above)
would at this time like provide the clearest solution for MoIP.

In MoIP where MPLS is utilized, a great amount FEC MUST be set up in all LSR's for each
Precedence level and the CRITIC/ECP level. This will allow proper mapping
of truth Precedence levels to this AF BA's (when chosen as well) within the campus or
Base infrastructure, and on to the MPLS Cloud in
concept. Every session between anyone can have all Bases in the
prioritization anyone wants, but until there core
of the DSN network that is an effective way
to preempt another's session, it's meaningless.

But on MoIP compliant. If the other hand, imagine (at least EF DSCP is utilized as
well, regardless of the reason, a separate LSP SHALL exist in all LSR's
for it as well.

If RSVP is utilized in the US) you Campus or Base level, [27] describes tunnels in
MPLS, which can be mapped to RSVP Paths from [29]. If such a case, all
packets could and should have the
ability to set your voice call into Ticketmaster to get priority
treatment EF DSCP.

5.10 RTP for all concert MoIP

Media Payload shall be provided with Real-Time Protocol [7] for voice,
video and sporting events tickets? Very few
would notice they had real-time collaboration. RTP requires little adjusting or
extending other than the possibility of marking the RTP Headers with the
matching precedence level that was Signaled by the Signaling or Control
Protocol exchange between end devices. An Internet Draft has been
introduced for this RTP extension [14] in the one's AVT WG. This ID also has the
6th Precedence Level CRITIC/ECP for the GETS communications Service [16].
Little else is evident that RTP needs to have their calls dropped
while waiting further support MoIP.

5.11 Gateway Requirements Regardless of Protocol

Regardless of the Signaling or Control Protocol used within the MoIP
Domain, IP-to-MLPP signaling MUST adhere to the MLPP requirements set
forth in [1,2,17,18,19] regardless of what L2 technology is utilized on hold, but it would still
either side or both. There will likely be a unfair treatment islands of MoIP connecting to
the existing MLPP network. This translation MUST be seamless to the
network traffic loads elements and unfair MUST be seamless to the person you just
preempted. users on either end of a
communications session/call.

This creates MUST include the need for some form transparent signaling of user authentication and
authorization. I don't think the major IP carriers are going Precedence level set on
one side of the Gateway to
evoke or enable MLPP the other side with no alterations when the
Gateway in their networks, but anywhere there is
Priority between MLPP and MoIP network. When the possibility of Preemption, Gateway is communi-
cating with a MOM-MLPP network, the MoIP administrator can chose what
ingress Precedence Level those calls should be set to. Default should be
"Routine"; but there needs might a certain dialed in circuit translates to be
some checks and balances.

On those closed boundary networks that enable a
certain Precedence Level situation.

6.0 IANA Considerations

There are no IANA considerations with this feature(s),
authentication and authorization is required in my opinion;
unless, that network document

7.0 Security Considerations

It's obvious when a mechanism is perfectly utilized for preempted one traffic engineered and there
can never be flow
over another, it has security considerations. However, this document is a situation where
combination document mandating the watchful control by Government hired
employees that are already overseeing an identical network resources can bottleneck in any way. Because, when enabled, concept � so
the transition to IP from a oversight position shouldn't be too different.
That said, misuse of preemption is a concern, even when limited to a
single interface domain, albeit a large one.

8.0 Changes since last version

Increased the requirements of MLPP network compliance.

Broke out the involved IETF Protocols for clarity and analysis of how
each function with regard to MoIP requirements.

Added MPLS for Domain Core analysis.

Added a Gateway Requirements section for the transition between MLPP and
MoIP networks.

Added the references to the Internet Drafts that
has too little resources can are currently active
attempting to extend which Protocols and likely will experience procedures are necessary for
enabling IP to meet the requirements of an MoIP network.

9.0 Acknowledgements

To Brian Rosen for encouragement and motivation. To Captain Gordon Bradley
(Can. AF) for his aid in gathering the information and scope of this
Preemption on that interface.

7.0
effort.

10.0 References

[1] ANSI specification ANSI T1.619-1992.

[2] ANSI specification ANSI T1.619A-1994.

[3] James RFC 2475 "An Architecture for Differentiated Service", S. Blake, D.
Black, M. Polk, "draft-polk-sip-mlpp-mapping-01.txt", IETF Carlson, E. Davies, Z. Wang, W. Weiss, December 1998

[4] V. Jacobson, K. Nichols, K. Poduri, "An Expedited
Forwarding PHB" RFC 2598, June 1999 3031 "Multiprotocol Label Switching Architecture", E. Rosen, D.
Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, January
2001

[5] H. Folts, H. Ohno, "draft-folts-ohno-ieps-considerations-
00.txt" IETF Internet Draft, June 2000 RFC 791 "Internet Protocol", J. Postel, Sept 1981

[6] D. Durham, RFC 2543, "SIP: Session Initiation Protocol", M. Handley, H.
Schulzrinne, E. Schooler, J. Boyle, R. Cohen, Rosenberg March 1999

[7] RFC 1889 "RTP: A Transport Protocol for Real-Time Applications", H.
Schulzrinne, S. Herzog, Casner, R. Rajan, Frederick, V. Jacobson, January 1996

[8] RFC 2705 "Media Gateway Control Protocol(MGCP) Version 1.0", M.
Arango, A.
Sastry, "The COPS (Common Open Policy Service) Protocol" Dugan, I. Elliott, C. Huitema, S. Pickett, October 1999

[9] RFC
2748 January 2000

[7] 3015 "MEGACO Protocol Version 1.0", F. Cuervo, N. Greene, A.
Rayhan, C. Huitema, B. Rosen, J. Segers, "Megaco Protocol Version 1.0", Request for Comments:
3015, November 2000

[8] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and
S. Jamin,

[10] RFC 2205 "Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, R. Ed. Braden, L. Zhang, S. Estrin, S. Herzog,
and S. Jamin, September 1997.

[9] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP:
Session Initiation

[11] RFC 2748 "The COPS (Common Open Policy Service) Protocol" D.
Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, January 2000

[12] RFC 2543, March 2598 "An Expedited Forwarding PHB" RFC 2598, V. Jacobson, K.
Nichols, K. Poduri, June 1999

[10] M. Handley,

[13] RFC 2597 "Assured Forwarding PHB Group", J. Heinanen, F. Baker, W.
Weiss, J. Wroclawski, June 1999

[14] "draft-polk-avt-rtpext-res-pri-00.txt" IETF Internet Draft, J. Polk,
November, 2001. Work in Progress

[15] "draft-polk-sip-resource-00.txt", J. Polk, H. Schulzrinne, E. Schooler, Schulzrinne IETF
Internet Draft, November, 2001. Work in Progress

[16] "Framework for supporting IEPS in IP telephony", K. Carlberg and
I. Brown, IETF Internet Draft, Oct. 2001. Work in Progress

[17] "Generic Switching Center Requirements" (GSCR), JIEO Technical
Report 8249, March 1997

[18] Defense Switched Network "Generic Switching Test Plan" (GSTP), June
1999

[19] ITU-T Recommendation Q.735.3 (1993), "Description for Community of
Interest Supplementary Services using SS7 - Multilevel precedence and
preemption"

[20] "draft-polk-mlpp-over-ip-00.txt", IETF Internet Draft, J. Rosenberg
"draft-ietf-sip-rfc2543bis-02" Polk, Feb
2001. Work in Progress

[21] ANSI T1.604-1990 "Integrated Services Digital Network (ISDN)"

[22] ANSI T1.113-1988 "Signaling System Number 7 (SS7) � ISDN User Part"

[23] ANSI T1.604-1990 "ISDN � Layer 3 Signaling Specification for
Circuit-Switched Bearer service for Digital Subscriber System Number 1
(DSS1)"

[24] ANSI T1.610-1990 "DSS1 � Generic Procedures for the Control of ISDN
Supplementary Services"

[25] RFC 3181 "Signaled Preemption Priority Policy Element" S. Herzog,
Oct 2001

[26] "draft-greis-rsvp-analysis-00.txt" IETF Internet Draft November 24,
2000

8.0 Draft, M. Greis,
Nov 2001. Work in Progress

[27] RFC 2702 "Requirements for Traffic Engineering Over MPLS", D.
Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, September 1999.
Work in Progress

[28] "draft-ietf-mpls-diff-ext-09.txt", F. Le Faucheur, L. Wu, B. Davie,
S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen, April, 2001.
Work in Progress

[29] "draft-ietf-mpls-rsvp-lsp-tunnel-09.txt", D. Awduche, L. Berger, D.
Gan, T. Li, V. Srinivasan, G. Swallow, August 2001. Work in Progress

11.0 Author Information

James M. Polk
Cisco Systems
18581 N. Dallas Parkway, Suite 100
Dallas, TX 75287
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
jmpolk@cisco.com

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 organi-
zations, 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 re-
voked 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."

The Expiration date for this Internet Draft is:

August 23rd, 2001

May 22nd, 2002