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