Download QoS model intro

NSIS Signaling for QoS Models
(Was: QoS Model discussion)
draft-kappler-nsis-qosmodel-controlledload-00
draft-ash-nsis-nslp-qos-sig-proof-of-concept-01
draft-bader-rmd-qos-model-00
Cornelia Kappler, Jerry Ash, Chuck Dvorak,
Al Morton, Percy Tarapore, Yacine El Mghazli,
Sven Van den Bosch, Attila Bader, Lars Westberg,
Georgios Karagiannis
‘Goal’

Validate QoS NSLP by combining it with
three different QoS Models

A QoS Model is a mechanism for achieving QoS



E.g. IntServ, DiffServ
QoS-NSLP can signal for different QoS Model
Actual resource description is carried in the
QSpec Object of RESERVE
How can we validate the
operation of QoS-NSLP?



analyze and specify how QoS-NSLP signaling
is used for different QoS models
clarification of what is a QoS model, and its
relation to NSIS signaling
three examples:



IntServ Controlled-Load Service
Standardization work in the ITU-T for
QoS signaling requirements
NSIS signaling for DiffServ aware routers
(old: Resource Management in DiffServ (RMD))
First validation results
QoS Model specific Control Information – where is it processed?
























+---------------+
|
Local
|
|Applications or|
|Management (e.g|
|for aggregates)|
+---------------+
^
^
QoS Model specific
V
QoS-NSLP
V
Processing?
+----------+
+----------+
+---------+
| QoS-NSLP |
| Resource |
| Policy |
|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
+----------+
+----------+
+---------+
. ^
|
*
^
| V
.
*
^
+----------+
*
^
|
NTLP
|
*
^
|Processing|
*
V
+----------+
*
V
|
|
*
V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.
.
*
V
First validation results

State held in QNEs

processing box



Resource Management box


Common : QoS-NSLP Processing box
QoS Model specific: QoS Model specific QoS NLSP Processing box
Resource allocation dependant
Do we need a standardized feedback mechanism for failed
sender-initiated reservations?

E.g. local QNE returns error RESPONSE containing why reservation
failed




Next RESERVE may also fail because of a problem further down the path
Next stateful node returns error RESPONSE
E.g. RESERVE continues up to QNR, collecting more information
Terminate error RESPONSE at QNE who added the failed QSpec?
First validation results:
What is a QoS Model (I)

Need to refine definition of “QoS Model”

A mechanism for achieving QoS


And a description of how to use QoS-NSLP to
signal for it


E.g. IntServ Controlled-Load, RMD, ITU-T
E.g. current QoS Model IDs
After yesterdays discussion, we think that


saying “we define QoS Models for NSIS” is
misleading
NSIS is about QoS Signaling Models
First validation results:
What is a QoS Model (II)

A description of how to signal for a QoS Model
should include:


Objects to be carried in RESERVE (i.e. QSpec), QUERY
RESPONSE and NOTIFY
how that information should be treated or interpreted
by the Resource Management and QoS Model specific
NSLP Processing


Role of QNEs


E.g. admission control, scheduling, policy control, QoS
parameter accumulation (e.g. delay)…
E.g. location, frequency, …
Usage of QoS-NSLP messages to signal the QoS model
What next?


Details of signaling for three QoS-model examples
(next three presentations)
Question: Further NSIS QoS Signaling Model work

Working Group IDs? proceeding to Informational RFCs
for


Examples of how NSIS can signal for QoS models
Guidelines for signaling for QoS models


Including templates for Objects carried in RESERVE (i.e. QSpec),
RESPONSE, QUERY, NOTIFY?
Current QoS Model Signaling IDs differ considerably in what they
describe
NSIS signaling model for
DiffServ aware routers
(Old: RMD QoS-NSLP model)
Attila Báder, Georgios Karagiannis,
Lars Westberg
Main goal

Validate how NSIS can be used for
signaling within DiffServ domains
Concept
QNF Interior nodes: NTLP stateless,
NSLP reduced state (or stateless)
QNF Edge:
Stateful
QNF Edge:
Stateful
QNE
QNE
Diffserv domain
PDR
E2E QoS-NSLP
Basic features


Provides dynamic signaling for Diffserv
routers
Scalability :


separating per-hop and per-domain reservation
per-Diffserv traffic class reservation states in
interior nodes
NTLP features
Reduced NTLP functions in QNF interior
nodes
 Simple datagram mode transport
(UDP/IP)
 Routing states in QNF edge nodes and
no routing states in QNF interior nodes
 E2E-ignore function for some NSLP
messages

NSLP features





