nsis signaling for qos models (was: qos model discussion) cornelia kappler, jerry ash, chuck dvorak,...

NSIS Signaling for QoS Models (Was: QoS Model discussion)

Cornelia Kappler, Jerry Ash, Chuck Dvorak, Al Morton, Percy Tarapore, Yacine El Mghazli,

Sven Van den Bosch, Attila Bader, Lars Westberg, Georgios Karagiannis

draft-kappler-nsis-qosmodel-controlledload-00draft-ash-nsis-nslp-qos-sig-proof-of-concept-01draft-bader-rmd-qos-model-00

‘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 State held in QNEs

processing box Common : QoS-NSLP Processing box QoS Model specific: QoS Model specific QoS NLSP Processing box

Resource Management 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

E.g. IntServ Controlled-Load, RMD, ITU-T And a description of how to use QoS-NSLP to

signal for it 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

E.g. admission control, scheduling, policy control, QoS parameter accumulation (e.g. delay)…

Role of QNEs 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

ConceptQNF Edge: Stateful

QNF Interior nodes: NTLP stateless, NSLP reduced state (or stateless)

Diffserv domain

QNEQNE

QNF Edge: Stateful

PHR

E2E QoS-NSLP

PDR

PHR PHR

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

End-to-end QoS NSLP

NFingress

NTLP stateful

RESERVE

RESPONSE

RESERVE

RESPONSE(PDR:M=1)

RESERVE (PHR)RESERVE(PHR: M=1)

NFinterior

NTLP stateless

NFinterior

NTLP stateless

NFegress

NTLP stateful

RESERVE(PHR: M=1)

TEAR(PHR:TTL=1)

RMD signaling

unsuccessful

NSIS NSLP QoS Signaling Proof of Concept(draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt)

Jerry AshAT&[email protected]

Chuck DvorakAT&[email protected]

Percy Tarapore AT&[email protected]

Yacine El [email protected]

Al MortonAT&[email protected]

Sven Van den [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 & InformationExchange Parameters

BW Allocation andProtection

Y.1541 QoS Class, DS-TE class type,QoS-PAR, TRAF-PAR

Priority Routing CAC-PRTY, REST-PRTY

Priority Queuing DIFFSERV

Class-of-ServiceIdentification

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)


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]


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 Objectivesfor IP-Based Services

NetworkPerformance

Parameter

Nature of NetworkPerformance

Objective

Class 0 Class 1 Class 2 Class 3 Class 4 Class 5Un-

specified

IPTD Upper bound on themean IPTD

100ms 400 ms 100ms 400ms 1 s U

IPDV Upper bound on the1-10 -3 quantile ofIPTD minus theminimum IPTD

50ms 50 ms U U U U

IPLR Upper bound on thepacket lossprobability

1*10-3 1*10-3 1*10-3 1*10-3 1*10-3 U

IPER Upper bound 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 withSpecified Parameter Indications

Field Name Value MandatoryField?

QoS Class Requested Class 0 YesQoS Class Response Accept YesMean Transfer Delay (IPTD) 80 ms No99.9% - min Delay Var.(IPDV)

20 ms No

Loss (IPLR) NoErrored Packets (IPER) No


Example of QoS Class Rejection with Alternative Offer & Indications

Field Name Value MandatoryField?

QoS Class Requested Class 0 YesQoS Class Response Reject YesQoS Class Offered Class 1 NoMean Transfer Delay (IPTD) 180 ms No99.9% - min Delay Var.(IPDV)

No

Loss (IPLR) NoErrored Packets (IPER) No


Example of Accumulating & Signaling Current Performance

Requested CurrentlyAchieved

QoS Class Class 0 Class 0Mean Transfer Delay (IPTD) 100 ms 20 ms99.9% - min Delay Var.(IPDV)

50 ms 10 ms

Loss (IPLR) 10-3 <10-3

Errored Packets (IPER) 10-4 <10-4

Status of ParameterIndications

Allowed


Example of Accumulating & Signaling Current Performance

Requested Network 1 Network 2 CurrentlyAchieved

QoS Class Class 0 Class 0 Class 0 Class 0Mean Transfer Delay (IPTD) 100 ms 20 ms 10 ms 30 ms99.9% - min Delay Var.(IPDV)

50 ms 10 ms 10 ms 15 ms

Loss (IPLR) 10-3 <10-3 <10-3 <10-3

Errored Packets (IPER) 10-4 <10-4 <10-4 <10-4

Status of ParameterIndications

Allowed Allowed 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?

nsis signaling for qos models (was: qos model discussion) cornelia kappler, jerry ash, chuck dvorak,...

Documents