wdiff draft-polk-sip-mlpp-mapping-00.txt draft-polk-sip-mlpp-mapping-01.txt

Internet Draft James M. Polk
Expiration: September 8, 2000 2, 2001 Cisco Systems
File: draft-polk-sip-mlpp-mapping-00.txt draft-polk-sip-mlpp-mapping-01.txt

SIP Precedence mapping to Extension for MLPP Interworking

March 7, 2000 1, 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 Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents
as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.

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 an extension to the Session Initiation
Protocol [1] for direct interworking and interoperability with
TDM-based to allow SIP (and IP) into existing Voice Backbone
Infrastructures that require Multi-Level Precedence and Preemption Pre-
emption [2] Service
Capability throughout those networks. This document
will further include
details and similar mechanisms to evolve and/or replace
existing TDM-based also allow MLPP network topologies with networks that are ISDN-based now to evolve/
migrate or be replaced by a SIP-based Voice Signaling topologies network
with no loss in capability of capability. Al-
though that original network. More likely
is the case that additional mobility functionality and capabilities can easily
be realized such as mobility and reduced user headaches (ex-
plained later) with this complete topology architecture implemented.

The author believes SIP being MLPP enabled within a network
infrastructure.

I believe these additional Prioritization Precedence and Preemption capabilities capabili-
ties will have wider deployment benefits
without direct connectivity to than named MLPP
networks such as the US Government networks.

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2
Table of Contents. . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2.0 The need for this Extension vs. incorporation? . . . . . 3
2.1 Part of a bigger effort? . . . . . . . . . . . . . . . . 4
3.0 MLPP Overview. . . . . . . . . . . . . . . . . . . . . . 3
3.0 5
4.0 Objective of ANSI's MLPP specification . . . . . . . . . 4
4.0 6
5.0 Requisites from ANSI's MLPP Specification. . . . . . . . 4
5.0 7
6.0 Defined SIP Priority request-header field. . . . . . . . 6
6.0 Merging Priority Value Sets. 9
7.0 Request Header-Field:MLPP-Enabled Extension . . . . . .10
7.1 A subset of MLPP? . . . . . . . . . 7
7.0 . . . . . . . . . .11
8.0 Results of MLPP Extensions to SIP Priority Field . . . .11
9.0 Unknowns needing discussion still . 9
8.0 . . . . . . . . . .13
9.0 Changes from the last version . . . . . . . . . . . . .14
10.0 IANA Considerations . . . . . . . . . . . . . . . . . . 10
9.0 .14
11.0 Security Considerations. . . . . . . . . . . . . . . . . 10
10.0 .14
12.0 References. . . . . . . . . . . . . . . . . . . . . . . 11
11.0 15
13.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . 11
12.0 15
14.0 Author Information. . . . . . . . . . . . . . . . . . . 11 16
1.0 Introduction

This document describes an extension to the Session Initiation
Protocol [1] for direct interworking and interoperability with
TDM-based to allow SIP (and IP) into existing Voice Backbone
Infrastructures that require Multi-Level Precedence and Preemption (MLPP) Pre-
emption [2] Service Capability throughout those networks. This document
will further include
details and similar mechanisms to evolve and/or replace exist-
ing TDM-based also allow MLPP network topologies with networks that are ISDN-based now to evolve/
migrate or be replaced by a SIP-based Voice Signaling topologies network
with no loss in capability of capability; although addi-
tional mobility that original network. More likely
is the case that additional functionality and capabilities can easily
be realized such as mobility and reduced user headaches (ex-
plained later) with
this complete topology architecture implemented.

The author believes SIP being MLPP enabled within a network
infrastructure.

I believe these additional Prioritization Precedence and Pre-
emption capabilities Preemption capabili-
ties will have wider deployment benefits with-
out direct connectivity to than named MLPP net-
works such as the US Government networks.

2.0 The need for this Extension vs. incorporation?

