QoS-NSLP QSPEC Template (draft-ietf-nsis-qspec-03.txt)

1. QoS-NSLP QSPEC Template(draft-ietf-nsis-qspec-03.txt) Georgios Karagiannis g.karagiannis@ewi.utwente.nl Jerry Ash gash@att.com Attila Bader Attila.Bader@ericsson.com Andrew McDonald andrew.mcdonald@roke.co.uk Chuck Dvorak cdvorak@att.com Al Morton acmorton@att.com Yacine El Mghazli yacine.el_mghazli@alcatel.fr Percy Tarapore tarapore@att.com Lars Westberg Lars.Westberg@ericsson.com Cornelia Kappler cornelia.kappler@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 <Min QoS>)? • 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: • <traffic description> = <Token Bucket> <Bandwidth> • <constraints> = <PHB Class> <Path Latency>, 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 • <Path Latency>, <Path Jitter>, <Path BER>, <Ctot>, <Dtot>, <Csum>, & <Dsum> • IntServ parameters <Ctot>, <Dtot>, <Csum>, <Dsum> rarely used • parameters can be read-only or read-write

8. QSPEC Parameters • QSPEC = <QSPEC Control Information> <QoS Description> • <QSPEC Control Information> = <NON NSLP Hop> <NSLP Hops> <Max NSLP Hops> <Excess Treatment> • <QoS Description> = <QoS Desired > <QoS Available> <QoS Reserved> <Minimum QoS> • supports both sender & receiver initiated signaling • provides functionality corresponding to RSVP IntServ QOSM objects (AdSpec, Tspec, RSpec)

9. QSPEC Parameters • <QoS Desired> = <Traffic Description> <QoS Class> <Priority> • <Traffic Description> = <Bandwidth> <Token Bucket> • <Bandwidth> = link bandwidth needed by flow [RFC 2212, RFC 2215] • <Token Bucket> = <r> <b> <p> <m> <M> [RFC 2210] • <QoS Class> = <PHB Class> <Y.1541 QoS Class> <DSTE Class Type> • <Priority> = <Reservation Priority> <Preemption Priority> <Defending Priority> • <QoS Available> = <Traffic Description> <Path Latency> <Path Jitter> <Path BER> <Ctot> <Dtot> <Csum> <Dsum> <Priority> • <Path Latency>, <Path Jitter>, <Path BER>, <Ctot>, <Dtot>, <Csum>, & <Dsum> are optional QSPEC parameters • <QoS Reserved> = <Traffic Description> <QoS Class> <Priority> <S>

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 <QoS Available> as follows: • QNI populates <QoS Desired>, <QoS Available>, & possibly <Minimum QoS> • initializes <QoS Available> to <QoS Desired> • QNEs check if <QoS Available> resources can be reserved • if not, QNE reduces parameter values in <QoS Available> & reserves these values • minimum parameter values given in <Minimum QoS> • zero if <Minimum QoS> 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 <QoS Available> satisfactory • Case 2: QNI does not do procedure to determine <QoS Available> • QNI populates Initiator QSPEC to achieve <QoS Desired> • <QoS Desired> cannot be guaranteed

12. Example of NSLP/QSPEC Operation • QNEs read & interpret QSPEC parameters to best achieve <QoS Desired> 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 <Token Bucket> parameters in Initiator QSPEC to determine needed <bandwidth> 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 <QoS Available> 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 <Minimum QoS> • <NON NSLP Hop>, <NSLP Hops>, & <Max NSLP Hops> parameters • are these all needed? • how does <NON NSLP Hop> 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