1 / 21

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

IP QoS signaling in the IETF: Past, Present and Future. John A. Loughney john.loughney@nokia.com NSIS WG Chair http://www.ietf.org/html.charters/nsis-charter.html. email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio.

linh
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IP QoS signaling in the IETF: Past, Present and Future John A. Loughney john.loughney@nokia.com NSIS WG Chair http://www.ietf.org/html.charters/nsis-charter.html

  2. email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio... Background Material “Watching the Waist of the Protocol Hourglass” Steve Deering - IETF 51 Plenary, London http://www.iab.org/Documents/hourglass-london-ietf.pdf Workshop on end-to-end QoS. What is it? How do We Get It?

  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. Workshop on end-to-end QoS. What is it? How do We Get It?

  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) Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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. Workshop on end-to-end QoS. What is it? How do We Get It?

  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. Workshop on end-to-end QoS. What is it? How do We Get It?

  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 Workshop on end-to-end QoS. What is it? How do We Get It?

  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. Workshop on end-to-end QoS. What is it? How do We Get It?

  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. Workshop on end-to-end QoS. What is it? How do We Get It?

  20. 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?

  21. Questions? Workshop on end-to-end QoS. What is it? How do We Get It?

More Related