As much as I believe this in this capability, I also believe it
should be necessarily a burden for all SIP developers to include.
Therefore, I believe this I-D should be a Standards Track WG
item, but separate for the core 2543bis effort such that those
vendors that wish to develop products into this fairly limited,
yet potentially very large segment, can merely be following
this I-D. I believe this will also help in the IETF Standarding
process of SIP by itself by not being included in the core
effort mandating (I believe) 3 completely interoperable solu-
tions for every feature and specification within the SIP I-D.

An additional reason for this maintaining its name is the
customer driven requirement and comfort-zone of MLPP itself.
An RFP can state fairly clearly that it requires adherence
to RFC-XXXX (SIP Ext. for MLPP) in its bidding between vendors.
This does make it quite a bit easier for that process as well.

I'm also aware of the desire to NOT include everything and the
kitchen sink in the core 2543bis effort.

SIP is, and is well put in [3], "not a PSTN replacement". And
any Priority or Preemption without government intervention is
not allowed (GETS [4] is the best example of this). "SIP is a
Protocol for initiating, modifying, and terminating interactive
sessions" from [3] as well. Which goes on to state the following
that applies directly:

" This process involves the discovery of users, (or more
generally, entities that can be communicated with,
including services, such as VM or translation devices)
wherever they may be located, so that a description of
the session can be delivered to the user."

Sometimes the Signaling for a session will take the same path
the RTP stream will, most times it will not. Although each will
likely take different paths, the specifics of the MLPP call
set-up such as which Precedence level is chosen by the user
needs to start with the calling or session initiating device.

Even though SIP is intended to traverse more than a single
network infrastructure in its creation, MLPP functionality like-
ly will not, but could on a limited basis where strict SLA's or
similar agreements are adhered to. Creating an Extension that is
basically intended for a single network is generally frowned
upon, and I understand. Additionally, extensions that define a
function's usefulness only if all devices support that extension
is also discouraged [3]. However, one of the networks that
requires MLPP adherence before considering IP-based anything
voice session initiation has currently more than 800 Class 5's
operating in that network. The migration to IP will difficult
at best for this one network that has such strict requirements,
and that is the reason for this Extension: adherence to strict
guidelines and capabilities in a "Standards way". I have talked
to a customer representing parts, to all of 19 country's
government networks that are mostly all waiting on MLPP to be
defined in IP in this Standarding Body before moving their
respective networks towards IP. So, the question that I pose to
you is this I-D:

2.1 Part of a bigger effort?

Yes, this I-D is part of a larger IETF effort. I have written an
I-D [5] that attempts to address the non-SIP requirements for
enabling MLPP into an IP network infrastructure. What I propose
here is just what SIP is intended to do: initiate the session
with certain features, capabilities and descriptions in that
session initiation. Relatively speaking, this is easier than
getting the network to behave in a deterministically Preemptive
mode to a customer's satisfaction. It gets more complicated with
inclusion of 'other' services. IM could become MLPP-enabled.
Video certainly could, but traffic engineering then becomes a
problem due to its bandwidth requirements.

Another effort was started at the Pittsburgh meeting, IEPS [4].
It has been suggested that this MLPP effort is the logical pre-
cursor to the IEPS effort. Section 1.2.1 of [4] refers to another
type of PSTN requirement, GETS (Government Emergency Telephone
Service). MLPP could be used as a basis for that requirement
with some user authentication enhancements.

3.0 MLPP Overview

Multi level Precedence and Preemption [2] Service Capability
stipulates a relative priority ranking order of Call flows
on a hop-by-hop basis through a Voice Network from their
relative beginning Voice device to the end Voice device.
Within the TDM world, these call flows were closed network
circuit switched from PBX or Tandem Switch to PBX or Tandem
Switch. Each Switch, upon initiation of a higher priority call
flow where there were not available outbound resources or
trunks, preempted a lesser priority call flow by seizing the
resources of an existing external truck circuit to satisfy
that higher Priority Call. Eliminating the previous call with-
out giving either end station a choice or chance to continue
the call flow of the overridden call. Typically, an audible
tone [defined in 2] occurred on the inbound caller's phone
receiving the Preempting call flow.

