RMDQOSM The Resource Management in Diffserv QoS model draftietfnsisrmd01 - PowerPoint PPT Presentation

About This Presentation
Title:

RMDQOSM The Resource Management in Diffserv QoS model draftietfnsisrmd01

Description:

Standard QoS-NSLP procedure is used ... Can be used only for elastic traffic ... Consistency checks: identify and check fields that cannot be changed, RII, PDR ... – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 13
Provided by: ietf
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: RMDQOSM The Resource Management in Diffserv QoS model draftietfnsisrmd01


1
RMD-QOSM - The Resource Management in Diffserv
QoS modeldraft-ietf-nsis-rmd-01
  • A. Báder, L. Westberg, G. Karagiannis,
  • C. Kappler, T. Phelan, H. Tschofenig

2
Outline
  • Updates in the document
  • Congestion notification
  • Security consideration

3
Major updates in 01 version
  • Title, terminology changed following the
    discussions regarding the QSpec Template draft
  • 3.2 Basic features of RMD-QOSMsection was
    completed, redundant texts were removed from next
    sections
  • ltHop Countgt PHR and PDR control info was changed
    for ltNSLP Hopsgt and ltMax NSLP Hopsgt
  • New control info added ltPDR Noncegt
  • Security considerations were included

4
Severe congestion
X
Stateful edge
Stateless interior
Severe congestion (overload, edge node should be
notified, fast reaction is needed)
5
Conditions for severe congestion
  • Severe congestion due to link/router failure
    rerouting causes (up to 100) overload in the new
    path
  • Queues are over-floated, packets may be dropped
  • Packet drop cannot be tolerated,
    terminating/preempting flows are needed
  • Marking based on rate (for inelastic traffic) or
    queue length (for elastic traffic) measurement
  • Decision is done in the edge node, reaction only
    if a threshold is exceeded
  • Desirable time frame to restore normal operation
    seamless handover requirements for inelastic
    traffic, e.g. 200 ms

6
Congestion notification, proposed solutions
  • DSCP remarking of data packets, proportional
    marking
  • Advantages
  • Fast response (100 ms)
  • Terminates or pre-empts the required number of
    flows (estimation of the per flow congestion
    percentage)
  • Standard Diffserv procedures used
  • Can be used both for elastic and inelastic
    traffic
  • Can be used together with end-to-end ECN marking
  • Disadvantage requires 2 DSCPs per PHB
  • QoS-NSLP refresh messages
  • Advantages
  • Standard QoS-NSLP procedure is used
  • Terminating/pre-empting the required number of
    flows (congestion )
  • DSCP marking is not required
  • Can be used together with end-to-end ECN marking
  • Disadvantage slower response than in case of
    data marking (depending on the frequency of
    refresh messages)

7
Other proposals (discussion initiated by David
Black)
  • ECN marking, RFC 3168
  • Advantages
  • Uses standard ECN procedure
  • DSCP remarking is not required
  • Problems
  • End-to-end scope, cannot be over-defined for
    local (edge-to-edge) use
  • Can be used only for elastic traffic
  • Terminating/preempting the required number of
    flows to solve the congestion is difficult (no
    indication of the per flow congestion percentage)
  • Discovering if end points are ECN capable

8
ECN marking, probes
  • Using RFC 3168 in a local domain, sending ECN
    probe packets
  • Advantages
  • Uses standard ECN procedure
  • DSCP remarking is not required
  • Disadvantages
  • Slow response (depending on the frequency of
    probes)
  • Additional load to network
  • No association between probes and the end-to-end
    sessions
  • Terminating/preempting the required number of
    flows is difficult (no indication of the per flow
    congestion percentage)
  • How to distinguish between probe packets and
    other ECN packets?
  • Using ECN additional procedures needed
  • Discovering if Ingress and Egress are ECN capable
  • Define the probe packets

9
ECN for real-time traffic
  • draft-babiarz-tsvwg-rtecn-03
  • Advantages
  • Can be used for real-time, rate based measurement
  • DSCP remarking is not needed (but there are open
    issues)
  • Problems
  • Not standard yet
  • Terminating/preempting the required number of
    flows is difficult (no indication of the per flow
    congestion percentage)
  • Cannot be used for elastic traffic
  • How to distinguish between end-to-end and
    edge-to-edge ENC marked packets?
  • Open issues (raised in TSVWG)
  • Additional DSCPs may be needed to separate
    traffic (sharing the same PHB but) using or not
    using ECN
  • If a router is not Diffserv aware, how to
    separate ECN 3168 and rt ECN

10
Security considerations
  • Constraints
  • No per flow states within the domain, no reverse
    routing state
  • Threats
  • Injecting signaling messages by off-path, on-path
    non-NSIS nodes
  • Injecting messages by on-path NSIS nodes
  • Remarking of packets to indicate severe
    congestion
  • Possible security solutions
  • Protection of edge-to-edge messages to limit
    signaling protocol interaction with nodes within
    the domain
  • Consistency checks identify and check fields
    that cannot be changed, RII, PDR NONCE,
    consistency between intra-domain and inter-domain
    messages
  • Intrusion detection to deal with malicious node
    (packet data marking)

11
PDR Nonce
  • Protection against injection of fake RESPONSE
    messages in the RMD domain
  • Intra-domain RESPONSE is included into e2e
    RESPONSE as additional object
  • RII can not be used because RESPONSE carries e2e
    RII
  • Solution
  • QNF ingress includes PDR Nonce into
    intra-domain RESERVE
  • QNF egress includes the same PDR Nonce into
    intra-domain RESPONSE
  • Is this a good solution?
  • Reinvent the same mechanism (functionally
    identical to RII)?
  • Shall we define a new object in QoS-NSLP for
    edge-to-edge security?
  • QNF QNF QNF
    QNF
  • ingress interior
    interior egress
  • NTLP stateful NTLP stateless NTLP
    stateless NTLP stateful

  • RESERVE
  • --------gt RESERVE
  • ----------------------------------
    -----------gt
  • RESERVE'
  • --------------gt

12
Plans for next version
  • Work on severe congestion handling by refresh
    procedure, investigate the real-time ECN marking
  • Complete bi-directional reservation section
  • Complete security considerations
  • PDR Nonce and impact on QoS-NSLP
Write a Comment
User Comments (0)
About PowerShow.com