RMDQOSM The Resource Management in Diffserv QoS model draftietfnsisrmd01 - PowerPoint PPT 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
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
Recommended
CrystalGraphics Presentations
