[NOTE: This attachment will not appear in the Code of Federal Regulations.] ATTACHMENT 2 Docket No. RM95-9 Form Approved OMB No. 1902-0173 Expires February 28, 1999 FEDERAL ENERGY REGULATORY COMMISSION ______________________________________________________________ STANDARDS AND COMMUNICATION PROTOCOLS FOR OPEN ACCESS SAME-TIME INFORMATION SYSTEM (OASIS) ______________________________________________________________ Version 1.0 (April 24, 1996) The public burden for the development and initial operation of this information requirement is estimated to average 1,879 reporting hours and 418 record keeping hours per public utility. The estimate includes the time required to review and implement the standards, develop the necessary software, search existing data sources, gather and maintain the data, complete and review the information. Send comments regarding this burden estimate or any other aspect of this information requirement, including suggestions for reducing the burden, to each of the following: Federal Energy Regulatory Commission Attention: Michael Miller, Information Services Division 888 First Street, N.E. Washington, DC 20426 Office of Management and Budget Office of Information and Regulatory Affairs Attention: Desk Officer for the Federal Energy Regulatory Commission Washington, DC 20503 You shall not be penalized for failure to respond to this collection of information unless the collection of information displays a valid OMB control number. ii TABLE OF CONTENTS GENERAL INFORMATION I. Purpose . . . . 1 II. Who Must Comply 1 III. Implementation Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 IV. Development Of The Standards And Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 1 V. OASIS Standards And Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. INTRODUCTION 3 1.1 DEFINITION OF TERMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NETWORK ARCHITECTURE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 ARCHITECTURE OF OASIS NODES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 INTERNET-BASED OASIS NETWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 COMMUNICATION STANDARDS REQUIRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 INTERNET TOOL REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 NAVIGATION AND INTERCONNECTIVITY BETWEEN OASIS NODES . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. INFORMATION ACCESS REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 REGISTRATION AND LOGIN REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 SERVICE LEVEL AGREEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 ACCESS TO INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 PROVIDER UPDATING REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 ACCESS TO CHANGED INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 SERVICE REQUEST TRANSACTION SUPPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. INTERFACE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 INFORMATION MODEL CONCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1 ASCII-Based Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 OASIS NODE CONVENTIONS AND STRUCTURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1 OASIS Node Naming Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2 Data Element Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3 General Rules for OASIS Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.4 Display Request and Response Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.4.1 Display Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.4.2 Display Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.5 File Request, File Download Response, and Form Upload Rules and Procedures . . . . . . . . . . 13 4.2.5.1 File Request Rules and Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.5.2 File Download Response Rules and Procedures . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.5.3 Form Upload Rules and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 TEMPLATE DESCRIPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.1 Summary System Information Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.2 Provider System Information Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.3 Secondary Provider (Reseller) Posting Templates . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.4 Services Information Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.5 Service Request Transaction Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 iii 4.3.6 Informal Information Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4 FILE REQUEST AND FILE DOWNLOAD EXAMPLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4.1 File Example for Summary Path Hourly ATC . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4.2 File Example for Hourly Schedule Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4.3 Customer Capacity Purchase Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4.4 Capacity Purchase Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4.5 Customer s Purchase Acknowledge Acceptance (Input) . . . . . . . . . . . . . . . . . . . . . . 30 5. PERFORMANCE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1 SECURITY 30 5.2 ACCESS PRIVILEGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3 OASIS RESPONSE TIME REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.4 OASIS PROVIDER ACCOUNT AVAILABILITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5 BACKUP AND RECOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.6 TIME SYNCHRONIZATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.7 TS INFORMATION TIMING REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.8 TS INFORMATION ACCURACY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.9 PERFORMANCE AUDITING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.10 MIGRATION REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 APPENDIX A - DATA ELEMENT DICTIONARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 APPENDIX B - OASIS QUERY VARIABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 iv GENERAL INFORMATION I. Purpose In Order No. 888 the Commission requires public utilities to provide comparable access to transmission services and transmission system information. Order No. 889 amends the Commission's regulations, by adding 18 CFR Section 37, to require utilities to provide information about the availability of transmission service on an Open Access Same-Time Information System (OASIS). This information will be provided both through displays and through standardized files that users can download to their own computers. Certain information will also be uploaded through standardized forms and files transmitted from customers' computers to the OASIS. The regulations require public utilities to comply with standardized procedures and communication protocols governing the means by which the information is made available. This document contains the standardized data sets that show the information that must be provided, standard operating procedures and the protocols for communication of that information. II. Who Must Comply All jurisdictional public utilities that are required to maintain an OASIS under Part 37 of the Commission's regulations must comply with these standards and communication protocols. III. Implementation Date Utilities must implement these standards and protocols by November 1, 1996. IV. Development Of The Standards And Communication Protocols The standards and communication protocols were developed by the electric utility industry through a working group facilitated by EPRI. This working group included representatives from all major segments of the electric utility industry, such as utilities and marketers, as well as other interested parties such as computer and software firms. The standards and communication protocols represent a broad agreement of the working group. As the industry obtains experience with OASIS and the new operating environment created by Order No. 888, the standards and communication protocols will need to be 1 revised. The Commission has requested the industry to continue to develop standards and identify necessary changes. The Commission will provide all interested parties with notice and an opportunity for comment on proposed changes to this document. 2 V. OASIS STANDARDS AND COMMUNICATION PROTOCOLS 1. INTRODUCTION 1.1 DEFINITION OF TERMS The following definitions are offered to clarify discussions of the OASIS in this document. a. Transmission Services Information (TS Information) is transmission and ancillary services information which must be made available by public utilities on a non- discriminatory basis to meet the regulatory requirements of transmission open access. b. Open Access Same-Time Information System (OASIS) comprises the computer systems and associated communications facilities that public utilities are required to provide for the purpose of making available to all transmission users comparable interactions with TS Information. c. Open Access Same-Time Information System Node (OASIS Node) is a subsystem of the OASIS. It is one computer system in the (OASIS) that provides access to TS Information to a Transmission Customer. d. Transmission Provider (TP or Provider) is the public utility (or its designated agent) that owns, operates or controls facilities used for the transmission of electric energy in interstate commerce . (This is the same term as is used in Part 35.3) e. Transmission Customer (TC or Customer) is any eligible customer (or its designated agent) that can or does execute a transmission service agreement or can or does receive transmission service. (This is the same term as is used in Part 35.3) f. Secondary Transmission Provider (ST, Reseller, or Secondary Provider) is any Customer who offers to sell transmission capacity it has purchased. (This is the same as Reseller in Part 37) g. Transmission Services Information Provider (TSIP) is a Transmission Provider or an agent to whom the Transmission Provider has delegated the responsibility of meeting any of the requirements of Part 37. (This is the same as Responsible Party in Part 37) h. Value-Added Transmission Services Information Provider (VTSIP) is an entity who uses TS Information in the 3 same manner as a Customer and provides value-added information services to its Customers. 2. NETWORK ARCHITECTURE REQUIREMENTS 2.1 ARCHITECTURE OF OASIS NODES a. Permit Use of Any OASIS Node Computers: TSIPs shall be permitted to use any computer systems as a OASIS Node, so long as they meet the OASIS requirements. b. Permit Use of Any Customer Computers: OASIS Nodes shall permit the use by Customers of any commonly available computer systems, as long as they support the required communication links to the Internet. c. Permit the Offering of Value-Added Services: TSIPs are required, upon request, to provide their Customers the use of private network connections on a cost recovery basis. Additional services which are beyond the scope of the minimum OASIS requirements are also permitted. When provided, these private connections and additional services shall be offered on a fair and non- discriminatory basis to all Customers who might chose to use these services. d. Permit Use of Existing Communications Facilities: In implementing the OASIS, the use of existing communications facilities shall be permitted. The use of OASIS communication facilities for the exchange of information beyond that required for open transmission access (e.g., transfer of system security or operations data between regional control centers) shall also be permitted, provided that such use does not negatively impact the exchange of open transmission access data and is consistent with the Standards of Conduct in Part 37. e. Single or Multiple Providers per Node: A OASIS Node may support a single individual Primary Provider (plus any Secondary Providers) or may support many Providers. 2.2 INTERNET-BASED OASIS NETWORK a. Internet Compatibility: All OASIS Nodes shall support the use of internet tools, internet directory services, and internet communication protocols necessary to support the Information Access requirements stated in Section 4. b. Connection through the public Internet: Connection of OASIS Nodes to the public Internet is required so that 4 Users may access them through Internet links. This connection shall be made through a firewall to improve security. c. Connection to a private internet network: OASIS Nodes shall support private connections to any OASIS User (User) who requests such a connection. The TSIP is permitted to charge the User, based on cost, for these connections. The same internet tools shall be required for these private networks as are required for the public Internet. Private connections must be provided to all users on a fair and nondiscriminatory basis. d. Internet Communications Channel: The OASIS Nodes shall utilize a communication channel to the Internet which is adequate to support the performance requirements given the number of Users subscribed to the Providers on the Node (see section 5.3). 2.3 COMMUNICATION STANDARDS REQUIRED a. Point-to-Point Protocol (PPP) and Internet Protocol Control Protocol (IPCP) (reference RFCs 1331 and 1332) shall be supported for private internet network dial-up connections. b. Serial Line Internet Protocol (SLIP) (reference RFC 1055) shall be supported for private internet network dial-up connections. c. Transport Control Protocol and Internet Protocol (TCP/IP) shall be the only protocol set used between OASIS Nodes whenever they are directly interconnected, or for Users using private leased line internet network connections. d. Hyper Text Transport Protocol (HTTP) shall be supported on the OASIS Node so that Users can use it to select information for viewing displays and for downloading and uploading files electronically. e. Internet Protocol Address: All OASIS Nodes are required to use an IP address registered with the Internet Network Information Center (InterNIC), even if private connections are used. 2.4 INTERNET TOOL REQUIREMENTS Support for the following specific internet tools is required, both for use over the public Internet as well as for any private connections between Users and OASIS Nodes: 5 a. Hypertext Markup Language (HTML), at least version 3, and optionally Secure Sockets Layer (SSL), shall be used by TSIPs as a standard tool for presenting information to Users. b. HTML Forms shall be provided by the TSIPs for Customers to use to request purchases from a Provider. The activation of a form (sending a filled-out form to the Provider) shall be time-stamped and logged as part of the audit trail. c. Domain Name Service (DNS) (ref. RFC 1034, 1035) shall be provided as a minimum by the TSIPs (or their Internet Service Provider) for the resolution of IP addresses to allow Users to navigate easily between OASIS Nodes. d. Simple Network Management Protocol (SNMP) shall be supported to provide tools for operating and managing the network, if private interconnections between OASIS Nodes are established. e. Email shall be supported by the OASIS Node for exchanges between Providers and Customers, including the sending of attachments. The protocols supported shall include, as a minimum, the Simple Messaging Transfer Protocol (SMTP), POP, and MIME. 2.5 NAVIGATION AND INTERCONNECTIVITY BETWEEN OASIS NODES a. World Wide Web Browsers: TSIPs shall permit Users to navigate using WWW browsers for accessing different sets of TS information from one Provider, or for getting to TS information from different Providers on the same OASIS Node. These navigation methods shall not favor User access to any Provider over another Provider, including Secondary Providers. b. Internet Interconnection across OASIS Nodes: Navigation tools shall not only support navigation within the TSIP s Node, but also across interconnected OASIS Nodes. This navigation capability across interconnected Nodes shall, as a minimum, be possible through the public Internet. 3. INFORMATION ACCESS REQUIREMENTS 3.1 REGISTRATION AND LOGIN REQUIREMENTS a. Location of Providers: To provide Users with the information necessary to access the desired Providers, publicly available documentation or menus shall list 6 the OASIS Node addresses of all Primary, Secondary, and Value-Added Providers. b. Initial User Registration: TSIPs shall require Users to register with a Provider before they are permitted to access the Provider s TS information. This registration shall require at least the following information: ù Company name ù Name of company OASIS Account Administrator ù Name of the individual user(s) within a company (each individual user is considered as a separate User with possibly different levels of authority) ù User password ù Supplemental information such as address, telephone number, fax number, and e-mail c. Initial Access Privileges: Initial registration shall permit a User only the minimum Access Privileges. A User and a Provider shall mutually determine what access privilege the User is permitted: the TSIP shall set a User's Access Privilege as authorized by the Provider. d. User Login: After registration, Users shall be required to login every time they establish a dial-up connection. If a direct, permanent connection has been established, Users shall be required to login initially or any time the connection is lost. Use of alternative forms of login and authentication using certificates and public key standards is acceptable. e. User Logout: Users shall be automatically logged out any time they are disconnected. Users may logout voluntarily. 3.2 SERVICE LEVEL AGREEMENTS a. Service Level Agreements: It is recognized that Users will have different requirements for frequency of access, performance, etc., based on their unique business needs. To accommodate these differing requirements, TSIPs shall be required to establish a "Service Level Agreement" with each User which specifies the terms and conditions for access to the information posted by the Providers. The default Service Level Agreement shall be Internet access with the OASIS Node meeting all minimum performance requirements. 3.3 ACCESS TO INFORMATION a. Text Display: TSIPs shall format all TS information as 7 plain or HTML 3.0 text such that it may be viewed and read directly by Users without requiring them to download it. This text shall be in clear English as much as possible, with the definitions of any mnemonics or abbreviations available on-line. The templates for displaying the text are described in Section 4.3. b. Read-Only Access to TS Information: For security reasons, Users shall have read-only access to the TS information. They shall not be permitted to enter any information except where explicitly allowed, such as on transaction request forms. c. Downloading Capability: Users shall be able to download from a OASIS Node the TS information in electronic format as a file. The rules for formatting of this data are described in section 4.4. d. On-Line Data Entry on Forms: Customers shall be permitted to fill out on-line the Service Request forms supplied by the TSIPs on the OASIS Nodes, for requesting the purchase of services and for posting of products for sale (by Customers who are resellers). Customers shall also be permitted to fill-out and post Want-Ads. e. Uploading Capability: Customers shall be able to upload to OASIS Nodes the filled-out forms. TSIPs shall ensure that these uploaded forms are handled identically to forms filled out on-line. TSIPs shall provide Forms that support the file input type available in HTML 3.0. This capability shall permit a Customer to upload a file (or files) using standard Web browsers by providing an input space to specify a file stored on the Customer s hard disk. f. Selection of TS Information: Users shall be able to dynamically select the TS information they want to view and/or download. This selection shall be, as a minimum, through navigation to text displays, the use of pull- down menus to select information for display, data entry into forms for initiating queries, and the selection of files to download via menus. 3.4 PROVIDER UPDATING REQUIREMENTS TO BE COMPLETED BY INDUSTRY 3.5 ACCESS TO CHANGED INFORMATION a. General Message & Log: TSIPs shall post a general message and log that may be read by Users. The message 8 shall state that the Provider has updated some information, and shall contain (or point to) a reverse chronological log of those changes. The User may use the manual or automatic refresh capability to see the message. b. TSIP Notification Design Responsibilities: The TSIP shall avoid a design that could cause serious performance problems by necessitating frequent requests for information from many Customers. 3.6 SERVICE REQUEST TRANSACTION SUPPORT The requirements for supporting Service Request transactions are as follows: a. Basic Service Request Transaction Support: Providers shall support basic Service Request transaction requests from the Customer. All forms shall be formatted according to the Service Request templates described in Section 4. Specifically, the following four types of transactions shall be supported as a minimum: ù A Customer issues a Service Request to a Provider, either by data entry on an on-line form or by uploading a filled-out form. ù The TSIP posts the receipt of the Service Request to the Customer. ù The Provider responds by posting the Service Request Status of the Customer s Service Request each time it changes. The changed status includes: received by the Provider, accepted by seller, accepted by customer, confirmed for scheduling, withdrawn, or refused / rejected. ù The Provider issues an acknowledgment of his acceptance or denies the Service Request. ù The Customer issues an acknowledgment of his acceptance or withdraws the Service Request. ù A Customer who wishes to resell transmission rights shall issue a request to the TSIP for a product posting and then becomes a seller of transmission rights. 4. INTERFACE REQUIREMENTS 4.1 INFORMATION MODEL CONCEPTS 4.1.1 ASCII-Based Information Model a. ASCII-Based OASIS Templates: For displaying information to Users, TSIPs shall use the specified OASIS Templates. These Templates define the information 9 which, as a minimum, must be presented to Users, both in the form of graphical displays and as downloaded files, whenever they access the Template. Users shall be able to request Template information using the request-response data flows (Query Variables for use with HTTP) that are defined in Appendix B. Responses shall contain the same Query Variables containing the results of the query. The OASIS Templates are described in section 4.3. The Data Element Dictionary which defines the data elements in the OASIS Templates is provided in Appendix A. Additional information may be presented in a display or a file at the discretion of the TSIP. However, no User shall be obligated or expected to recognize or use this additional information. As stated above, although the minimal contents of the displays are precisely defined, the actual graphical display formats of the TS information are beyond the scope of the OASIS requirements. b. ASCII-Based OASIS File Structures: For uploading requests from and downloading information to Users, TSIPs shall use specific file structures that are defined for OASIS Template information (see section 4.4). These file structures are based on the use of headers which contain the Query Variable information, including the name of the OASIS Template. These headers thus determine the contents and the format of the data that follows. 4.2 OASIS NODE CONVENTIONS AND STRUCTURES 4.2.1 OASIS Node Naming Requirements The following are the OASIS Node naming requirements: a. Node Naming Convention: In order to provide a consistent method for locating a OASIS Node, the standard Internet naming convention shall be used. All OASIS Node names shall be unique, and shall be registered to the OASIS Management Organization at the web site http://www.tsin.com. OASIS Node names shall be stored in a DNS name directory, which shall be accessible by Customers as an HTML page. b. URL Structure: The OASIS Node naming conventions shall use standard URL structures. c. OASIS Node Home Directory: The home directory name on a OASIS Node shall be OASIS to identify that the directory is related to the OASIS. The name of each Primary Provider and Secondary Provider with shall be 10 listed under OASIS with a hot-link , so that Users can navigate directly to Provider Home Pages. Common Gateway Interface (CGI) scripts shall be located in the directory cgi as follows: //(OASIS Node name)/OASIS/(Transmission Provider)/cgi/(cgi script name) Where: (OASIS Node name) is the World Wide Web URL address of the OASIS Information Provider. Transmission Provider is the 4 character acronym of the transmission provider (cgi script name) is (register | (template name)) (?search) Where: register is the name of the cgi script program to register a user (template name) is name of the template cgi script for the template of data being requested, see Appendix B, Query Variables. (?search) a list of query variable with their settings Example: To request the hourly schedule template at WXYZ Co. http://www.wxyz.com/oasis/wxyz/cgi/scheduledatc ?TEMPLATE=scheduledatc&VER=1&FMT=html &DATETIMETZ=19960412040000PD&PROVIDER=wxyz 4.2.2 Data Element Dictionary The following are the requirements for the Data Element Dictionary: a. Definition of OASIS Information Elements: All OASIS Information elements shall be defined in the Data Element Dictionary which will be stored in the OASIS Node directory: http://(OASIS Node Name)/OASIS/(Transmission Provider)/(datadic.html | datadict.txt). Where: datadic.html is the HTML version of the data element dictionary datadic.txt is the ASCII text version of the data element dictionary The global Data Dictionary is defined in Appendix A. The local data element names, such as Path Codes, may be unique within the Primary Provider s territory, while universally accessible data element names shall be globally unique. In posting OASIS information, TSIPs shall use only 11 the names listed in the Data Element Dictionary. Each entry in the Data Element Dictionary shall contain as a minimum: ù Unique name of the data element ù Description of the data element ù Formats for all primitive data elements shall include: - Character string (ASCII), Floating point, integer, Boolean, universal time format, registered object definition, etc. - Length of field ù Units ù Lists of valid values that the data element could assume, limits on numerical values, or other validation criteria. ù Definition of the data element 4.2.3 General Rules for OASIS Templates Section 4.3 lists the set of OASIS Templates. These OASIS Templates are intended to be used precisely as shown for download and upload of data. For on-line display, all relevant information must be provided but flexibility is permitted as to how the data are displayed. The construction of the OASIS Templates shall follow the rules described below: a. Unique OASIS Template Name: Each type of OASIS Template shall be identified with a unique name which shall be displayed to the User whenever the OASIS Template is accessed. b. Source Information: Each OASIS Template shall identify the source of its information by including or linking to the name of the Primary Provider, the Secondary Provider, or the Customer who provided the information. c. Time Stamp: Each OASIS Template shall include a timestamp indicating when it was created or last updated. d. Column Headings: OASIS Template column headings shall define the elementary Data Element Dictionary entries for the data values. The order of the column headings shall define the order that the values are presented. Within a table, the ordering of some column headings may be selected by Users from pull-down menus. For tables with selectable columns, the number of columns displayed or selected for download shall be determined by entry into a specified field. e. Rows: The table rows below the column headings shall represent the data being presented. 12 f. Row Wrap: If the width of tables is larger than can be displayed in readable size on a single screen, the rows shall either wrap on the screen or shall be accessible through horizontal scrolling. g. Documentation: OASIS Information shall be in non- cryptic English, with all mnemonics defined in a glossary of terms. TSIPs shall provide on-line descriptions and help screens to assist Users understanding the displayed information. Documentation of all formats, contents, and mnemonics shall be available both as displays and as files which can be downloaded electronically. ù HTML Hot-Links or other pointer mechanisms may be provided for column headings in OASIS Templates which permit the User to access documentation describing the meaning, type, and format of the data in the column. ù HTML Hot-Links or other pointer mechanisms may be provided for data in the OASIS Templates to explanations, comments, constraints, and other notes. ù In order to meet the User-Friendly goal and permit the flexibility of the OASIS to expand to meet new requirements, the OASIS Templates shall be as self- descriptive as possible. 4.2.4 Display Request and Response Procedures 4.2.4.1 Display Request A request for the display of the information in a OASIS Template shall consist of the following minimal input (either through direct data entry or through selection procedures): TEMPLATE=(template name) Additional Query Variables may be included to specify non-default data, either through direct data entry or through selection procedures. These additional Query Variables shall be prefixed with an ampersand (&), suffixed with an equal sign (=), and followed by the appropriate parameters. If repeated values are given for a Query Variable, the variable name will be suffixed with a digit starting with 1 and increasing by one for each repeated variable, for example: &PATH1=ABC-XYZ &PATH2=ABC-RST 13 4.2.4.2 Display Response The information in the OASIS Template requested shall be presented as a display, using the display formats defined by the TSIP. 4.2.5 File Request, File Download Response, and Form Upload Rules and Procedures 4.2.5.1 File Request Rules and Procedure A request to download a file of the information in a OASIS Template to a User site shall consist of the following minimal input (either through direct data entry, through selection procedures on a display, or through an uploaded computer file): TEMPLATE=(template name) &VER=(nn.n) &FMT=(aaaa) $DTZ= (nnnnnnnnnnnnnnaa) $PROVIDER=(aaaa) Additional Query Variables may follow to specify specific data; otherwise default data will be assumed. These additional Query Variables shall be prefixed with an ampersand (&), suffixed with an equal sign (=), and followed by the appropriate parameters. If repeated values are given for a Query Variable, the variable name will be suffixed with a digit starting with 1 and increasing by one for each repeated variable, for example: &PATH1=ABC-XYZ &PATH2=ABC-RST 4.2.5.2 File Download Response Rules and Procedures The response to a request for the download of Template information into file at the User site shall conform to the following rules: a. Download ASCII Delimited Files: Users shall always be able to download all OASIS Template information in ASCII with no special embedded codes. Query Variables shall be used to define what data is being downloaded. Each Query Variable (containing the response to the query) shall be followed by an equals sign (=) and the parameters associated with the variable. Each record shall be separated by a carriage return plus line feed ( ). The fields within a record shall be delimited by a comma (,). Text fields shall be enclosed with double quotes ("). 14 b. Data Compression: Data compression of downloadable files shall be supported, using ZIP compression methods. c. Non-ASCII Formats: Formats in addition to ASCII may be used (at the TSIP s option). If formats other than ASCII are available for downloading or uploading specific data elements, these formats shall be indicated in the Data Element Dictionary for those data elements. d. Partial OASIS Template Download: TSIPs shall either divide large OASIS Templates into separate files for downloading or shall permit the User to select which rows of a OASIS Template they wish to download. Every download file for a OASIS Template shall contain the following records in the indicated order. The following 6 records shall always precede the Template information: REQUEST_STATUS=nnn VERSION=nn.n DATETIMETZ=nnnnnnnnnnnnnnaa PRIMARY_PROVIDER=aaaaaaaaaaaaaaaaaaaaaaaaa DATA_ROWS=nnn COLUMN_HEADERS=aaaa ..aaaaaa The DATA_ROWS record contains the number of data records following the COLUMN_HEADERS. The COLUMN_HEADERS record contains a column for each field that is required in the Template, in the order shown in the Template. The Template information then follows as records which correspond one-to-one with the column headings. The order of the records shall be that a column only changes its value after all columns to the right of it have changed their values. In other words, the rightmost column varies first, then the second rightmost, on back to the leftmost column which varies only after all columns to the right have varied. 4.2.5.3 Form Upload Rules and Procedures a. Upload using HTTP Protocol: Customers and Providers shall be able to upload OASIS Templates using the file request format of section 4.2.5.1. b. Upload ASCII Delimited Files: Customers and Providers shall be able to upload OASIS Templates in ASCII with no special embedded codes. Query Variables shall be used to define what data is being 15 uploaded. Each Query Variable shall be followed by an equals sign (=) and the parameters associated with the variable. Each record shall be separated by a carriage return plus line feed ( ). The fields within a record shall be delimited by a comma (,). Text fields shall be enclosed with double quotes ("). Every ASCII delimited upload file reflecting an input OASIS Template (as opposed to a file requesting Template information) shall contain the following records in the indicated order. TEMPLATE=(template name) (If template CGI procedure is called then this record is optional) VERSION=nn.n OUTPUT_FORMAT=aaaa DATETIMETZ=nnnnnnnnnnnnnnaa PRIMARY_PROVIDER=aaaaaaaaaaaaaaaaaaaaaaaaa DATA_ROWS=nnn COLUMN_HEADERS=aaaa ..aaaaaa The DATA_ROWS record contains the number of data records following the COLUMN_HEADERS. The COLUMN_HEADERS record contains a column for each field that is required in the Template, in the order shown in the Template. The Template information then follows as records which correspond one-to-one with the column headings. c. Data Compression: Data compression of large uploaded files shall be supported, using ZIP compression methods. d. Default User Directory: The default customer directory for upload of files shall be /OASIS/(Provider)/upload Where: Provider is the 4 character acronym of the Primary Provider. 4.3 TEMPLATE DESCRIPTIONS The following OASIS Templates are required as a minimum. The definitions of the data elements are listed in the Data Dictionary in Appendix A. The definitions of the Query Variables are listed in the Query Variable Dictionary in Appendix B. TSIPs must provide a more detailed supplemental definition of the terms Point of Receipt (POR) and Point of Delivery (POD), clarifying how the terms are being used. If POR and POD are not used, then Path Name must include directionality. Most of the Templates represent response information, sent from the OASIS Node to the Customer. Some, as noted in their 16 descriptions, are input information, sent from the Customer to the OASIS Node. 4.3.1 Summary System Information Templates The Summary System Information Templates provide information on a specific path with ATC being offered by one or more Providers (Primary and Secondary Providers). a. Summary Path Hourly ATC Template (sumpathhouratc) ù PROVIDERS (all PROVIDERS supplying CAPACITY for Path) ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù INTERFACE_TYPE ù COMMENTS ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE b. Summary Path Daily ATC Template (sumpathdayatc) ù PROVIDERS (all PROVIDERS supplying CAPACITY for Path) ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù INTERFACE_TYPE ù COMMENTS ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE c. Summary Monthly ATC Template (sumpathmonthatc) ù PROVIDERS (all PROVIDERS supplying CAPACITY for Path) ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù INTERFACE_TYPE ù COMMENTS ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE d. Summary Yearly ATC Template (sumpathyearatc) ù PROVIDERS (all PROVIDERS supplying CAPACITY for Path) ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù INTERFACE_TYPE ù COMMENTS ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE 17 4.3.2 Provider System Information Templates The OASIS Templates which display Provider TS Information shall provide the following information. Depending upon the Query Variables, the information will be provided with Providers per Path or Paths per Provider or other combinations: a. Hourly Capacity Available for Purchase (houratc)is used to display the hourly ATC that is available for sale by a Primary Provider or Reseller for one or more paths. ù PRIMARY_PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù BEGDATETZ ù ENDDATETZ ù SELLER_NAME ù INTERFACE_TYPE ù ANCILLARY_SERVICES_REQUIREMENTS ù COMMENTS ù TIME_OF_LAST_UPDATE ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE ù PRICE ù PRICE_UNITS b. Daily Capacity Available for Purchase (dayatc) is used to display the daily ATC that is available for sale by a Primary or Secondary Provider. ù PRIMARY_PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù BEGDATETZ ù ENDDATETZ ù SELLER_NAME ù INTERFACE_TYPE ù ANCILLARY_SERVICES_REQUIREMENTS ù COMMENTS ù TIME_OF_LAST_UPDATE ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE ù PRICE ù PRICE_UNITS c. Monthly Capacity Available for Purchase (monthatc) is used to display the monthly ATC that is available for sale. ù PRIMARY_PROVIDER ù PATH_NAME 18 ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù BEGDATETZ ù ENDDATETZ ù SELLER_NAME ù INTERFACE_TYPE ù ANCILLARY_SERVICES_REQUIREMENTS ù COMMENTS ù TIME_OF_LAST_UPDATE ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE ù PRICE ù PRICE_UNITS d. Yearly Capacity Available for Purchase (yearatc) is used to display the yearly ATC that is available for sale. (Optional) ù PRIMARY_PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù BEGDATETZ and ENDDATETZ ù SELLER_NAME ù INTERFACE_TYPE ù ANCILLARY_SERVICES_REQUIREMENTS ù COMMENTS ù TIME_OF_LAST_UPDATE ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE ù PRICE ù PRICE_UNITS e. Hourly Schedule (scheduledatc) is used to display a Provider s scheduled transmission capacity usage. ù PRIMARY_PROVIDER ù PATH_NAME(S) ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù CURTAILMENT_PRIORITY ù SOURCE ù SINK ù ASSIGNMENT_REF ù INTERFACE_TYPE ù CUSTOMER_REQUEST_IDENTITY ù DEAL_REFERENCE ù COMMENTS ù TIME_OF_LAST_UPDATE ù DTMMTZ (Date and Time Available) ù CAPACITY ù CAPACITY_TYPE 19 ù PRICE ù PRICE_UNITS 4.3.3 Secondary Provider (Reseller) Posting Templates Sellers may aggregate portions of several previous purchases to create a new service, if this capability is provided by the Transmission Services Information Provider. Secondary Providers shall use the following templates for providing resell information: a. Secondary Provider Capacity Posting (Input) (secondatcpost) shall be used by the Secondary Provider to post on to the OASIS Node the transmission capacity for resale. ù PRIMARY_PROVIDER ù SELLER_NAME ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù INTERFACE_TYPE ù ANCILLARY_SERVICES_REQUIREMENTS ù REQUEST_REF ù BEGDATETZ ù ENDDATETZ ù CAPACITY ù CAPACITY_TYPE ù TERMS_AND_CONDITIONS ù SELLER_NAME ù SELLER_COMPANY ù SELLER_PHONE ù SELLER_FAX ù SELLER_EMAIL ù PREV_ASSIGN_REF ù REASSIGNED_CAPACITY (Capacity from each previous assignment being offered for sale) ù REASSIGNED_BEGDATETZ ù REASSIGNED_ENDDATETZ ù COMMENTS ù HOUR ù PRICE ù PRICE_UNITS b. Secondary Provider (Reseller) Capacity Remove (Input) (secondatcremove) shall be used by the Secondary Provider to remove a posting of transmission capacity. ú PRIMARY_PROVIDER ù SELLER_NAME ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù INTERFACE_TYPE 20 ù ANCILLARY_SERVICES_REQUIREMENTS ù REQUEST_REF ù BEGDATETZ ù ENDDATETZ ù CAPACITY(Total capacity being removed) ù CAPACITY_TYPE ù TERMS_AND_CONDITIONS ù SELLER_NAME ù SELLER_COMPANY ù SELLER_PHONE ù SELLER_FAX ù SELLER_EMAIL ù PREV_ASSIGN_REF ù REASSIGNED_CAPACITY (Capacity being removed from each previous reassignment) ù REASSIGNED_BEGDATETZ ù REASSIGNED_ENDDATETZ ù COMMENTS 4.3.4 Services Information Templates a. Ancillary Services Available for Purchase (servavail) is used to provide information regarding the different services that are available for sale by a Service Provider. ù ANCILLARY_SERVICE_ PROVIDER ù ANCILLARY_SERVICE_CATEGORY ù ANCILLARY_SERVICE_TYPE ù SELLER_NAME ù SELLER_COMPANY ù SELLER_PHONE ù SELLER_FAX ù SELLER_EMAIL ù PRICE ù PRICE_UNITS ù DTTZTS_POSTED ù DTTZTS_EXPIRES ù COMMENTS ù SERVICE_DESCRIPTION b. Services Transmission (servtrans) is used to provide detailed information regarding the transmission services that are available for sale by a Primary Provider in the Templates in Section 4.3.2. This Template is used to summarize tariff information for the convenience of the Customer. Fields which are not used may have Not Applicable assigned to them. (Optional) ù TARIFF_REFERENCE ù PRIMARY_ PROVIDER ù SERVICE_CATEGORY ù SERVICE_TYPE 21 ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù RATE_INFORMATION ù UNITS ù COMMENTS ù RECALLABLE_REASONS ù RECALLABLE_MINIMUM_NOTICE ù RECALLABLE_QUEUE_ORDER ù RECALLABLE_RESUMPTION ù CURTAILMENT_REASONS ù CURTAILMENT_MINIMUM_NOTICE ù CURTAILMENT_QUEUE_ORDER ù CURTAILMENT_RESUMPTION ù SERVICE_TIMING_MINIMUM_DURATION ù SERVICE_TIMING_MAXIMUM_DURATION ù CUSTOMER_PAYMENT ù ASSIGNABILITY ù INCREASE_OBLIGATION ù LOSS_OBLIGATION ù CUSTOMER_REQUIREMENTS ù PROVIDER_OPTIONS 4.3.5 Service Request Transaction Templates The Primary Provider shall assign a unique assigned reference identifier for each customer request to purchase capacity or services. This identifier will be used to track the request through various stages. a. Customer Capacity Purchase Request (Input) (atcrequest) is used by the Customer to request the purchase of transmission services. ù CUSTOMER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù SELLER_NAME (Secondary Provider) ù SOURCE ù SINK ù CAPACITY ù CAPACITY_TYPE ù BEGDATETZ ù ENDDATETZ ù REQUEST_REF ù PRICE ù PRICE_UNITS ù DISCOUNT ù DEAL_REFERENCE ù ANCILLARY_SERVICES_REQUIREMENTS ù INTERFACE_TYPE ù COMMENTS 22 b. TSIP Posting of Acknowledge Receipt of Request (atcacknowledge)is used to acknowledge that the Customer s request was received by the OASIS Node. It does not imply that the Provider has received the request. ù CUSTOMER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù SELLER_NAME ù SOURCE ù SINK ù CAPACITY ù CAPACITY_TYPE ù BEGDATETZ ù ENDDATETZ ù ASSIGNMENT_REF ù REQUEST_REF ù PRICE ù PRICE_UNITS ù DISCOUNT ù DEAL_REFERENCE ù ANCILLARY_SERVICES_REQUIREMENTS ù INTERFACE_TYPE ù COMMENTS c. Provider Capacity Purchase Status Response to Customer Request (atcstatus) is posted upon the request of a Customer, to indicate the status and queue of the request. It is almost identical to the Customer Purchase Request, but includes a Status field, a Queue field, and an Assignment Reference identifier assigned by the Primary Provider, which will be used to track all transactions for specific Capacity. When a Customer calls up the Template, all posted requests for that Customer are retrieved. Only the authorized Customer is permitted to view this information. When a Secondary Provider calls up the Template, all posted requests for that Secondary Provider are retrieved. Only the authorized Secondary Provider is permitted to view this information. The following information is included: ù PRIMARY_PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù SELLER_NAME ù SOURCE 23 ù SINK ù CAPACITY (of total transaction) ù CAPACITY_TYPE ù BEGDATETZ ù ENDDATETZ ù REQUEST_REF ù CUSTOMER ù PRICE ù PRICE_UNITS ù DISCOUNT ù DEAL_REFERENCE ù SERVICE_DESCRIPTION ù ASSIGNMENT_REF ù STATUS = None, Pending, Received, Accepted by Customer, Accepted by Seller, Confirmed for Scheduling, Withdrawn, or Rejected ù INTERFACE_TYPE ù DTTZTS_QUEUED ù COMMENTS ù PREV_ASSIGN_REF ù REASSIGNED_CAPACITY (Capacity from each previous transaction) ù REASSIGNED_STATUS= Posted, Received, Accepted by Seller, Accepted by Customer, Withdrawn, or Rejected ù REASSIGNED_BEGDATETZ ù REASSIGNED_ENDDATETZ ù COMMENTS d. Customer s Purchase Acknowledge Acceptance (Input) (atcaccept) is used by the Customer to acknowledge his agreement or rejection of a purchase after the Provider has indicated that the purchase request is accepted. It is identical to the Provider Response. ú CUSTOMER ù PRIMARY_ PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù SELLER_NAME ù SOURCE ù SINK ù CAPACITY ù CAPACITY_TYPE ù BEGDATETZ ù ENDDATETZ ù REQUEST_REF ù PRICE ù PRICE_UNITS ù DISCOUNT ù DEAL_REFERENCE ù SERVICE_DESCRIPTION ù ASSIGNMENT_REF 24 ù STATUS =Accepted or Rejected ù INTERFACE_TYPE ù DTTZTS_QUEUED ù COMMENTS e. Seller Form to Acknowledge Capacity Purchase Status (Input) (sellerack) is used by a Secondary Provider to indicate the status and queue of a request by a Customer. It is almost identical to the Customer Purchase Request, but includes a Status field, a Queue field, and a Schedule Reference number assigned originally by the Primary Provider, which will be used to track all transactions for the specific Capacity. The following information is included in the Form: ù CUSTOMER ù PRIMARY_PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù SELLER_NAME ù SOURCE ù SINK ù CAPACITY (Total capacity acknowledged) ù CAPACITY_TYPE ù BEGDATETZ ù ENDDATETZ ù REQUEST_REF ù PRICE ù PRICE_UNITS ù DISCOUNT ù DEAL_REFERENCE ù SERVICE_DESCRIPTION ù ASSIGNMENT_REF ù INTERFACE_TYPE ù DTTZTS_QUEUED ù PREV_ASSIGN_REF ù REASSIGNED_CAPACITY(Previous capacity to be reassigned) ù REASSIGNED_STATUS= Received, Accepted by Seller, Withdrawn, or Rejected ù REASSIGNED_BEGDATETZ ù REASSIGNED_ENDDATETZ ù COMMENTS f. Seller Form to Reassign Service Rights to Another Customer (Input) (sellerrassign) is used by the Secondary Provider to ask the Transmission Services Information Provider to reassign some or all of the Seller s rights to Services to another Customer, following a confirmation of a sale of these services from that Customer. ù CUSTOMER 25 ù PRIMARY_PROVIDER ù PATH_NAME ù POINT_OF_RECEIPT ù POINT_OF_DELIVERY ù SELLER_NAME ù SOURCE ù SINK ù CAPACITY (Total capacity being sold) ù CAPACITY_TYPE ù BEGDATETZ ù ENDDATETZ ù REQUEST_REF ù PRICE ù PRICE_UNITS ù DISCOUNT ù DEAL_REFERENCE ù SERVICE_DESCRIPTION ù ASSIGNMENT_REF ù INTERFACE_TYPE ù DTTZTS_QUEUED ù PREV_ASSIGN_REF ù REASSIGNED_CAPACITY (Capacity being sold from each previous assignment) ù REASSIGNED_BEGDATETZ ù REASSIGNED_ENDDATETZ ù REASSIGNED_STATUS = Accepted or Rejected ù COMMENTS 4.3.6 Informal Information Templates a. Provider/Customer Want-Ad Posting Request (Input) (wantadpost) is used by Providers and Customers who wish to advertise. ù PROVIDER or CUSTOMER ù COMPANY ù PHONE ù FAX ù EMAIL ù DTTZTS_POSTED ù DTTZTS_EXPIRES ù KEYWORD ù SUBJECT ù WANT-AD b. TSIP Posting of Want-Ad Response (wantadlisting) is the response of the TSIP to a Want-Ad posting request. The contents are identical to the request. ù PROVIDER or CUSTOMER ù CONTACT ù PHONE ù FAX ù E-MAIL 26 ù DTTZTS_POSTED ù DTTZTS_EXPIRES ù KEYWORD ù SUBJECT ù WANT-AD 4.4 FILE REQUEST AND FILE DOWNLOAD EXAMPLES 4.4.1 File Example for Summary Path Hourly ATC Example of the request and response for path W/AAAA/PATH-ABC// for today. ù Request http://(OASIS Node name)/OASIS/wxyz/cgi/sumpathouratc?&ver=1.0&fmt=data& dtz=19960412043010ED& pprovider=wxyz& path=W/AAA/PATHABC//& relday=0& shr=0& her=14& capacity_type1=firm& capacity_type2=non-firm ù Response Data REQUEST-STATUS=200 (Successful) VERSION=1.0 DATETIMETZ= 19960410113526PD PRIMARY_PROVIDER=wxyz DATA_ROWS=30 COLUMN_HEADERS= PROVIDER , PATH_NAME , POR , POD , IT , CT , CAP , DTMMT Z , COMMENTS AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100100PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100100PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100200PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100200PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100300PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100300PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100400PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100400PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100500PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100500PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100600PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100600PD , N/A 27 AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100700PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100700PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100800PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100800PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604100900PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604100900PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604101000PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604101000PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604101100PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604101100PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604101200PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604101200PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604101300PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604101300PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604101400PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604101400PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , FIRM ,300, 199604101500PD , N/A AAA , W/AAA/PATHABC// , N/A , N/A , E , NON- FIRM ,500, 199604101500PD , N/A 4.4.2 File Example for Hourly Schedule Data This example shows a request for the hourly schedule data. This demonstrates how to specify query variables from a file. ù Request URL Request (HTTP method=GET) http://(OASIS Node name)/OASIS/wxyz/cgi/scheduledatc& ver=1.0& fmt=data& dtz=19960412043010ED& pprovider=wxyz &por=BBB &pod=CCC &relday=1 &hour- start=08 &hour-end=17 URL Request (HTTP method=POST) $ fetch_http http://(OASIS Node name)/OASIS/wxyz/cgi/OASISdata -f c:/OASIS/wxyz/upload/inputfile.txt Where inputfile.txt contains the following: 28 Template=scheduledatc& ver=1.0 & fmt=data& dtz=19960412044010CD& pprovider=wxyz& por=BBB& pod=CCC &relday=1 &hour-start=08 &hour-end=17 ù Response Data REQUEST-STATUS=200 VERSION=1.0 DATETIMETZ=19960410114702PD PROVIDER=wxyz DATA_ROWS=50 COLUMN_HEADERS= PATH_NAME , POR , POD , SOURCE , SINK , REF , IT , CUSTO MER , DEAL , CT , CAP , DTMMTZ , AAA , AAABBB , BBB , CCC , source , sink , 794245 , E , BPA , deal , NO N-FIRM ,50, 199604100800PD , , AAA , AAABBB , BBB , CCC , source , sink , 795000 , E , BPA , deal , FI RM ,39, 199604101700PD , , 4.4.3 Customer Capacity Purchase Request This example shows how a customer might make a request to purchase capacity from a provider. The information to be sent to the provider is specified using Query Variables in a file. The example uses the FETCH_HTTP program to send a file to the OASIS node. ù Request File purchase.txt template= atcrequest& fmt=data& ver=1.0& dtz=19960412043010MD& pprovider=abcd &por=aaa&pod=bbb&path=aaa1bbb1&source=src1& sink=sink1& capacity=100& capacity_type=non-firm& year=1996& month=04&day-start=15& day-end=20& tz=pd& price=1.00& customer=cust1& deal_ref=1234567800& comments= Example purchase request FETCH_HTTP Command to send purchase request $ fetch_http http://(OASIS Node name)/OASIS/abcd/cgi/atcrequest -f c:/OASIS/abcd/upload/purchase.txt ù Response Data REQUEST-STATUS=200 VERSION=1.0 DATATIMEZ=19960412073500PD PRIMARY_PROVIDER=abcd DATA_ROWS=1 COLUMN_HEADERS= BEGDATETZ , ENDDATETZ , ASSIGNMENT_REF , PROVIDER , PATH , POR , POD , SELLER_NAME , SOURCE , SINK , CAPACITY , CAPACITY_TYPE , REQUEST_REF , DEAL_REFERENCE , COMMENTS 29 19960415000100PD , 19960420002400PD , ABC998553 , ABC , AAA1BBB1 , AAA , AAA , ABC , src1 , sink1 , 100 , NON-FIRM , , 1234567800 , Example Purchase Request 4.4.4 Capacity Purchase Status ù Request URL http://(OASIS Node name)/OASIS/abc/cgi/atcstatus? ver=1.0& fmt=data& dtz=19960412043010ED& pprovider=wxyz& customer=cust1& year=1996&month=04 ù Response Data REQUEST-STATUS=200 VERSION=1.0 DATATIMEZ=19960412090215PD PRIMARY_PROVIDER=wxyz DATA_ROWS=1 COLUMN_HEADERS=BEGDATETZ, ENDDATETZ, ASSIGNMENT_REF, PROVIDER, PATH, POR, POD, SELLER_NAME, SOURCE, SINK, CAPACITY, CAPACITY_TYPE, REQUEST_REF, DEAL_REFERENCE, COMMENTS, STATUS, ASSIGNMENT_REF, DTTZTS_QUEUED, NO_PREF_ASSIGN_REF 19960415000100PD , 19960420002400PD , ABC998553 , ABC , AAA1BBB1 , AAA , AAA , ABC , src1 , sink1 , 100 , NON-FIRM , , 1234567800 , Example Purchase Request , Accepted by Seller , ABC998532 , 19960412080000PD , 0 4.4.5 Customer s Purchase Acknowledge Acceptance (Input) ù Customer Input File: accept.txt TEMPLATE=atcaccept &VERSION=1.0& FORMAT=data& &dtz=19960412043010ED& provider=wxyz &STATUS= Accepted & BEGDATETZ=19960415000100PD &ENDDATETZ=19960420002400PD &ASSIGNMENT_REF=ABC998553 &PROVIDER=wxyz &PATH=AAA1BBB1 &POR=AAA &POD=AAA &SELLER_NAME=ABC &SOURCE=src1 &SINK=sink1 &CAPACITY=100 &CAPACITY_TYPE=NON-FIRM &REQUEST_REF= &DEAL_REFERENCE=1234567800 &COMMENTS= Example Purchase Request &ASSIGNMENT_REF= ABC998532 &DTTZTS_QUEUED=19960412080000PD &NO_PREF_ASSIGN_REF=0 FETCH_HTTP command $ fetch_http http://(OASIS node name)/OASIS/(provider)/cgi/atcaccept -f c:\OASIS\wxyz\upload\accept.txt 5. PERFORMANCE REQUIREMENTS A critical aspect of any system is its performance. Performance encompasses many issues, such as security, sizing, response to user requests, availability, backup, and other parameters that are critical for the system to function as desired. The following sections cover the performance requirements for the OASIS. 30 5.1 SECURITY Breaches of security include many inadvertent or possibly even planned actions. Therefore, several requirements shall be implemented by the TSIPs to avoid these problems: a. Provider Update of TS Information: Only Providers, including Secondary Providers, shall be permitted to update their own TS Information. b. User Input Only ASCII Text: TSIPs shall be permitted to require that inputs from Customers shall be filtered to permit only strict ASCII text (strip bit 8 from each byte). c. Provider Updating Over Public Facilities: If public facilities are involved in the connection between a Provider and the OASIS Node, the Provider shall be able to update his TS Information only through the use of ASCII or through encrypted files. d. User Registration and Login: All Users shall be required to register and login to a Provider s Account before accessing that Provider s TS Information. e. User Passwords: All Users shall enter their personal password when they wish access to TS Information beyond the lowest Access Privilege. f. Service Request Transactions: Whenever Service Request transactions are implemented entirely over the OASIS, Customer Service Request requests shall require both an individual Customer password for the request, and an individual Provider password for the notification of acceptance. g. Data Encryption: Sophisticated data encryption techniques and the secure id mechanisms being used on the public Internet shall be used to transfer sensitive data across the Internet and directly between OASIS Nodes. h. Viruses: TSIPs shall be responsible for protecting the OASIS Nodes from viruses. i. Performance Log: TSIPs shall keep a log on User usage of OASIS resources. j. Disconnection: TSIPs shall be allowed to disconnect any User who is degrading the performance of the OASIS Node through the excessive use of resources, beyond what is permitted in their Service Level Agreement. 31 k. Premature Access: The TSIP log shall also be used to ensure that Users who are affiliated with the Provider s company (or any other User) do not have access to TS information before it is publicly available. l. Firewalls: TSIPs shall employ security measures such as firewalls to minimize the possibility that unauthorized users shall access or modify TS Information or reach into Provider or User systems. Interfaces through Public Data Networks or the Internet shall be permitted as long as these security requirements are met. m. Certificates and Public Key Standards (optional) Use of alternative forms of login and authentication using certificates and public key standards is acceptable. 5.2 ACCESS PRIVILEGES Users shall be assigned different Access Privileges based on external agreements between the User and the Provider. These Access Privileges are associated with individual Users rather than just a company, to ensure that only authorized Users within a company have the appropriate access. The following Access Privileges shall be available as a minimum: a. Access Privilege Read-Only: The User may only read publicly available TS information. b. Access Privilege for Transactions: The Customer is authorized to transact Service Request requests. c. Access Privilege Read/Write: A Secondary Provider shall have write access to his own Provider Account on a OASIS Node. 5.3 OASIS RESPONSE TIME REQUIREMENTS TSIPs can only be responsible for the response capabilities of two portions of the Internet-based OASIS network: ù The response capabilities of the OASIS Node server to process interactions with Customers ù The bandwidth of the connection(s) between the OASIS Node server and the Internet. Therefore, the OASIS response time requirements are as follows: a. OASIS Node Server Response Time: The OASIS Node server shall be capable of supporting its connection(s) to 32 Users with an average aggregate data rate of at least A bits per second. A is defined as follows: A = N * R bits/sec where: N = 5% of registered Customers. and R = 28,800 bits/sec per Customer. b. OASIS Node Network Connection Bandwidth: The bandwidth B of the OASIS Node connection(s) to the Internet shall be at least: B = 2 * A bits/sec c. Time to Meet Response Requirements: The minimum time responses shall be met within 1 month of User registration for any single new User. If more than 10 new Users register in one month, 2 months lead time shall be permitted to expand/ upgrade the OASIS Node to meet the response requirements. 5.4 OASIS PROVIDER ACCOUNT AVAILABILITY The following are the OASIS Provider Account availability requirements: a. OASIS Provider Account Availability:The availability of each OASIS Provider account on a OASIS Node shall be at least 98.0% (downtime of about 7 days per year). Availability is defined as: % Availability = (1 - Cumulative Provider Account Downtime) * 100 Total Time A Provider account shall be considered to be down, and downtime shall be accumulated, upon occurrence of any of the following: 1. One or more Users can not link and log on to the Provider account. The downtime accumulated shall be calculated as: ä for affected Users of 1/n * (Login Time), which is the time used by each affected User to try to link and log on to the Provider account, and where n is the total number of Users actively registered for that Provider account. 2. One or more Users can not access TS Information once they have logged on to a Provider account. The downtime accumulated shall be calculated as: ä for affected Users of 1/n * (Access Time), which is the time used by each affected User to try to access data, and where n is the total number of Users actively registered for that Provider. 33 3. A five (5) minute penalty shall be added to the cumulative downtime for every time a User loses their connection to a Provider s account due to a OASIS Node momentary failure or problem. 5.5 BACKUP AND RECOVERY The following backup and recovery requirements shall be met: a. Normal Backup of TS Information: Backup of TS Information and equipment shall be provided within the OASIS Nodes so that no data or transaction logs are lost or become inaccessible by Users due to any single point of failure. Backed up data shall be no older than 30 seconds. Single points of failure include the loss of one: ù Disk drive or other storage device ù Processor ù Inter-processor communications (e.g. LAN) ù Inter-OASIS communications ù Software application ù Database ù Communication ports for access by Users ù Any other single item which affects the access of TS Information by Users b. Spurious Failure Recovery Time: After a spurious failure situation, all affected Users shall regain access to all TS Information within 30 minutes. c. Long-Term Backup: Permanent loss of critical data due to a catastrophic failure shall be minimized through off-line storage on a daily basis and through off-site data storage on a periodic basis. d. Catastrophic Failure Recovery: Recovery from a catastrophic failure or loss of a OASIS Node may be provided through the use of alternate OASIS Nodes which meet the same availability and response time requirements. TSIPs may set up prior agreements with other TSIPs as to which Nodes will act as backups to which other Nodes, and what procedure will be used to undertake the recovery. Recovery from a catastrophic failure shall be designed to be achieved within 24 hours. 5.6 TIME SYNCHRONIZATION The following are the time requirements: a. Time Synchronization: Time shall be synchronized on 34 OASIS Nodes such that all time stamps will be accurate to within ñ0.5 second of official time. This synchronization may be handled over the network using NTP, or may be synchronized locally using time standard signals (e.g. WWVB, GPS equipment). b. Network Time Protocol (NTP): OASIS Nodes shall support the Internet tool for time synchronization, Network Time Protocol (NTP), which is described in RFC-1305, version 3, so that Customers shall be able to request the display and the downloading of current time on a OASIS Node for purposes of user applications which might be sensitive to OASIS time. 5.7 TS INFORMATION TIMING REQUIREMENTS TO BE COMPLETED BY THE INDUSTRY 5.8 TS INFORMATION ACCURACY The following requirements relate to the accuracy of the TS information: a. TS Information Reasonability: TS information posted and updated by the Provider shall be validated for reasonability and consistency through the use of limit checks and other validation methods. b. TS Information Accuracy: Although precise measures of accuracy are difficult to establish, Providers shall use their best efforts to provide accurate information. 5.9 PERFORMANCE AUDITING The following are the performance auditing requirements: a. User Help Desk Support: TSIPs shall provide a Help Desk that is available at least during normal business hours (local time zone) and normal work days. b. Time-Stamped OASIS Performance Log: All posting of TS information, all updating of TS information, all User logins and disconnects, all User download requests, all Service Request requests, and all other transactions shall be time stamped and stored in a OASIS Performance Log. This OASIS Performance Log shall be the official log for auditing performance, as well as acting as the official record of interactions. c. Monitoring Performance Parameters:TSIPs shall use their best efforts to monitor performance parameters. Any 35 Customer shall be able to read or download these performance statistics. 5.10 MIGRATION REQUIREMENTS The following are the migration requirements: a. Support for Legacy Capabilities: Any time mandated upgrades or modifications to OASIS capabilities and tools are made to the OASIS, TSIPs shall continue to support the existing capabilities and tools for at least 3 months. This overlap will permit Customers the time to upgrade their own systems to reflect these changes. 36