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

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


  • 46 Views
  • 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

MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements

draft-baker-tsvwg-mlef-concerns-01.txt


Problem statement multi level preemption and precedence

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

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

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

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

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

Control paths may not follow data paths

Military

PSTN

SS7

PSTN

VoIP

Network

VoIP

Network


Voip call control application layer exchange

VoIP Call Control:Application Layer Exchange

Military

PSTN

SS7

PSTN

VoIP

Network

VoIP

Network

Control Plane: Call Flow


Voip content traffic network layer exchange

VoIP Content Traffic:Network Layer Exchange

Military

PSTN

SS7

PSTN

Data Plane: Voice Data

VoIP

Network

VoIP

Network


Baker polk fundamental concern

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

Baker/Polk proposal for MLPP

draft-baker-tsvwg-mlpp-that-works-01.txt


End system preemption

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

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

Where to configure signaling

Military

PSTN

SS7

PSTN

Data Plane: Voice Data

VoIP

Network

VoIP

Network


Use diffserv in the data plane

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

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

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

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

RFC 3175: RSVP Aggregation


The way forward

The way forward

  • We are looking for:

    • Guidance from the IETF

    • Comments from the IETF


Implementing mlpp in the internet architecture

Implementing MLPP in the Internet Architecture

draft-baker-tsvwg-mlpp-that-works-01.txt


  • Login