By contrast, in a Packetized Voice Network, there will likely
not be fixed or pre-configured outbound circuits waiting for
higher priority call flows to occur on a per-MLPP-enabled IP
Internetworking device basis. This presents a more challenging
problem of preemption in a less statically configured Network
Topology.

SIP per [1] created a Priority Header-Field "Header-Field:Priority" as a non-mandatory
field within the signaling set-up. This document recommends set-up (section 6.0 shows this). The
2543bis I-D [7] added a single Priority Header-Field that is and
for less than normal traffic. Although this capability be included in all implementations of SIP
devices, even if creates 5 distinct
Priority levels, it does not enabled. Further, this document recommends satisfy the ability MLPP semantics require-
ments of 5 levels with normal traffic (called 'Routine' by [2])
at the lowest Priority or Precedence level, escalating to make the Header-Field "Priority:" mandatory
within an Administrator's Domain if they choose, for all SIP
based call signaling devices. In this scenario, a SIP device
that doesn't have
highest Priority or Precedence level (called ' Flash Override' in
[2]). All this value present will be denied access to is explained in more detail on the invite request.

3.0 next page in
section 4.0.

4.0 Objective of ANSI's MLPP Specification

The MLPP concept was created so that there was a real-time
method of prioritizing voice communications. It was created
back before electronic switching in the U.S. Government
"AUTOVON" network. It is designed so that normal telephone
traffic would not cause problems in the event of a crisis.

Here is an example using Military Rank as a conceptual com-
parison:

The lowest level, ROUTINE, would be used for all normal call
traffic. If a Company commander needed 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 PRI-
ORITY and potentially the IMMEDIATE precedence levels. The
field grade traffic (brigade, battalion, and division) would
use the IMMEDIATE, and in some cases FLASH precedence levels.
Communications within the Corps and Theater commanders would
use FLASH. The President, the Joint Chiefs, and some select
theater commanders (e.g. CICNORAD, or CICSAC) would use the
FLASH OVERRIDE precedence. This guaranteed (in theory) that
the most important commands (the President forbidding nuclear
launch) would get through even over all other traffic.

This pre-grading of relative importance is to a method of assigning maximum
levels of session is how an
authorized user can assign the appropriate priority to traffic
based on user that user's Profile (e.g. within what they are authorized auth-
orized to do). assign a session to). Someone who was authorized to
use IMMEDIATE precedence would normally use ROUTINE unless there
was a legitimate reason to escalate the precedence to a higher
level.

4.0

5.0 Requisites from ANSI's MLPP Specification [2]

ANSI T.619-1992 states the 5 levels of Precedence (or Priority)
for MLPP networks as the following:

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

0101 to
1111 "Spare"

There are actually 16 values/levels possible within this spec,
but any additional levels will have a preemption Preemption functionality
below, or less than, "Routine". The intent is that "Flash
Override" is always the highest level capable within a MLPP-
compliant network.

In any case, a call session of any given Precedence level or
value can preempt any Precedence level of a lesser level or
value. If these values are equal, then other mechanisms, if
any, can react according to their individual capabilities
(e.g. Call waiting).

Preemption can take one of two forms. First, the called party
may be busy with a lower Precedence call which must be pre-
empted in favor of completing the incoming higher Precedence
call from the calling party. Second, the network resources
somewhere in between the calling and called party may be satur-
ated with some combination of call sessions of lower Precedence
requested by the calling party and other traffic (data). If the
data traffic is of some lower priority level (perhaps a lower
level of DSCP value), it should receive less priority in order
to allow this higher priority call session to seize outbound
resources. If there is still not enough available outbound
interface resources, then one or more of the lower Precedence
calls shall be preempted to complete the higher Precedence call.

There are three characteristics of preemption:

a) Any party whose connection was preempted (whether that
resource was reused or not) shall receive a distinctive
audible notification. An addition notification can be
provided via some visual indication if possible or
desirable;

b) Any called party of an active call that is being pre-
empted by a higher Precedence call shall be required to
acknowledge the preemption before being connected to
the new calling party, and

c) When there are no idle resources, preemption of the
lowest of these lower level Precedence resources shall
occur;

