< draft-polk-mlpp-over-ip-00.txt   draft-polk-mlpp-over-ip-01.txt >
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft James M. Polk Internet Draft James M. Polk
Expiration: August 23rd, 2001 Cisco Systems Expiration: May 22nd, 2002 Cisco Systems
File: draft-polk-mlpp-over-ip-00.txt File: draft-polk-mlpp-over-ip-01.txt
Multi-Level Precedence and Preemption over IP An Architecture for
Multi-Level Precedence and Preemption over IP
February 23rd, 2001 November 21st, 2001
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with all
with all provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engi- Internet-Drafts are working documents of the Internet Engineering Task
neering Task Force (IETF), its areas, and its working groups. Force (IETF), its areas, and its working groups. Note that other groups
Note that other groups may also distribute working documents may also distribute working documents as Internet-Drafts.
as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months and
months and may be updated, replaced, or obsoleted by other may be updated, replaced, or obsoleted by other documents at any time. It
documents at any time. It is inappropriate to use Internet- is inappropriate to use Internet-Drafts as reference material or to cite
Drafts as reference material or to cite them other than as them other than as "work in progress."
"work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html. at http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"MAY", and "OPTIONAL" in this document are to be document are to be interpreted as described in [RFC-2119].
interpreted as described in [RFC-2119].
Abstract 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 Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 MLPP Overview . . . . . . . . . . . . . . . . . . . . . 4 2.0 Definitions and Conventions . . . . . . . . . . . . . . . . . . 4
3.0 Requirements for MLPP in an IP Infrastructure . . . . . 8 3.0 Motivation for replicating functionality into IP Networks . . . 8
3.1 General Priority Requirements . . . . . . . . . . . . . 9 4.0 MLPP Requirements in any Network . . . . . . . . . . . . . . . 8
3.2 General Preemption Requirements . . . . . . . . . . . . 10 4.1 MLPP Precedence. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 End Station Requirements . . . . . . . . . . . . . . . . 11 4.2 MLPP Preemption. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 End user Requirements . . . . . . . . . . . . . . . . . 11 4.2.1 Access Preemption Event . . . . . . . . . . . . . . . . . . . . 11
3.5 Internetworking Device Requirements . . . . . . . . . . 12 4.2.2 Network Preemption Event . . . . . . . . . . . . . . . . . . . . 12
3.6 Media Gateway (MG) Requirements . . . . . . . . . . . . 12 4.3 MLPP Feature Scenarios . . . . . . . . . . . . . . . . . . . . 12
3.7 General Security Requirements . . . . . . . . . . . . . 13 4.3.1 Bearer Services Supported . . . . . . . . . . . . . . . . . . . 12
4.0 IP Infrastructure . . . . . . . . . . . . . . . . . . . 13 4.3.2 Commonalities of Interest . . . . . . . . . . . . . . . . . . . 13
5.0 IANA Considerations . . . . . . . . . . . . . . . . . . 15 4.3.3 Conferences Preset . . . . . . . . . . . . . . . . . . . . . . 13
6.0 Security Considerations. . . . . . . . . . . . . . . . . 15 5.0 MoIP Requirements and solutions . . . . . . . . . . . . . . . . 13
7.0 References . . . . . . . . . . . . . . . . . . . . . . . 16 5.1 Setting Priority to an MoIP Session . . . . . . . . . . . . . . 14
8.0 Author Information . . . . . . . . . . . . . . . . . . . 16 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 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . . 21
8.0 Changes since last version . . . . . . . . . . . . . . . . . . 21
9.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.0 Introduction 1.0 Introduction
This document describes how the ANSI specification T1.619- The intent of this document is to introduce an Architecture for Multi-
1992[1] and its extension T1.619a-1994[2] should be mapped or Level Precedence and Preemption (MLPP) into the IP realm. MLPP was
correlated or migrated over to either a mixed TDM and IP network originally written to create "a prioritized call handling service" [1]
(with Gateways in between) or a pure IP network that requires in combination with ISDN supplementary services. MLPP has two very
the functionality of these two ANSI specs as Standard Operating simple concepts for voice (Real-Time) communications:
Procedure within the IP portion of a network.
T1.619-1992 describes an ISDN based ability of marking and A) setting or marking every session at inception with a
tracking each and every (TDM) phone call, from call set-up, to Precedence level relative to others within a known network
connection, to completion (hang-up) throughout a defined Voice domain; and
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 in a PRI T1
circuit, but can and is take down to the BRI circuit (two B-
Channels at 64kbps and one 16kbps D-Channel). In this marking
and tracking of every single phone call, the network becomes
priority "aware" of which phone calls are important and which
are not. Which phone calls have priority 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, 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, and no call flow problems.
But this isn't always the case. Certain environments require the B) the end-stations or internetworking devices preempting
ability to prioritize calls over others in those network lower relative priority sessions in order for higher
situations that bottlenecks occur and are deemed "important" relative level sessions to pass or occur during times of
phone call that need to get completed even if it means congestion at any point in that known, managed domain,
disconnecting an existing, pre-established call somewhere within including to the end-station (phone).
the network.
T1.619-1992 was written for networks that have this type of This concept has existed for more than a decade, and been deployed in many
requirement. To have multiple levels of priority for all voice networks throughout the world for years. It is based, or founded, in US
calls and the ability in the time of need, to preempt voice calls Government network requirements. It is an augmentation service to ANSI's
that are deemed less important than others in order to get ISDN [21,22,23,24]. This document is the first attempt, though incomplete
those fewer, more important calls through the network to their at this time, at bringing those specialized functionalities of MLPP from a
intended destination. This specification has been called MLPP, more traditional world voice communications delivery practice into the IP
for 'Multi-Level Precedence and Preemption' ever since its realm.
original publication in 1992. The Clarification document T1.619-
1994[2] merely clarifies some errors from the original
specification and added some minor functionality, but didn't
change the essence of the original specification.
I am going to use the words 'Precedence' and 'Priority' inter- MLPP over IP, or MoIP, shall specific as many IETF Standards and practices
changeably throughout the remainder of this ID. as possible. The intend here is not to reinvent anything that already
exists. However, certain functionalities in IETF Protocols will require
adjusting, or extending, to fit the MLPP model that will be laid out
within this document to satisfy the requirements and experiences of the
trained user of MLPP in the past.
Why is this document here needed in the IETF? Most of the specifications and concepts stated here for MLPP were taken
from the ANSI specification T1.619-1992 [1] and its supplement T1.619A-
1994 [2]. Still other specifications and concepts stated here are from ITU
Q.735.3 [19]. Any remaining details and concepts attained from documents
came from the certification materials which all products must tested
against to achieve MLPP compliance and interoperability status [17,18].
There are a few concepts mentioned here that were attained from inter-
viewing users and testers of MLPP for guidance of how this MLPP-concept
might be enhanced with the additional capabilities that IP and IP-based
services brings to offer.
Because these MLPP enabled networks were built. And they were This document will state its scope, to include what will and will not be
sometimes built very big, by anyone's standards. One closed covered here. It will define all the terms as best as possible due the
network I know of has 800+ Class 5's in it, for example; that's readers might not be completely familiar or savvy with the IETF and its
fairly large and fairly complicated, and it will be fairly languages, but from more of a telephony background where MLPP lives today.
difficult to migrate to our current love: Packets. IP packets to This document will then define the network feature and functions necessary
be more specific with our area of focus in the IETF. to be compliant with existing MLPP networks. This is as much a background
and education, or level-setting, as anything. This section will detail the
known behaviors each component of an MLPP network must do under explained
circumstances and scenarios.
So, there needs to be a migration from an ISDN based, PBX based, The next section will get into the IP realm of MoIP. Please notice the
TDM based Voice infrastructure to a partial ISDN/PBX/TDM based convention change. Within this document, MLPP shall refer to the tra-
infrastructure and partial IP-based infrastructure, or just ditional GSTN-based MLPP network and all components and requirements;
completely to an IP based infrastructure with MLPP capabilities. whereas, MoIP shall refer to its IP based counterpart. That Counterpart
No functionality can be lost in this transition or build out. shall be near in functionality, but this isn't exactly an apples to apples
conversion from one topology to 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 advantages, such as maintaining state of a circuit end-to-
end, that IP doesn't have easily. As best as possible, the document shall
point out where a functionality is enhanced, duplicated, or how far
replication falls short.
Conventional wisdom sez that in order for consumers to move from Next there will be an IANA Considerations section to the IANA group for
one 'thing' or 'habit' to another, it requires some form of registration of mappings, which shouldn't occur here as this is not a
motivation to do that new 'thing' or 'habit'. In the telephony Standards Track document. This section will be followed by the security
case, it's usually the case which this new idea costs a whole considerations section which states all the security problems enacting
lot less (possibly with less functionality) or it has a whole this document should cause. No normative language should be within this
lot more functionality (possibly costing more). But none of the section, but here there shall be the remaining caveats not previously
consumers which are connected to MLPP enabled networks are covered within this document, with some reminders, but more general
paying a dime out of their own pockets for these networks, language here. The details are within the document's main text in previous
because they are utilizing this functionality only in their sections.
respective work environments. So, if cost isn't a factor
(arguably), functionality is; an all-of-a-sudden-lack-in-
functionality would and will be noticed and likely not positively.
This document was written with another ID in mind that is The next 4 sections are: Acknowledgements, the changes since the last
intended to be a Standards track ID within the SIP WG [3] that version of document, the references and author's information sections.
is intended to be the smaller, SIP focused aspects of MLPP that
needed extending within a WG that a "general" Informational-
based ID could not stipulate or require. In other words, the
intent here is to try not to solve MLPP in one BIG document.
Where would it go, and who would oversee it? I decided to break
it up into several ID's. This one is the larger overview,
general ID, and Informational. In talking to Scott Bradner, he
and I felt it wise to create this larger ID on an Info track,
and submit the smaller Standards Track ID's into the appropriate
WG's that had the need for adjustment or extensions for MLPP-
specific features and capabilities. SIP was the first I
identified and submitted into; there will likely be many others.
I hope, as Scott does I believe, that each of these WG
extensions will be small in nature and scope, tweaks if you
will. MLPP is not the biggest thing to come to networking, and I
don't want to treat it like it is. But there is a customer
requirement (many actually) for these specific features and
functionalities, and in talking with customers on both sides of
the Atlantic, IP and voice communications will remain separated
until these capabilities are incorporated into an IP-Manageable
infrastructure in a Standards accepted way where multiple
companies can provide products for bid.
2.0 MLPP Overview After the main body of this document, following the author section, are
the Appendices, which are 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 requirements are met within the MoIP part of that
topology. There shall be a different Appendix for each topology and set of
protocols present. Within each Appendix, the rules stay the same for 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 detailed out here. As this document progresses, I
expect more and more examples, or Appendices, to be written, and 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.
Multi level Precedence and Preemption Service Capability 2.0 Definitions and Conventions
stipulates a relative priority ranking order of all Call flows
on a hop-by-hop basis through a Voice Network from their
relative beginning Voice device (calling party) to the end
Voice device (called party). Within the TDM world, these
call flows were in a closed circuit switched network from
a PBX or Tandem Switch to PBX or Tandem Switch. Each
Switch, upon initiation of a higher priority call flow
where there were no 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 switch determined overridden call.
Typically, an audible tone occurred on the inbound caller's
phone receiving the Preempting call flow. But this only occurred
if that caller happened to be the resource that was preventing
the higher priority call from being completed. In other words,
like a forced call waiting with all the tones and such, but the
existing call is not put on hold, it's disconnected. I don't
know if that aspect of the MLPP spec is desired still or not,
and should be looked at as a choice perhaps with a timer
controlling how long the preempted call waits for the new call
to be disconnected in order to reconnect the original call; with
that first call being disconnected after an agreed upon
timeframe within this spec.
The MLPP concept was created so that there was a real-time The following is a list of definitions and conventions to used throughout
method of prioritizing voice communications. It was created this document. Note that some of the definitions are either MLPP *or* IP
back before electronic switching in the U.S. Government centric, and might not make sense to the other. Advice is taking these
"AUTOVON" network. It is designed so that normal telephone words in the context of the section of this document they are written in.
traffic would not cause problems in the event of a crisis.
By contrast, in a Packetized Voice Network, there will likely Alternate Party Is another endstation which is configured for any
not be fixed or pre-configured outbound circuits waiting for call diversion if the Called device has an inbound
higher priority call flows to occur on a per-MLPP-enabled IP Precedence inbound call while that Called User is
Internetworking device basis. This presents a more challenging actively on a call/session
problem of preemption in a less statically configured Network
Topology. Also, every network device will need to have the code
within it to make this Prioritization and Preemption
determination similar or exactly like the Class 5's of today's
MLPP networks, or there will be weaknesses in the IP
Infrastructure that might prevent the proper completion of a
(deemed) very important voice session.
Here is an example using Military Rank as a conceptual com- Assured Forwarding AF [13] in Diffserv û marks the IP Headers with a
parison: codepoint value relating to the expected behavior of
that value throughout a single IP domain on a per hop
basis
The lowest level, ROUTINE, would be used for all normal call DE MLPP defined as the PBX the destination endstation is
traffic. If a Company commander needed to reach his platoon directly connected to
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, 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 guarantees (in theory) that
the most important commands (the President forbidding nuclear
launch) would get through even over all other traffic of any
priority or type.
This pre-grading of importance is a method of assigning maximum Diffserv Differentiated Services [3] û IETF Standard defining
levels of priority to traffic based on user Profile (e.g. what a Priority marking of IP Packets to achieve deter-
they are authorized to do). Someone who was authorized to use ministic behavior through an IP-based network
IMMEDIATE precedence would normally use ROUTINE unless there
was a legitimate reason to escalate the precedence to a higher
level.
ANSI T.619-1992 states the 5 levels of Precedence (or Priority) Domain For MLPP, the set of MLPP subscribers and contiguous
for MLPP networks as the following: network resources in use at any time supporting those
MLPP subscribers;
For IP, everything within the logical IP boundary
supporting MoIP capabilities in a single network
bits Name Edge Router ER - A Router at the logical boundary of an MoIP
---- ---- Domain
0000 "Flash Override" (0)
0001 "Flash" (1)
0010 "Immediate" (2)
0011 "Priority" (3)
0100 "Routine" (4)
0101 to End Office Node EN û see EOS
1111 "Spare"
There are actually 16 values/levels possible within the ANSI End Office Switch EOS û Similar to a PBX configured to only service
spec, but any additional levels will have a preemption func- that local community and its needs; it is internal
tionality below, or less than, "Routine". The intent is that network controlled; this unit connects all CPE
"Flash Override" is always the highest level capable within a equipment in that community
MLPP-compliant network.
In any case, a call session of any given Precedence level or Endpoint H.323-based voice device (IP Phone) utilizing only
value can preempt any Precedence level of a lesser level or H.323 Signaling Protocols
value where network resources are already utilized. If these
call values are equal, then other mechanisms, if any, can react
according to their individual capabilities (e.g. Call waiting).
One very important concept to keep in mind with anything here, Expedited Forwarding EF marking [12] in Diffserv creating a forwarding
is that if network bandwidth or resources or trunks have the queue with no other above it, that in which a packet
capacity to complete the call, it doesn't matter what the entering the queue shall not be delayed by more than
priority is of *any* call, each will get treated equally. one packet length/time from any other queue
Key concept: Unless resources are at their respective maximum Gateway converts media provided in one type of network to the
somewhere in the network, the Priority level any format required in another type of network; the
call has doesn't matter in the least. gateway shall be capable of full duplex audio trans-
lations
Preemption can take one of two forms. First, the called party GSTN Global Switched Telephony Network û worldwide circuit
may be busy with a lower Precedence call which must be pre- switched public telephony network
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
DSCP value[4]), 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: H.323 ITU originated Peer-to-Peer Multimedia Signaling
Protocol
a) Any party whose connection was preempted (whether that ISDN Integrated Services Data Network
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- Label Switched Path LSP û MPLS short fixed length label assigned to
empted by a higher Precedence call shall be required to packets upon ingress to an MPLS cloud. This label
acknowledge the preemption before being connected to is what MPLS Routers use to make forwarding decisions
the new calling party, and on.
c) When there are no idle resources, preemption of the Look ahead For Busy LFB û this optional feature has one endstation
lowest of these lower level Precedence resources shall prematurely acquiring the path, preempting if
occur; necessary, to another endstation; this can occur
any interval before the call/session is actually
placed
Any call session can be preempted anytime after the Precedence Media Gateway See Gateway above û but one side is IP, and the is
value has been established for a call and call clearing has not; could be analog voice of an IP phone, or it
begun. could be a trunk interface to a PBX
If there is a user or IP Voice device that is configured Media Gateway Controller MGC û or Call Agent û the server that acts as
(somehow compliant with the parameters within that the control plane for audio, video, or both, or
Administrative Domain (AD), and outside the scope of this full multimedia communications
document) to disable the ability to be preempted, that user or
IP Voice 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 [1].
Precedence calls that are not responded to by the called party MGCP Media Gateway Control Protocol û IETF Informational
(e.g. the called party chooses to hang up their phone without RFC 2705 Client/Server based Call Control Protocol of
taking the call) may have their phone speaker initialized for media Gateways (Gateways or IP Phones), resulted from
that inbound Precedence call in order to complete the call; the merger of IPDC and SGCP
sometimes regardless if this called party wants the Precedence
call [1]. An alternative to this approach could be to have an
'alternate called party' signaled (e.g. that person's admini-
strator). This mechanism would be a per Domain decision.
An MLPP call session should automatically be set up with the MLPP Multi-level Precedence and Preemption [1 & 2] û ANSI
lowest precedence level by default, until the user chooses a T1.619 and 619A specifications stipulating mechanisms
level up to their maximum allowed within that Domain. for marking each voice communication with a Prece-
dence level, and defining the requirement for the
Preemption of lower Precedence existing sessions
during congestion in favor of new higher Precedence
sessions
3.0 Requirements for MLPP in an IP Infrastructure MoIP MLPP over IP
Since this is not currently a Working Group item from any WG in MPLS Multi Protocol Label Switching [4] û IETF Standard
the IETF, this effort (right now) will not go through the for using label switching and for the implementation
process of a WG in the defining of Requirements first and attain of label-switched paths over various link-level tech-
consensus on those before proceeding. Hence, this section deals nologies, such as Packet-over-Sonet, Frame Relay,
with the requirements of MLPP as I see them now. There could ATM, and LAN technologies
very well be more, that I am more than open to comment on this
effort from my peers to that end, and possible inclusion in the
next version of this I-D.
Actually, this draft doesn't have a known home (email reflector) Multifunction Switch MFS - A combination of a End Office Switch (EOS) and
for discussion within the IETF either, and I'd like that to be Tandem Switch (TS); having trunking and CPE connec-
solved by the London meeting. There has been some talk about tion capabilities within one, more economical unit
placing this along with the IEPS efforts of Hal Folts [5] - and
that's certainly possible. That is a worthy effort, and fairly
similar in scope and architecture and complexity.
And to make matter worse, I think it's questionable whether MLPP NSIS Next Steps in Switching û currently a proposed IETF
should *only* be written for Voice Communications over the long Working Group to focus on simplifying signaling
run. I see the great need to have it focus presently on Voice within a network vs. a more heavyweight version: RSVP
sessions (calls), but this should apply to anything that's RTP
based at least, which is not just voice. And then in the future
when authentication can be verifiable to a list of applications
and Protocols within a IP-Managed network domain, to them 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, or removed, for other applications to take advantage
of Priority and Preemption.
I will simply put the requirements for MLPP over IP in bullet OE MLPP defined as the PBX the originating endstation is
form for this version of the ID and categorize them into areas directly connected to
of scope or functionality. Keep in mind that these requirements
must be adhered to by all devices within a single, IP-Managed
Domain in order to function properly.
3.1 General Priority Requirements Precedence The relative priority level assigned to each session
o ANSI T.619-1992 states the 5 levels of Precedence (or Precedence Call Any call that has a Precedence level higher than
Priority) for MLPP networks as the following: Routine
bits Name Preempt Notification The notification sent from the endstation receiving
---- ---- the inbound preempting call to the endstation being
0000 "Flash Override" (0) preempted from their previous call/session
0001 "Flash" (1)
0010 "Immediate" (2)
0011 "Priority" (3)
0100 "Routine" (4)
0101 to Preempted The audible notification sent to all endstations who
1111 "Spare" have been preempted for any reason
There are actually 16 values/levels possible within the ANSI Preempting Call Is a call with a Precedence level higher than others
spec, but any additional levels will have a preemption func- on a specified interface at a time of congestion,
tionality below, or less than, "Routine". The intent is that including an end-station that is on a call
"Flash Override" is always the highest level capable within
a MLPP-compliant network.
Where ANS.1/binary coding occurs, there must be 4 bits given Proxy Server SIP Server [6] that acts on behalf of other Devices
to MLPP Prioritization as shown above where 0000 is the Registrar Server SIP Server [6] that serves as a Registration point
highest Priority level and 16 is the lowest. This doesn't principally for mobility
match the TOS or Diffserv bit mapping, so this must be done
somewhere else in the packet (of every packet).
Where text coding occurs, the names associated with the 5 Response Timer T-sub-K Is started when the network notifies the Called
level of Priority must match the above order with "Flash device of a inbound precedence call; acceptance must
Override" being the highest, and "Routine" being the lowest occur by the Called device; the timer is specified in
known one used. [1] at from 4 û 30 seconds
I acknowledge right now I'm not a coder, BTW. Response Timer T-sub-L Is started when an LFB information unit is sent
into the network to establish an open path between
the Calling endstation and the intended called end-
station; the timer is expected in [1] as from 5 û 20
seconds
o It is unclear if this infrastructure should apply to RSVP Resource Reservation Protocol û IETF Standard defined
Instant messaging for Priority yet, but it likely will at in RFC 2205, for reserving bandwidth from end station
some point to end station, without congestion affecting it once
the path exists
3.2 General Preemption Requirements 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
o Any party whose connection was preempted (whether that Switch Packet-based multiport Router intended for internal
resource was reused or not) shall receive a distinctive network use and not connected between different
audible notification [1]. An addition notification can be networks (owners); here they are Layer 3, or IP-
provided via some visual indication if possible or Header, aware devices that switch packets to desti-
desirable; nation interfaces based on the Destination address
within a packet
o Any called party of an active call that is being pre- Tandem Switch TS - Only connects to EOS's; is the primary backbone
empted by a higher Precedence call shall be required to of a circuit-switched MLPP Network
acknowledge the preemption before being connected to
the new calling party,
o When there are no idle resources, preemption of the Termination The end of a circuit, or in the MEGACO definition,
lowest of these lower level Precedence resources shall the end device, a Gateway circuit or IP-based Phone
occur;
o How to chose which established session, amongst the probable Transit Router Router or any Layer 3 aware device that is not an
many that traverse an interface experiencing congestion, is endpoint in the communications path, but that path
to be terminated when a higher Priority session is initiated travels through it to get to the destination
through an internetworking device is likely a topic needing
discussion. I would vote for the session that has existed
the longest through that interface, meaning per session
timers must be kept either within the internetworking device
(in COPS [6], the PEP) or the server/node making the policy
decisions for that internetworking device (in COPS [6], the
PDP, which could be co-located and is allowed for in that
RFC)
o If more than one session must be preempted in order to allow User Agent SIP [6] defined as an application which can act both
that new high priority session through a congested network as a user agent client and user agent server
interface, this must be allowed to occur on any inter-
networking interface within this MLPP domain
o Discussion is needed to determine if Voice (and possibly User Agent Client SIP [6] defined is a client application that initi-
Video) session should be allowed to drown out or starve all ates a SIP request
other types of traffic through any congested network
interface. The Diffserv WG had similar discussions and I
don't know if an outcome was chosen. Conventional wisdom has
a limited amount of the bandwidth through any interface for
any one application or Protocol, but that is absolutely
choice for each domain.
o It is unclear if this infrastructure should apply to Instant User Agent Server SIP [6] defined A user agent server is a server
messaging for Preemption yet, but it likely will at some Application that contacts the user when a SIP request
point is received and that returns a response on behalf of
the user. The response accepts, rejects or redirects
the request.
3.3 End Station Requirements VPN Virtual Private Network; defined as existing among
many devices, but able to communicate with only a
network pre-configured limited number of devices, at
the same time, devices not belonging to this group
within the private network cannot communicate within
either
This section includes the IP devices that start the MLPP-enabled 3.0 Motivation for replicating functionality into IP Networks
communication (IP phones, PC's, Handheld's and the likeà)
o Ability of the End Station to generate RTP sessions with Many MLPP-based networks wish to move into the IP realm, yet have opera-
all 5 MLPP Priority levels in the Packet headers, whether tional features and functions that the administrators of these networks
that's self signalled (like would be the case in SIP), or deem important/mandatory, and are not willing to set aside in this
determined from another Node on the network (Server or Media migration which arenÆt available or defined in IP yet. Accomplishing
Gateway Controller) for a defined Standard (MEGACO [7]) or certain of these functionalities is similar to fitting a round peg into a
Proprietary Control Protocol; square hole. MLPP is circuit-based technology, and 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 clear and open path to make a
call to another phone, even though the calling phone hasn't started to
make the call, and might not for seconds, minutes or hours, makes sense in
the networks where MLPP exists presently; but that feature makes little to
no sense in IP networks where available bandwidth is freely given on a
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 IP for this example, but it only reserves
bandwidth end-to-end if that bandwidth is available through each transit
Router, and upon set-up of that symmetrical session that is about to
occur, not before.
I don't know if the initial Priority level should be set to MLPP has very little impact on end devices like the phones because all the
"Routine" for all users and have them individually raise the signaling and processing is in the EOS, not the phone. Signaling mecha-
level within what they are authorized to set to if they need to, nisms that have stateful awareness, and have this resource reservation
or if this aspect is more network controlled on logon and feature enabled from the example above have a great impact on the
authentication to the network, and that user's profile within processor of that end device (IP Phone) the way the IETF Protocols are
that domain controls each, or at least the default Priority written today. IP has no physical circuit endpoint to map to in these
level. Discussion on this should occur to reach consensus. transit Routers (unlike the EOS or TN in MLPP networks); no easy way to
reserve a fixed portion of bandwidth; in fact, these transit Routers
almost never know which packet belongs to which session going through it,
or that any sessions are going through it.
o Ability to differentiate users and allow each user's access These administrators understand that IP Telephony offers significant
only to those priority levels they are authorized to increases in features, functionality and services for all end-users.
initiate per session (in the current MLPP-ISDN networks, the However, there has not yet been an effort to describe this architecture
level of Priority is determined by, and only by, the color with IP. This document takes that challenge.
of the phone; which is hardwired to a PBX interface that is
configured at a certain single MLPP Prioritization level)
o The Preemption audible tone and generator stipulated in [1] 4.0 MLPP Requirements in any Network
must be built/written into each end station
3.4 End user Requirements This section details the requirements of MLPP without IP and, as best as
can be accomplished, without ISDN or SS7. Many circuit-switched nomen-
clatures and references (words, not bibliographical) will be made due to
MLPP only existing in the circuit-switched world to this point in time. It
is an attempt at a generic, yet specific set of network requirements for
any network to function as an MLPP compliant network; and yet not too
specific to the 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 making IP equivalents and
solutions for MLPP in a packet environment.
This section includes the people themselves that are placing the For this to happen, the core MLPP documents [1 & 2] must be referenced in
Voice (and possibly Video) call sessions for now, but will detail, as well as the documents involving the actual testing of any
likely include the automated initiation of sessions by non- component for certification of MLPP compliance [17,18,19].
humanoids soon ;-) But this could fall under whether IM
receives this applicability of MLPP.
o Ability to uniquely identify themselves to the MLPP enabled The root specification [1] states that there are two parts to MLPP
network in order to be granted the priority choices (this conceptually: Precedence and Preemption.
quickly gets into the Security aspects discussed below)
3.5 Internetworking Device Requirements 4.1 MLPP Precedence
This section includes Layer 2 & 3 switches, Routers and Servers: Precedence means Priority, relative priority to all other calls within
that single domain. It is set or assigned by the calling party at the
beginning of a call, on a per call basis by that party. Once the
precedence level is chosen by a caller, it cannot be changed for the
duration of that call. However, the next call being independent of the
first call, can be made at another authorized level, also chosen by the
calling party.
o Monitor all interfaces within each internetworking device Precedence Values are:
for congestion and resource allocation
o Appropriately self regulate all congestion interfaces 1 "0000" = "Flash Override" (highest level)
similar to COPS configurations [6] in which a individual 2 "0001" = "Flash"
internetworking device makes decisions either locally (it is 3 "0010" = "Immediate"
both the PEP and PDP for a scenario or as a rule within that 4 "0011" = "Priority"
network), to utilizes the COPS Protocol for communication 5 "0100" = "Routine" (lowest level)
with a COPS Server for specific traffic instructions down to "0101 û 1111" are unspecified
the session level
o When an MLPP session preempts another MLPP session on an The above list of precedence levels are listed in order from highest to
internetworking device, and that internetworking device is lowest; meaning no call SHALL be of higher priority than "Flash Override"
not directly attached to any of the 3 or 4 end users of in an MLPP domain, the "Flash", and so on down to "Routine" as the lowest
either session, it must signal the end stations that were level able to be signified. "Routine" is for normal, everyday phone calls.
preempted notifying them of the occurrence(I'm not sure what The unspecified values, if ever used, are to have priority levels below
Protocol should be used here, but SNMP could be utilized that of "Routine"; none have been utilized to date [17].
even if authentication is necessary, although its
modification might be necessary via an ID)
3.6 Media Gateway (MG) Requirements The Precedence levels authorized for a phone are set up for that circuit,
ensuring the user of that phone cannot use a level above what they are
authorized to gain access to.
This section includes Media Gateways that are not end stations 4.2 MLPP Preemption
within the MLPP infrastructure, but translate either from IP to
some TDM infrastructure (ISDN could mean another MLPP network,
PSTN TDN means from a non-MLPP network):
o If the MG is connected between an IP-based MLPP network and Preemption is the seizing of otherwise used resources of one or more calls
a non-MLPP network, it must set the Priority to "Routine" in order to complete another call in a congestion situation. This is
for that incoming call (unless someone clever creates a way determined by EOS's or TN's evaluating or comparing the Precedence levels
for that user to uniquely identify themselves to an IP-MLPP of all existing calls outbound on a circuit or a trunk, upon a time of
device and allows the session to receive higher Priority; congestion or no other resources available on that same interface, with
comments here are again welcome) the level of the next inbound call (set-up) intended to egress that same
interface. One or more resources can be cleared for a higher precedence
level call, ensuring that call the newly available resources.
o If the MG is connected to a known and trusted MLPP-enabled There are two modes of Preemption: preemption of the called device with
network (in either direction and determination which is another inbound higher precedence call (Access Preemption), and preemption
outside of the current scope of this document), let the within the network not involving either party of the preempted call at
Priority of the calling party continue (unless your network all, but at a point of congestion (Network Preemption).
has a policy to do something different with the incoming
call request, of course)
An example of this case is the transition of an MLPP enabled MLPP is mandated as having influence with a single domain based imple-
ISDN network to that of an MLPP enabled IP network. With these mentation only . The precedence value set in one MLPP Domain SHOULD NOT
existing networks being the size they are, there will be a mi- cross Domain boundaries into another domain and have any preferential
gration from one infrastructure type to the other, maybe not treatment applied to that call. The MLPP Domain-Identifier was included
completely getting ride of the ISDN network for quite some time, for this reason into the ISDN signaling for MLPP service. MLPP compliant
if ever. Tandems (TN's) are to look at the Precedence level set within the call
set-up signaling as well as the domain identifier within that same call
set-up to ensure validity within that network. This prevented leaking of
one domain's call behavior into another's. In other words, no preemption
of any resources shall occur within a domain as a result of a call into
that domain from outside the domain, even if both domains are MLPP
compliant networks;
There are several other examples of MG networking scenarios, but Here are the three preemption conditions:
I won't list them all here just yet. Suffice to say, the MG is
either in your network from the IP network to an ISDN network
(which may or may not be MLPP enabled) or PSTN point of view,
and is either connected to a trusted side and an untrusted side
(as is likely the case in connection 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 for simplicity
or as a more firm example if necessary.
3.7 General Security Requirements o A distinctive preemption notification (tone) shall be introduced
into any connection(s) that is to be cleared due to either a Access
or network Preemption event;
o This is an somewhat ambiguous requirement for the o The party on the inbound end of a preempting call MUST acknowledge
authentication and authorization of all End users, this is that inbound call before connection to that call;
likely network specific to some external form of
authentication such as a SmartCard for the *trusted*
identification of each authorized user, granting them access
to resources as well as MLPP Priority levels for call
sessions
4.0 IP Infrastructure o Upon determination of no available resources and calls existing on
an interface of lower precedence, the lowest level call(s) MUST be
cleared in order to complete the higher precedence call;
Obviously, if [1] is to be adhered to but in an IP infra- A call can be preempted at any time after the precedence level has been
structure, and even in a transitionary network (one that is determined to be lower than the existing call and before call clearing has
migrating from ISDN enabled to IP enabled MLPP), a lot of begun. However, no preemption of any resources shall occur within a domain
aspects of how RTP sessions (principally Voice) over IP will as a result of a call into that domain from not originating in that
require sometimes significant changes in how networks are domain, even if both domains are MLPP compliant networks.
currently configured. Some of these changes will require
Standards to be modified and new code to be written from those
Standards into some or most of existing network devices in order
to follow [1] to the letter.
Customers that I've talked to have not been willing (so far) A clarification must be stated: higher precedence provides preferential
to give away any functionality from [1] within their networks. call handling throughout an MLPP domain, regardless of how much higher a
It gets more complicated where GETS requirements are included call is relative to others. For example, a "Routine" call is equally lower
from [5], because that involves theoretically every phone and in precedence level than "Priority", "Immediate", "Flash" and "Flash
phone line in the US; but that's for another ID to deal with. Override" as far as preferential treatment in the network is concern.
Below is a list of topics that need discussing in order to change/ Having stated that, currently there is no recognized/Standardized method
modify/extend/enhance existing IETF Specifications to enable MLPP or mechanism in the case of which one of several lower precedence calls
in IP networks. I believe this list will get longer with time and gets disconnected, where such a condition exists. Only such that the
discussion and more detailed in nature. lowest level gets disconnected first. But if there are 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 the implementer.
o Within the IETF for Signaling Protocols and Media Gateway An example, if there is a saturated interface with 6 equal bandwidth
Control Protocols, SIP & MEGACO are affected by this effort. connections existing, 1 "Flash" call, 1 "Immediate" and 4 "Routine" calls,
Each will have to (for the strict MLPP compliance) modify when another "Flash" level attempts to gain resources out that interface;
their respective headers to include the 5 levels stipulated if that new "Flash" call is the same bandwidth as the others (all are
in 3.1 equal in this situation), then a "Routine" is preempted, being the lowest
level on that interface. Which one is up to that vendor's product
algorithm. MoIP might want to standardize this mechanism for consistency.
o RSVP [8] is not mandatory for MLPP, but it is the only Who the preemption picks to get whacked is not defined within the
bandwidth aware IP Protocol within the IETF that can handle requirements. So it's up to the implementers. My thought of a stateful
RTP streams that I'm aware of. Without this virtual session timer assigned to each interface that picks either who is on the lowest
created by RSVP, I'm at a loss now as to how any inter- level the shortest or longest gets it.
networking 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 of both endpoints of an RTP MLPP [1] also established the Alternative Party, and the Non-Preemptable
session, so it for signaling or even making aware of a Resources options. The Alternative Party option is a pre-configured to
Preemption occurrence is not yet likely possible that phone-line secondary phone to ring in the times where the first phone
is being used. This can prevent a preemption event, even when that new
inbound MLPP call is of higher precedence. The Alternative Party must
answer before the Timer T sub K expires. Additionally, a party of a phone
can preset their phone with the option of 'Non-Preemptable Resources'.
This prevents Access Preemption events, but does not prevent Network
Preemption events.
Problem with SIP in [9] and the bis draft [10] is that they The Alternative Party redirect MUST be to a valid domain address and is
modified in the bis draft to go to 5 levels from 4, but the RECOMMENDED to a location which always answers the phone, such as a
5th level was placed at "less than normal", and doesn't coincide operator or ACD pool of personnel. An additional benefit to the Timer T
with the MLPP 5 levels. This might not be a big deal to a lot sub K is that it prevents indefinite diversions when it expires for a
people, but people running MLPP network mandate the existing 5 call. The example below give this mechanism more clarity.
levels defined in [1]. This is part of what [3] covers, along
with a additional Header-Field "MLPP Enabled", it provides the 5
MLPP levels due to this inconsistency between the two requirements.
This also relieves the SIP WG for making the main effort of that
WG responsible for complete incorporation 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 and will have more substance to it in the next 4.2.1 Access Preemption Event
version of this I-D. But due to time constraints and an
unforeseen event, this -00 version wasn't as fulfilling as it shall
be in the near future. Comments will also (hopefully) substantially
add and clarify this I-D as it progresses.
5.0 IANA Considerations The following is an example of the MLPP mandated process for Access-based
Preemption events occur, similar to a flow chart:
This author doesn't believe there are any within this document Scenario #1: Caller A and D are on an MLPP call when Caller C calls D
at this time.
6.0 Security Considerations If there is an existing call between two parties (A & D), and a third
party (C) calls into D (provided there is no congestion between C & D),
D (at the EOS) first checks the Precedence of this new inbound call. If
the Precedence value is equal to or less than that of the existing call
between D & A, then C either is returned a Disconnect (user busy), or is
diverted to an alternate party (another phone) if there is one speci-
fied; C is Disconnect (Precedence Call Blocked indication) if one isn't
specified.
A wise person said once (OK, it was Dave Oran, one of our AD's, If the MLPP call from C has a greater Precedence value than the A to D
and I'm paraphrasing): "End user Security for real time sessions call, then a determination is made at D (at the EOS) whether D is
never was that important until the effective use of QoS (priori- Preemptable. If D is not Preemptable, then an alternate party is looked
tization) could be realized". This effort is stipulating that for. If there is identified, the call is diverted. If it is not, C is
exactly that scenario and Architecture can be and is built in returned a Disconnect (Not Equipped for Preemption). If D is Preempt-
the Packet world. able, the user and device of D is notified. So is the Device A. The
device at D is offered with Call Setup information, while also starting
the T sub K timer (defined as being between 4-30 seconds). A Disconnect
is sent to A now, placing it in the Idle state for at least the moment.
The device at D is waiting for the user at D to determine 1 of 3
possible paths to take:
All arguments with whether Dave's statement is exactly correct Path #1 is when nothing occurs until the T sub K timer expires. This
aside, I believe there is a great amount of truth to this in results in a determination if an alternate party was specified by D. If
concept. Every session between anyone can have all the there is, C is then connected to this alternate party. If not, C's call
prioritization anyone wants, but until there is an effective way is normally set-up into D.
to preempt another's session, it's meaningless.
But on the other hand, imagine (at least in the US) you have the Path #2 is if there is a request from C to Clear the call. This results
ability to set your voice call into Ticketmaster to get priority in A, C, and D being idle now.
treatment for all concert and sporting events tickets? Very few
would notice they had been the one's to have their calls dropped
while waiting on hold, but it would still be a unfair treatment
of network traffic loads and unfair to the person you just
preempted.
This creates the need for some form of user authentication and Path #3 is when D acknowledges the inbound Preemption by C, thereby
authorization. I don't think the major IP carriers are going to accepting the call from C. This stops the T sub K timer. The Call is
evoke or enable MLPP in their networks, but anywhere there is set-up between C to D.
Priority and the possibility of Preemption, there needs to be
some checks and balances.
On those closed boundary networks that enable this feature(s), 4.2.2 Network Preemption Event
authentication and authorization is required in my opinion;
unless, that network is perfectly traffic engineered and there
can never be a situation where network resources can bottleneck
in any way. Because, when enabled, even a single interface that
has too little resources can and likely will experience this
Preemption on that interface.
7.0 References The following is an example of the MLPP mandated process for Network-based
Preemption events occur, similar to a flow chart:
Scenario #2: Caller A and B are on an MLPP call when Caller C initiates
a higher precedence call to 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 A-B call, the network first checks to see if there are available
resources for that new call; if there is, everything works as if both
calls were on the same Precedence level with no congestion. But if there
is congestion at any common interface between the calls A to B and C to
D, there is now a search at that interface for Preemptable resources. If
there is not, a determination is made whether the Call from C is a
Precedence call. If the call from C is not, C is returned from the
network a "Disconnect: Network Resources Unavailable" indication. If the
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 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 same time B is notified of Preemption (also without
knowing where from. The network now releases (disconnects) the amount of
resources in order to have the C-D call be set-up normally.
Under this Network Preemption scenario within MLPP, the amount of
resources necessary for this call C-D, even if it requires more than one
other call to be preempted, MUST be made to satisfy the higher precedence
call completion. All necessary lower Precedence level resources MUST be
cleared for any higher Precedence Call.
4.3 MLPP Feature Scenarios
4.3.1 Bearer Services Supported
MLPP [1] is applicable to 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 Interest
The Commonalities of Interest (COI) scenario is a configuration within the
MLPP Domain such that a limited group of users primarily call each other,
and few others. This group shall have enhanced or reduced treatment of
call attempts within their assigned group. This configuration has the
choice of optionally allowing Higher Precedence calls specifically to
another within the group, or this capability is not allow. Call detail
recording shall record all Precedence call attempts from this type of
group.
4.3.3 Conferences Preset
This is a preset configured list of attendees to a conference bridge
identified by the number and key dialed at the originator's station. All
EN, EOS, MFS shall be capable of simultaneously having 10 such conferences
with up to 20 configured endstations for each conference. The ability to
add up to 5 additional participants utilizing Hook-Flash by the initiator
of the conference is permitted as well. Each conference shall have a
Precedence level set by the originator of that conference bridge.
Preemption shall occur as already specified û meaning, conferences bridges
do not get preferential treatment beyond the precedence level the bridge
is set 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
attendees, and then the bridge is disconnected to all. This includes those
who were not, under other condition, subject to a preemption event.
5.0 MoIP Requirements and solutions
Based on the previous sections, requirements for what is mandatory and
optional in any network to be MLPP compliant, here is an overview of the
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 SHALL
NOT occur, and RECOMMENDED practices that are highly desirable if imple-
mented. This should give the reader a sense of the tone of this Archi-
tecture and what is needed to ensure it is as close to compliance as
possible to the intent of MLPP.
Because MLPP is principally a symmetrical natured transport, meaning that
traffic is bi-directional and typically almost identical in the number of
packets traveling each direction, this document is for unicast traffic
only. Multicast traffic in MoIP is to be defined at a later date once the
case and need is presented to this document's author or if by chance this
effort moves into a WG, and it becomes subject to that WG's consensus
charter and directions.
MoIP can be broken into several areas of interest or specialization from
an IETF perspective: Header Marking, Routing, Signaling and/or Call
Control, and Media. A logical migration of 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 include video, it shouldn't yet take on single-directional broadcasts
of a video feed, whether live or recorded. A possibility comes to mind in
High Priority announcements to a select few receivers. But this likely
would include multicast transmissions as well, and that is outside the
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 Precedence level of each session upon
initiation of that session, and
o Recognizing congested interfaces and 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 SIP (Standard)
o MEGACO (Standard)
o MGCP (Informational only)
Presently there exist two IETF-based mechanisms to set (not signal)
Priority to a communications stream from end-to-end û with one more
potentially coming:
o Diffserv [3]
o RSVP [10]
o Potentially coming from the IETF: NSIS
o others at layer 2
An additional mechanism exists for propagating preferential treatment of
Packet flows, but more in a 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 not. Little is negotiated,
especially at the level.
5.3 SIP in MoIP
The Session Initiation Protocol (SIP) [6] "is an application-layer control
(signaling) protocol for creating, modifying and terminating sessions with
one or more participants. These sessions include Internet multimedia
conferences, Internet telephone calls and multimedia distribution."
As a Signaling Protocol, this is an ideal candidate for conveying the
Precedence level from the Calling party to the Called party. In SIP
language, one UA includes a Request, General or Requires Header-Field in
the initial INVITE message to that 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 MoIP domain, and this header-Field might
not be supported, causing either an error or confusion. Either of which is
not good for successful communications. It can be 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 ID is not a WG item within the SIP
(it was just submitted). However, it matches the RFC 791 [5] and MLPP
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 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 communication set-up is
outside the scope of this document for now.
This new ID is specifically written loosely for wide appeal. Here, once
that document becomes a Working Group Item officially (then RFC) it 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 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 have SIP communications. Their intent was originally for Mobil-
ity, but that has was a lost belief in the SIP community for quite some
time, until recently when Dean Willis stated that, as WG Co-Chair, the
Registrar Server ought to be renamed to 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 CANNOT be altered during a session. Addi-
tionally, the last Precedence level requested for a session does NOT reset
the UA's default to that new level û the Precedence level MUST start at
default without user intervention at "Routine".
The exceptions within the IP world are obviously when taking advantage of
what the circuit-switched world can't do: Determine who is making the
session request. Modern user authentication mechanisms can verify who is
making the 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 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 many ways of doing this function.
Conference Bridge Applications could be accomplished through a Proxy
initiated INVITE to 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 Precedence level of 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 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 Media Gateway Controller
(MGC).
Media Gateways translate signals from one type of network to another type
of network. 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 brains for those endstations,
or Terminations.
MEGACO has 8 Primitives or commands:
Add: Adds a 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 current values of properties, events,
signals and statistics
AuditCapabilities: Returns the possible values of properties,
events, signals and statistics
Notify: Allows the media gateway to notify the MGC of events
within MG
ServiceChange: Allows MG to inform MGC it is going in or 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 one option of 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 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 needed to ensure MEGACO has the existing mecha-
nisms for 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 anywhere. It is, however, deployed in a
wide range of vendor solutions û significantly more so than MEGACO. This
is as much to do with the timing of the Protocol û it was first to the
field, by more than a year. That kind of a 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 combination of IPDC from Level 3 Corporation and
SGCP from Bellcore. It has 8 primitives as well as 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 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 one option of 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 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 needed to 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 new function by obsoleting the first 6 bits of the old Type of
Service Byte in 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 marked at the edge of boundary of a Diffserv
Domain with what those authors called an Edge Router. If properly policed,
this ensured proper forwarding and traffic engineering within that domain.
Diffserv has no session awareness, so Preemption of an entire session
would be 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 VoIP utilizing DSCP 101110 for
EF [12]. This mandates not packet shall precede an EF marked packet in the
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 one another by session, not application.
Diffserv prioritizes packets, not sessions, in fact has no session
awareness û therefore lack the preemption capability within it of while
using it.
Perhaps a well thought out AF [13] DSCP marking where nothing is marked
EF within the entire domain. This has tremendous potential due the drop
characteristics of the AF classes if thoroughly maintained and policed
within a domain û which will be daunting at best. AF has the ability to
drop packets in any of the 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 as classes of up to 3 (AF11, AF12 and AF13 for
example). Below is the chart from [13] detailing the codepoint markings
and packet drop characteristics per class:
The RECOMMENDED values of 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 are
not defined to in order relative to 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 MPLS Label Switch Path (LSP) could extend
this Preferential Treatment functionality desired in MoIP on a wider scale
[28]. The AF DSCP value MUST be set by the Precedence level Request within
the SIP INVITE with the Resource Header, or conveyed by 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 increase as the congestion gets worse,
but the session will stay up with more like bad Cell phone quality instead
of Toll Quality. If communications is important and quality not so import-
ant, this is a viable option if the session awareness is solved for 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 in the end device. The end device determines the bandwidth necessary
for a bi-directional communication stream and sends a PATH packet out to
the destination device 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 a better way of
putting it, in COPS or Common Open Policy Service [11] with a defined
mechanism for Preemption priority policy element in [25].
Most of the hits against RSVP are regarding Mobility (or lack of support
of), no End-to-Edge reservations and the one consistent hit RSVP has taken
is it's heavyweight nature of implementation. In other words, it's hard to
code û especially in smaller devices like IP Phones which MoIP must
support. NSIS is supposed to be a new WG forming for this reason.
RSVP does lack one feature that's minimally utilized: Look ahead For Busy
(LFB) to ensure that a path between two devices is available for a call in
the future.
5.8 NSIS in MoIP
"Next Steps in Switching" is a proposed WG within the IETF to potentially
solve some of the deficiencies of RSVP while taking advantage of its
strengths. Many Internet Drafts exist already within that effort. [26]
references specifically RSVP and why it should be modified. More on this
effort will be in the next version of this draft
5.9 MPLS in MoIP
The MPLS concept assigns short fixed length labels to packets at the
ingress to an 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 can potentially provide faster and
more predictable protection and restoration capabilities in the face
of topology changes than conventional hop by hop routed IP systems."
MPLS is not intended for a campus solution û which a Base would most
categorically fall into. The use of AF BA's mentioned previously, mapped
to the LSP's of MPLS at the ingress LSR, with MPLS Protection (above)
would at this time like provide the clearest solution for MoIP.
In MoIP where MPLS is utilized, a FEC MUST be set up in all LSR's for each
Precedence level and the CRITIC/ECP level. This will allow proper mapping
of Precedence levels to AF BA's (when chosen as well) within the campus or
Base infrastructure, and on to the MPLS Cloud in between Bases in the core
of the DSN network that is MoIP compliant. If the 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 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 EF DSCP.
5.10 RTP for MoIP
Media Payload shall be provided with Real-Time Protocol [7] for voice,
video and 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 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 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
either side or both. There will likely be islands of MoIP connecting to
the existing MLPP network. This translation MUST be seamless to the
network elements and MUST be seamless to the users on either end of a
communications session/call.
This MUST include the transparent signaling of the Precedence level set on
one side of the Gateway to the other side with no alterations when the
Gateway in between MLPP and MoIP network. When the 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 might a certain dialed in circuit translates to a
certain Precedence Level situation.
6.0 IANA Considerations
There are no IANA considerations with this document
7.0 Security Considerations
It's obvious when a mechanism is utilized for preempted one traffic flow
over another, it has security considerations. However, this document is a
combination document mandating the watchful control by Government hired
employees that are already overseeing an identical network in 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 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 are currently active
attempting to extend which Protocols and 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
effort.
10.0 References
[1] ANSI specification ANSI T1.619-1992. [1] ANSI specification ANSI T1.619-1992.
[2] ANSI specification ANSI T1.619A-1994. [2] ANSI specification ANSI T1.619A-1994.
[3] James M. Polk, "draft-polk-sip-mlpp-mapping-01.txt", IETF [3] RFC 2475 "An Architecture for Differentiated Service", S. Blake, D.
Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, December 1998
[4] V. Jacobson, K. Nichols, K. Poduri, "An Expedited [4] RFC 3031 "Multiprotocol Label Switching Architecture", E. Rosen, D.
Forwarding PHB" RFC 2598, June 1999 Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, January
2001
[5] H. Folts, H. Ohno, "draft-folts-ohno-ieps-considerations- [5] RFC 791 "Internet Protocol", J. Postel, Sept 1981
00.txt" IETF Internet Draft, June 2000
[6] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. [6] RFC 2543, "SIP: Session Initiation Protocol", M. Handley, H.
Sastry, "The COPS (Common Open Policy Service) Protocol" RFC Schulzrinne, E. Schooler, J. Rosenberg March 1999
2748 January 2000
[7] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. [7] RFC 1889 "RTP: A Transport Protocol for Real-Time Applications", H.
Segers, "Megaco Protocol Version 1.0", Request for Comments: Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996
3015, November 2000
[8] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and [8] RFC 2705 "Media Gateway Control Protocol(MGCP) Version 1.0", M.
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, October 1999
Functional Specification", RFC 2205, September 1997.
[9] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP: [9] RFC 3015 "MEGACO Protocol Version 1.0", F. Cuervo, N. Greene, A.
Session Initiation Protocol" RFC 2543, March 1999 Rayhan, C. Huitema, B. Rosen, J. Segers, November 2000
[10] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg [10] RFC 2205 "Resource ReSerVation Protocol (RSVP) -- Version 1,
"draft-ietf-sip-rfc2543bis-02" IETF Internet Draft November 24, Functional Specification", R. Ed. Braden, L. Zhang, S. Estrin, S. Herzog,
2000 and S. Jamin, September 1997.
8.0 Author Information [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 2598 "An Expedited Forwarding PHB" RFC 2598, V. Jacobson, K.
Nichols, K. Poduri, June 1999
[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 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. 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, 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 James M. Polk
Cisco Systems Cisco Systems
18581 N. Dallas Parkway, Suite 100 2200 East President George Bush Turnpike
Dallas, TX 75287 Richardson, Texas 75082 USA
jmpolk@cisco.com jmpolk@cisco.com
"Copyright (C) The Internet Society (February 23rd, 2001). "Copyright (C) The Internet Society (February 23rd, 2001).
All Rights Reserved. All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished to
to others, and derivative works that comment on or otherwise others, and derivative works that comment on or otherwise explain it or
explain it or assist in its implementation may be prepared, assist in its implementation may be prepared, copied, published and
copied, published and distributed, in whole or in part, without distributed, in whole or in part, without restriction of any kind,
restriction of any kind, provided that the above copyright provided that the above copyright notice and this paragraph are included
notice and this paragraph are included on all such copies and on all such copies and derivative works. However, this document itself
derivative works. However, this document itself may not be may not be modified in any way, such as by removing the copyright notice
modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,
or references to the Internet Society or other Internet organi- except as needed for the purpose of developing Internet standards in
zations, except as needed for the purpose of developing Internet which case the procedures for copyrights defined in the Internet
standards in which case the procedures for copyrights defined Standards process must be followed, or as required to translate it into
in the Internet Standards process must be followed, or as languages other than English.
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not be re-
be revoked by the Internet Society or its successors or assigns. voked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided This document and the information contained herein is provided on an "AS
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A FITNESS FOR A PARTICULAR PURPOSE."
PARTICULAR PURPOSE."
The Expiration date for this Internet Draft is: The Expiration date for this Internet Draft is:
August 23rd, 2001 May 22nd, 2002
 End of changes. 119 change blocks. 
602 lines changed or deleted 1068 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/