Mlef without capacity admission does not satisfy mlpp requirements
Sponsored Links
This presentation is the property of its rightful owner.
1 / 20

MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements. draft-baker-tsvwg-mlef-concerns-01.txt. Problem statement: Multi-Level Preemption and Precedence. MLPP: Telephone policy system in which calls are classified by “ importance ”

Download Presentation

MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements


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

    • 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

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

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:

      • “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

Control paths may not follow data paths









VoIP Call Control:Application Layer Exchange









Control Plane: Call Flow

VoIP Content Traffic:Network Layer Exchange





Data Plane: Voice Data





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


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”

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





Data Plane: Voice Data





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


by IP address

Designed to permit aggregation of reservations

Service Provider Voice…


IP Source/Destination Pairs

Tunnels and LSPs


RSVP reservation for aggregate is the sum of the reservations using it

Traffic in aggregate identified/services by DSCP

RFC 3175: RSVP Aggregation

The way forward

  • We are looking for:

    • Guidance from the IETF

    • Comments from the IETF

Implementing MLPP in the Internet Architecture


  • Login