Any call session can be preempted anytime after the Precedence
value has been established for a call and call clearing has
begun. Here coordination with a Bandwidth aware mechanism such as
RSVP will be needed, making sure that the Preempting call is
assigned that bandwidth freed up from the call clearing action.

If there is a user or SIP device that is configured (somehow
compliant with the parameters within that Administrative Domain
(AD), and outside the scope of this document) to disable the
ability to be preempted, that user or SIP phone device will
not experience preemption of calls by higher precedence calls,
if the cause of preemption would be due to called party busy
condition (e.g. call waiting is enacted here). However, the
user may still experience preemption of calls due to a lack
of network resources other than the user's own access resources
[2].

Precedence calls that are not responded to by the called party
(e.g. the called party chooses to hang up their phone without
taking the call) may have their phone speaker initialized for
that inbound Precedence call in order to complete the call;
sometimes regardless if this called party wants the Precedence
call [2]. Section 8.0 of this I-D discusses the potential rele-
vance of this feature. An alternative to this approach could
be to have an 'alternate called party' signaled (e.g. that
person's admini-
strator). administrator). This mechanism would be a per Domain
decision, and not mandatory for SIP-MLPP interworking compliance.

An MLPP call session should automatically be set up with the
lowest precedence level by default, default until the user chooses a
level up to their 'their' maximum allowed authorized within that Domain.

5.0
Controlling whether users always chose the lowest level, or the
Appropriate level, is an administrative decision, and outside of
the scope of this document.

6.0 Defined SIP Priority request-header field

SIP[1]

SIP [1] defines the Priority request-header field and its
possible non-mandatory values in section "6.25 Priority" as
the following (exact text from page 40 of [1]):

" Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal"
| "non-urgent"

It is RECOMMENDED that the value of "emergency" only be
used when life, limb or property are in imminent danger.

Examples:

Subject: A tornado is heading our way!
Priority: emergency

Subject: Weekend plans
Priority: non-urgent

These are the values of [3], [8], with the addition of
"emergency". "

This author sees no inconsistencies in adding

In the "Flash
Override" Value with [1].

6.0 Merging 2543bis draft [7], this has changed to include a 5th
Priority Value Sets

When comparing sections 4.0 and 5.0, value "other priority" (section 6.31 of [7]), but
doesn't change the semantics of this section otherwise; meaning
"emergency" is still the recommendation for highest Priority,
but only difference in the values case of an *emergency* (pun partially intended).
The next level with less Priority is this fifth "urgent", which is followed
by the Priority value in MLPP, that might as well be the Highest default Priority
value ("Flash Override"), although each has a subtly different
name associated for of most SIP messages, because this is the first 4 values, value for "normal"
traffic - where most voice sessions will take place. Whatever the intended function-
ality appears
"non-urgent" value is supposed to be no different. This document recommends
adoption provide other than less than
"normal", it doesn't match the MLPP model at this end of the
spectrum as well as not having multiple "emergency" levels similar
to MLPP name designation ("Flash" and "Flash Override").

Even if "non-urgent" were mapped to everyday session traffic,
the Priority model of [3&7] won't match enough, and a separate
Header-Field is necessary

Both [3 & 7] state this Header-Field is not necessary, it fact it
Has been mentioned at numerous meetings that this header-Field
isn't even used, so why all the fuss about MLPP.

7.0 Request Header-Field:MLPP-Enabled Extension

The MLPP-Enabled request-header field indicates the relative Pri-
ority of the session initiation as perceived by the client.

MLPP-Enabled = "MLPP-Enabled" ":" MLPP-priority-value

MLPP-priority-value = "Flash Override" | "Flash"
| "immediate" | "Priority" | "Routine"

The semantics are a repeat of the Military example from section
3.0:

