International Telecommunication Union

Workshop on End-to-End Quality of Service.What is it? How do we get it?Geneva, 1-3 October 2003

Quality of Service at the

Internet Engineering Task Force

Robert HancockSiemens/Roke Manor Research

John LoughneyNokia; NSIS w.g. chair

ITU-T

21-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

QoS: What Is It?

o In its broadest sense, QoS refers to “the

ability to ensure the quality of the end user

(human) experience”

o This can encompass a huge range of

technological and other aspects

• Multimedia coding and quality measurement

• SLA definition and performance verification

• Application behaviour to select QoS

• High performance physical and link layers

• Packet delivery (primary IETF focus)

ITU-T

31-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

The IETF: What Is It?

o A collection of individuals, developing standards for the Internet since 1986

• 1-2 thousand people, meeting 3 times/year

o Work is done in working groups, which usually define and develop a specific technology and then terminate

• Currently 130 WGs, of which 90 are active

o WGs are organised into Areas; the Area Directors constitute the Internet Engineering Steering Group (IESG)

o The Internet Architecture Board (IAB) provides architectural guidance and handles liaisons

ITU-T

41-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Scope of the IETF

o Formally, the IETF will work on a topic if:

o There is community momentum behind it

• “People who want work done must drive it”

o A working group has the mandate to do it

• WG activities are scoped by charters

o Or, a working group can be formed to do it

• WG formation requires (IESG) approval

o The technical direction is „IETF-compatible‟

• Fit the general architecture of the Internet; be compatible with/complementary to existing protocols; match a well-defined problem

ITU-T

51-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

The Role of the IETF in QoS

o Work on QoS has focussed on the stack “above the wire and below the application”

• We don‟t standardise media coding but care about how it drives QoS requirements

• We don‟t standardise link layers but care about how they constrain network behaviour

o The IETF likes to develop solution components which are widely applicable

• We don‟t standardise or mandate network architectures for delivering QoS

• But we have 2 models to help understand how specific technologies fit the „big picture‟

ITU-T

61-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Current QoS Activities

o Work in the IETF on QoS-related subjects has its centre of gravity in the “Transport” Area

o E2E protocols for transporting real time or other non-best-efforts traffic

• avt, dccp, pwe3

o Application and network signalling and control

• NSIS, mmusic, sip/sipping

o Performance monitoring and measurement

• ippm (see also Operations Area)

o Specific activities on voice (less QoS-centric)

• iptel, speechsc, (megaco)

ITU-T

71-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Principal IETF QoS Technologies

1994

1995

1996

1997

1998

1999

2000

2001

2002

2003

Integrated

Services

(IntServ)

RFC1633

Differentiated

Services

(DiffServ)

RFC2475

Resource

Reservation

Protocol

(RSVP)

RFC2205

Next Steps in

Signaling

(NSIS)

Integrated

Services

over

Specific

Link Layers

(ISSLL)

Timescale shows period of major activity;

Reference is 'top level' RFC

(not necessarily a standards track document)

QoS Architectures Signalling Protocols

ITU-T

81-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Integrated Services

o Defined the “Integrated Services” network

• Fairly complete QoS architecture

• Assumes homogeneous network environment

• Assumes multicast requirement• But most impact on the signalling protocol

o Three primary components

• Service definitions: a template (RFC 2215/6) and two service element definitions (RFC2211/2)

• No performance targets for different traffic types

• Protocol to request resources (RFC 2210)

• Admission control • Enables more complex policy control architectures

ITU-T

91-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Differentiated Services

o Complement to IntServ in the network „core‟ but with opposite emphasis in scope:

• Simple differentiation without admission control or feedback

• Emphasis on aggregate behaviour

• Provides tools without defining QoS

o Three primary components

• DSCPs– processing method identified by standardised bit pattern (RFC 2474)

• PHBs – QoS behaviour per hop; some PHBs currently defined (RFC 3246 „Expedited Forwarding‟, 2597 „Assured Forwarding‟, 3248 „Expedited Forwarding with Delay Bounds‟)

• PDBs – QoS behaviour per domain; template to allow coupling of classifiers, traffic conditioners and specific PHBs – RFC 3086

o A component of the QoS capabilities of MPLS (QoS component, RFC 3270)

ITU-T

101-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

ISSLL

o Definition of how to use IntServ in particular network environments, i.e. how the abstract classes can be used in the real world

o Defines interactions with lower layers (service mappings, adaptation, admission control..)

o Proposed mappings include:

• ATM networks (RFC 2379-2382)

• Ethernet LANs (RFC 2814-2816)

• „Slow‟ links (RFC 2688/89)

• DiffServ networks (RFC 2998, 3175)

o IntServ-over-DiffServ completes the DiffServ architecture with resource management capabilities

ITU-T

111-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Next Steps in QoS Architectures

o In 2000, the IAB produced RFC 2990 “Next Steps for the IP QoS Architecture”

• Considered a broader question of possible architectural approaches and their requirements

• Compared IntServ and DiffServ style networks

o Identified the critical architectural “gaps”

• Routing; resource management; monitoring and accounting; application and service development; incremental, heterogeneous deployment

o 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”

ITU-T

121-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Signalling Protocols

o Considered as one „free standing‟ component applicable to several overall QoS solutions

o Core protocol: RSVP (RFC 2205), originally designed to support the IntServ architecture

• Many later extensions for performance and additional scenarios (e.g. from ISSLL work)

• MPLS (“RSVP-TE”) and DiffServ functionality

• Security and policy control interactions

o Recent recognition that the RSVP concepts can be used as the basis of a more general protocol suite for an „Internet control plane‟

o This is the topic of the NSIS w.g.

ITU-T

131-3 October 2003 Workshop on End-to-End Quality of Service. What is it? How do we get it?

Conclusions

o The IETF has developed a large body of work for many components of QoS solutions

o The work includes making protocols support or coexist with other technologies (ATM, …)

• Community „cultural bias‟ towards generic, component based approaches supports this

o The IETF has key attributes which support a central role in making a world with e2e QoS:

• „Wide reach‟ – public telecommunications, enterprise, consumer, mobile, …

• Ubiquitous use of IP by new applications

• Community expertise in protocol development