IP QoS signaling in the IETF: Past, Present and Future

1
IP QoS signaling in the IETF Past, Present and
Future

• John A. Loughney
• john.loughney_at_nokia.com
• NSIS WG Chair
• http//www.ietf.org/html.charters/nsis-charter.htm
  l

2
Background Material

• Watching the Waist of the Protocol Hourglass
• Steve Deering -
• IETF 51 Plenary, London
• http//www.iab.org/Documents/hourglass-london-ietf
  .pdf

3
Ancient History

• First there was ST-II, which begat RSVP.
• IntServ was developed concurrently.
• RSVP started simple, but eventually ended up as a
  fairly complicated protocol, partly related to
  multicast support and IntServ support.
• In reaction to scalability concerns, DiffServ
  work was started.

4
Major Work Related to QoS in the IETF

• Integrated Services (intserv)
• Resource Reservation Setup Protocol (rsvp)
• Integrated Services over Specific Link Layers
  (issll)
• Differentiated Services (diffserv)
• Resource Allocation Protocol (rap)
• Policy Framework (policy)
• Sub-IP (ccamp, gsmp, mpls, tewg)
• Next Steps in Signaling (nsis)

5
Integrated Services (intserv)

• Concluded December 2000
• The working group will focus on defining a
  minimal set of global requirements which
  transition the Internet into a robust
  integrated-service communications infrastructure.
  
• The Use of RSVP with IETF Integrated Services -
  RFC2210
• Specification of the Controlled-Load Network
  Element Service - RFC2211
• Specification of Guaranteed Quality of Service -
  RFC2212

6
Resource Reservation Setup Protocol (rsvp)

• Concluded May 2001
• The primary purpose of this working group is to
  evolve the RSVP specification and to introduce it
  into the Internet standards track. The task of
  the RSVP Working Group, creating a robust
  specification for real-world implementations of
  RSVP and parallel IETF working group that is
  considering the service model for integrated
  service.
• RSVP Version 1 Applicability - RFC 2208
• RSVP Version 1 Message Processing Rules - RFC
  2209
• RSVP Operation Over IP Tunnels - RFC 2746
• RSVP Cryptographic Authentication - RFC 2747
• RSVP Refresh Overhead Reduction Extensions - RFC
  2961
• RSVP Cryptographic Authentication-New Message
  Type - RFC 3097

7
Integrated Services over Specific Link Layers
(issll)

• Concluded May 2002
• The ISSLL Working Group defines specifications
  and techniques needed to implement Internet
  Integrated Services capabilities within specific
  network technologies.
• Format of the RSVP DCLASS Object - RFC 2996
• Specification of the Null Service Type - RFC 2997
• A Framework For IntServ Operation Over Diffserv
  Networks - RFC 2998
• RSVP Reservations Aggregation - RFC 3175

8
Differentiated Services (diffserv)

• Concluded Feb 2003
• The differentiated services approach to providing
  quality of service in networks employs a small,
  well-defined set of building blocks from which a
  variety of aggregate behaviors may be built.
• Definition of the DiffSerField in the IPv4 and
  IPv6 Headers - RFC 2474
• An Architecture for Differentiated Services - RFC
  2475
• An Expedited Forwarding PHB - RFC 3246
• Assured Forwarding PHB Group - RFC 2597
• Def. of DiffServ Per Domain Behaviors Rules for
  their Specification - RFC 3086

9
Resource Allocation Protocol (rap)

• Dormant
• The working group will define general-purpose
  objects that facilitate the manipulation of
  policies and provisioned objects available
  through COPS and COPS-PR. Where appropriate,
  these will include frameworks clarifying the
  applicability of COPS objects and the best
  practices for the definition of additional
  objects defined in other working groups.
• The COPS (Common Open Policy Service) Protocol -
  RFC 2748
• COPS usage for RSVP - RFC 2749
• A Framework for Policy-based Admission Control -
  RFC 2753
• COPS Usage for Policy Provisioning - RFC 3084

10
Policy Framework (policy)

• Dormant
• This working group has three main goals. First,
  to provide a framework that will meet these
  needs. Second, to define an extensible
  information model and specific schemata compliant
  with that framework that can be used for general
  policy representation. Third, to extend the core
  information model and schema to address the needs
  of QoS traffic management.
• Policy Core Information Model - Version 1
  Specification - RFC 3060
• Terminology for Policy-Based Management - RFC
  3198
• Policy Core Information Model Extensions - RFC
  3460

11
Common Control and Measurement Plane (ccamp)

• Active
• Coordinates the work within the IETF defining a
  common control plane and a separate common
  measurement plane for ISP and SP core tunneling
  technologies.