The lowest level, ROUTINE, would be used for
this new Highest Precedence Value all normal call
traffic. If a Company commander needed 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 PRI-
ORITY and potentially the IMMEDIATE precedence levels. The
field grade traffic (brigade, battalion, and division) would
use the IMMEDIATE, and in some cases FLASH precedence levels.
Communications within the interests of con-
sistency. Corps and Theater commanders would
use FLASH. The President, the Joint Chiefs, and some select
theater commanders (e.g. CICNORAD, or CICSAC) would use the
FLASH OVERRIDE precedence. This document explicitly requests guaranteed (in theory) that
the 5th MLPP value
("Flash Override") be included from this document, most important commands (the President forbidding nuclear
launch) would get through even over all other traffic.

This pre-grading of relative importance to a session is how an
authorized user can assign the appropriate priority to traffic
based on that user's Profile (e.g. within what they are auth-
orized to assign a
Standards Track requirement, session to). Someone who was authorized to possibly
use IMMEDIATE precedence would normally use ROUTINE unless there
was a legitimate reason to escalate the precedence to a higher
level.

7.1 A subset of MLPP?

A subset of MLPP can also be folded into implemented not having all 5 levels
of Precedence, and still be quite useful in infrastructures
desiring the explicit benefits of the semantics stated above, yet
don't implement all 5 levels from a
future RFC revision case of [1], unless obsoleted prior need.

Examples can easily be seen in Hospitals under emergency situa-
tions like power outages or "Code Blues" where a patient's heart
has stopped and the IP infrastructure requires an explicit mecha-
nism in place to that ensure Prioritized traffic reaches its destina-
tions in the time expected.

Another example is where this relative Prioritization of certain
types of traffic (here SIP initiated) are constantly provided
the higher levels regardless of the state of the network con-
gestion levels at any time.

7.0 Financial Institutions where stock
trading occurs and can't "get a busy signal".

8.0 Results of MLPP Extensions MLPP-Enabled Extension to SIP Priority Field

The following are recommendations or requirements for a SIP
Signaling Environment or Domain enabled with MLPP, or a
subset of MLPP, for the purposes of creating a Network where
Voice Sessions (at first) have a the need for sub-classification Precedence
classification within a Domain's control: control.

This is the purpose of this request for Extension to the SIP
Protocol, and the reason I believe this should be a separate
effort, not tied to the main SIP effort. I realize this isn't to
be implemented everywhere (too tight or focused a specification)
and desire the vendors and customers to look at this specifi-
cation separately for implementation purposed both in products to
be built, and features to be incorporated:

* SIP end-device MUST include the Request Header-Field "Priority:"
"MLPP-Enabled:" in all Session Signaling, session signaling, regardless of
the session's intent or destination;

* Header-Field "Priority:" " MLPP-Enabled:" MUST be default set to
'Routine' unless the calling user party specifies a Domain authorized an author-
ized Higher Value for that all call session; sessions;

* User must be authorized to access higher priority Priority values
for any Higher Precedence call session initiations (method of
authorization is outside the scope of this document); document) in
order to utilize those higher levels;

* MUST allow Administrator to make it mandatory for any SIP
receiving device to be MLPP-enabled (goal to have any
non-MLPP device not able to engage in any call session -
in a MLPP environment, this capability should be required
of all devices by that Domain's Administrator)

* Otherwise call isn't established with the following op-
tional (rough language) results:

* Automated attendant stating to caller "remote device
not MLPP-enabled... call cannot be completed" - call
gets either fast-busy or new tone indicating bad
remote device called;

* Automated attendant stating caller "remote device not
MLPP-enabled... do you wish to proceed with non-pri-
oritized call anyway"

* Simply a fast busy

* SIP SIP-based Gateways within MLPP-enabled Domain MUST have
direct mapping of ISDN Signaling according to [2 and 5]; 9],
else they should merely create the SIP Header with the
request Header-Field MLPP-Enabled, while entering a Pre-
dence value of "Routine" for that session;

* It is believed COPS should be utilized for mid-session
path rejections due to congestion, congestion (of what [2] calls
"call clearing", when a Higher Prece-
dence Precedence Call session
is requesting resources, but that mechanism is currently
outside of the scope of this document, but might be more
detailed in a future version of this I-D;

8.0

9.0 Unknowns needing discussion still

There are many unknowns still regarding the migration of the
original ANSI requirements in [2] into a SIP implementation here.
Discussion would be greatly encouraged on at least these issues
listed below to determine from the original requirements for
having something like MLPP, how much of those requirements need
to evolve for today's (and the future's) capabilities in
networking. Here is a brief list of a few of them:

