"Quality of Service at the Internet Engineering Task Force" Workshop on "End-to-End Quality of Service. What is it? How do we get it?" Geneva, 1-3 October 2003.

1. International Telecommunication Union
Quality of Service at the
Internet Engineering Task Force
Robert Hancock
Siemens/Roke Manor Research
John Loughney
Nokia; NSIS w.g. chair
Workshop on End-to-End Quality of Service.What is it? How do we get it?
Geneva, 1-3 October 2003

2. QoS: What Is It?
ITU-T
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)
Workshop on End-to-End Quality of Service. What is it? How do we get it? 2
1-3 October 2003

3. The IETF: What Is It?
ITU-T
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
Workshop on End-to-End Quality of Service. What is it? How do we get it? 3
1-3 October 2003

4. Scope of the IETF
ITU-T
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
Workshop on End-to-End Quality of Service. What is it? How do we get it? 4
1-3 October 2003

5. The Role of the IETF in QoS
ITU-T
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‟
Workshop on End-to-End Quality of Service. What is it? How do we get it? 5
1-3 October 2003

6. Current QoS Activities
ITU-T
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)
Workshop on End-to-End Quality of Service. What is it? How do we get it? 6
1-3 October 2003

7. Principal IETF QoS Technologies
ITU-T
QoS Architectures Signalling Protocols
1994
Integrated
Services
1995
(IntServ)
Resource
RFC1633
1996 Reservation
Protocol
Integrated
1997 (RSVP)
Services
RFC2205
over
1998
Specific
Differentiated Link Layers
1999
Services (ISSLL)
(DiffServ)
2000
RFC2475
2001
2002
Next Steps in
Timescale shows period of major activity; Signaling
2003
Reference is 'top level' RFC (NSIS)
(not necessarily a standards track document)
Workshop on End-to-End Quality of Service. What is it? How do we get it? 7
1-3 October 2003

8. Integrated Services
ITU-T
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
Workshop on End-to-End Quality of Service. What is it? How do we get it? 8
1-3 October 2003

9. Differentiated Services
ITU-T 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)
Workshop on End-to-End Quality of Service. What is it? How do we get it? 9
1-3 October 2003

10. ISSLL
ITU-T 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
Workshop on End-to-End Quality of Service. What is it? How do we get it? 10
1-3 October 2003

11. Next Steps in QoS Architectures
ITU-T 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”
Workshop on End-to-End Quality of Service. What is it? How do we get it? 11
1-3 October 2003

12. Signalling Protocols
ITU-T
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.
Workshop on End-to-End Quality of Service. What is it? How do we get it? 12
1-3 October 2003

13. Conclusions
ITU-T
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
Workshop on End-to-End Quality of Service. What is it? How do we get it? 13
1-3 October 2003