• GMPLS Signaling Functional Description - RFC 3471
• GMPLS Signaling CR-LDP Extensions - RFC 3472
• GMPLS Signaling RSVP-TE Extensions - RFC 3473

12
General Switch Management Protocol (gsmp)

• Active
• Provides switch configuration control and
  reporting, port management, connection control,
  QoS and traffic engineering control and the
  reporting of statistics and asynchronous events
  for MPLS label switch devices, all either from or
  to a third party controller.
• GSMP V3 - RFC 3292
• GSMP Packet Encapsulations for ATM, Ethernet and
  TCP - RFC 3293
• GSMP Applicability - RFC 3294

13
Multiprotocol Label Switching (mpls)

• Active
• Responsible for standardizing a base technology
  for using label switching and for the
  implementation of label-switched paths over
  various link-level technologies.
• Requirements for Traffic Engineering Over MPLS -
  RFC 2702
• Multiprotocol Label Switching Architecture - RFC
  3031
• RSVP-TE Extensions to RSVP for LSP Tunnels - RFC
  3209
• MPLS Support of Differentiated Services - RFC 3270

14
Internet Traffic Engineering (tewg)

• Active
• Defined as that aspect of Internet network
  engineering concerned with the performance
  optimization of traffic handling in operational
  networks, with the main focus of the optimization
  being minimizing over-utilization of capacity
  when other capacity is available in the network.
• Overview and Principles of Internet Traffic
  Engineering - RFC 3272
• Applicability Statement for Traffic Engineering
  with MPLS - RFC 3346
• Network Hierarchy and Multilayer Survivability -
  RFC 3386
• Requirements for Support of DiffServ-aware MPLS
  Traffic Engineering - RFC 3564

15
NSIS Charter (1/2)

• The Next Steps in Signaling Working Group is
  responsible for standardizing an IP signaling
  protocol with QoS signaling as the first use
  case. This working group will concentrate on a
  two-layer signaling paradigm. The intention is
  to re-use, where appropriate, the protocol
  mechanisms of RSVP, while at the same time
  simplifying it and applying a more general
  signaling model.
• The existing work on the requirements, the
  framework and analysis of existing protocols will
  be completed and used as input for the protocol
  work.

16
NSIS Charter (2/2)

• NSIS will develop a transport layer signaling
  protocol for the transport of upper layer
  signaling. In order to support a toolbox or
  building block approach, the two-layer model will
  be used to separate the transport of the
  signaling from the application signaling. This
  allows for a more general signaling protocol to
  be developed to support signaling for different
  services or resources, such as NAT firewall
  traversal and QoS resources. The initial NSIS
  application will be an optimized RSVP QoS
  signaling protocol. The second application will
  be a middle box traversal protocol. It may be
  that a rechartering of the working group occurs
  before the completion of this milestone.

17
What NSIS Will Do

• Requirements of a QoS Solution for Mobile IP -
  RFC 3583
• Submitted 'Signaling Requirements' to IESG for
  publication as an Informational RFC.
• Submit 'RSVP Security Properties' to IESG as
  Informational RFC
• Submit 'NSIS Threats' to IESG as Informational
  RFC
• Submit 'Analysis of Existing Signaling Protocols'
  to IESG as Informational RFC
• Submit 'Next Steps in Signaling Framework' to
  IESG for publication as Informational RFC
• Submit 'NSIS Transport Protocol' to IESG for
  publication for Proposed Standard
• Submit 'NSIS QoS Application Protocol' to IESG
  for publication for Proposed Standard
• Submit 'NSIS Middle Box Signaling Application
  Protocol' to IESG for publication for Proposed
  Standard

18
NSIS Overview

• Requirements of a QoS Solution for MIP
  Requirements for Signaling Protocols documents
  set the goals for the work.
• Next Steps in Signaling Framework sets the
  stage for the protocol work.
• The NTLP QoS NSLP NAT/FW Traversal NSLP
  protocols are the main deliverables.
• Focusing initially on on-path signaling as this
  is seen as a more critical problem for the
  Internet.
• Off-path signaling may worked on, in a later
  phase, but there scalability and end-to-end
  concerns.

19
NSIS Summary

• The work done in NSIS is meant to be general, not
  focused on a single application and meant to
  support other IETF protocols.
• The current goal of the WG is to achieve a
  scalable solution for signaling, but it is not
  meant as a complete solution.
• There is more work to be done.

20
Summary

• The IETFs is concerned with working on solvable
  problems.
• QoS is more than just QoS classes, parameters,
  applications, etc.
• Internet-wide deployment issues are a concern.
• Good possibilities for collaboration between the
  IETF and other bodies, such as the ITU exist.
• Participation is welcome.

21
Questions?