1 / 20

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. MLPP: Telephone policy system in which calls are classified by “ importance ”

bairn
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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

More Related