Quality of Service at the Internet Engineering Task Force

1
Quality of Service at the Internet Engineering
Task Force

• Robert Hancock
• Siemens/Roke Manor Research
• John Loughney
• Nokia NSIS w.g. chair

2
QoS What Is It?

• In its broadest sense, QoS refers to the ability
  to ensure the quality of the end user (human)
  experience
• 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)

3
The IETF What Is It?

• A collection of individuals, developing standards
  for the Internet since 1986
• 1-2 thousand people, meeting 3 times/year
• 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
• WGs are organised into Areas the Area Directors
  constitute the Internet Engineering Steering
  Group (IESG)
• The Internet Architecture Board (IAB) provides
  architectural guidance and handles liaisons

4
Scope of the IETF

• Formally, the IETF will work on a topic if
• There is community momentum behind it
• People who want work done must drive it
• A working group has the mandate to do it
• WG activities are scoped by charters
• Or, a working group can be formed to do it
• WG formation requires (IESG) approval
• 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

5
The Role of the IETF in QoS

• Work on QoS has focussed on the stack above the
  wire and below the application
• We dont standardise media coding but care about
  how it drives QoS requirements
• We dont standardise link layers but care about
  how they constrain network behaviour
• The IETF likes to develop solution components
  which are widely applicable
• We dont standardise or mandate network
  architectures for delivering QoS
• But we have 2 models to help understand how
  specific technologies fit the big picture

6
Current QoS Activities

• Work in the IETF on QoS-related subjects has its
  centre of gravity in the Transport Area
• E2E protocols for transporting real time or other
  non-best-efforts traffic
• avt, dccp, pwe3
• Application and network signalling and control
• NSIS, mmusic, sip/sipping
• Performance monitoring and measurement
• ippm (see also Operations Area)
• Specific activities on voice (less QoS-centric)
• iptel, speechsc, (megaco)

7
Principal IETF QoS Technologies
8
Integrated Services

• Defined the Integrated Services network
• Fairly complete QoS architecture
• Assumes homogeneous network environment
• Assumes multicast requirement
• But most impact on the signalling protocol
• 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

9
Differentiated Services

• 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
• 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
• A component of the QoS capabilities of MPLS (QoS
  component, RFC 3270)

10
ISSLL

• Definition of how to use IntServ in particular
  network environments, i.e. how the abstract
  classes can be used in the real world
• Defines interactions with lower layers (service
  mappings, adaptation, admission control..)
• Proposed mappings include
• ATM networks (RFC 2379-2382)
• Ethernet LANs (RFC 2814-2816)
• Slow links (RFC 2688/89)
• DiffServ networks (RFC 2998, 3175)
• IntServ-over-DiffServ completes the DiffServ
  architecture with resource management capabilities

11
Next Steps in QoS Architectures

• 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
• Identified the critical architectural gaps
• Routing resource management monitoring and
  accounting application and service development
  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

12
Signalling Protocols

• Considered as one free standing component
  applicable to several overall QoS solutions
• 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
• Recent recognition that the RSVP concepts can be
  used as the basis of a more general protocol
  suite for an Internet control plane
• This is the topic of the NSIS w.g.

13
Conclusions

• The IETF has developed a large body of work for
  many components of QoS solutions
• The work includes making protocols support or
  coexist with other technologies (ATM, )
• Community cultural bias towards generic,
  component based approaches supports this
• 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