Sender initiated reservation
Per-Diffserv traffic class reservation states in all
nodes, and if needed additional per-flow
reservation states in QNF edges
QSpec: PHR, PDR objects
Uses simple bandwidth as QoS parameter
PHR control fields can be modified by QNF
interior nodes
Unsuccessful reservation: marking of
signaling packets
NF
ingress
NTLP stateful
NF
interior
NTLP stateless
NF
interior
NTLP stateless
NF
egress
NTLP stateful
End-to-end QoS NSLP
RESERVE
RMD signaling
RESERVE
RESERVE (PHR)
RESERVE
(PHR: M=1)
unsuccessful
RESPONSE(PDR:M=1)
RESPONSE
TEAR(PHR:TTL=1)
RESERVE
(PHR: M=1)
NSIS NSLP QoS Signaling Proof of Concept
(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)
Jerry Ash
AT&T
[email protected]
Al Morton
AT&T
[email protected]
Chuck Dvorak
AT&T
[email protected]
Percy Tarapore
AT&T
[email protected]
Yacine El Mghazli
Alcatel
[email protected]
Sven Van den Bosch
Alcatel
[email protected]
Outline
(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)
 proposed QoS signaling model based on 3 ITU-T Recommendations
 later versions to specify objects & control details
 Qspec template proposed
 consider standardizing some signaling functions within NSLP
– common to all QoS models rather than proprietary within Qspec
– e.g., performance requirements such as delay, delay variation, packet loss,
etc.
 next steps
 as in intro discussion
Background & Motivation
 proposed QoS signaling model based on 3 ITU-T Recommendations
on QoS signaling (summarized in the draft):
 [TRQ-QoS-SIG] "Signaling Requirements for IP-QoS," January 2004
– specifies QoS parameter & control information
• based on Y.1541 QoS classes
» quantitative guarantees for delay, delay variation, packet loss
• include CAC & restoration priority
– specifies requirements for signaling IP-QoS information
• at user-network interface (UNI)
• across network interfaces(NNI)
• enable request, negotiation & delivery of Y.1541 QoS classes from
UNI to UNI, spanning NNIs as required
» objects for accumulation along path
» how info should be interpreted in network
 [Y.1541] "Network Performance Objectives for IP-Based Services," May
2002
– specifies 6 QoS service classes
• specific objectives for delay, delay variation, loss for each class
Background & Motivation
 proposed QoS signaling model based on 3 ITU-T Recommendations on
QoS signaling (summarized in the draft):
 [E.361] "QoS Routing Support for Interworking of QoS Service Classes
Across Routing Technologies," May 2003
– identifies QoS routing functions & associated parameters to be signaled across
networks
QoS Routing Function
Supported Signaling & Information
Exchange Parameters
BW Allocation and
Protection
Y.1541 QoS Class, DS-TE class type,
QoS-PAR, TRAF-PAR
Priority Routing
CAC-PRTY, REST-PRTY
Priority Queuing
DIFFSERV
Class-of-Service
Identification
SI, CT, LC
Qspec Template
(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)
 QSpec ID (allows IANA reservation of QSpec parameter
combinations):
 IANA specified
 Traffic Envelope/Conformance:
 algorithm is token-bucket
 conformance parameters
–
–
–
–
–
–
token bucket rate (Br)
peak rate (Rp)
peak bucket size (Bp)
sustainable rate (Rs)
sustainable bucket size (Bs)
maximum allowed packet size (M)
 Excess Treatment:
 excess traffic may be dropped, shaped and/or remarked.
 excess treatment (EXTR)
Qspec Template
(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)
 Offered Guarantees:
 QoS-REQUEST-PAR are qualitative guarantees
–
–
–
–
–
Y.1541 QoS class
DiffServ behavior
service identity (SI)
class type (CT)
link capability (LC)
 QoS-ACCUM-PAR are quantitative guarantees
– transfer delay, delay variation, packet loss
– used in RESERVE/QUERY or RESPONSE message to collect information
along the path
 Service Schedule:
 indicates start time & end time of service
 specified in Appendix B/[TRQ-QoS-SIG]
Qspec Template
(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)
 Priority and Reliability:
 CAC Priority (CAC-PRTY)
 Restoration Priority (RES-PRTY)
 Monitoring requirements:
 As specified in Appendix B/[TRQ-QoS-SIG]
Next Steps
 progress draft as an individual Informational RFC
 with feedback & review by NSIS WG
 seek IANA registration for QoS model
 consider standardizing some signaling functions within NSLP
 common to all QoS models rather than proprietary within Qspec
 e.g., performance requirements such as delay, delay variation,
packet loss, etc.
Backup Slides
Background & Motivation
(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)
 “NSLP for Quality-of-Service Signaling” provides
 an NSIS signaling layer protocol (NSLP) to signal QoS reservations
 support for different reservation models
 a generic Qspec template to specify individual QoS signaling models
 “there are already a number of QoS models specified outside of the
IETF, for example the ITU, 3GPP, etc… [we should] allow consenting
peers to use the QoS NSLP with particular QoS models… one way to
achieve this is to use IANA registries to register QoS models, and the
QoS NSLP to signal these.”
 John Loughney, 27 October 2003
 “take 1 or 2 existing QoS models & detail them in a separate draft, as a
