Transcript Presentation 3

IP QoS signaling in the IETF:
Past, Present and Future
John A. Loughney
[email protected]
NSIS WG Chair
http://www.ietf.org/html.charters/nsis-charter.html
Background Material
“Watching the Waist of the
Protocol Hourglass”
Steve Deering IETF 51 Plenary, London
http://www.iab.org/Documents/hourglass-londonietf.pdf
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Workshop on end-to-end QoS.
What is it? How do We Get It?
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.
Workshop on end-to-end QoS.
What is it? How do We Get It?
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)
Workshop on end-to-end QoS.
What is it? How do We Get It?
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


Workshop on end-to-end QoS.
What is it? How do We Get It?
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





Workshop on end-to-end QoS.
What is it? How do We Get It?
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



Workshop on end-to-end QoS.
What is it? How do We Get It?
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




Workshop on end-to-end QoS.
What is it? How do We Get It?
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



Workshop on end-to-end QoS.
What is it? How do We Get It?
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


Workshop on end-to-end QoS.
What is it? How do We Get It?
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


Workshop on end-to-end QoS.
What is it? How do We Get It?
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


Workshop on end-to-end QoS.
What is it? How do We Get It?
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



Workshop on end-to-end QoS.
What is it? How do We Get It?
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



Workshop on end-to-end QoS.
What is it? How do We Get It?
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.
Workshop on end-to-end QoS.
What is it? How do We Get It?
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.
Workshop on end-to-end QoS.
What is it? How do We Get It?
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
Workshop on end-to-end QoS.
What is it? How do We Get It?
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.
Workshop on end-to-end QoS.
What is it? How do We Get It?
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.
Workshop on end-to-end QoS.
What is it? How do We Get It?
Summary





The IETF’s 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.
Workshop on end-to-end QoS.
What is it? How do We Get It?
Questions?
Workshop on end-to-end QoS.
What is it? How do We Get It?