[[PageOutline]] = 2nd GENI Instrumentation and Measurement Workshop = Tuesday, June 8, 1pm - Wednesday, June 9, 2pm [[BR]] Chicago O'Hare Hilton [[BR]] NOTE: By invitation only [[BR]] == Announcement with goals, topics and reference material == The following announcement (with figures and references) was sent to the attendees to prepare for the workshop: [[BR]] [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/060410b%20%20InstMeasWorkshopAgenda.pdf Announcement, v1.1 (060410)] [[BR]] [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/060310%20%20All%20Fig%20%20IM-ARCH-Figures.pdf Figures, v1.1 (060410)] [[BR]] == Attendees at workshop == (Attended workshop: yes or no) Paul Barford - University of Wisconsin – Madison (no)[[BR]] Bruce Maggs – Duke University and Akamai (yes)[[BR]] Harry Mussman – BBN/GPO (yes)[[BR]] Vic Thomas - BBN/GPO (yes)[[BR]] Evan Zhang – BBN/GPO (yes)[[BR]] OML (ORBIT Measurement Library) OMF (ORBIT Management Framework) Max Ott – NICTA (yes, by phone)[[BR]] Ivan Seskar – Rutgers WINLAB (yes)[[BR]] Instrumentation Tools Jim Griffioen - Univ Kentucky (yes) perfSONAR Matt Zekauskas - Internet2 (no)[[BR]] Jason Zurawski – Internet2 (yes)[[BR]] Martin Swany - Univ Delaware (yes)[[BR]] Guilherme Fernandes – Univ Delaware (yes)[[BR]] Ezra Kissel – Univ Delaware (yes)[[BR]] Scalable Sensing Service (S3) Sonia Fahmy – Purdue (yes)[[BR]] Puneet Sharma - HP Labs (yes)[[BR]] !OnTimeMeasure for network measurements Prasad Calyam - Ohio Supercomputing Ctr (yes) GENI Meta-Operations Center and !NetKarma Jon-Paul Herron - Indiana Univ[[BR]] Camilo Viecco - Indiana Univ (yes)[[BR]] Chris Small - Indiana Univ (yes)[[BR]] Beth Plale - Indiana Univ (no)[[BR]] Virtual Machine Introspection (VMI) Brian Hay – Univ Alaska (yes)[[BR]] Data-Intensive Cloud Control for GENI Michael Zink - UMass Amherst (yes)[[BR]] Experiment Management Service – Digital Object Registry Jim French - CNRI (yes)[[BR]] Giridhar Manepalli - CNRI (yes)[[BR]] Larry Lannom – CNRI (no)[[BR]] == Announcement with notes == The following announcement now includes all notes from the workshop: [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/062510%20InstMeasWorkshopAgenda.pdf Announcement, v1.2 (062510)] [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/062510%20InstMeasWorkshopAgenda.doc word version][[BR]] [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/Visio-062510_All_IM-ARCH-Figures.pdf Figures, v1.2 (062510)] [[BR]] == Priority topics == The following priority topics were identified at the workshop, and teams of attendees (and some non-attendees0 were identified for each topic to discuss it, and write a text summary for review by the WG at GEC8. === Topic 1 GENI I&M Use Cases === Team members: Paul Barford - University of Wisconsin – Madison (no)[[BR]] Jim Griffioen - Univ Kentucky (yes)[[BR]] Prasad Calyam* - Ohio Supercomputing Ctr (yes)[[BR]] Camilo Viecco - Indiana Univ (yes)[[BR]] Brian Hay – Univ Alaska (yes)[[BR]] *agreed to organize first writing and discussion Identify all user groups, and provide basic use cases: 1. Experiment researchers 2. Experiment (opt-in) users (see http://groups.geni.net/geni/attachment/wiki/041409NYCOptInWGAgenda/071509%20%20GENI-SE-OI-Overview-01.4.pdf for listing of opt-in issues, such as privacy) 3. Central (i.e., GMOC) operators 4. Cluster and aggregate providers and operators 5. Archive service providers and operators 6. Researchers that use archived measurement data, archived by other researchers (!DatCat model) === Topic 2 GENI I&M Services === Team members:[[BR]] Harry Mussman* – BBN/GPO (yes)[[BR]] Evan Zhang – BBN/GPO[[BR]] Giridhar Manepalli - CNRI (yes)[[BR]] Chris Small - Indiana Univ (yes)[[BR]] Beth Plale - Indiana Univ (yes)[[BR]] *agreed to organize first writing and discussion Summarize current view of:[[BR]] Measurement Orchestration (MO) Service [[BR]] Measurement Point (MP) Service [[BR]] Measurement Information (MI) Service [[BR]] Measurement Collection (MC) Service [[BR]] Measurement Analysis and Presentation (MAP) Service[[BR]] Measurement Data Archive (MDA) Service[[BR]] Need: Basic definition of a Measurement Data Archive (MDA) Service[[BR]] Identify different types of services:[[BR]] Type 1: Dedicated service platform, with dedicated sliver, for customized information. [[BR]] (Completely dedicated to an experiment) [[BR]] Type 2: Common service platform, with dedicated slivers, for customized information. [[BR]] (Common portion, plus parts associated with different experiments)[[BR]] Type 3: Common service, for common or customized information. [[BR]] (Common service, with data provided to multiple experiments)[[BR]] === Topic 3 GENI I&M Resources === Team members: Vic Thomas - BBN/GPO (yes)[[BR]] Jim Griffioen* - Univ Kentucky (yes)[[BR]] Martin Swany - Univ Delaware (yes)[[BR]] Camilo Viecco - Indiana Univ (yes)[[BR]] Brian Hay – Univ Alaska (yes)[[BR]] Giridhar Manepalli - CNRI (yes)[[BR]] *agreed to organize first writing and discussion Significant question uncovered at workshop:[[BR]] Jim on 6/25 via email: We should involve Rob Ricci in the discussion.[[BR]] Consider these resources for I&M capabilities:[[BR]] 1. Hosts, VMs, etc. 2. Network connectivity 3. Software, e.g., I&M software that can be included in an experiment 4. I&M services 5. I&M data flows and file transfers 6. I&M data files stored in archives For each item, consider how to:[[BR]] Create[[BR]] Name[[BR]] Register and discover[[BR]] Authorize and assign[[BR]] Does each item have:[[BR]] Unique and persistent name?[[BR]] Unique and persistent identifier?[[BR]] Need to carefully consider this for all of GENI[[BR]] For each item, consider:[[BR]] Ownership[[BR]] What sort of policies the owner may want to apply[[BR]] How are each of these discovered, specified, authorized and assigned: Always by mechanisms provided by the CF? With CF plus additional mechanisms? Consider example of LS in perfSONAR [[BR]] Consider example of data file stored in archive, owned by an experimenter Need to define and then compare these options[[BR]] Need to understand interop with CF for each option[[BR]] Does CF setup secondary authorization mechanisms in some cases? If so, how?[[BR]] === Topic 4 GENI I&M Measurement Plane and Interfaces === Team members: Harry Mussman* – BBN/GPO (yes)[[BR]] Ezra Kissel – Univ Delaware (yes)[[BR]] Chris Small - Indiana Univ (yes)[[BR]] *agreed to organize first writing and discussion Consider: IP network[[BR]] Layer 2 (VLAN) connections[[BR]] Discuss:[[BR]] Which protocols are active[[BR]] Access to resources in aggregates, even when resources are in private address space, via GWs or proxies[[BR]] How to provide authentication and authorization[[BR]] How to provide QoS to protect measurement traffic[[BR]] How to provide QoS to protect other traffic when measurement traffic is large.[[BR]] Reserve bandwidth?[[BR]] Martin on 6/28: Consider XSP (extensible session protocol) to provide transport layer GW functions. === Topic 5 GENI I&M Interfaces and Protocols (APIs): Manage Services === Team members: Vic Thomas - BBN/GPO (yes)[[BR]] Ivan Seskar – Rutgers WINLAB (yes)[[BR]] Max Ott – NICTA (yes, by phone)[[BR]] Sonia Fahmy* – Purdue (yes)[[BR]] Giridhar Manepalli - CNRI (yes)[[BR]] *agreed to organize first discussion and writing Define an approach based on OMF/OML and S3: HTTP(S)[[BR]] REST vs SOAP[[BR]] Authorization by credentials or ? If credentials, how to revoke?[[BR]] Pass XML fragments[[BR]] Define basic API[[BR]] === Topic 6 GENI I&M Interfaces and Protocols (APIs): Data Flows and Data File Transfers === Team members:[[BR]] Harry Mussman* – BBN/GPO (yes)[[BR]] Ivan Seskar – Rutgers WINLAB (yes)[[BR]] Max Ott – NICTA (yes, by phone)[[BR]] Ezra Kissel – Univ Delaware (yes)[[BR]] Prasad Calyam - Ohio Supercomputing Ctr (yes)[[BR]] Michael Zink - UMass Amherst (yes)[[BR]] *agreed to organize first writing and discussion Consider data flows and data file transfers between all services Define range of options: What:[[BR]] Data flows[[BR]] Data files transfers[[BR]] Type:[[BR]] Pull[[BR]] Push[[BR]] Pub/Sub[[BR]] Protocol:[[BR]] SNMP[[BR]] SCP[[BR]] FTP and gridFTP[[BR]] HTTP[[BR]] XMPP[[BR]] TCP[[BR]] SCTP[[BR]] Consider:[[BR]] Naming[[BR]] Discovery[[BR]] Connectivity [[BR]] Authentication and authorization mechanisms[[BR]] Map to current projects, giving examples:[[BR]] Consider: Minimum set required for GENI[[BR]] === Topic 7 GENI I&M Interfaces and Protocols (APIs): Registration and Discovery of Services with Available Measurement Data === Team members:[[BR]] Jason Zurawski* – Internet2 (yes)[[BR]] Prasad Calyam - Ohio Supercomputing Ctr (yes)[[BR]] *agreed to organize first writing and discussion[[BR]] Consider approach used in perfSONAR Summarize for:[[BR]] Services with data flows[[BR]] Also sources of file transfers?[[BR]] Also GUIs?[[BR]] === Topic 8 GENI I&M Interfaces and Protocols (APIs): GUIs === Team members:[[BR]] Jeremy Reed - Univ Kentucky (no)[[BR]] Zongming Fei - Univ Kentucky (no)[[BR]] Guilherme Fernandes* – Univ Delaware (yes)[[BR]] Puneet Sharma - HP Labs (yes)[[BR]] *Agreed to organize team[[BR]] This section will lay out requirements and recommendations for GUIs that allow GENI users to manage (control, configure, access), visualize and discover I&M services, including the GUI themselves, and related data. The portals used by GENI experimenters to request the deployment of an I&M system or the instantiation of a sliver in an I&M component are not covered in the present draft. Requirements are defined to ensure GUIs and other services adhere to general GENI principles that must be enforced (e.g. privacy), and will tend to evolve from recommendations deemed essential by GENI I&M community. On the other hand, recommendations try to capture best practices in the field and general principles to increase the usability and effectiveness of these GUIs. Note: This draft does not currently define any requirements or recommendations, but rather describes current practices, possible use cases and general thoughts that can hopefully inform the future definition of these requirements and recommendations by the GENI I&M WG. Many design principles must be taken into consideration when developing GUIs for I&M architectures. As usual in Computer Science, these principles can be in sharp contrast with each other and trade-offs are made depending on the overall objective of the GUI. Following the general methodology of GENI, we identify GUIs developed for other I&M frameworks and services in order to capitalize on their strengths. A discussion of some of these design principles follows. * Centralized/Remote vs Distributed/Local vs Hybrid - These principles can be seen as part of a spectrum, with GUIs that provide a visual interface to services and data residing locally on the same machine on one end (e.g. pS-Performance Toolkit web interface), and GUIs that centralize management and distributed access to remote data and services on the other (e.g. MRTG+Cacti, CACTISonar). A centralized interface is the preferred approach on many use cases, such as health and status monitoring, as it increases the effectiveness and facilitates the access by providing a single, unified location for network management. However, collecting the data on a centralized location tends to increase the network overhead generated by network management. In contrast, GUIs with local scope tend to be faster in accessing data, create little or no network overhead and are generally simpler to build. Between these two extremes we can find hybrid GUIs. For example, a centralized visualization interface might cache only common queries and request others on demand (e.g. Periscope). * Flexibility vs Usability - GENI users should be able to have as much control as possible over the configuration of I&M services dedicated to their slice. In several instances it might be hard (or impossible) to identify a single set of parameters that satisfies all experimenters. GUIs can be designed to provide great flexibility (e.g. by permitting users to select what is to be displayed, how it should be displayed, or providing an interface to all sorts of configuration parameters). Expert users certainly appreciate having great flexibility, but even experts expect sensible defaults to be defined. On the other hand, non-expert users might be overwhelmed with too many options, reducing the GUI’s usability and users’ overall experience. Having different views (e.g. normal and advanced) with varying levels of complexity can be a conciliatory bridge between flexibility and usability. * Common graphical layouts and visualization aids - [There are established ways of presenting some types of data (e.g. utilization as line/area graphs with out and in directions overlayed, one- and two-way latency tests as scatter plots, measurement meshes results in 2D matrices). GUI developers should recognize de facto standards and try to follow them. Visualization aids are commonly provided through geographical maps, network topology diagrams, etc.] * Documentation? The GENI I&M Architecture draft includes a Measurement Analysis and Presentation (MAP) Service. Many of the GUIs discussed in this section fall into this category. In contrast, network monitoring frameworks that take a middleware approach (e.g. perfSONAR) tend to view this type of service as users of the framework, sitting in a higher (external) layer. There are clear benefits of including this type of service in the architecture definition (e.g. it enables the main purpose of this section, namely to identify requirements and guide user expectations regarding GUIs). However, careful attention must be paid to the place of these services within the framework and the issues that arise. One possible concern regards the substitutability of API functionality of other components through GUIs. For example, the API for a Measurement Point Service might define Start/Stop methods through a Web Services interface. If a GENI I&M system provides a GUI that allows the user to Start/Stop the MP, must the MP implement the same functionality (through the Web Services interface) to be considered compliant? Consider now the more complex example of GUIs that are the sole interface to a given dataset. Data might be pushed or pulled into a local (or remote) database which is then accessed by the GUI to display the data to the user (e.g. MRTG+Cacti). The data is clearly available to the experimenter through the GUI, but must it also be available through the defined MDA interface? Would it suffice for the GUI to be able to export the raw data in a give format (e.g. through HTTP file download)? The access of GUIs to data raises very important issues regarding authentication and authorization in GENI. All of the GENI facilities must employ security mechanisms to ensure privacy and policy constraints are met. If a GUI has direct access to data, the GUI must likely employ the similar (same?) mechanisms as required on an equivalent MDA. On the other hand, if the GUI accesses other I&M services on demand to retrieve the d ata to be displayed, the GUI should allow the user to authenticate itself. In this case, should the user authenticate itself with the GUI, which is then trusted by the other services [this might make sense when the GUI is deployed as part of the I&M system]? Or should the GUI relay the authentication to the services by asking the user for its certificate (and password)? Both cases raise trust issues with the GUI themselves. Finally, we address the discovery of and access to the GUI themselves. Some GUIs will likely act as services of the I&M systems (i.e. deployed within the system, maybe with direct access to data), and as such should likely be discoverable as any other service of I&M system (e.g. by registering to a Lookup Service). Open issues include determining the necessary information to register in order to meaningfully describe the GUI and its capabilities. Also, it is expected that many GUIs will be developed through the years by GENI users. GENI should likely provide an archive/repository to make these GUIs available and easily discoverable by the larger GENI community. Is this repository a centralized location (maintained by GENI) or just a Lookup Service pointing to the remote locations where the GUIs can be found? === Topic 9 GENI Measurement Data Schema === Team members:[[BR]] Bruce Maggs – Duke University and Akamai (yes)[[BR]] Max Ott – NICTA (yes, by phone)[[BR]] Ivan Seskar – Rutgers WINLAB (yes)[[BR]] Martin Swany* - Univ Delaware (yes)[[BR]] Camilo Viecco - Indiana Univ (yes)[[BR]] Michael Zink - UMass Amherst (yes)[[BR]] Jim French - CNRI (yes)[[BR]] *agreed to organize first discussion and writing Consider:[[BR]] Measurement data schema[[BR]] Metadata schema[[BR]] Metadata contents[[BR]] Consider measurement data schema and/or metadata schema from:[[BR]] perfSONAR[[BR]] GMOC-provided[[BR]] Current OML[[BR]] Proposed using IPFIX[[BR]] NetCDF (as used by DI Cloud)[[BR]] Consider: Minimum set required for GENI Provide overall template for GENI metadata, considering above.[[BR]] Which items in GENI metadata template are: Required?[[BR]] Invariant?[[BR]] == Project Summaries == === Instrumentation Tools === === OMF/OML === === perfSONAR === === Scalable Sensing Service === === On Time Measure === === Data Intensive Cloud === === Digital Object Registry === == References == All references Individual references [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/GIMS_Design_UseCases_033110.pdf GIMS_Design_UseCases] "Use-cases for GENI Instrumentation and Measurement Architecture Design" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20MeasPlane-1%20%20www2008-restws-pautasso-zimmermann-leymann.pdf MeasPlane-1] "RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20OMF_OML-1%20%20rfc4506.pdf OMF-OML-1:] "XDR: External Data Representation Standard" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20OMF_OML-2%20%20final-oml-paper.pdf OMF-OML-2] "ORBIT Measurements Framework and Library (OML): Motivations, Design, Implementation, and Features" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20OMF_OML-3%20%20%20ott%20%20OML%20-%20GEC7%20-%20march.pdf OMF-OML-3] "OML Overview" Slides [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20OMF_OML-4%20%20oml_tridentcom_2009.pdf OMF-OML-4] "Measurement Architectures for Network Experiments with Disconnected Mobile Nodes" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20InstTools-1%20%20instools-design-doc.pdf InsTools-1] "Architectural Design and Specification of the INSTOOLS Measurement System" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20perfSONAR-1%20%20trident.pdf perfSONAR-1] "Scalable Framework for Representation and Exchange of Network Measurements" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20perfSONAR-2%20%20extensible%20schema%20%20%20doc15649.pdf perfSONAR-2] "An Extensible Schema for Network Measurement and Performance Data" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20perfSONAR-3%20%20topoSchema-OGF21.pdf perfSONAR-3] "NM-WG/perfSONAR Topology Schema" [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20GMOC-1%20%20data_exchange_format-posted.pdf GMOC-1] “GMOC Topology-Entity Data Exchange Format Specification” [[BR]] [http://groups.geni.net/geni/attachment/wiki/2ndInstMeasWork/ref%20%20GMOC-2%20%20urn-proposal.pdf GMOC-2] "Proposal: Use of URN's as GENI Identifiers" == Figures == Figure 1-1: I&M Services for Researchers [[BR]] [[Image(060310Fig1-1_SrvcsRes_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 1-2: I&M Services for Operators [[BR]] [[Image(060310Fig1-2_SrvcsOps_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 1-3: I&M Services for both Researchers and Operators [[BR]] [[Image(060310Fig1-3_SrvcsBoth_ IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-1: OMF/OML I&M Srvcs [[Image(060310Fig2-1_SrvcsOMFOML_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-2: Inst Tools I&M Srvcs [[BR]] [[Image(060310Fig2-2_SrvcsInsTools_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-3: perfSONAR I&M srvcs [[BR]] [[Image(060310Fig2-3_Srvcs_perfSONAR_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-4: Scal Sense Srvc I&M Srvcs [[BR]] [[Image(060310Fig2-4_SrvcsS3_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-5: !OnTimeMeas I&M Srvcs [[BR]] [[Image(060310Fig2-5_OnTimeMeas_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-6: DICLOUD config [[BR]] [[Image(060310Fig2-6_DICloud_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 2-7: DOR MDA Srvc and Mess[[BR]] [[Image(060310Fig2-7_DOR_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 3-1: Meas Traffic Flows[[BR]] [[Image(060310Fig3-1_MeasTrafficFlows_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 3-2: Meas Traffic Proxies[[BR]] [[Image(060310Fig3-2_measTrafPorxies_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 4-1: OMF/OML Srvcs and Mess[[BR]] [[Image(060310Fig4-1_OMLSrvcs_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 4-2: OML Component Arch[[BR]] [[Image(060310Fig4-2_OMLArch_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 4-3: OMF/OML Overview[[BR]] [[Image(060310Fig4-3_OMLOverview_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 4-4: ORBIT Network Diagram [[BR]] [[Image(060310Fig4-4_OMLNtwk_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 5-1: Inst Tools Srvcs and Mess [[BR]] [[Image(060310Fig5-1_InstToolsSrvcs_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 5-2: Inst Tools Components [[BR]] [[Image(060310Fig5-2_InstToolsComps_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 5-3: Inst Tools Topology [[BR]] [[Image(060310Fig5-3_InstToolsToplogy_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 6-1: perfSONAR Srvcs and Messages[[BR]] [[Image(060310Fig6-1_perfSONARSrvcs_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 6-2: perfSONAR Meas Data Schema [[BR]] [[Image(060310Fig6-2_perfSONARSchema_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 7-1: Scal Sens Srvc Srvcs and Messages [[BR]] [[Image(060310Fig7-1_S3Srvcs_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 8-1: !OnTimeMeas Srvcs and Mess[[BR]] [[Image(060310Fig8-1_OnTimeMeasSrvcs_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 9-1: [[BR]] [[Image(063010Fig9-1_DICloudSrvcs_IM-ARCH-Fig.jpg, 80%)]] [[BR]] Figure 10-1: DOR MDA Srvc and Mess [[BR]] [[Image(060310Fig10-1_DORSrvcs_IM-ARCH-Figures.jpg, 80%)]] [[BR]] Figure 10-2: DOR MDA Srvc File Org [[BR]] [[Image(060310Fig10-2_DORFileOrg_IM-ARCH-Figures.jpg, 80%)]] [[BR]]