Compliance and Interoperability Discussion 11/25/2014 Paul Grun.

Slides:



Advertisements
Similar presentations
XBRL International Standards Update Ignacio Hernandez-Ros Technology Development, XBRL International Inc.
Advertisements

RoCEv2 Update from the IBTA
Objectives In this session, you will learn to:
Understand Web Services
Gap Analysis of Simplified Use of Policy Abstractions (SUPA) Presenter: Jun Bi draft-bi-supa-gap-analysis-02 IETF 92 SUPA BoF Dallas, TX March 23, 2015.
1-1 Introduction to Computer Networks and Data Communications.
Hillsboro August F2F Summary Paul Grun OFI WG co-chair 01 Sept ‘14.
Modified by: Masud-Ul-Hasan and Ahmad Al-Yamani 1 Chapter 11 Network Management (Selected Topics)
Testing Framework TST 15 Source: Laurent Velez, ETSI, Meeting Date: TST Testing_framework.PPT.
Discussions for Testing Group Name: WG-6 Source: Yoshinori Goto, NTT, Shingo Fujimoto, FUJITSU,
Web Service What exactly are Web Services? To put it quite simply, they are yet another distributed computing technology (like CORBA, RMI, EJB, etc.).
CECS 474 Computer Network Interoperability Notes for Douglas E. Comer, Computer Networks and Internets (5 th Edition) Tracy Bradley Maples, Ph.D. Computer.
January 2013 CDMI: An Introduction. Big Data Complexity Volume Speed “Big Data” refers to datasets whose size is beyond the ability of typical tools to.
NETWORKING CONCEPTS. OSI MODEL Established in 1947, the International Standards Organization (ISO) is a multinational body dedicated to worldwide agreement.
Authors list to be completed.
New Direction Proposal: An OpenFabrics Framework for high-performance I/O apps OFA TAC, Key drivers: Sean Hefty, Paul Grun.
Typical Software Documents with an emphasis on writing proposals.
HIP API issues in base spec Tom Henderson IETF-59, March 3, 2004.
SNIA/SSIF KMIP Interoperability Proposal. What is the proposal? Host a KMIP interoperability program which includes: – Publishing a set of interoperability.
Presentation on Osi & TCP/IP MODEL
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Authors list to be completed.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Week one - networks and Layered Communication Introduction to Networks Layered Communication OSI Model The Physical Layer The Data Link Layer.
An Introduction to Software Architecture
ACM 511 Chapter 2. Communication Communicating the Messages The best approach is to divide the data into smaller, more manageable pieces to send over.
Modeling Process CSCE 668Set 14: Simulations 2 May be several algorithms (processes) runs on each processor to simulate the desired communication system.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Teamwork and roles in student Scrums. Most software is designed by teams …but merely throwing people together does not result in a functioning team To.
Web Services Glossary Summary of Holger Lausen
11 August 2010Abstract Test Cases 1 Abstract Test Case Development Phil Beecher (BCC) Edge / Enterprise Conformity.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
OpenSG Conformity IPRM Overview July 20, ITCA goals under the IPRM at a high level and in outline form these include: Organize the Test and Certification.
IEEE SCC41 PARs Dr. Rashid A. Saeed. 2 SCC41 Standards Project Acceptance Criteria 1. Broad market application  Each SCC41 (P1900 series) standard shall.
Overview TIA TR-50 – Smart Device Communications Orlett W. Pearson March 2010.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
Ajh January 2007 CCSDS “Books” Adrian J. Hooke CMC Meeting, Colorado Springs 26 January 2007.
CCWG Second public Consultation Reaching Consensus.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
TP#13 oneM2M testing discussion TP#13 Source: Laurent Velez, ETSI, Meeting Date:
Work Group / Work Item Proposal Slide 1 © 2012 oneM2M Partners oneM2M-TP oneM2M_Work_Group_Work_Item_Proposal Group name: Technical Plenary Source:
Privecsg Privacy Recommendation PAR Proposal Date: [ ] Authors: NameAffiliationPhone Juan Carlos ZúñigaInterDigital
Object-Oriented Analysis and Design with the Unified Process by Şensev Alicik.
Information Architecture WG: Report of the Spring 2004 Meeting May 13, 2004 Dan Crichton, NASA/JPL.
 Design goals are derived form the non- functional requirements  Every subsystem is assigned to a team and realized independently  During system design,
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
4.3 [4] Technical Scope of M2M Consolidation Brian Daly – Member of ATIS Delegation (AT&T Director, Core Network & Government/Regulatory Standards) Meeting.
OpenFabrics Interface WG A brief introduction Paul Grun – co chair OFI WG Cray, Inc.
Privecsg Privacy Recommendation PAR Proposal Date: [ ] Authors: NameAffiliationPhone Juan Carlos ZúñigaInterDigital
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
© Drexel University Software Engineering Research Group (SERG) 1 The OASIS SOA Reference Model Brian Mitchell.
Privecsg Privacy Recommendation PAR Proposal Date: [ ] Authors: NameAffiliationPhone Juan Carlos ZúñigaInterDigital
14 October 2002GGF6 / CGS-WG1 Working with CIM Ellen Stokes
Doc.: IEEE /084r0 Submission March 2000 David Skellern, RadiataSlide 1 Comments by P WLAN WG on P WPAN High Rate Study Group PAR 7.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
SEDRIS Technology Conference How to Produce SEDRIS Transmittals Presenter: Paul Berner, Ph.D. Consultant.
Data Plane Computing System CERN Openlab Technical Workshop 5-6th November 2015 Lazaros Lazaridis › 05/11/2015.
Technical Plenary Terms for the collaboration with P2413 From: oneM2M TP Chair Source: Meeting Date: Agenda Item:
Information Architecture WG: Report of the Fall 2004 Meeting November 16th, 2004 Dan Crichton, NASA/JPL.
Fall ‘99 Simulation Interoperability Workshop RTI Interoperability Study Group Final Report Michael D. Myjak, Chair.
Privecsg Privacy Recommendation PAR Proposal Date: [ ] Authors: NameAffiliationPhone Juan Carlos ZúñigaInterDigital
Group Name: oneM2M WG1 Requirements Source: Phil Hawkes, Rapporteur “Benefits of oneM2M technology” TR,
Interface, Subclass, and Abstract Class Review
OpenFabrics Alliance An Update for SSSI
CIGRE D2.24 Information Architecture ** where CIM fits in **
An Introduction to Software Architecture
HSSC11 – 5.1D S-100 Readiness Levels.
Networking for Home and Small Businesses – Chapter 6
Scope and Approach of ONF OIMT Internet Protocol Work Items
Certification Plan EdgeX TSC F2F May 1,
Presentation transcript:

