A large part of what was established and reinforced during the QoS Sessions at the San Jose Conference was the mission of the Quality of Service Task Force and the positioning within the Industry and The Open Group.

The Steering Committee of The QoS Task Force: DISA, Hewlett-Packard, Sun Microsystems, Securities Industry Automation Corporation (SIAC), Systems/Technology Development Corporation (S/TDC), Teknowledge, and The Open Group’s Advanced Research & Development Team, has been, over the past quarter, defining and validating the area of QoS which most need our attention and which we are particularly well suited to address.  That niche is captured by our mission of Linking Enterprise QoS with Networking QoS in order to address true End-to-End Quality of Service: from the enterprise through wide area networks to remote services and back again.

The Open Group, as an organization focused on enterprise interoperability, is well positioned to take on the challenge of true End-to-End QoS with:

• The multiple forums under one umbrella within The Open Group: Architecture, Directory Interoperability, Enterprise Management, Mobile Management, Real-Time & Embedded Systems, Security, add to the value proposition as the innate cross sectional aspects of QoS allow us to draw on the expertise within our other forums as we move forward with Enterprise and End-to-End QoS. This past session in San Jose, featured joint Sessions with both the Enterprise Management and Real-Time & Embedded Systems Forums.
• The Open Group’s Advanced Research & Development Team brings three years of experience in designing and implementing mission critical Quality of Service Solutions.
• The Open Group’s inclusive philosophy toward other consortia encourages us to establish close working relationships with other consortia, which are already working on parts of the end-to-end QoS solution particularly on the networking aspects of QoS.  The QoS Task Force will not duplicate effort being done in networking QoS, but will, instead, work together with those consortia to achieve true end-to-end QoS.

Minutes and Format of the QoS  3-day Open Session in San Jose:

One of the main objectives of the Quality of Service Task Force is to help validate that end-user's requirements for Quality of Service are being propagated and can be measured at all component levels within the various IT industry segments along the end-to-end information delivery path – from the enterprise through the networks to remotes services and back again.

Towards that end, the Open 3-day Quality of Service Meeting focused on solutions in the market today, which are responding to Quality of Service requirements, and on gathering Quality of Service requirements and measurements from both a customer-vendor and a vendor-vendor perspective.

Through presentations and interactive working sessions we discussed how best to map QoS requirements to QoS measurements.

The meeting was organized as serial sub-sessions devoted to Quality of Service as it relates to the following IT segments:

•      Internet Applications
•      Mission Critical Enterprise Servers and Applications
•      Service Providers and Mobile Computing
•      Real-Time and Embedded Systems
•      Routers, Switches and Test Equipment

For access to Agenda, Presentations, Speaker Bios, click here

QoS Component Model - Objectives and Purpose:

The interactive sessions at San Jose, began with an overview of the QoS Component Model, followed by in depth discussion and feedback.

The QoS Task Force component Model is a working document, developed by the QoS Steering Committee, where input from program participants is anticipated to shape the component map until it has achieved the deliverables of the QoS Task Force. These deliverables are:

• Provide a summary of the QoS constituents and components involved in end-to-end delivery of QoS.
• ·         Provide functional components that can be understood from a system-wide level and further expanded in detail at a unit level by actual implementations, designs or sub-architectures.
• Provide a generic QoS architecture (or pattern) that can be referenced in application-specific architectures that deliver on QoS requirements

When the component map has reached an agreeable understanding of the parts involved in delivering end-to-end QoS, then there are several intended purposes for the component map:

• Allow customers, QoS vendors, infrastructure providers, service providers (including IT enterprises) and standards providers to identify their role and relationships with others and to participate in the process of clarifying requirements, interfaces and functionality to deliver End-to-End Quality of Service.
• Divide up the problem space so that the QoS program can roadmap and somewhat isolate the problem areas to be focused on.
• Provide a framework for a top-down process for specifying, measuring, predicting, controlling and guaranteeing levels of service along the end-to-end delivery path.

Feedback on the Component Model was solicited and recorded at the beginning of each of interactive session and will be fed back to the working groups who are focusing on the evolution of the Component Model.  The Component Model was also used as a framework for Interactive Break-Out discussions:

Break-out Interactive Discussions:

After the component model discussions, we broke into smaller groups.  The exercise involved picking an application and recording the services required from the application in its execution and then mapping requirements and measurements to each of those services.  This proved to be a significant task, with each group taking it in a particular direction indicative of the experience and business/technological perspective of the participants.

Much of the interactive discussion focused on Service Level Agreements and the issues involved in mapping SLAs to the rules, policies, and measurements necessary for enforcement of Service Level Policies.  Report back presentations were given, and the output recorded to be used within the newly established working groups going forward.

Milestones, Working Groups:

The final session was devoted to establishing milestones and working groups for the QoS Task Force.  The following Milestones were agreed to.

Short Term Milestones:

• Founding Membership – March 1^st Deadline
• Roadmap - Q2
• Working Groups Established, Focus Areas defined, and Deliverables begun – Q2
• White Paper (Objectives/Component Map)- Q2
• Building Partnerships with QoS Consortia - Q2

Long Term Milestones:

• Depend on Roadmap, Members’ Objectives
• To Be Defined – Q2

Upcoming Events:

• 2 Regional Open Meetings - Q2

(One Day Open Meeting on QoS and Enterprise Management – Speakers, Panel Discussion) –encourage your colleagues to attend)

• Boston/Burlington Massachusetts – Sponsored by Sun - March 12^th
• Cupertino, CA - Sponsored by Hewlett-Packard – March 15^th

Working Groups Established:

The three following working groups were established:

• Technical
• Policy
• Business

Each of these groups will focus on driving tasks and issues that fall into the category indicative of the Working Group Name.  A Brainstorming session identified various areas that require attention. The prioritization of the identified tasks/issues is left up to each of the working groups.

The members/participants who were in attendance chose which working groups they would like to participate in. The groups will continue to meet throughout the quarter via teleconference to prioritize focus areas, identify deliverables and begin work on deliverables.

Tasks/Issues To be Filtered and Prioritized by Working Group Participants

Measurements

• Measurements

  - Mapping Requirements to Measurements

  - Kernel, Network, Services, Applications.

• QOS APIs – Identify what/where APIs would make sense
• Process Communication

  - Control systems feedback loops (e.g flight control)

• Liaison DIF, OMG, IETF, DMTF, Java, OASIS, W3C
• Validation (Reality Check) with vertical solutions problem space

Policy Working Group - Brainstorming Session

Tasks/Issues To be Filtered and Prioritized by Working Group Participants

• Taxonomy
• Service Level Agreements
• Requirements
• Process
• Federated QoS Requirements (See Component Model)
• Component Model
• Revisions

SLA, Mapping/validating with various existing Architectures

• Automated SLAs

Business Working Group - Brainstorming Session

Tasks/Issues To be Filtered and Prioritized by Working Group Participants

• Outreach – to Members to encourage their business partners, colleagues, to participate in QoS Task Force
• Liaison with other Consortia – Very important for end-to-end QoS
• Marketing
• Membership
• Work with solution providers to understand and extend Industry Models (Existing Implementations of QoS) to meet requirements of Enterprise and Networking QoS

For more information or to sign up for Membership and/or Working Groups contact Sally Long – Sally Long 781-376-8211