MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements

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
• 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 ControlApplication Layer Exchange
Military PSTN
SS7 PSTN
VoIP Network
VoIP Network
Control Plane Call Flow
9
VoIP Content TrafficNetwork 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 dont 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-gtdecryptor b
y 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