QoS Standards Challenges for NGNs

greydullΔίκτυα και Επικοινωνίες

30 Οκτ 2013 (πριν από 4 χρόνια και 10 μέρες)

80 εμφανίσεις

SOURCE:

ATIS

TITLE:

The challenges of E2E QoS for NGNs

AGENDA ITEM:

GTSC
-
2; #5.2

CONTACT:

Charles Dvorak,
cdvorak@att.com
, +1.973.236.6700

GSC9/GTSC_
016

1

GSC
-
9, Seoul

QoS Standards Challenges for NGNs

Charles Dvorak, AT&T Labs

ATIS GSC Delegation

GSC
-
9, Seoul

2

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?

GSC
-
9, Seoul

3

A QoS framework that applies to any service

(
G.1000)

GSC
-
9, Seoul

4



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

GSC
-
9, Seoul

5

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 2000

GSC
-
9, Seoul

6

QoS Issues, circa 2002 (still valid !)



Most carriers today zero out any QoS
-
related bits

(ToS, DiffServ) of incoming packets and look at

nothing but the IP destination address


IP routing protocols route around failures, not

congestion (some have congestion indicators

telling sender to use less B/W…no good for VoIP)


QoS monitoring is dependent on the types of secure

architectures (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, Seoul

7





State 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, Seoul

8

A way forward, based on

ITU
-
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, Seoul

9

Y.1541
-

IP QoS Classes and NI
-
NI Objectives

GSC
-
9, Seoul

10

Y.1541 Guidance for IP QoS Classes

QoS
Class

Applications (Examples)

Node Mechanisms

Network
Techniques

0

Real
-
Time, Jitter Sensitive,
High Interaction

(VoIP, VTC)

Separate Queue with
Preferential
Servicing, Traffic
Grooming

Constrained
Routing/Distance

1

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

Less Constrained
Routing/ Distance

2

Transaction Data, Highly
Interactive (Signalling)

Separate Queue,
Drop Priority

Constrained
Routing/Distance

3

Transaction Data,
Interactive

Less Constrained
Routing/ Distance

4

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

Long Queue, Drop
Priority

Any Route/Path

5

Traditional Applications of
Default IP Networks

Separate Queue
(Lowest Priority)

Any Route/Path

GSC
-
9, Seoul

11

Y.1221: Traffic and Congestion

Control 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 which

QoS specs can be met)

GSC
-
9, Seoul

12

Service Level Parameters to be Signaled
(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, Seoul

13

Assumed Network Functionality


Subscription Verification


Authentication


Call Admission Control


Performance Management

GW

GW

GW

Network

UNI

GW

NNI

GSC
-
9, Seoul

14

IPCablecom

QoS (J.163):

Segmented signalling model

GSC
-
9, Seoul

15

Segmented signalling model

…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, Seoul

16

What does the NGN need for e2e QoS?

(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.


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


GSC
-
9, Seoul

17

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 identified

needed action, such as a standards work plan to

achieve the needed signaling for E2E QoS.

GSC
-
9, Seoul

18

Parting Comments on

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, Seoul

19

BACKUP SLIDES

GSC
-
9, Seoul

20

Scope of SG11 QoS Signaling Reqts.

GSC
-
9, Seoul

21

One Approach: E2E Session Control

GSC
-
9, Seoul

22

Another approach: No Session Control

GSC
-
9, Seoul

23

Call Signalling

Packet Flow

QoS Signalling

Application Plane

Transport Plane

Approach of SG 16

(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, Seoul

24

Proposed (AAP) ITU
-
T Y.1291 Appendix



An architectural framework for support of
quality 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