Transcript MLEF Without Capacity Admission Does Not Satisfy MLPP

MLEF Without Capacity
Admission Does Not Satisfy
MLPP Requirements
draft-baker-tsvwg-mlefconcerns-01.txt
Problem statement: Multi-Level
Preemption and Precedence

MLPP:



Telephone policy system in which calls are
classified by “importance”
Today, this is military. Proposals are on the table
for civilian service as well.
The rule:


More important calls override less important calls
when congestion occurs within a network.
“Override” may mean


Called handset hangs up to make way for incoming call
Another call is preempted to make way for a more
important call
Important MLPP
characteristics


Need to be able to authenticate and
authorize certain calls
Need to be able to preempt calls



Need to signal to users using standard
signals


At handset – incoming call preempts existing call
In network – new bandwidth requirement
preempts lower precedence usage of the
bandwidth
Chime/tone indicating preemption
Need to preserve existing calls at all
precedences
DISA Assured Service

Definition



draft-pierce-ieprep-assured-service-req-02.txt
draft-pierce-ieprep-assured-service-arch-02.txt
Proposed Implementation




draft-pierce-ieprep-pref-treat-examples-02.txt
draft-ietf-sipping-reason-header-for-preemption00.txt
draft-ietf-sip-resource-priority-02.txt
draft-silverman-diffserv-mlefphb-03.txt
The Multi-Level Expedited
Forwarding (MLEF) PHB

Builds on the RFC 3246 EF PHB




Assigns DSCPs to packets by call
precedence
Policer on low jitter queue drops excess
MLEF traffic preferentially by call
precedence.
Call Admission not required
Note that admission is an issue in EF
as well as in MLEF
SIP/H.323 Call Admission
Control (CAC)

Call control considerations:

Basic policy rules:


Location-based CAC:



“yes, you have paid your bill”
“permit up to N calls to neighboring Gatekeepers or SIP
Proxy-based systems”
No direct knowledge of IP Routing or Congestion
Solution:

RFC 3312 defines interaction with RSVP
Control paths may not follow
data paths
Military
PSTN
SS7
PSTN
VoIP
Network
VoIP
Network
VoIP Call Control:
Application Layer Exchange
Military
PSTN
SS7
PSTN
VoIP
Network
VoIP
Network
Control Plane: Call Flow
VoIP Content Traffic:
Network Layer Exchange
Military
PSTN
SS7
PSTN
Data Plane: Voice Data
VoIP
Network
VoIP
Network
Baker/Polk fundamental
concern:



While the Assured Service talks about CAC, it does
not require it, and specifically does not request
Capacity Admission
SIP Call Admission without RFC 3312 Capacity
Admission is inadequate
MLEF without Capacity Admission is a very different
service from MLPP



Dropping voice packets is inadequate to protect lower
priority calls
Even advanced codecs don’t fix this
Dropping calls based on MLEF-induced loss is
indeterminate
Baker/Polk proposal for MLPP
draft-baker-tsvwg-mlpp-thatworks-01.txt
End system preemption

Deals with case where call with
elevated precedence is placed to a
handset that is in use


SIP Resource Priority Header


Alice calls Bob who is talking with Carol at
lower precedence
Label call with precedence level
SIP Call Failure Reason Code

Reason = “Call Preempted”
Network bandwidth
admission

It is possible, using RSVP, to



Use control plane signaling to
deterministically authorize/preempt
bandwidth
Start up data transmission only when
authorized
Not maintain state in over-provisioned
systems (LAN and Optical WAN with no
congested interfaces)
Where to configure signaling
Military
PSTN
SS7
PSTN
Data Plane: Voice Data
VoIP
Network
VoIP
Network
Use Diffserv in the Data Plane




Basic RFC 3246 (EF) operation should
be sufficient in our opinion
Pierce et al would like to use multiple
code points for Voice Activity
management
Whatever
RFCs 2996 (DCLASS) and 2998
(Framework)
Identification, Authentication,
and Authorization



Use SIP AAA procedures in session layer
signaling
Use RSVP Authentication/
Authorization/Preemption procedures in
Capacity Admission
RFCs



2747, 3097 Cryptographic Authentication
2750, 2753 , 3182 Policy Control
3181 Preemption Policy Element
Encryption and aggregation
Red side devices see end
to end connectivity with
peers in other red-side
networks and their own
Red Side
Red Side
Black Side
Red Side
Red Side
Black side is a maze of
tunnels, at least in a
sense. Could be literal
tunnels or LSPs, but in
any event data flows are
encryptor->decryptor
by IP address
RFC 3175: RSVP Aggregation

Designed to permit aggregation of reservations


Supports



Service Provider Voice…
IP Source/Destination Pairs
Tunnels and LSPs
Mechanism:


RSVP reservation for aggregate is the sum of the
reservations using it
Traffic in aggregate identified/services by DSCP
The way forward

We are looking for:


Guidance from the IETF
Comments from the IETF
Implementing MLPP in the
Internet Architecture
draft-baker-tsvwg-mlpp-thatworks-01.txt