Subject: Charter for Integrated Services WG

From: Craig Partridge <[email-masked]>
Date: Fri, 21 Jan 94 09:14:36 -0800

Hi Allison:
    
    OK -- here it is.  A charter and a description of the management
structure.  Please let me know if you have any questions.

    Also, I've gotten some questions about why this WG is being proposed
in the Transport Area.  This decision was made before I signed up, but
as I understand the thinking, the idea is that Integrated Services issues
cross several layers of the architecture and that Transport lies nicely
in the middle of the problem (between demanding applications and request
to IP, with the job of achieving communications between them).  I expect
as we start spinning off WGs, they'll go in whatever area fits them.

Craig

***************************************************************************

Integrated Services Working Group Management Plan

The General Chair is Craig Partridge (BBN).  The Co-Chairs are Dave Clark
(MIT), Scott Shenker(XEROX), and John Wroclawski (MIT)

The dual reasons for this management structure are:

    (1) The WG will have do considerably more outreach into the larger
    networking community than the typical IETF working group.  For instance,
    one of the important tasks is to convince the larger public that IP
    is suitable for integrated services.  So we need management manpower
    to do outreach.

    (2) The WG has a lot of work to do and swiftly.  Even though we plan to
    spin off WGs as fast as we can, a lot of key architectural decisions will
    need to be made in one place (e.g., by this WG) if the final architecture
    is to be sound.  So we need management manpower just to keep the WG
    moving.

So Craig has primary responsibility for keeping the WG moving, and Dave,
Scott, and John have primary responsibility for outreach to different
communities (and titles sufficient to show they can speak for the WG).

***************************************************************************

Integrated Services Working Group Charter

Description of Working Group:

    Recent experiments demonstrate the capability of packet switching
    protocols to support Integrated Services - the transport of audio,
    video, real-time, and classical data traffic within a single network
    infrastructure.  These experiments suggest that expanding the Internet
    service model would better meet the needs of these diverse applications.
    The purpose of this working group is to specify this enhanced service model
    and then to define and standardize certain interfaces and requirements
    necessary to implement the new service model.

    The working group will focus on defining a minimal set of global
    requirements which transition the Internet into a robust
    integrated-service communications infrastructure.  Enhancements to
    individual protocols (e.g., adding additional routing information to
    routing protocols, or choosing IP queueing disciplines for routers)
    will be left to other working groups, except in those rare cases where
    detailed definitions of behavior are critical to the success of the
    enhanced architecture.

    Extending the Internet service model raises a series of questions.
    The working group will focus on the three problems listed below:

    (1) Clearly defining the services to be provided. The first task faced
    by this working group is to define and document the enhanced Internet
    service model.

    (2) Defining the application service, router scheduling and (general)
    subnet interfaces.  The working group must define at least three
    high-level interfaces; that expressing the application's end-to-end
    requirements, that defining what information is made available to
    individual routers within the network, and the additional expectations
    (if any) the enhanced service model has for subnet technologies.  The
    working group will define these abstract interfaces.

    (3) Developing router validation requirements which can ensure that
    the proper service is provided.  We assume that the Internet will
    continue to contain a heterogeneous set of routers, running different
    routing protocols and using different forwarding algorithms.  The
    working group will seek to define a minimal set of additional router
    requirements which ensure that the Internet can support the new
    service model. Rather than presenting specific scheduling and admission
    control algorithms which must be supported, these requirements will likely
    take the form of behavioral tests which measure the capabilities of
    routers in the integrated services environment. This approach is used
    because no single algorithm seems likely to be appropriate in all
    circumstances at this time.

    We expect to generate three RFCs as a products of performing these
    tasks.

    In addition, because many of the integrated services concepts are new,
    the WG may produce informational RFCs explaining specific algorithms
    that may be appropriate certain circumstances and may host some
    educational meetings to assist both IETF members and members of the
    larger Internet community to understand the proposed enhancements to IP.

    The WG proposes to hold regular meetings beyond those held at IETF.

Goals and Milestones:

    [These milestones are conservative.  We hope to finish much more quickly
    than this.]

    4/94: Seattle IETF: First full meeting of working group.  Discuss
    proposed service model.  Discuss strategy for addressing other issues.

    11/94: Submit informational RFC on service model.  Discuss initial
    draft documents describing router requirements and strategies for
    behavioral testing.  Hold coordination meeting with RSVP Working Group
    (and perhaps others as well) to discuss Application (end-to-end) PI.

    3/95: Continue discussion of router requirements. Develop
    experimental verification of behavioural testing approach. Continue
    discussion of API and subnet models.

    11/95: Submit router requirement RFC.  Finalize API.

    3/96: Submit API.  Finalize subnet model.

    6/96: Submit subnet RFC.

The WG mailing list is [email-masked]