1 GSC-9, Seoul

Charles Dvorak, cdvorak@att.com, +1.973.236.6700CONTACT:

GTSC-2; #5.2AGENDA ITEM:

The challenges of E2E QoS for NGNsTITLE:

ATISSOURCE: GSC9/GTSC_016

QoS Standards Challenges for NGNsQoS Standards Challenges for NGNs

Charles Dvorak, AT&T LabsATIS GSC Delegation

GSC-9, Seoul2

A well-accepted definition from ITU-T E.800:“the collective effects of service performance which determine the degree of satisfaction of a user of the service.” (This means QoS is always really E2E.)

Will QoS be important for NGNs?Every industry forum that has addressed this issue has concluded the answer is an emphatic “YES!”For example, at the 2002 ATIS VoIP Summit, service providers agreed that inadequate QoS for future, IP-based services was “a potential show-stopper.”

QoS—what is it, and what about the NGN?QoS—what is it, and what about the NGN?

GSC-9, Seoul3

SERVICE QUALITY CRITERIA

SPEED

1

ACCURACY

2

AVAILABILITY

3

RELIABILITY

4

SECURITY

5

SIMPLICITY

6

FLEXIBILITY

7

SERVICE FUNCTION

Sales & Pre-Contract Activities 1

Provision 2

Alteration 3

Service Support 4

Repair 5

SE

RV

ICE

MA

NA

GE

ME

NT

Cessation 6

Connection Establsh. 7

Information Transfer 8

CO

NN

EC

TIO

N

QU

AL

ITY

Connection Release 9

BILLING 10

NETWORK / SERVICE MANAGMENT BY CUSTOMER 11

A QoS framework that applies to any serviceA QoS framework that applies to any service

((G.1000)G.1000)

GSC-9, Seoul4

CUSTOMERSERVICEPROVIDER

Customer’sQoS

Requirements

QoS OfferedBy

Provider

QoSAchieved byProvider

QoSPerceived

By Customer

Four Views of QoS (G.1000) that Four Views of QoS (G.1000) that always apply (PSTN, ISDN, NGN)always apply (PSTN, ISDN, NGN)

GSC-9, Seoul5

The IAB’s RFC 2990 “Next Steps for the IP QoS Architecture” compared IntServ and DiffServ style networks and considered broader architectural approaches / requirements, including critical “gaps” in routing; resource management; monitoring and accounting; application and service development; and incremental, heterogeneous deployment.

Conclusion: What is needed is “a set of QoS mechanisms and a number of ways these mechanisms can be configured to interoperate in a stable and consistent fashion”

Needed QoS Steps: The IETF circa 2000Needed QoS Steps: The IETF circa 2000

GSC-9, Seoul6

QoS Issues, circa 2002 (still valid !)QoS Issues, circa 2002 (still valid !)

• Most carriers today zero out any QoS-related bits(ToS, DiffServ) of incoming packets and look atnothing but the IP destination address

• IP routing protocols route around failures, notcongestion (some have congestion indicatorstelling sender to use less B/W…no good for VoIP)

• QoS monitoring is dependent on the types of securearchitectures (MPLS nets, IPsec VPNs, SSL VPNs…)

• Scalability, security and restorability still big issues

• Full IP integration of service types still a pipe dream

GSC-9, Seoul7

State of E2E IP QoS in 2004State of E2E IP QoS in 2004 • Application requirements are known; needed QoS

classes defined; monitoring metrics widely used

• QoS is not just per-domain but end-to-end and thus has to be signaled / provisioned across networks.Requirements for needed protocols largely done;now very active positioning on different solutions.

• Much work needed to ensure these solutions are: Reliable, secure and scalable Capable of supporting all traffic/service mixes/priorities Resilient regarding any between-layer dependencies

(e.g., rapid restoration of QoS as well as lower layers)

GSC-9, Seoul8

A way forward, based onA way forward, based onITU-T Y.1541 and Y.1221ITU-T Y.1541 and Y.1221

• Y.1541: QoS classes quantify user application needs in terms of IP network performance

