1. MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements
draft-baker-tsvwg-mlef-concerns-01.txt

2. 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

3. Important MLPP characteristics
Need to be able to authenticate and authorize certain calls
Need to be able to preempt calls
At handset – incoming call preempts existing call
In network – new bandwidth requirement preempts lower precedence usage of the bandwidth
Need to signal to users using standard signals
Chime/tone indicating preemption
Need to preserve existing calls at all precedences

4. DISA Assured Service Definition Proposed Implementation
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-preemption-00.txt
draft-ietf-sip-resource-priority-02.txt
draft-silverman-diffserv-mlefphb-03.txt

5. 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

6. SIP/H.323 Call Admission Control (CAC)
Call control considerations:
Basic policy rules:
“yes, you have paid your bill”
Location-based CAC:
“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

7. Control paths may not follow data paths
Military
PSTN
SS7
PSTN
VoIP
Network
VoIP
Network

8. VoIP Call Control: Application Layer Exchange
Military
PSTN
SS7
PSTN
VoIP
Network
VoIP
Network
Control Plane: Call Flow

9. VoIP Content Traffic: Network Layer Exchange
Military
PSTN
SS7
PSTN
Data Plane: Voice Data
VoIP
Network
VoIP
Network

10. 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

11. Baker/Polk proposal for MLPP
draft-baker-tsvwg-mlpp-that-works-01.txt

12. End system preemption
Deals with case where call with elevated precedence is placed to a handset that is in use
Alice calls Bob who is talking with Carol at lower precedence
SIP Resource Priority Header
Label call with precedence level
SIP Call Failure Reason Code
Reason = “Call Preempted”

13. 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)

14. Where to configure signaling
Military
PSTN
SS7
PSTN
Data Plane: Voice Data
VoIP
Network
VoIP
Network

15. 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)

16. 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

17. 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

18. RFC 3175: RSVP Aggregation
Designed to permit aggregation of reservations
Service Provider Voice…
Supports
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

19. The way forward We are looking for: Guidance from the IETF
Comments from the IETF

20. Implementing MLPP in the Internet Architecture
draft-baker-tsvwg-mlpp-that-works-01.txt