o Conferencing - if a caller is on the conference bridge,
for example, and a call clear event occurs
(meaning they are the recipient of the
inbound higher priority call) does every-
one need to hear the audible tone?

If a caller is on a conference bridge, and
they are preempted by a network resource
bottleneck that causes their respective
leg to terminate, does everyone hear the
audible tone

Should there be some provision for
announcing to the conference 'who' has
been terminated from the call (where
possible by some other mechanism)?

o Version ID - Currently [7] defines as mandatory the
SIP version number or value be included
(section 4.3.1 of [7] to be specific). I
don't know yet how to identify this cap-
ability of MLPP in the SIP headers. I
don't know in a 'letter' should be added
to the SIP/2.0? I'm at a loss right now on
how to solve this and am looking for
suggestions.

o Speaker - The part of the ANSI spec [2] which states
that if the called party who is still in a
session has to acknowledge the higher pri-
ority in-bound session and answer it, else
have their respective device's speaker
turned on (in the case of that user merely
hanging up or terminating the session to
avoid answering or acknowledgement of this
new session). This feature might not be
desired further, but there should dis-
cussion from those that have experience
with MLPP to see if this is the case.

9.0 Changes since the Last Version

The following is a list of the noticeable changes to this effort
from the -00 version of this I-D:

o Changed the name and scope of this draft to "SIP Extension
for MLPP" requesting that a separate Request Header-Field:
MLPP-Enabled be created in this draft on a Standards Track
apart from the main SIP effort due it limited focus, yet
usefulness within certain markets

o Hinted at the potential synergies with both IEPS and GETS
efforts

o Suggested the use of a sub-set of the MLPP effort outside the
strict environments that still require all of MLPP's features
like Hospitals and Financial Institutions

o Added section 9.0 "Unknowns" to this version to attempt to
bring out the known differences in the why in which Voice
networks operated 'then' verses now and in the near future;

10.0 IANA Considerations

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

9.0

11.0 Security Considerations

It can be argued that Authentication and Authorization of Call
Sessions will not require any security mechanisms until Pri-
ority, Precedence and Preemption are enabled within a network
Domain. Once any or each of these are implemented within a
Domain Network, Security considerations could become signifi-
cantly more important to that Domain.

In an MLPP-enabled Domain, unauthorized setting of any Higher
Priority session should have a great impact on other traffic
unless there is no congestion occurring at any point within the
network, at any time. This author believes Security and Encryp-
tion will become very important within Packetized Voice Communi-
cations in the near future.

Since [2] mandates that each MLPP be defined and (relatively)
closed in nature, boundary controls can and should be possible.

10.0

12.0 References:

[1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP:
Session Initiation Protocol" RFC 2543, March 1999

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

[3] Palme, J., "Common J. Rosenberg, H. Schulzrinne "draft-ietf-sip-guidelines-01"
IETF Internet message headers", RFC 2076,
February 1997. Draft, November 2001

[4] K. Carlberg, "draft-carlberg-ieps-framework-00", Internet
Draft, November 2000

[5] James M. Polk, IETF Internet Draft "draft-polk-mlpp-over-ip",
March 2001

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

[5]

[7] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
"draft-ietf-sip-rfc2543bis-02" IETF Internet Draft, November 24,
2000

[8] Palme, J., "Common Internet message headers", RFC 2076,
February 1997.

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

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

11.0 Acknowledgments

A couple of people have made comments and suggestions contribu-
ting to this document. In particular, this author would

I'd like to thank Bob Bell Scott Bradner for his advice on this effort
and Rohan Mahy all of Cisco Systems. this MLPP efforts direction within the IETF up to
this point.

12.0 Author Information

James M. Polk
Cisco Systems
18581 N. Dallas Parkway, Suite 100
Dallas, TX 75287
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, 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."

The Expiration date for this Internet Draft is:

September 8, 2000 2, 2001