• Y.1221: “traffic contract” complements QoS class by describing flow characteristics/limits

Together, the two Recommendations specify the key data needed for IP network QoS signaling.

GSC-9, Seoul9

Y.1541 - IP QoS Classes and NI-NI ObjectivesY.1541 - IP QoS Classes and NI-NI Objectives

NetworkPerformance

Parameter

Nature ofNetwork

PerformanceObjective Class 0 Class 1 Class 2 Class 3 Class 4

Class 5(Un-

specified)IPTD Upper bound

on the meanIPTD

100 ms 400 ms 100 ms 400 ms 1 s U

IPDV Upper boundon the 1-10-3

quantile ofIPTD minusthe minimum

IPTD

50 ms 50 ms U U U U

IPLR Upper boundon the packet

lossprobability

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

IPER Upper bound 1*10-4 U

GSC-9, Seoul10

Y.1541 Guidance for IP QoS ClassesY.1541 Guidance for IP QoS ClassesQoS Class

Applications (Examples) Node MechanismsNetwork

Techniques

0Real-Time, Jitter Sensitive, High Interaction

(VoIP, VTC)

Separate Queue with Preferential Servicing, Traffic Grooming

Constrained Routing/Distance

1Real-Time, Jitter Sensitive, Interactive (VoIP, VTC)

Less Constrained Routing/ Distance

2Transaction Data, Highly Interactive (Signalling)

Separate Queue, Drop Priority

Constrained Routing/Distance

3Transaction Data, Interactive

Less Constrained Routing/ Distance

4Low Loss Only (Short Transactions, Bulk Data, Video Streaming)

Long Queue, Drop Priority

Any Route/Path

5Traditional Applications of Default IP Networks

Separate Queue (Lowest Priority)

Any Route/Path

GSC-9, Seoul11

Y.1221: Traffic and CongestionY.1221: Traffic and Congestion Control in IP Based NetworksControl in IP Based Networks

Traffic Contract

• Dedicated BW• Statistical BW• Best Effort

• Max Pkt Size• Token Bucket

–Rate (Rp, Rs)–Size (Bp, Bs)

(Y.1541)

IP Transfer Capability

Traffic Descriptor

QoS Class

(conditions under whichQoS specs can be met)

GSC-9, Seoul12

Service Level Parameters to be Signaled Service Level Parameters to be Signaled (came partly out of ATIS VoIP Summit in 2002)(came partly out of ATIS VoIP Summit in 2002)

• Y.1541 QoS class (objective numerical levels for IP Loss Ratio, IP Transfer Delay, and IP Delay Variation may be indicated by specifying the Y.1541 QoS class itself as a signalling parameter)

• Traffic Parameters from Y.1221 Peak rate (Rp) Peak bucket size (Bp) Sustainable rate (Rs) Sustainable bucket size (Bs) Maximum allowed packet size (M)

• IP DSCP (optional) as specified in RFC 2474• Priority/reliability of the service

GSC-9, Seoul13

Assumed Network FunctionalityAssumed Network Functionality

• Subscription VerificationSubscription Verification• AuthenticationAuthentication• Call Admission ControlCall Admission Control• Performance ManagementPerformance Management

GW GWGW

Network

UNIGW

NNI

GSC-9, Seoul14

IPCablecomIPCablecom QoS (J.163):QoS (J.163):Segmented signalling modelSegmented signalling model

T0912600-01

MTA CM Cable CMCable MTAANBackbone Reservation

AN

Access Reservation Access Reservation

GSC-9, Seoul15

Segmented signalling modelSegmented signalling model

T0912600-01

MTA CM Cable CMCable MTAANBackbone Reservation

AN

Access Reservation Access Reservation

……but what if the path looks like:but what if the path looks like:

ISP-1(Intserv)

ISP-2(over-prov)

BB-1(Diffserv)

BB-2(MPLS-TE)

Cable

xDSL?

Wireless w/3GPP sig.

GSC-9, Seoul16

What does the NGN need for e2e QoS?What does the NGN need for e2e QoS?(The following currently being proposed in ATIS)(The following currently being proposed in ATIS)