sort of proof-of-concept for the QoS NSLP”
 John Loughney, 19 November 2003
Y.1541 Network Performance Objectives
for IP-Based Services
Network
Performance
Parameter
IPTD
IPDV
IPLR
IPER
Nature of Network
Performance
Objective
Upper bound on the
mean IPTD
Upper bound on the
1-10 -3 quantile of
IPTD minus the
minimum IPTD
Upper bound on the
packet loss
probability
Upper bound
Class 0
Class 1
Class 2
Class 3
Class 4
Class 5
Unspecified
100ms
400 ms
100ms
400ms
1s
U
50ms
50 ms
U
U
U
U
1*10-3
1*10-3
1*10-3
1*10-3
1*10-3
U
1*10-4
U
Y.1221-based Traffic Contracts
• IP transfer capabilities include: the service model, traffic
descriptor, conformance definition and any QOS commitments.
• Transfer Capabilities include Dedicated Bandwidth, Statistical
Bandwidth, and Best Effort.
Example of QoS Signaling Requirements
Based on Y.1541 QoS Classes
Example of QoS Class Acceptance with
Specified Parameter Indications
Field Name
Value
QoS Class Requested
QoS Class Response
Mean Transfer Delay (IPTD)
99.9% - min Delay Var.
(IPDV)
Loss (IPLR)
Errored Packets (IPER)
Class 0
Accept
80 ms
20 ms
Mandatory
Field?
Yes
Yes
No
No
No
No
Example of QoS Signaling Requirements
Based on Y.1541 QoS Classes
Example of QoS Class Rejection with
Alternative Offer & Indications
Field Name
Value
QoS Class Requested
QoS Class Response
QoS Class Offered
Mean Transfer Delay (IPTD)
99.9% - min Delay Var.
(IPDV)
Loss (IPLR)
Errored Packets (IPER)
Class 0
Reject
Class 1
180 ms
Mandatory
Field?
Yes
Yes
No
No
No
No
No
Example of QoS Signaling Requirements
Based on Y.1541 QoS Classes
Example of Accumulating & Signaling Current Performance
Requested
QoS Class
Mean Transfer Delay (IPTD)
99.9% - min Delay Var.
(IPDV)
Loss (IPLR)
Errored Packets (IPER)
Status of Parameter
Indications
Class 0
100 ms
50 ms
10-3
10-4
Currently
Achieved
Class 0
20 ms
10 ms
<10-3
<10-4
Allowed
Example of QoS Signaling Requirements
Based on Y.1541 QoS Classes
Example of Accumulating & Signaling Current Performance
QoS Class
Mean Transfer Delay (IPTD)
99.9% - min Delay Var.
(IPDV)
Loss (IPLR)
Errored Packets (IPER)
Status of Parameter
Indications
Requested
Network 1
Network 2
Class 0
100 ms
50 ms
Class 0
20 ms
10 ms
Class 0
10 ms
10 ms
10-3
10-4
<10-3
<10-4
Allowed
<10-3
<10-4
Allowed
Currently
Achieved
Class 0
30 ms
15 ms
<10-3
<10-4
Allowed
A QoS Signaling Model for
IntServ Controlled-Load
Draft-kappler-nsis-qosmodel-controlledload-00
Cornelia Kappler, Siemens AG
What is IntServ Controlled-Load Service?
 IntServ Controlled Load Service is
(in NSIS terms) a QoS Model
 This ID is the corresponding NSIS QoS Signaling Model
 How to signal for IntServ Controlled Load using NSIS
 RFC 2210 specifies how to signal for
Controlled-Load Service using RSVP
 Controlled-Load Service (RFC 2211)
 Provides approximately e2e service of an unloaded best-effort
network
 QoS parameters signaled are Token Bucket and MTU
 Implemented per “network element”, i.e. per-router or per-subnet
– Can be used for
• Reserving resources per-flow per-router
• Admission control at edge of DiffServ domains
• Admission control into MPLS clouds
How to signal for Controlled-Load Service with NSIS
 Role of QNEs
 One or more QNE per “network element”
 QoS-model specific Control Information
 None
 Content of QSpec
 Token bucket and MTU
 Objects to be carried in RESPONSE and QUERY
 Tbd. Query for MTU?
 Processing Rules in QNEs
 Admission Control based on token bucket and MTU conformance
– How find out about MTU?
• Cf discussion of “feedback on failed reservations”
 Usage of QoS-NSLP messages
 Sender-initiated RESERVE
 QUERY for finding out about MTU of path before reserving?
Backup:
First validation results

Format of QSpec?

Separate immutable from mutable fields?


In RSVP: mutable fields are in AdSpec
Separate QoS Model Specific Control
Information from QoS parameters?