QoSNSLP QSPEC Template draftietfnsisqspec03.tx - PowerPoint PPT Presentation
Title:
QoSNSLP QSPEC Template draftietfnsisqspec03.tx
Description:
QoSNSLP QSPEC Template draftietfnsisqspec03.txt – PowerPoint PPT presentation
Number of Views:54
Avg rating:3.0/5.0
Title: QoSNSLP QSPEC Template draftietfnsisqspec03.tx
1
QoS-NSLP QSPEC Template(draft-ietf-nsis-qspec-03.
txt)
Georgios Karagiannis g.karagiannis_at_ewi.utwente.nl
Jerry Ash gash_at_att.com
Andrew McDonald andrew.mcdonald_at_roke.co.uk
Attila Bader Attila.Bader_at_ericsson.com
Chuck Dvorak cdvorak_at_att.com
Al Morton acmorton_at_att.com
Yacine El Mghazli yacine.el_mghazli_at_alcatel.fr
Percy Tarapore tarapore_at_att.com
Lars Westberg Lars.Westberg_at_ericsson.com
Cornelia Kappler cornelia.kappler_at_siemens.com
2
Outline
- updates to draft
- terminology
- issues update
- QSPEC template update
- remaining open issues
3
Terminology Update
- QoS Model (QOSM)
- methodology to achieve QoS for a traffic flow
- specifies QSPEC parameters that describe QoS
how resources will be managed by RMF - proposed QOSMs RMD, Y.1541, Controlled Load
- Resource Management Function (RMF)
- QOSM-specific functions related to resource
management - processes QSPEC parameters
- QSPEC parameters include
- QoS description
- describes actual QoS in objects QoS Desired, QoS
Available, QoS Reserved, Minimum QoS - these objects are input/output parameters of RMF
- e.g., bandwidth, token bucket
- QSPEC control information
- contains parameters that govern RMF
- e.g., excess treatment
4
Issues Update
- extensive issues discussions on the list
- I-D updated to reflect discussion
- Issue 1. Need for Minimum QoS (MAY, SHOULD or
MUST)? - Status supported as a MAY
- Issue 2. Priority parameters encodings
- Status support for reservation priority,
preemption priority, defending priority as
separate parameters - Dave Oran suggests to signal these parameters at
a new ('common') NSIS layer between NSLPs NTLP - Issue 3. Need for QOSM discovery
- Status support, but different views on approach
- Dave Oran suggests capabilities analogous to RSVP
diagnostic messages (RFC 2745) or SIP options"
message - Changes TBD perhaps changes should be made in
the QoS-NSLP I-D rather than the QSPEC I-D - Issue 4. Need to differentiate QoS Model (QOSM)
QoS signaling policy (QSP)? - Status support to use QOSM terminology rather
than QSP terminology - QoS-signaling related discussions should reside
in QoS-NSLP I-D
5
Issues Update
- Issue 5. Need to signal discrete set of possible
values for parameters (in connection with using
ltMin QoSgt)? - Status some support, approaches suggested by
Ronald Bless Dave Oran some opposition,
continuous (not discrete) values OK - Changes TBD if agreed, describe mechanism to
signal multiple choices of parameter values - Issue 6. Need for "service schedule" as an
optional parameter? - Status No support, too complex, no requirement
- Issue 7. PHB parameters encodings.
- Status Discussion with David Black, resolved to
use RFC 3140 encoding of PHB - Issue 8. Need to differentiate generic optional
QSPEC parameters? - Status Dave Oran suggests breakdown by
'traffic-description' 'constraints' parameters
in lieu of generic/optional parameters - this has generally been followed in the updated
I-D - lttraffic descriptiongt ltToken Bucketgt
ltBandwidthgt - ltconstraintsgt ltPHB Classgt ltPath Latencygt, etc.
6
QSPEC Template
7
QSPEC Parameters
- QSPEC Parameters
- based on DiffServ IntServ parameters
- SHOULD be used if applicable to underlying QOSM
- mandatory QSPEC parameters
- MUST be understood by any QNE if populated
- optional QSPEC parameters
- SHOULD be understood by any QNE if populated
applicable to QOSM(s) supported by QNE - QNE MAY ignore if it does not support a QOSM
needing the optional QSPEC parameter - all QSPEC parameters mandatory except
- ltPath Latencygt, ltPath Jittergt, ltPath BERgt,
ltCtotgt, ltDtotgt, ltCsumgt, ltDsumgt - IntServ parameters ltCtotgt, ltDtotgt, ltCsumgt, ltDsumgt
rarely used - parameters can be read-only or read-write
8
QSPEC Parameters
- QSPEC ltQSPEC Control Informationgt ltQoS
Descriptiongt - ltQSPEC Control Informationgt ltNON NSLP Hopgt
ltNSLP Hopsgt ltMax NSLP Hopsgt ltExcess Treatmentgt - ltQoS Descriptiongt ltQoS Desired gt ltQoS
Availablegt ltQoS Reservedgt ltMinimum QoSgt - supports both sender receiver initiated
signaling - provides functionality corresponding to RSVP
IntServ QOSM objects (AdSpec, Tspec, RSpec)
9
QSPEC Parameters
- ltQoS Desiredgt ltTraffic Descriptiongt ltQoS Classgt
ltPrioritygt - ltTraffic Descriptiongt ltBandwidthgt ltToken
Bucketgt - ltBandwidthgt link bandwidth needed by flow RFC
2212, RFC 2215 - ltToken Bucketgt ltrgt ltbgt ltpgt ltmgt ltMgt RFC 2210
- ltQoS Classgt ltPHB Classgt ltY.1541 QoS Classgt
ltDSTE Class Typegt - ltPrioritygt ltReservation Prioritygt ltPreemption
Prioritygt ltDefending Prioritygt - ltQoS Availablegt ltTraffic Descriptiongt ltPath
Latencygt ltPath Jittergt ltPath BERgt ltCtotgt ltDtotgt
ltCsumgt ltDsumgt ltPrioritygt - ltPath Latencygt, ltPath Jittergt, ltPath BERgt,
ltCtotgt, ltDtotgt, ltCsumgt, ltDsumgt are optional
QSPEC parameters - ltQoS Reservedgt ltTraffic Descriptiongt ltQoS
Classgt ltPrioritygt ltSgt
10
Example of NSLP/QSPEC Operation
- laptop computer connected to home network with
no QoS support - laptop is QNI
- home network connected to cable access network
with dynamic QoS (DQOS) support e.g., CMSS - cable network connected to RMD-QOSM Diffserv core
network - RMD-QOSM network connected to XG-QOSM wireless
access network - XG-QOSM network connected to handheld endpoint
- handheld device is QNR
11
Example of NSLP/QSPEC Operation
- QNI populates Initiator QSPEC to achieve QoS
desired - Case 1 QNI determines ltQoS Availablegt as
follows - QNI populates ltQoS Desiredgt, ltQoS Availablegt,
possibly ltMinimum QoSgt - initializes ltQoS Availablegt to ltQoS Desiredgt
- QNEs check if ltQoS Availablegt resources can be
reserved - if not, QNE reduces parameter values in ltQoS
Availablegt reserves these values - minimum parameter values given in ltMinimum QoSgt
- zero if ltMinimum QoSgt not included
- note RSVP works similarly
- ADSPEC in PATH message collects resource
availability - RSPEC in RESERVE message based on ADSPEC
- QNI populates Initiator QSPEC if ltQoS Availablegt
satisfactory - Case 2 QNI does not do procedure to determine
ltQoS Availablegt - QNI populates Initiator QSPEC to achieve ltQoS
Desiredgt - ltQoS Desiredgt cannot be guaranteed
12
Example of NSLP/QSPEC Operation
- QNEs read interpret QSPEC parameters to best
achieve ltQoS Desiredgt using QOSM within its
domain - local QSPEC generated at RMD-QNI XG-QNI
- procedures described in Section 4.5 of QoS-NSLP
- e.g., RMD-QNI interprets ltToken Bucketgt
parameters in Initiator QSPEC to determine needed
ltbandwidthgt parameter - local QSPEC pushed on top of Initiator QSPEC
within the RMD XG domains, becomes current
QSPEC - local QSPEC popped at egress edge of the RMD XG
domains - QNR processes RESERVE request
- flow established
13
Open Issues
- specify ltQoS Availablegt discovery mechanism
- e.g., QUERY/RESPONSE capability analogous to
RSVP diagnostic messages (RFC 2745) or SIP
options" message - specify in QoS-NSLP I-D or QSPEC I-D?
- specify mechanism to signal multiple choices of
parameter values - to support ltMinimum QoSgt
- ltNON NSLP Hopgt, ltNSLP Hopsgt, ltMax NSLP Hopsgt
parameters - are these all needed?
- how does ltNON NSLP Hopgt get identified, since
nodes allowed to not support NSLP in NSIS domain? - specify in QoS-NSLP I-D or QSPEC I-D?
- need to flesh out general QSPEC formats object
formats - illustrate mobility issues in NSLP/QSPEC example
- NSLP/QSPEC/QOSM support issues
- need to define optional QSPEC parameters for new
technologies - in IETF Informational RFCs
- e.g., for non-IETF technologies such as XG
QOSM - need common set of NSLP/QSPEC processing
guidelines - ensure consistent NSLP/QSPEC processing across
domains supporting different QOSMs
Recommended
CrystalGraphics Presentations