• A standard set of IP network QoS classes and associated traffic descriptors, for characterizing end-to-end IP packet flows in managed IP networks (or alternatively, more than one specification and an associated set of interworking standards for mapping among them).

• Standard signaling capabilities enabling independent operators of managed IP networks to cooperate in establishing end-to-end IP flows supporting particular user-requested QoS classes and traffic profiles.

• Standards (or guidelines) for relating signaled QoS and traffic specifications with network resource sharing mechanisms capable of supporting them.

GSC-9, Seoul17

Progress towards E2E QoS Requirements for an e2e QoS protocol are being developed in SG11.

IP QoS Signaling "proofs of concept" are being kicked around in the IETF's NSIS WG. AT&T recently submitted :http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt , which is based on 3 ITU-T QoS signaling items:

1) [TRQ-QoS-SIG] "Signaling Requirements for IP-QoS," January 2004.

2) [Y.1541] "Network Performance Objectives for IP-Based Services," 2002.

3) [E.361] "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies," 2003.

Also, the ATIS VoIP Focus Group has identifiedneeded action, such as a standards work plan to achieve the needed signaling for E2E QoS.

GSC-9, Seoul18

Parting Comments onParting Comments on End-to-End QoS End-to-End QoS Y.1541/Y.1221 specs exist for NI-to-NI IP QoS, but

there is no widely accepted delivery mechanism yet Still unclear if QoS-related resource control of

others’ networks will ever be allowed; even if some carriers agree, interoperability is still an issue

Over-provisioning still central to many solutions No forum is advancing Reliability and Restoration

mechanisms for e2e IP QoS in any tangible way yet Recent attention on IP emergency communications

have served as a magnet for all of the shortcomings of e2e QoS proposals in IP space (IETF’s IEPREP)

GSC-9, Seoul19

BACKUP SLIDESBACKUP SLIDES

GSC-9, Seoul20

Scope of SG11 QoS Signaling Reqts.Scope of SG11 QoS Signaling Reqts.

TE TEGW . . .

Network

End-End Network (IP Service QoS)

Network Network

Customer Installation Customer Installation

User-to-User Connection (Transport and higher QoS)

TE GWTerminal EquipmentGatewayRouter Protocol Stack

LAN LAN

IP Network Cloud

UNI UNI

*NI Network Interface

GW GW GW GW GW

DSTSRC

NNI NNI

Protocol Requirements

GSC-9, Seoul21

Call / session control

Packet forwarding

Gate control

Session IP flow

Call / session control (with indication of QoS requirements)

QoS mechanism (e.g. RSVP or Diffserv packet marking)

End-s

yst

em

End-s

yst

em

1

2 3

4

5 6

7

One Approach: E2E Session ControlOne Approach: E2E Session Control

GSC-9, Seoul22

Packet forwarding

Gate control

Session IP flow

Call / session control (with indication of QoS requirements)

QoS mechanism (e.g. RSVP or Diffserv packet marking)

En

d-sy

stem

En

d-sy

stem

1

2 3

4

5 6

7

Policy Control

Another approach: No Session ControlAnother approach: No Session Control

GSC-9, Seoul23

Call Signalling

Packet Flow

QoS Signalling

Application Plane

Transport Plane

Approach of SG 16Approach of SG 16 (see new H.360) (see new H.360)

Service Domain 1

Transport Domain 1

Transport Domain 2

Transport Domain 3

Service Domain 2

Application Level QoS Signalling

H.323 Annex N

Vertical QoS Signalling

(H.trans.cont)

Transport Level QoS Signalling

(H.trans.cont or NSIS)

H.323 Annex N

H.323 Annex N

GSC-9, Seoul24

Proposed (AAP) ITU-T Y.1291 Appendix–Proposed (AAP) ITU-T Y.1291 Appendix– An architectural framework for support of An architectural framework for support of quality of service (QoS) in packet networksquality of service (QoS) in packet networks

Bearer Layer

Bearer Control Layer

Service Control Layer

Edge Router

Transit Router

Core Router

Service Control Server

Bearer Resource Manager

LSP