Compliance and Interoperability Discussion 11/25/2014 Paul Grun

C & I Already agreed on several criteria leading up to a release: –Provider existence proof, test cases, man pages… Should we also include either compliance or interoperability testing –Either as part of the release process or as an adjunct to it Should the OFA provide a C&I service for libfabrics implementations? ISC

Compliance Compliance: An implementation is said to be compliant with a set of requirements if it conforms to those requirements through some measurable objective criteria Important point: “Compliance of what, with respect to what?” Typically, requirements are stated in formal language as part of a specification –There is no formal libfabrics specification ISC

Application hardware consumer provider In terms of classical layering… Application hardware consumer provider - Any given layer has a vertical interface to the layers above it and below it. - Peer layers communicate with each other via a protocol. protocol interface

Application hardware consumer provider Compliance, Interoperability Application hardware consumer provider Technically: Interoperability describes how accurately two peers exchange a well-defined protocol. Compliance describes how well a given layer conforms to an interface specification.

Application hardware consumer provider Compliance, Interoperability Application hardware consumer provider For our purposes, roughly: Interoperability is the horizontal relationship between peer layers, Compliance is the vertical relationship between adjacent layers. interop compliance

Application hardware consumer provider Application layer Application hardware consumer provider Interoperability among instances of an application is defined solely by the...application. Similarly, the interface to the consumer is defined by a combination of the consumer and the application. Both are outside the scope of the OFA.

Application hardware consumer provider Consumer layer Application hardware consumer provider The consumer protocol is defined by…somebody else (OpenMPI, MPICH…). Outside the scope of the OFA. But the consumer/provider interface is defined by us (OFI WG). Very much in scope for the OFA. Should the OFA define a compliance test for OFI WG consumers?

Application hardware consumer provider Provider layer Application hardware consumer provider As above, the consumer/provider interface is defined by OFI WG. Should the OFA define a compliance test for OFI providers? Not clear! What about the end-to-end provider protocol? Again, not clear.

Application hardware consumer provider Hardware layer Application hardware consumer provider Interoperability on the wire is defined by an industry standard – ENET, FCOE, IB…Clearly out of scope for the OFA. Likewise, the provider/hardware interface is the province of somebody else.

Application hardware MPI OFI provider Example: MPI Application hardware MPI OFI provider defined by MPI The MPI on-the-wire protocol is defined by somebody like OpenMPI, MPICH, etc… The application interface is similarly defined by somebody else. In both cases, this is outside the scope of the OFA

Application hardware MPI OFI provider Example: MPI Application hardware MPI OFI provider libfabrics API defined by MPI defined by OFA But the interface to the OFI provider is defined by the OFA – OFI

Application hardware MPI OFI provider Example: MPI Application hardware MPI OFI provider libfabrics API As an industry service, the OFA could provide: 1.Compliance testing of the MPI implementation to the OFI-defined APIs but not the MPI on-the-wire protocol 2.Compliance testing of the provider implementation to the OFI-defined APIs

Application hardware MPI OFI provider Example: MPI Application hardware MPI OFI provider libfabrics API As an industry service, the OFA could provide: 1.Compliance testing of the MPI implementation to the OFI-defined APIs but not the MPI on-the-wire protocol 2.Compliance testing of the provider implementation to the OFI-defined APIs 3.Protocol testing of provider layer on-the-wire protocols

Discussion ISC 2013