Participant Technical Reference Manual - IESO

MANUAL 

PUBLIC 

IMO_MAN_0024 

Market Manual 6 

Participant Technical 

Reference Manual 

Issue 21.1 

The “PTRM” provides the technical details for 

hardware and software that a participant in the 

electricity market may need to interface with the 

IESO 

Public

Disclaimer 

The posting of documents on this Web site is done for the convenience of market participants and 

other interested visitors to the IESO Web site. Please be advised that, while the IESO attempts to have 

all posted documents conform to the original, changes can result from the original, including changes 

resulting from the programs used to format the documents for posting on the Web site as well as from 

the programs used by the viewer to download and read the documents. The IESO makes no 

representation or warranty, express or implied that the documents on this Web site are exact 

reproductions of the original documents listed. In addition, the documents and information posted on 

this Web site are subject to change. The IESO may revise, withdraw or make final these materials at 

any time at its sole discretion without further notice. It is solely your responsibility to ensure that you 

are using up-to-date documents and information. 

This document may contain a summary of a particular market rule. Where provided, the summary has 

been used because of the length of the market rule itself. The reader should be aware; however, that 

where a market rule is applicable, the obligation that needs to be met is as stated in the “Market 

Rules”. To the extent of any discrepancy or inconsistency between the provisions of a particular 

market rule and the summary, the provision of the market rule shall govern. 

Document ID 

IMO_MAN_0024 

Document Name Participant Technical Reference Manual 

Issue Issue 21.1 

Reason for Issue Revised for Verizon CA Renewal May 2010. 

Effective Date 

March 15, 2010 - estimated

Participant Technical Reference Manual 

Document Change History 

Document Change History 

Issue Reason for Issue Date 

For change history prior to Issue 10, see issue 17.0 of the PTRM. 

10.0 Issued for baseline 15.1 for changes related to the IESO Portal and 

Identity Management systems and access to the Cybertrust Entrust 

Authority Administration tool used for creation of version 7.1 

certificates that are required for TRA users accessing the Portal. 

11.0 Issued for Baseline 16.0. To Include new RTUs to the certified list 

of devices in section 4.1.2 

June 15, 2006 

September 13 2006 

12.0 Issued for Baseline 16.1 December 6, 2006 

13.0 Issued for Baseline 17.0 March 7, 2007 

14.0 Issued for Baseline 17.1 June 6, 2007 

15.0 Issued for Baseline 18.0 September 12, 2007 

16.0 Issued for Baseline 18.1 December 12, 2007 

17.0 Issued for Baseline 19.0 March 5, 2008 

18.0 Issued for Baseline 19.1 June 4, 2008 

19.0 Revised for Baseline 20.0 September 10, 2008 

20.0 Revised for Verizon Data Center Move date change from May to 

June 2009. 

June 5, 2009 

21.0 Revised for Baseline 21.0 December 9, 2009 

21.1 Revised for Verizon CA Renewal May 2010. March 15, 2010 

estimated 

Related Documents 

Document ID 

MDP_RUL_0002 

Document Title 

Market Rules 

Issue 21.1 - March 15, 2010 - estimated 

Public

Document Control 

IMO_MAN_0024 

Public 

Issue 21.1 - March 15, 2010 - estimated


Table of Contents 


Table of Contents ...................................................................................................... i 

List of Figures ....................................................................................................... iiiv 

Table of Changes ................................................................................................. ivvi 

1. Overview ........................................................................................................... 1 

1.1 About this Manual .............................................................................................. 1 

1.2 Purpose ............................................................................................................. 1 

1.3 Scope ................................................................................................................ 1 

1.3.1 Out of Scope .......................................................................................... 2 

1.4 Limitations ......................................................................................................... 2 

1.5 Who Should Use This Manual ........................................................................... 2 

1.6 Conventions ...................................................................................................... 2 

1.7 How This Manual is Organized .......................................................................... 3 

2. Participant Workstation, Network & Security ................................................ 5 

2.1 Participant Workstation ...................................................................................... 5 

2.1.1 Hardware Requirements ........................................................................ 5 

2.1.2 Software Requirements .......................................................................... 6 

2.2 Participant Network ......................................................................................... 33 

2.2.1 Internet ................................................................................................. 34 

2.2.2 Private Network .................................................................................... 34 

2.2.3 Shared Network ................................................................................... 35 

2.3 Accounts / Identity Credentials ........................................................................ 36 

2.3.1 Identity Management and Certification Authority .................................. 37 

2.3.2 Certificates & Keys ............................................................................... 39 

2.3.3 Integration of Digital Certificates with IESO Web Servers..................... 42 

2.3.4 Portal SSO and Identity Management System ..................................... 48 

2.3.5 Certificate Lifecycle System & Entrust Authority Administration Tool .... 48 

2.3.6 Requirements for Browser and Digital Certificate Software Compatibility50 

3. Dispatch Information...................................................................................... 56 

3.1 Dispatch Workstations ..................................................................................... 56 

3.1.1 Hardware Requirements ...................................................................... 56 

3.1.2 Software Requirements ........................................................................ 57 

3.2 Dispatch Message Exchange .......................................................................... 58 

3.2.1 Overview .............................................................................................. 58 

3.2.2 Functional Parts ................................................................................... 59 

3.2.3 Dispatch Messaging ............................................................................. 60 

Issue 21.1 – March 15, 2010 - estimated Public i


IMO_MAN_0024 

3.2.4 Dispatch Message Structure ................................................................ 61 

3.2.5 Dispatch Message Scenarios ............................................................... 62 

3.3 Real Time Network .......................................................................................... 65 

3.4 Voice Communication Specifications ............................................................... 67 

3.4.1 Normal-Priority PATH .......................................................................... 67 

3.4.2 High-Priority PATH............................................................................... 67 

3.4.3 Security ................................................................................................ 68 

3.4.4 Diverse Path ........................................................................................ 68 

4. Operational Metering Equipment & AGC ...................................................... 69 

4.1 Operational Metering Equipment ..................................................................... 69 

4.1.1 Introduction .......................................................................................... 69 

4.1.2 Qualified Devices ................................................................................. 69 

4.1.3 Field Instrumentation Standards .......................................................... 71 

4.1.4 Data Specifications .............................................................................. 72 

4.1.5 Power Supply Specification .................................................................. 72 

4.1.6 Communications Specification ............................................................. 73 

4.1.7 RTU Site Certification .......................................................................... 73 

4.2 AGC Operational RTU Specifications .............................................................. 74 

5. Market Applications ........................................................................................ 78 

5.1 Market Application Systems Information .......................................................... 78 

5.1.1 Overview of Dataflow Systems ............................................................ 78 

5.1.2 Bidding Application .............................................................................. 79 

5.1.3 Settlements Application ....................................................................... 83 

5.1.4 Application Interfaces ........................................................................... 86 

5.2 Funds Administration ....................................................................................... 87 

5.2.1 HTML and Text File Invoices ............................................................... 87 

5.2.2 E-mail .................................................................................................. 87 

5.2.3 Fund Transfers .................................................................................... 87 

Appendix A: Forms ...................................................................................... A–1 

Appendix B: List of Commonly Used Acronyms ............................................ 1 

References ................................................................................................................ 1 

ii Public Issue 21.1 - March 15, 2010 - estimated


List of Figures 

List of Figures 

Figure 2-1: Internet Explorer, Internet Options - Advanced ................................................... 9 

Figure 2-2: Internet Explorer, Entrust Truepass Applet Security Warning ............................14 

Figure 2-3: Internet Explorer, Untrusted Publishers Certificates Listing ...............................15 

Figure 2-4: Internet Explorer 6.0, Internet Options - Security – Windows XP .......................16 

Figure 2-5: Internet Explorer 7.0, Internet Options - Security - Windows XP ........................17 

Figure 2-6: Internet Explorer 7.0, Internet Options - Security - Windows Vista .....................17 

Figure 2-7: Internet Explorer 6.0, Internet Options - Custom Security Settings Window ......18 

Figure 2-8: Internet Explorer 6.0, Internet Options - Trusted Sites Security .........................19 

Figure 2-9: Internet Explorer 6.0, Trusted Sites Security - Web Sites Addition ............ 191920 

Figure 2-10: Internet Explorer 7.0, Trusted Sites Security - Web Sites Addition – Windows 

Vista .............................................................................................................................20 

Figure 2-10: Internet Explorer, Enabling or Disabling Pop-up Blocker ......................... 252526 

Figure 2-11: Internet Explorer, Activating Pop-up Blocker Settings .............................. 262627 

Figure 2-12: Pop-up Blocker Settings Window Filter Setting for MPI Use .................... 262627 

Figure 2-13: Addition of MPI URL to Allow Web Site List for Pop-ups ......................... 272728 

Figure 2-14: Java Control Panel Settings .................................................................... 282829 

Figure 2-15: Right Mouse Button 'Save Target as ..." Function to Download Java Policy File 

............................................................................................................................. 303031 

Figure 2-16: File type Selection to Download Java Policy File ..................................... 313132 

Figure 2-17: Folder Options, File Types Listing window .............................................. 313132 

Figure 2-18: Create New Extension Window ............................................................... 323233 

Figure 2-19: Folder Option Window with Detail on 'POLICY' extension shown. ........... 323233 

Figure 2-20: Edit File Type Extension Window ............................................................ 333334 

Figure 2-21: MPI and MIM API Conceptual Architecture ............................................. 484850 

Figure 2-22: IESO Portal Conceptual Architecture ...................................................... 545456 

Figure 3-1: Message Exchange Interfaces .................................................................. 595962 

Figure 3-2: Responsibilities for Telecommunications and Site Readiness for RTUs .... 666669 

Figure 3-3: Responsibilities for Telecommunications and Site Readiness for DWS ..... 666669 

Figure 4- 1 Block Diagram of Typical AGC Control Arrangement for Generation units With 

Remote MW Setpoint Control Capability .............................................................. 767681 

Figure 5-1: Overview of Dataflow from the MP to IESO systems ................................. 797985 

Figure 5-2: Schematic Overview for Settlement Statements and Data Files ................ 858591 

Issue 21.1 – March 15, 2010 - estimated Public iii

Table of Changes 

IMO_MAN_0024 

Table of Changes 

Reference 

(Section and 

Paragraph) 

Section 2.1.2 

paragraph 62 

Section 2.1.2 

paragraph 

93,94,95 

Section 2.3.6 

paragraph 173 

Section 4.1.2 

Qualified Devices 

Description of Change 

Updated content of Java Policy File for Verizon CA Update starting in 

March 2010 

Updated Market Participant Firewall configuration content for Verizon 

CA Update starting in March 2010 

Updated IP addresses and Domain Names for Verizon CA Update starting 

in March 2010 

Added 2 new Remote Terminal Unit (RTU) to line 266 

iv Public Issue 21.1 - March 15, 2010 - estimated


1. Overview 

1. Overview 

1.1 About this Manual 

1 The “Participant Technical Reference Manual” is comprised of the following 

sections: 

Section 

1.0 Overview 

Name of Section 

2.0 Participant Workstation, Network and Security 

3.0 Dispatch Information 

4.0 Operational Metering Equipment and AGC 

5.0 Market Applications 

The content of each is described more fully later in this section. 

1.2 Purpose 

2 This “Participant Technical Reference Manual” (“PTRM”) provides the potential 

market participants with the necessary general technical standards to participate in the 

IESO-administered markets. It also provides references to other documents and 

information sources for detailed technical specifications required for participating in 

the IESO-administered markets. This document is not intended to be used as a standalone 

technical reference manual for all issues within the realm of electricity 

production, distribution, or consumption. 

3 Written for market participants, it provides only information relevant to the participant 

for communicating with the IESO and participating in the electricity market. It provides 

more detailed information on the requirements stated in the “Market Rules”. 

4 It is intended as a generic guide and the relevance of information in certain sections 

will depend on the market requirements of the participant. Market participants are 

expected to understand what information they will require for their particular role in the 

market and apply the required sections accordingly. 

1.3 Scope 

5 This document is intended to provide market participants with a description of the 

various facilities and interfaces they require to participate in the IESO-administered 

markets. 

6 This document supplements the market rules. It also points to other documents and 

information sources that provide installation, set-up, and configuration information for 

the various tools and facilities required for participation in the electricity market as a 

supplier, transmitters, distributor, generator, or consumer. 

Issue 21.1 - March 15, 2010 - estimated Public 1

1. Overview IMO_MAN_0024 

7 The material contained in various sections of the PTRM is limited to information that is 

relatively stable and not subject to frequent change. Technical details that are subject 

to change, on a more frequent basis, are posted on the Technical Interfaces page of 

IESO‟s Web site at www.ieso.ca. It is therefore important for market participants to 

refer to the specific technical documents on the Technical Interfaces page when 

reviewing the requirements outlined in the “PTRM”. Specific document references are 

included in each of the relevant sections of the “PTRM” as well as in the References 

table at the rear of the document. 

1.3.1 Out of Scope 

8 Technical requirements for revenue metering are not contained within the “PTRM”. 

Details for revenue metering requirements are contained in “Market Manual 3: 

Metering” which is available on IESO‟s Web site. 

1.4 Limitations 

9 The information in this document is limited to the information available at the time of 

publication. It is subject to change as the various technical interfaces and/or market 

requirements evolve. 

10 The information in this document is based on the market rules provided to the IESO by 

the Minister of Energy, Science and Technology dated April 15, 1999 and subsequent 

updates thereof. Future changes in the “Market Rules” may result in changes in this 

document. No warranty is provided that any participant‟s requirements have been 

completely or correctly interpreted or that all issues have been identified. 

11 The “Participant Technical Reference Manual” is only a technical specification manual 

and does not provide any procedural information. For procedural details please refer to 

the relevant user manual and/or guide. 

1.5 Who Should Use This Manual 

12 The “PTRM” is meant for all those who wish to participate in the IESO-administered 

market. These include, but are not limited to, the generators, distributors, wholesale 

sellers, wholesale consumers, retailers, transmitters and the financial market 

participants. 

13 The “PTRM” provides the participants with the technical details and specifications of 

the hardware and software as well as other security-related information required by 

participants for interfacing and information exchange with the IESO. 

1.6 Conventions 

14 The standard conventions followed for market manuals are as follows: 

The word „shall‟ denotes a mandatory requirement; 

Terms and acronyms used in this market manual including all Parts thereto that are 

italicized have the meanings ascribed thereto in Chapter 11 of the “Market Rules”; 

2 Public Issue 21.1 - March 15, 2010 - estimated


1. Overview 

Double quotation marks are used to indicate titles of legislation, publications, forms 

and other documents. 

Any procedure-specific convention(s) shall be identified within the procedure 

document itself. 

1.7 How This Manual is Organized 

15 This document is organized by specific areas of interest and not by market participant 

roles. It is the responsibility of market participants to know what components are 

relevant. 

16 The “Participant Technical Reference Manual” is divided into several parts based on 

specific areas of interest. A brief description and summary of each part is provided 

below: 

Section 1.0 - Overview: Contains information about the purpose, scope, limitations 

and structure of the manual. 

Section 2.0 - Participant Workstation, Network and Security: This section contains 

the minimum technical specifications for the participant workstation required by 

market participants making bids/offer or obtaining information about market 

activity. The minimum hardware and software specifications for the participant 

network used for interacting with the IESO are also described. This part also 

provides market participants with information and technical specifications for the 

digital certificates. The participants require the digital certificates or User ID 

account, identity credentials for purposes of data confidentiality and security. 

Section 3.0 - Dispatch Information: This part contains information about the 

technical requirement of the dispatch workstation and general information about 

dispatch message exchange. The primary audiences for this part are those 

participants who will be providing electrical power into or withdrawing electric 

energy from the IESO-controlled grid and will receive dispatch instructions from 

the IESO. It includes as well information on the functional aspects of the Dispatch 

Message Exchange as well as the message structures & actions. Minimum hardware 

and software specifications for the real time network required for acquiring real 

time data, dispatch of automatic generation control (AGC) and dispatch messaging 

are also provided besides general information on voice communication 

specifications and types. 

Section 4.0 - Operational Metering Equipment & AGC: This part details 

information and technical specifications for the operational metering requirements. 

It does not contain information on revenue metering which is provided in the 

“Market Manual 3: Metering” on the IESO‟s Web site. 

It also provides technical specifications for the AGC Operational Remote Terminal Units 

(RTUs). 

Section 5.0 -Market Applications: Provides technical specifications & requirements 

for the bidding application, settlement application, invoicing and application 

interfaces (MIM API). For viewing templates, validation tables and sample data 

files please refer to the Technical Interfaces page of IESO‟s Web site. 

Issue 21.1 - March 15, 2010 - estimated Public 3

1. Overview IMO_MAN_0024 

17 The technical specification and requirements contained in the Sections of this Manual 

are authorized under “Appendix 2.2 of the market rules”. Specific references, where 

applicable, will be included at the beginning of each section. 

– End of Section – 

4 Public Issue 21.1 - March 15, 2010 - estimated


2. Participant Workstation, Network & Security 

2. Participant Workstation, Network & 

Security 

18 (For supporting rule references, please refer to “Appendix 2.2, Section 1.4 of the 

market rules”) 

2.1 Participant Workstation 

2.1.1 Hardware Requirements 

Platform 

Processor 

19 The client software provided by the IESO is designed to be platform independent. The 

IESO has performed extensive testing of this software on the Windows XP and Vista 

operating systems. The software should also function on other versions of the Windows 

Operating System (i.e. Windows 98 or higher) but these are no longer formally 

supported by the IESO. Displays may be rendered incorrectly if a Windows Operating 

System is not used. Other operating systems and hardware may be used as long as the 

operating system supports the Java 2 Runtime Environment (see java.sun.com). At this 

time there are no known issues with the IESO Portal and the supported browsers. 

20 For Windows XP It is recommended that the client workstation hardware conform to 

Microsoft‟s specifications found at: 

http://www.microsoft.com/windowsxp/pro/evaluation/sysreqs.mspx 

and for Windows Vista at 

http://www.microsoft.com/windows/products/windowsvista/editions/systemrequiremen 

ts.mspx. 

However going forward the IESO recommends the following: 

21 The minimum recommended processor is a 1 GHz 32 –Bit (X86) or 64-bit (x64) CPU 

Memory 

22 The minimum recommended system requirements are 1 GB of internal RAM. 

Disk 

23 The recommended available disk space is a minimum of 15 gigabytes on a 40 GB hard 

drive. 

Interface Cards 

24 A minimum 56Kb modem or faster cable modem or equivalent is strongly 

recommended if the market participant is interfacing with the IESO over the public 

Internet. 

Issue 21.1 – March 15, 2010 - estimated Public 5

2. Participant Workstation, Network & Security IMO_MAN_0024 

Monitor 

Printer 

25 Support for DirectX 9 graphics and 128 MB of graphics memory (minimum), WDDM 

driver, Pixel Shader 2.0 in hardware and 32 bits per pixel. 

26 If connecting to the IESO through an internal network over the web, then the 

appropriate participant network equipment will be required. 

27 The supported monitor must be SVGA with a resolution capability of 800 x 600 pixels 

or greater. 

28 It is recommended that a printer with high resolution of at least 600 dpi and that 

supports multiple fonts be used. 

Other Components 

29 Additional components that should be included with your system are a compatible twobutton 

mouse, keyboard, and 1.44 MB high-density floppy disk drive. 

30 A Smartcard and reader are highly recommended options. 

31 DVD-ROM drive 

2.1.2 Software Requirements 

Operating System 

32 The recommended operating system is Windows XP SP2 or Vista as shown on the 

IESO Supported Client Platform web page at : 

http://www.ieso.ca/imoweb/ti/ti_Supported-Client-Platform.asp . 

Previous versions of Windows are no longer supported by the IESO. The operating 

system must have support for the TCP/IP protocol. 

Note: When Windows is used as the operating system, the preferred Short Date format is 

yyyy/mm/dd. Other Short Date formats may be used provided the year placement is set to 

yyyy. Go to the Control Panel Regional Settings to make this adjustment. The delivery dates 

used by the Internet Explorer browser in the submission of bids are generated from this date 

setting and value. 

Browser 

33 All IESO applications within the MPI are fully tested with the supported OS /Browser 

and JRE combinations. 

34 128-bit encryption is standard with the Internet Explorer browser and this can be 

verified under the 'Help' menu and then the 'About Internet Explorer' menu selection. 

IESO secure web sites also have been configured to work with SSL 3.0 or higher which 

requires this level of encryption. 

35 The viewing resolution must be 800 x 600 pixels or higher in view maximized mode. 

6 Public Issue 21.1 – March 15, 2010 - estimated



Firewall 

36 Internet Explorer has been tested with the Notice of Disagreement (NOD) and Meter 

Trouble Reporting (MTR) applications. MTR and NOD will function as expected with 

the supported Microsoft OS, Internet Explorer combinations 

37 The IESO Portal is accessible with the supported Microsoft OS, Internet Explorer 

combinations as well as Netscape 7.2 or 8.0 or Mozilla Firefox 1.0, 1.5 or 2.0.1 or 

Safari 2.0. These specifications are provided by the IESO‟s Portal vendor. 

38 Browser requirements as recommended by Entrust for the Entrust Authority 

Administration Services tool for the IESO desktop digital IDs (EPF files) are as shown 

on the IESO Supported Client Platform web page. 

However see http://www.entrust.com/pki/admin_services/specs.htm for complete 

information 

39 It is recommended that the each Market Participant ensure that each participant 

workstation is protected by an appropriate firewall for the network and workstations 

being used. The choice of the technology to be employed is up to the Market 

Participant. 



Microsoft Internet Explorer Configuration for MPI and Portal 

40 For the supported versions of Microsoft Internet Explorer to work properly with the Market 

Participant Interface and Portal there are a number of configuration settings that should be 

made. This includes configuration items in both the Advanced and Security tabs under 

Internet Options menu selection in Internet Explorer. It is important to note that the settings 

are unique to each user profile for IE on a workstation. Therefore, if multiple users with 

separate logins share a workstation, settings will need to be checked and altered as required 

for each user. It is also important to recognize that Internet Explorer 6.0 has differences in 

configuration settings between Windows XP SP1 and SP2 and so does Internet Explorer 

7.0 between Windows XP SP1 and SP2 and Vista. These differences are documented by 

the IESO as required. 

41 The browser settings are essentially the same for IE 6.0 and 7.0 with minor differences 

when using Windows XP–SP2 and Vista. However under Vista, Internet Explorer 7.0 is 

using the new Protected Mode capability for the various security zones as described at: 

http://msdn2.microsoft.com/en-us/library/bb250462.aspx. The recommendation at this 

time is to put the MPI, Portal and IESO corporate web site URL‟s into the „Trusted sites‟ 

zone when using Vista and turn off Protected Mode for this zone only. The MPI will not 

function correctly at this time with Protected Mode turned on and logout will not function 

correctly from the MPI unless the IESO corporate web site in included in the same zone as 

the MPI. Vista enforces the opening of a new browser window every time the security zone 

changes 

Internet Options - Advanced 

42 A number of parameters may need to be set for Advanced Internet Options. To do this: 

1. Under the IE Tools menu select Internet Options 

2. Select the Advanced tab. See Figure 2-1. (IE / Windows XP shown) 




Figure 2-1: Internet Explorer, Internet Options - Advanced 

3. Choose the following settings as shown in Table 2-1 for the appropriate Windows / IE 

combination and then click on the 'Apply' button. Depending on the user's workstation 

software environment, specific options may need to be altered from the settings 

recommended here for proper function of Internet Explorer under all circumstances 

with other non-IESO applications. 

Table 2-1 : Internet Explorer Advanced Internet Options with Windows XP-SP2 and Vista 

Advanced Internet Option 

Parameter 

Accessibility Parameters – all 

Value (blank means 

no check) IE 6.0 – 

XP-SP2 

IE 7.0 – XP-SP2 

IE 7.0 – Vista 

Always expand ALT text for images No stipulation No stipulation No stipulation 

Move system caret with 

focus/selection changes 

Reset text size to medium for new 

windows and tabs 

Reset text size to medium while 

zooming 

Reset Zoom level to 100% for new 

windows and tabs 

Browsing Parameters 

No stipulation No stipulation No stipulation 

N/A No stipulation No stipulation 



Always send URLs N/A N/A 




Parameter 

Automatically check for Internet 

Explorer updates 

Close unused folders in History and 

Favorites 



XP-SP2 

IE 7.0 – XP-SP2 



Disable script debugging No stipulation N/A N/A 

Disable script debugging ( Internet 

Explorer) 


Disable script debugging (Other) N/A No stipulation No stipulation 

Display a notification about every 

script error 


Enable folder view for FTP sites N/A N/A 

Enable FTP folder view (outside of 

Internet Explorer) 

Enable install on demand (Internet 

Explorer) 

N/A 

No stipulation N/A N/A 

Enable install on demand (Other) N/A N/A 

Enable offline items to be 

synchronized on a schedule 


Enable page transitions No stipulation No stipulation No stipulation 

Enable Personalized Favorites menu No stipulation No stipulation No stipulation 

Enable third-party browser extensions 

(requires restart) 

Enable visual styles on buttons and 

controls in web pages 

Force offscreen compositing even 

under Terminal Server (requires 

restart) 

 

 

Notify when downloads complete No stipulation No stipulation No stipulation 

Reuse windows when launching 

shortcuts 


Show friendly HTTP error messages 

Show friendly URLs N/A N/A 

Show Go button in Address bar N/A N/A 

Show Internet Explorer on the 

desktop 


Underline links Always Always Always 

Use inline AutoComplete No stipulation No stipulation No stipulation 





Parameter 

Use most recent order when switching 

tabs with Ctrl+Tab 

Use Passive FTP (for firewall and 

DSL modem compatibility) 



XP-SP2 

IE 7.0 – XP-SP2 




Use smooth scrolling 

HTTP 1.1 Settings 

Use HTTP 1.1 

Use HTTP 1.1 through proxy 

connections 

International 


Always show encoded addresses N/A No stipulation No stipulation 

Send IDN Server Names N/A No stipulation No stipulation 

Send IDN server names for 

Intranet addresses 


Send UTF-8 URLs N/A No stipulation No stipulation 

Show Information Bar for encoded 

addresses 


Use UTF-8 for mailto links N/A No stipulation No stipulation 

Java(Sun) 

Use Java 2 v1.5.0_xx for 

((requires restart) (If shown) 

Microsoft VM 

Java Console enabled No stipulation No stipulation N/A 

Java logging enabled No stipulation No stipulation N/A 

JIT compiler for virtual machine 

enabled 

Multimedia 

Don't display online media content in 

the media bar (if shown) 

N/A 


Always use ClearType for HTML N/A No stipulation No stipulation 

Enable automatic image resizing 

Enable Image Toolbar (requires 

restart) 


Play animations in web pages No stipulation No stipulation No stipulation 

Play sounds in web pages No stipulation No stipulation No stipulation 




Parameter 



XP-SP2 

IE 7.0 – XP-SP2 

Play videos in web pages No stipulation N/A N/A 


Show image download placeholders No stipulation No stipulation No stipulation 

Show pictures No stipulation No stipulation No stipulation 

Show image dithering No stipulation No stipulation No stipulation 

Printing 

Print backgrounds colors and images No stipulation No stipulation No stipulation 

Search from the Address bar No stipulation No stipulation No stipulation 

Security 

Allow active content from CD to run 

on My Computer 

Allow active content to run in files on 

My Computer 

Allow software to run or install even 

if the signature is invalid 

Check for Publishers certificate 

revocation 

Check for server certificate revocation 

(requires restart) 

Check for signatures on downloaded 

programs 




 

 

 

Do not save encrypted pages to disk No stipulation No stipulation No stipulation 

Empty Temporary Internet Files 

folder when browser is closed 

Enable Integrated Windows 

Authentication (requires restart) 



Enable Profile Assistant No stipulation N/A N/A 

Enable memory protection to help 

mitigate online attacks 

N/A N/A No stipulation 

Enable native XMLHTTP support 

Phishing Filter N/A Turn on 

automatic 

website checking 

Use SSL 2.0 

Use SSL 3.0 

Turn on 

automatic 

website 

checking 

Use TLS 1.0 No stipulation No stipulation No stipulation 





Parameter 



XP-SP2 

IE 7.0 – XP-SP2 

Warn about invalid site certificates 

Warn if changing between secure and 

not secure mode 

Warn if forms submittal is being 

redirected 

Warn if Post submittal is redirected to 

a zone that does not permit posts 

 

N/A N/A 

N/A 


Browser Settings for Entrust Authority Administration Tool 

43 The browser settings for compatible browsers for accessing the Entrust Authority 

Administration Tool available at the Cybertrust Certification Authority at: 

https://ccip.idm.cybertrust.com/AdminServices/ are as follows. 

Table 2-2 Entrust Authority Administration Tool – Browser Settings 

Browser Setting name Setting Location Comment 

Netscape 

Navigator 7.0 

Microsoft 

Internet 

Explorer 5.x 

Microsoft 

Internet 

Explorer 6.x 

and 7.0 

Enable all cookies 

Ask me before 

storing a cookie 

Enable Java 

Enable JavaScript 

for Navigator 

Allow per-session 

cookies 

(not stored) 

Active Scripting 

Scripting of Java 

applets 

Enable 

Enable 

Enable 

Enable 

Enable or Prompt 



First Party Cookies Accept or Prompt Tools/Internet 

Options/Privacy 

/Advanced 

Allow per-session 

cookies 

(not stored) 


Tools/Internet 


/Advanced 

Active Scripting Enable or Prompt Tools/Internet 

Options/Securit 

y/Internet/Custo 

m Level 


applets 




Make settings after selecting 

overall privacy setting to 

medium, medium high etc. 




Make setting for the internet 

or trusted sites zones as 

req‟d 

Make setting for the internet 

or trusted sites zones as 



Browser Setting name Setting Location Comment 

y/Internet/Custo 

m Level 

Third party Cookies Block Tools/Internet 


/Advanced 

Microsoft VM - 

Java Permissions 

Medium - (cannot 

be disable Java) 



y Settings ( all 

zones) 

req‟d 




Disabling Microsoft VM 

Java in the Security settings 

will disable use of the 

Entrust Authority system 

applet. 

These settings will need to be considered for other third party applications/systems the Market 

Participant may be using. SSL version 3.0 for https is also required and this should be set 

appropriately. All communications to the CA Entrust Authority system is done over port 443 

via the Entrust XAP protocol. 

44 The Entrust Authority Admin Tool uses a small java based applet. It is also a digitally 

signed applet that the user needs to allow to run by accepting the first time prompt if 

displayed (as shown below) when navigating to the Entrust Authority Administration 

website. If the user inadvertently chose the Never run software from Entrust Limited the 

Entrust Authority Administration tool will not work. The user should choose Always run 

software from Entrust Limited or Ask me every time. See Figure 2-2. The choice is stored 

on the user‟s workstation in Internet Explorer. 

Figure 2-2: Internet Explorer, Entrust Truepass Applet Security Warning 

45 If the user does inadvertently choose Never run software from Entrust Limited, it will 

need to be changed. This can be done by going to the IE menu selection - Tool/Internet 

Options/Content/Certificates/Publisher and then select the Untrusted Publishers tab. See 

Figure 2-3. In this location, the Entrust Limited certificate can be seen. The user will need 

to highlight it and click on remove. Then on the next attempted login to the Entrust 

Authority Administration tool, the user must choose the Always run software from Entrust 

Limited selection which will install the certificate in IE in the Trusted Publishers location. 




Figure 2-3: Internet Explorer, Untrusted Publishers Certificates Listing 

Internet Explorer - Internet Options - Security 

46 A number of security configuration settings may need to be made in order for 

proper functioning of the browser with various IESO web sites. The market 

participant can choose to define and place the MPI and Portal URLs for the 

Production and Sandbox environments into the Trusted Sites zone under IE 

Security or leave those URLs in the Internet zone by default for Windows XP. 

If the URLs are left in the Internet zone by default then it is recommended that 

the Security settings for that zone be configured as defaulted (medium security 

level) except where noted. However for Windows Vista is important that the 

URLs be placed in the „Trusted sites‟ zone as well as the IESO corporate site as 

discussed previously. 

47 When the URL's are included in the 'Trusted Sites' zone for XP then it is 

recommended that the Security settings be configured as Medium-low instead 

of the default Low. This provides reasonable security but eliminates most 

prompts. For Vista, the default is medium and this can be left as is. 

48 However the market participant's IT security people should be involved in 

deciding the appropriate settings and implement based on their own rules and 

policies, which may take precedence over the settings recommended here. The 

choice is in the end, up to each market participant. 

Internet Zone Security Settings 

49 When leaving the IESO MPI and Portal URLs by default in the IE 'Internet' 

zone for XP it is recommended the following settings be made: 

4. Under the Tools menu select Internet Options 

Select the Security tab. See Figure 2-4 and Figure 2-5. (IE / Windows XP shown). For 

Windows Vista some additional security has been added in the form of Protected Mode as 

mentioned above. This can be turned on or off for each security zone. It is required under 

Vista for the MPI web sites that Protected Mode is turned off. This can be done in the 



Security tab via the check box at the bottom of the Internet Options window as shown in 

Figure 2-6. 

Figure 2-4: Internet Explorer 6.0, Internet Options - Security – Windows XP 




Figure 2-5: Internet Explorer 7.0, Internet Options - Security - Windows XP 

Figure 2-6: Internet Explorer 7.0, Internet Options - Security - Windows Vista 

5. Click on the Internet zone icon to specify its security settings. The default level for the 

Internet zone in IE is 'Medium'. Most of the settings should be left as is unless security 

policies for the Market Participant require something else. 

6. Click on the 'Custom Level' button to activate the Security Settings configuration 

window. See Figure 2-7. (IE / Windows XP shown) 

7. Verify default settings are as per Table 2-2 and Table 2-3 when IESO MPI and Portal 

URLs are by default in the Internet zone. If conflicts occur for other IE operations with 

other web sites modify as required for optimal and secure operation of Internet 

Explorer. 

8. Click on the "OK" button to accept all changes. 



Figure 2-7: Internet Explorer 6.0, Internet Options - Custom Security Settings Window 

Trusted Sites Security Settings 

50 When including the IESO MPI and Portal URLs in the IE 'Trusted Sites' zone it 

is recommended the following configuration settings be made 

1. Under the Tools menu select Internet Options 

2. Select the Security' tab. See Figures 2-4 to 2.6 above. 

3. Click on the Trusted Sites zone icon to specify its security settings. The default level for 

the Trusted Sites zone in IE is 'Low' for XP and Medium for Vista. It is recommended 

to change this 'Medium-low' for XP and leave as default for Vista. Notice that the 

'Sites' button is now active. 

4. Click on the 'Sites' button to activate the 'Trusted Sites' entry window. See Figure 2-8 

5. Type in the address(es) of the trusted sites for the IESO's Production and Sandbox MPI 

and Portal environments and use the 'add' button to add them. See Figure 2-9. 

6. When using Vista the MPI logout transition to the IESO home page will work only 

within the same browser window provided that both “sites” (https://mos.ieso.ca ( or 

https://moswebh.ieso.ca for Sandbox) and http://www.ieso.ca) are in the same security 

zone. It appears that Vista enforces the opening of a new browser window every time 

the security zone changes. Maintaining the same browser window can be accomplished 

with the proper wildcard in the Trusted Sites list. See Figure 2-11. In this way, the 

logout redirect to the IESO home page stays within the Trusted Sites zone. 




Figure 2-8: Internet Explorer 6.0, Internet Options - Trusted Sites Security 

Figure 2-9: Internet Explorer 6.0, Trusted Sites Security - Web Sites Addition 



Figure 2-10: Internet Explorer 7.0, Trusted Sites Security - Web Sites Addition – Windows 

Vista 

7. Click on the "Require Server Verification (https) for all sites in this zone" option check 

flag if all sites entered here are https sites like the IESO's MPI or Portal. 

8. Click on the 'OK' button. 

9. Click on the 'Custom Level' button to activate the Security Settings configuration 

window. 

10. Verify settings as per Table 2-3 when IESO MPI and/or Portal URLs are in the Trusted 

Sites zone for and the appropriate Windows and Internet Explorer combination. If 

conflicts occur for other IE operations with other web sites modify as required for 

optimal and secure operation of Internet Explorer. Note that choosing the 'Prompt' 

parameter value will require more user overhead than 'Enable'. 

Note: The user can use the right mouse click and then on 'What's This' on each item in IE 'Security 

Settings' for an explanation of each item. 




Table 2-3: IE Internet Options, Security Settings – Windows XP-SP2 and Vista 

Parameter 

General Security 

Level for zone 

.NET Framework 

.NET Frameworkreliant 

components 

Active X Controls 

and Plug-ins 

Allow Previously 

unused ActiveX 

controls to run without 

prompting 

MPI and Portal 

URLs in 

'Internet' zone by 

default for XP- 

SP2 and IE 6.0 

When MPI and 

Portal URLs 

added to 

'Trusted Sites' 

zone in XP-SP2 

and IE 6.0 

When MPI and 

Portal URLs 

added to 



and IE 7.0 

Medium Defaults Medium-Low Medium Medium 

No stipulation on 

all settings 


all settings 


all settings 


all settings 

No stipulation 

on all settings 

No stipulation 

on all settings 

N/A N/A Enable Enable 

When IESO, 


URLs added to 


zone in Vista 

and IE 7.0 


all settings 


all settings 

Allow Scriptlets N/A N/A No stipulation No stipulation 

Automatic prompting 

for ActiveX controls 

Binary and script 

behaviors 

Display video and 

animation on a 

webpage that does not 

use external media 

player 

Download Signed 

ActiveX Controls 

Download Unsigned 

ActiveX Controls 

Initialize and script 

ActiveX controls not 

marked as safe 

Run ActiveX controls 

and plug-ins 

Enable Enable Enable No stipulation 

Enable Enable Enable Enable 

N/A N/A No stipulation No stipulation 

Prompt Enable Enable Enable 

Prompt Prompt Prompt Prompt 

Disable (prompt 

acceptable) 

Enable (prompt 

acceptable) 


acceptable) 


acceptable) 

Enable 

Enable Enable Enable 

Script ActiveX Enable (prompt Enable Enable Enable 



Parameter 

controls marked as 

safe 


URLs in 




acceptable) 

When MPI and 

Portal URLs 

added to 



and IE 6.0 

When MPI and 

Portal URLs 

added to 



and IE 7.0 



URLs added to 


zone in Vista 

and IE 7.0 

Downloads 

Automatic prompting 

for file downloads 


File Download Enable Enable Enable Enable 

Font Download 

Microsoft VM 


acceptable) 


Java Permissions High Safety Medium Safety Medium Safety 

Java VM 

Java permissions High Safety Medium safety Medium safety N/A 

Miscellaneous 

Access data sources 

across domains 

Allow META 

REFRESH 

Allow scripting of 

Internet Explorer Web 

browser control 

Allow script initiated 

windows without size 

or position constraints 

Allow web pages to 

use restricted 

protocols for active 

content 

Allow websites to 

open windows without 

addresses or status 

bars 

Change from 

Disable to Prompt 

or Enable 

Enable 

Change from 

Disable to Prompt 

or Enable 

Enable 

Prompt or 

Enable 

Prompt or Enable 

No stipulation No stipulation No stipulation No stipulation 



N/A N/A No stipulation No stipulation 

Display mixed content Prompt Enable Enable Enable 

Don't prompt for client 

certificate selection 

when no certificates or 

Disable (may be 

changed to enable 

if only one IESO 





Parameter 

only one certificate 

exists - (i.e. automatic 

certificate 

presentation) 

Drag and drop or copy 

and past files 

Include local directory 

path when uploading 

files to a server. 

Installation of desktop 

items 

Launching 

applications and 

unsafe files 

Launching programs 

and files in an 

IFRAME 

Navigate sub-frames 

across different 

domains 

Open files based on 

content, not file 

extension 

Software channel 

permissions 

Submit non-encrypted 

form data 


URLs in 




certificate for the 

profile has been 

imported and 

automatic 

presentation is 

desired) 


acceptable) 

When MPI and 

Portal URLs 

added to 



and IE 6.0 

When MPI and 

Portal URLs 

added to 



and IE 7.0 


N/A N /A Enable Enable 


N /A N /A Prompt Prompt 






URLs added to 


zone in Vista 

and IE 7.0 

Medium Safety Medium Safety Medium Safety Medium Safety 


acceptable) 


Use Phishing Filter N/A N/A Enable Enable 

Use Pop-up blocker No Stipulation No Stipulation No Stipulation No Stipulation 

User data persistence Enable Enable Enable Enable 

Web sites in less 

privileged web content 

zone can navigate into 

this zone 

Scripting 




Parameter 


URLs in 




When MPI and 

Portal URLs 

added to 



and IE 6.0 

When MPI and 

Portal URLs 

added to 



and IE 7.0 

Active scripting Enable Enable Enable Enable 

Allow paste operations 

via script 

Allow programmatic 

clipboard access 

Allow status bar 

updates via script 

Allow websites to 

prompt for 

information using 

scripted windows 


applets 

User Authentication 

Logon 

Enable Enable N/A N/A 

N/A N/A Prompt Prompt 




Automatic logon 

only in Intranet 

zone 

Automatic logon 

only in Intranet 

zone 



URLs added to 


zone in Vista 

and IE 7.0 

Internet Explorer Pop-up Blocker with Windows XP-SP2 / Vista and the MPI and 

Portal 

51 With the release of Windows XP-SP2, pop-up blocker functionality has been 

enabled within Internet Explorer 6.0. This can have some beneficial and some 

detrimental effects depending on the needs of the browser user. When enabled 

with just default settings, the IE pop-up blocker affects the functionality of the 

MPI and Portal. The MPI System Messages and Market Status windows for 

example do not activate and properly display when pop-up blocking is active 

and not disabled for the MPI web site. It is recommended that IE configuration 

settings for pop-up blocking be set so that MPI functionality is not affected. 

52 This functionality continues as is with Internet Explorer 7.0 under Windows XP 

and Vista. The directions included here apply to all the combinations of 

Windows XP and IE 6.0 and 7.0 and Windows Vista and IE 7.0. 

Internet Explorer Turn Pop-up Blocker On or Off 

53 In order to turn off (or on) the IE pop-up blocker function: 

1. Under the Tools menu select the Pop-Up Blocker menu option 




2. A submenu list will display. If the pop-up blocker is enabled the first submenu option 

will indicate Turn Off Pop-up Blocker. If it is disabled the first submenu option will 

indicate Turn On Pop-up Blocker. This option works as a toggle to enable or disable 

the pop-up blocker. See Figure 2-10. 

Figure 2-10: Internet Explorer, Enabling or Disabling Pop-up Blocker 

Internet Explorer Configure Pop-up Blocker Settings 

54 In order to access pop-up blocker settings and set up the pop-up blocker filter 

parameters to allow the proper functioning of MPI: 

1. Under the Tools menu select the Pop-Up Blocker menu option 

2. A submenu list will display. Select the Pop-up Blocker settings submenu option when 

the pop-up blocker has been toggled on. See Figure 2-11. 

3. The Pop-up Blocker Settings windows will activate See Figure 2-12 

4. Select the desired Filter setting (e.g. 'Low: Allow pop-ups from secure sites' as an option 

if pop-ups are required to be blocked from all sites except those sites protected by SSL). 

It is up to the discretion of the market participant to choose the required filter level for 

their needs. The low setting will allow all MPI windows as the MPI URL is a secure 

site. 

5. Enter in the URL addresses of the Sandbox and Production MPI and Portal sites in the 

address of Web site to allow and use the Add button (see Figure 2-13). This will allow 

the proper functioning of MPI and Portal, no matter what the filter level setting. 



Figure 2-11: Internet Explorer, Activating Pop-up Blocker Settings 

Figure 2-12: Pop-up Blocker Settings Window Filter Setting for MPI Use 




Figure 2-13: Addition of MPI URL to Allow Web Site List for Pop-ups 

Sun Java Runtime Environment 

55 Please refer to the IESO Supported Client Platform web page for the required 

Java runtime environment Obtaining this software from the Sun Java web site 

and its installation on the workstation is detailed in the Identity Management 

Operations Guide. It does not need to be set as the default for the browser 

however in either the Java control panel or IE Internet Options. 

56 Only a user with administrative rights may be able to set the default use of the 

JRE Plug-in with IE or not. 

57 The JRE should be installed on the workstation properly configured to enable 

the MPI applet to function when the user navigates to in Internet Explorer. 

These can be checked under the Java control panel. See Figure 2-14 below. 

58 Ensure the setting „Place Java icon in system tray‟ is checked in the Java 

control panel. This will allow access to the Java console via the right mouse 

button. 

59 Ensure that „Enable logging‟ is checked under Debugging in the Java control 

panel. 

60 Ensure that „Hide console‟ is checked under Java Console in the Java control 

panel. This will prevent the Java console from always activating when a user 

navigates to the MPI or uses Internet Explorer. 

61 Ensure that „SSL 3.0‟ is checked under Security in the Java control panel. Also, 

ensure that all other boxes under Security are checked except for „Use SSL 2.0‟ 

and „Use TLS 1.0‟ unless the user has other java applications that need these 

security protocols. If SSL 3.0 is not checked, a Java general exception error 



happens when the user navigates to the MPI in Internet Explorer and clicks on 

the Browse button. 

Figure 2-14: Java Control Panel Settings 




IESO Java Policy File 

62 A special IESO Java, policy file with the file name “.java.policy" (note the dot at the 

beginning of the filename) is required for successful IESO PKI and MPI processing on 

the workstation when using Internet Explorer as the browser for the MPI. It is not 

required for use with the MIM IDK or IESO Portal. This is a simple text-format file 

available from the IESO Technical Interfaces page. It must be installed in each user's 

"C:\Documents and Settings\userID" (e.g. C:\Documents and Settings\smithj) directory 

on the workstation where userID represents the login ID for the user. As of release 

19.0the Verizon CA update in early March, this file will be updated to include the new 

Verizon CA domain names for its replacement CA servers to handle the May 2010 

issuing CA certificate replacement, to simplify the content and improve MPI login 

performance while maintaining java security. Users can, if desired, still use the 

original java policy file which is available on the Technical Interfaces, Software 

downloads page. This version of the Java policy file has few security restrictions but 

high login performance. The edited latest version of the .java.policy file has the 

following content for java permissions: 

grant { 

permission java.lang.RuntimePermission "getProtectionDomain"; 

permission java.security.SecurityPermission "removeProvider.IAIK"; 

permission java.security.SecurityPermission "insertProvider.IAIK"; 

permission java.security.SecurityPermission "putProviderProperty.IAIK"; 

permission java.security.SecurityPermission "removeProvider.Entrust"; 

permission java.security.SecurityPermission "insertProvider.Entrust"; 

permission java.security.SecurityPermission "putProviderProperty.Entrust"; 

permission java.io.FilePermission "", "read, write"; 

permission java.util.PropertyPermission "*", "read, write"; 

permission java.lang.RuntimePermission "queuePrintJob"; 

permission java.net.SocketPermission "ccica1.idm.cybertrust.com", "connect,resolve"; 

permission java.net.SocketPermission "ccipdir.idm.cybertrust.com", "connect,resolve"; 

permission java.net.SocketPermission "ccica2.idm.cybertrust.com", "connect,resolve"; 

permission java.net.SocketPermission "ccipdir2.idm.cybertrust.com", "connect,resolve"; 

permission java.net.SocketPermission "cdp1.public-trust.com", "connect,resolve"; 

permission java.net.SocketPermission "crl.globalsign.net", "connect,resolve"; 

}; 

Without this java policy file with the above content in the home directory location for each user, 

the MPI applet PKI java code will not function correctly when attempting to login. Under such 

circumstances an "applet not inited" error on the browser status line at the bottom may display 

and/or a dialogue box with an error message "Login failed: access denied 

(java.security.SecurityPermission removeProvider.IAIK)". 

63 To download the file from the Technical Interfaces page the user can right mouse 

button click on the file's POL link on the web-site and choose to save to the required 

location as show in Figure 2-15. This will activate the typical Windows "Save As" 

window to allow the user to choose the directory location to save the file to. 



Figure 2-15: Right Mouse Button 'Save Target as ..." Function to Download Java Policy File 

64 The file type 'policy' is not a normal registered file type and this is not required for 

successful download of the IESO '.java.policy' file. To download the file, the user must 

choose the 'Save as type' option "All Files" and choose the appropriate C:\Documents 

and Settings\UserID directory path. The file name must not be changed. See Figure 2- 

16. Once this has been done login to the MPI with IE should be successful. 




Figure 2-16: File type Selection to Download Java Policy File 

65 Prior or after download, Windows XP and Vista users (or administrators) may create a 

'policy' document file type, extension to make the purpose of the file more explicit. To 

do so, after opening Windows Explorer (or any window), select the 'Tools' menu, then 

'Folder Options…' and then the 'File Types' tab selection. See Figure 2-17 for the 

resultant window. 

Figure 2-17: Folder Options, File Types Listing window 



66 Click in the 'New' button to activate the 'Create New Extension' window as shown in 

Figure 2-18 and type in 'POLICY' in the file extension field and leave the Associated 

File Type as . Click on the OK button. 

Figure 2-18: Create New Extension Window 

67 The Folder Options window will now typically indicate some details for the 'POLICY' 

extension and that files of the 'POLICY" extension are of type FT000001, (or 

FT000002 and so on if other customized file extensions have been created previously, 

Windows creates the numbered file types automatically). See Figure 2-19 for an 

example. 

Figure 2-19: Folder Option Window with Detail on 'POLICY' extension shown. 

Click on the 'Advanced' button in order to activate the 'Edit File Type' window as shown in 

Figure 2-20. 




Figure 2-20: Edit File Type Extension Window 

Replace the 'FT00001 entry (or FT000002..FT000003 etc.), with the term 'Java Policy File" for 

ease of identification of the file type and thenm click on the 'OK' button. Ensure that the correct 

file type for the 'POLICY' extension is being changed and not some other file type. 

Correct file extension editing will let the user see that the '.java.policy' file is of the 'Java Policy 

File' type in folder windows. 

Internet Connection 

68 For market participants planning to connect to the IESO through the public Internet, 

the market participant must have an established Internet connection. This may be in the 

form of either a dial-up link to an ISP (Internet Service Provider) or through an internal 

Web-gate or proxy server. The speed of this Internet connection will directly affect 

application performance. 

2.2 Participant Network 

69 Market participants will submit bids/offers, access market, settlements, and metering 

information through the use of the IESO participant network. 

70 There are three methods for a market participant to connect to the IESO. These are 

defined as PUBLIC over the Internet or as PRIVATE through a facility contracted by 

the market participant with a telecommunications service provider, or SHARED over 

the IESO provided frame relay switched network. Market participants who require high 

performance or reliability may wish to consider the PRIVATE or SHARED network 

alternatives. 



71 Regardless of the method chosen, failure of the telecommunications network can occur. 

Market participants should take this into consideration and establish alternate paths or 

contingency plans, as required. 

2.2.1 Internet 

72 The connectivity bandwidth should be at least 28.8-Kbps but higher speeds are 

recommended to maintain optimal performance. 

73 Market participants will access the IESO using IESO digital certificates. To 

authenticate to the IESO Web site the market participant will present an IESO digital 

certificate to the IESO Web Server MOSMIM (a.k.a. MOSWEB). If the IESO 

certificate is valid, the user will be granted access to selected systems. Market 

participants must register for IESO digital certificates. Certificate registration will be 

performed as specified in the Identity Management Operations Guide (see Technical 

Interfaces page of IESO‟s Web site). 

74 Secure Sockets Layer (SSL) is used to encrypt the messages between the client system 

at the market participant and the Web Server at the IESO. SSL uses a combination of 

asymmetric (public and private keys) and symmetric keys (shared secret) to negotiate 

the secure session between the market participant system and the IESO Web Servers. 

This is a standard technology developed originally by Netscape and used extensively 

by Internet web servers to establish secure connections between two systems. 

2.2.2 Private Network 

75 The Private Network option is recommended to market participants concerned about 

having direct control over the performance of telecommunications with the IESO for 

commercial purposes. As the name implies, the market participant privately arranges 

this service with a commercial telecommunications service provider. The quality of 

service is subject to the contract between the market participant and the service 

provider. All associated costs will be borne by the market participant. 

76 The IESO enables this option, by permitting the telecommunications service provider to 

establish a point of presence at the IESO‟s main and backup operating centers. The 

IESO also will provide space and a physically and electrically secure environment for 

the premises equipment. 

77 Market participant is expected to terminate its point-of-presence at the IESO‟s 

premises with routers, supplied by the market participant, located at the IESO‟s main 

and backup operating centers. The actual demarcation point is the Ethernet connection 

to the router. The market participant is solely responsible for the management of its 

telecommunications facilities. 

78 In the interest of manageability, a list of preferred telecommunications service 

providers has been established. These are listed below. As the list may be revised 

periodically, it is recommended that the market participant check the latest version of 

this document. Also, the IESO is prepared to review on a case-by-case basis if the 

market participant prefers a telecommunications service provider not in the list. 

79 The current list of preferred telecommunications carriers consists of the following: 

Allstream, Bell Canada, Hydro One Telecommunications, and Sprint. 




2.2.3 Shared Network 

80 The Frame Relay network will be maintained through AT&T with IESO having 

responsibility for connectivity up to the Frame Relay Access Device (FRAD) or Router 

located on the market participant site. Static routing will be used across the interfaces 

between IESO and the market participant’s network. Reserved internal TCP/IP 

addresses may not be accepted due to possible conflicting addressing schemes on the 

network. An incremental cost sharing agreement must be agreed to with the IESO and 

the proportionate cost will be borne by the market participant. 

81 The market participant must provide the IESO with a registered TCP/IP Ethernet 

address for the Ethernet port that connects to the market participant’s internal network. 

82 RFC 1918 IP addressing will be accepted under certain conditions. Please contact the 

IESO prior to your installation. 

83 To arrange for a Frame Relay connection, contact the IESO (see www.IESO.ca). 

Connecting to the Supplied Ethernet Port 

84 A network connection will need to be established between the Ethernet Port on the 

FRAD and the market participant’s Internal Network. 

85 If distance between the Ethernet Port on the FRAD and the market participant’s 

Internal Network is an issue, then a recommended solution will be to deploy an 

Ethernet Repeater or “Ethernet Extender.” Ethernet Repeaters can effectively increase 

the distance of typical 10BASE-T Ethernet connections from around 182 meters (600 

feet) to over 7,300 meters (24,000 feet) using existing ordinary copper telephone wires. 

86 The IEEE 802.3 10BASE-T standard requires that 10BASE-T transceivers be able to 

transmit over a 100-meter (328 feet) link-using 24AWG unshielded twisted pair wire. 

Due to cable delay, the maximum link length is nearly always limited to about 200 

meters (656 feet), regardless of the cable type. 

87 As a general rule, links up to 150 meters (492 feet) long are achievable for unshielded 

and shielded twisted pair cable, with a maximum 200 meters (656 feet) due to cable 

delay. For each connector or patch panel in the link, subtract 12 meters (39.4 feet) from 

the 150-meter limit. This will allow for links of up to 126 meters (413.4 feet) using 

standard 24 AWG UTP wire and two patch panels within the link. Higher quality low 

attenuation cables may be required when using links greater than 126 meters. 

Traffic Aggregation 

88 The IESO will preserve the predictable response time of the Real Time network for 

market participants who chose to use the Frame Relay Network to submit bids, offers, 

and access market settlements and metering information over the Frame Backbone. 

89 Separate Permanent Virtual Circuits (PVC‟s) will be established with an appropriate 

Committed Information Rate (CIR) for each specific type of function. For example: 

Browser based HTTP traffic will be allocated its own Frame Relay PVC. The CIR 

value will be adjusted to accommodate the individual bandwidth requirements of each 

market participant. The incremental cost of this will be charged to the market 

participant. 



Market Participant Firewall Configuration 

90 Web based network communications will be secured using SSL. Depending on the 

market participant’s internal network configuration, changes may have to be made to 

allow a SSL connection if firewalls are used. 

91 Changes to the market participant’s firewall configuration will be dependent upon the 

type of firewall in use. TCP Ports 80, 389, 443 and 829 will need to be open. Verizon 

Entrust systems are also configured for ports 636, 709, 710 but these are not used at 

this time by the IESO. See section 2.3.6 for specific IP address and port information for 

Certification Authority systems. 

92 In cases where FTP is required by a market participant, TCP Ports 20 & 21 will need to 

be open. 

93 Prior to the Verizon June 2009 data center move, tThe market participant’s firewall 

configuration will needmust to ensure e-mail can be received from the Cybertrust 

Certification Authority's data centre from IP address 212.162.235.5. E-mail for 

production certificate activation codes from this location should not be blocked by e- 

mail gateways or spam filters. E-mail will arrive from domain "CYBERTRUST.NET" 

regarding production certificate activation codes. 

94 After the Verizon June 2009 data center move The market participant’s firewall 

configuration will need to ensure e-mail can be received from the Cybertrust 

Certification Authority's data center(s) from IP addresses 

US – Mail Relays 

64.18.28.50 - Mailhost.us.betrusted.net 

64.18.28.51 - Mailhost.us.betrusted.net 

UK - Mail Relays 

195.217.199.19 (source domain name is @cybertrust.com) 

195.217.199.20 (source domain name is @cybertrust.com) 

95 Firewall changes – The IESO PKI service vendor, Verizon is planning implementing 

for a Cybertrust datacenter movereplacement CA system in early June March 201009 

to handle the transition from the existing CA system on which the CA issuing 

certificate is expiring May 13, 2010. The IESO will apprise all market participants 

appropriately and in a timely manner as discussion with Verizon proceeds on the 

finalized scheduling of the implementation and transition. Firewall rule changes will 

need to be made accordingly by market participants well before Juneas soon as 

possible, starting in March to account for changes to the primary and failovernew IP 

addresses for the associatedand Cybertrust CA domain names for communications 

between API, MPI and CLS workstations and CA systems. Section 2.3.6 details the IP 

address changes. Firewall rules must be implemented prior forto the Verizon IP address 

changes to allow a smooth transition when the data center move is conductedfrom the 

existing CA certificates over to the replacement ones during March and April 2010. 

2.3 Accounts / Identity Credentials 

96 The market rules requires that the IESO implement access control protocols to protect 

the unauthorized disclosure of confidential information transmitted by electronic 




communications. The use of X.509 version 3, medium level assurance, digital 

certificates and User ID account identity credentials allows the IESO to fulfill the 

appropriate market rules governing confidentiality. Additionally, digital certificate 

identity credentials can be used to establish authentication, authorization, integrity and 

non-repudiation while User ID account identity credentials in conjunction with SSL 

protocols can be used to establish authentication, authorization and integrity. 

97 Canadian legislation regarding digital certificates and digital signatures also exists 

within Bill C6 (Personal Information Protection and Electronic Documents Act) that 

may have applicable sections or those that may become applicable in time and is 

available for review and consideration at : 

www.parl.gc.ca/36/2/parlbus/chambus/house/bills/government/C-6/C-6_3/C-6_cover-E.html 

98 The IESO, in conjunction with ABB, Santa Clara, developed the PKI code within its' 

MPI and MIM API based market applications for creating, managing and using X.509 

version 3, digital certificates. The PKI enabled application code used at the IESO, 

underwent multiple formal independent reviews by Entrust prior to market opening to 

ensure it conformed to industry standard PKI coding practices. Any deficiencies found 

were corrected to the satisfaction of Entrust, Scotiabank (the original CA) and the 

IESO. Entrust, a major PKI systems provider worldwide, is the supplier of the Entrust 

Java Toolkit, which was used by the IESO and ABB to develop the PKI enabled 

applications. The Entrust web site is available at: http://www.entrust.com. 

99 The IESO utilizes a commercial PKI package, „TruePass‟ from Entrust to provide PKI 

authentication and management services using X.509 version 3, digital certificates in 

conjunction with its Portal. The IESO Portal is based on commercial products from 

BEAOracle. 

100 User ID account identity credentials used with the IESO Portal are authenticated and 

managed for identity management and Single Sign on by a combination of commercial 

products from Oracle and Microsoft. 

2.3.1 Identity Management and Certification Authority 

101 The current Certification Authority, Cybertrust has been providing CA services since 

February 28, 2004. Prior to that date, the original Certification Authority (CA), e-Scotia 

or Scotiabank (formerly e-Scotia Incorporated), handled all external management 

aspects of the PKI (Public Key Infrastructure) and digital certificates. 

102 The Cybertrust Certification Authority‟s (now owned by Verizon) version of the 

Entrust PKI for use with the IESO MPI and Portal is 7.2. Where a user has both Portal 

and MPI account privileges, the same version 7.2 digital certificate profile is usable 

with both systems. Where some users possess multiple digital certificates for MPI use 

to act on behalf of multiple market participants, only one of those certificates will be 

usable or needed to login to the Portal. IESO Market Entry will work with those users 

under such circumstances to identify which digital certificate shall be used for Portal 

use. 

103 IESO Identity Management Officers (formerly known as LRA (Local Registration 

Authority Officers) (a.k.a. Market Coordinators), handle all internal IESO management 

aspects of the PKI and other Identity Management processes and coordinate their 

efforts with both market participants and the Certification Authority. Access to the 



IESO secure web servers requires the use of digital certificates or User ID account 

identity credentials for authentication and authorization. 

104 Administration activities for digital certificates and User ID account identity credentials 

include: 

Registration 

Identification 

Approval 

Creation and system access privileges assignment 

Identity credential Revocation and removal of system access privileges 

Change of system access privileges 

Certificate Revocation & Re-issue 

Certificate Recovery 

User ID password reset 

Certificate Update 

Certificate Name or USERID Extension Change 

Activation Code Expiration 

105 Individual Subscriber refers to a person at the market participant or agent of such. 

Application Subscriber refers to an application at the market participant or agent of 

such. Either can be referred to as Credential Subscribers. Market Participant 

Registration Officers who request certificates or User ID account identity credentials 

for themselves shall be considered Individual Subscribers when dealing with their own 

certificates or User ID account identity credentials. Each Individual Subscriber, 

Application Subscriber must be identified by one of three identification models (see 

“Identity Management Operations Guide” which is available on the Technical 

Interfaces page of IESO‟s Web site): 

1) IESO Identity Management Officer Model 

2) Market Participant Registration Officer Model 

3) Notary Public Model 

The different models dictate the way different administrative activities are completed. 

In all cases where digital certificates are involved, the IESO will archive the 

“Certificate Subscriber Agreement” (see the Technical Interfaces Page of IESO‟s Web 

site) and for all credentials, all instances of “Certificate Subscriber Request Form” 

(Section 1). From the “Certificate Subscriber Request Form” (Section 1), the IESO can 

identify what action (issue, recover, revoke, revoke & re-issue or name or extension 

change) the market participant would like to take. User ID account password reset is 

handled by direct communication with IESO Customer Relations and does not involve 

the request form. 

The Certification Authority is responsible for issuing X.509 digital certificates, secure 

initialization of the digital certificates and associated key maintenance and updates. The 

Certification Authority is also responsible for maintaining digital certificate history for 

each user over time (for audit and recovery purposes). The IESO Identity Management 

Officer is responsible for issuing and maintaining User ID account identity credentials. 




106 The ABB provided software coding for PKI for the Internet Explorer 6.X and 7.0 

browser and updated MIM IDK the software coding for PKI is based on the 

Entrust/Java Toolkit, 7.2 as supplied by Entrust. The digital certificates provided by the 

Certification Authority are X.509 version 3 certificates. The certificates and software in 

combination provide for: 

Confidentiality – The encrypted transmission of messages and proprietary 

information; 

Access Control – Allowing access to information based on a given set of rules; 

Authentication – The verification of the identity of a person or process sending and 

receiving a message and information; 

Data Integrity – Verification that a message sent is the message received and has 

not been altered in transit etc. from that sent; and 

Non-Repudiation (Digital Signatures) – A sender shall not be able to deny later that 

he sent a message. 

107 The Entrust provided TruePass software for the Portal PKI is a java based package that 

provides: 

Confidentiality – The encrypted transmission of messages and proprietary 

information; 

Access Control – Allowing access to information based on a given set of rules; 

Authentication – The verification of the identity of a person or process sending and 

receiving a message and information; 

Data Integrity – Verification that a message sent is the message received and has 

not been altered in transit etc. from that sent; and 

Non-Repudiation (Digital Signatures) – A sender shall not be able to deny later that 

he sent a message. 

2.3.2 Certificates & Keys 

108 Each certificate will be registered to an individual person or custodian 

(Individual Subscriber, Application Subscriber). 

109 For the Individual Subscriber, two types of certificates will be generated. These include 

a „verification‟ or „signing‟ certificate (associated with the private signing key) and an 

„encryption‟ certificate (associated with the private decryption key). Each type of 

certificate has a private and public key associated with it. Individuals using the MPI 

web browser interface will use these certificates and keys in the two file formats (EPF 

and P12) while the Portal and MPI API use just one format (EPF). The verification and 

encryption certificates are encapsulated within an Entrust Profile File (EPF file 

extension) which is presented by the user along with the user generated password for 

the EPF file when prompted by the MPI applet login or the Portal‟s TruePass applet 

login. The verification certificate and signing key is also encapsulated within a 

PKCS#12 format file (P12 file extension) for the MPI. The P12 certificate content must 

be imported into the browser certificate database for the appropriate browser user 

profile prior to attempting any login to the IESO MPI secure web servers. The 

password chosen by the user at the time of creation of the EPF and P12 files must be 

used to import the P12 file contents into the browser (this is not required for using the 

imported certificates within the browser). 



110 Since it is possible for users to share workstations, it is recommended by the IESO that 

separate browser profiles be created for each user where the workstation is shared and 

that the certificate database within each profile be protected by a password. The 

browser has the capability of password protecting the certificate database it uses for 

each user profile. It is up to the market participant to determine and use a password for 

each user profile certificate database, which is completely independent of the EPF and 

P12 files password. 

111 For the Application Subscriber, two types of certificates will be generated in one file 

format. A verification (associated with the private signing key) certificate and an 

encryption certificate (associated with the private decryption key). Each type of 

certificate has a private and public key associated with it. Applications using the MIM 

API Application will use these types of certificates and keys. The verification and 

encryption certificates are encapsulated within an Entrust Profile File (EPF file 

extension). 

112 The “Certificate Subscriber Agreement”, signed by an Authorized Signatory at the 

market participant, governs the certificate modes of use, accountability and 

responsibility. 

113 The private signing keys within the EPF and P12 files are never backed up by the CA. 

This ensures that only the owner has access to them. Only the individual or application 

subscriber should have access to the private keys assigned to them. Messages and data 

signed will be verified as authentic with a corresponding verification public key 

registered to the Certificate Subscriber. 

114 In order to comply with the ”Certificate Subscriber Agreement”, the IESO recommends 

the market participant store all private keys (in the EPF and P12 files) on secure media. 

The IESO strongly suggests, if and when available, the use of Smartcard technology to 

secure the certificate/private keys EPF and P12 files. Smartcard use will benefit the 

market participant in key management, non-repudiation and portability between 

servers and workstations. The IESO will announce when provision for Smartcards can 

be deployed. Until then, the IESO does not recommend placing private keys in a 

publicly accessible directory on the hard drive of any system. Private keys placed on 

unsecured hard drives are highly vulnerable to password attacks. These private keys 

allow designated individuals‟ access to sensitive, proprietary information, and in some 

cases, allow for submission of bids and offers. Bids and offers are signed with these 

private keys. If private keys are stolen undetected, and this act is not reported to the 

IESO LRA, it is possible to submit counterfeit bids and offers. Successfully stolen 

private keys could also be used by competitors to gain a market advantage by passively 

watching transactions. Market participants are solely responsible for protecting their 

private keys and are required under the provisions of the "Certificate Subscriber 

Agreement" to report immediately to the IESO LRA any suspicious act regarding such 

that may have taken place. 

115 The IESO suggests at a minimum, market participants provide for storage of keys on a 

floppy disk, secured directory on a workstation or network drive or, some other form of 

secure media for operational use (e.g. user controlled USB memory card or equivalent). 

This should be combined with normal backup practices for the most current EPF and 

P12 files to provide for disaster recovery purposes and to ensure reasonable continuity 

of access to the IESO secure web servers. If and where the EPF and P12 files are stored 

on network servers, the IESO recommends that secure individual directories for each 

user be created and used, rather than a single common directory for all certificate files 




used at a market participant. The access to each user's directory must be limited to the 

user/owner of the certificate files stored within each directory and, where required, to 

authorized administrative personnel. The management of certificates is up to the market 

participant within the restrictions of the "Certificate Subscriber Agreement". This does 

not imply that lost or corrupt EPF and P12 files will result in critical loss of service 

since the IESO and its CA can securely enable recovery or re-creation of any 

Certificate Subscriber‟s certificates as per the procedures documented in the "Identity 

Management Operations Guide". However, there is a procedural time component for 

„recovery‟ or re-creation, which may result in longer loss of access time than 

anticipated for the user. 

116 Each current EPF file must be stored in one and only one location to prevent potential 

automatic update conflict problems when used within the MPI or Portal. Multiple 

copies of an EPF file spread over and actively used at several workstations will result 

in problems when automatic update is required and will result in de-activation of the 

certificates until recovery is requested and achieved. 

117 The certificate user (i.e. an individual person, computer application) must have 

read/write access to their certificate EPF and P12 files for access and create/update 

purposes, but no access to another user's certificate files. As discussed, this can be a 

local floppy drive, a secure network directory location or other form of secure 

read/write capable media etc. Read/write access to the files is required only by the 

market participant user (or in the case of certificates used for access to the market 

systems via the MIM API, the application/custodian) who 'owns' them. This read/write 

access does not provide outside parties, such as the IESO or the IESO's Certification 

Authority, access to the market participant's certificates, servers or workstations 

through the MPI, Portal or API except those privileges granted by the user during login 

for downloading the applet etc. All communications between the market participant's 

systems accessing the IESO secure servers is encrypted within a SSL v3 session for 

each user. 

118 Only a small, limited amount of disk space is required for storage of digital certificate 

files. Each EPF file typically takes about 10 to 15KB initially upon creation, while the 

P12 file takes about 4KB in size. Over time, with each updating event, these files will 

grow as they will contain key and certificate update history. A reasonable storage space 

requirement for certificate files in any directory / media location is about 100 KB for a 

single user. Any change to this is easily manageable. 

119 MOSMIM and/or the Portal‟s identity management components will check for data 

integrity, authenticity, and authorization. When bids or offers are uploaded to 

MOSMIM or an application hosted in the Portal, the Individual or Application 

Subscriber digitally signs (via the Internet Explorer browser and MIM MPI Applet, 

TruePass applet or the MIM Programmatic API Application) and submits the bid/offer 

data and the associated unique digital signature of the data to the IESO. Upon receipt of 

the uploaded bid/offer data the MOSMIM Web Server or Portal Truepass component 

takes the data and re-computes the hash of the data. MOSMIM or the Portal hosted 

application then takes the received digital signature created automatically by user with 

their private signing key and the MPI Applet, TruePass applet or MIM API and 

recreates the hash of the data from the signature (a signature is just an encrypted one 

way hash) using the Individual or Application Subscriber‟s public verification key. If 

the two independently derived hashes agree, this ensures the data sent and received is 

identical and was not tampered with in transit. For the MPI and MIM API to ensure the 

signer is the authenticated user, the user is identified from the SSL (Secure Socket 



Layer) session logon established with the certificate presented to the server from the 

browser certificate database. This is inherent in the Portal‟s TruePass component 

functionality. This successfully accomplishes data integrity checking, authenticity and 

authorization of the user. 

120 The ABB provided software helps to make the use of certificates as transparent and 

user friendly as possible. 

121 Entrust supports the following Digital Signature Algorithms: 

RSA 

DSA 

ECDSA 

The current choice for the IESO is RSA. 

122 Entrust supports the following Hashing Algorithms: 

SHA-1 

MD5 

MD2 

RIPEMD-160 

The current choice by the IESO is SHA-1. 

2.3.3 Integration of Digital Certificates with IESO Web Servers 

MIM MPI (Market Participant (Graphical User) Interface) Applet 

(Browser Based Solution) 

123 All market participants must have the ability to use the browser-based solution. 

124 Market participants can download the “Identity Management Operations Guide”, the 

“Market Participant Graphical User Interface User’s Guide” and “Portal User 

Interface User’s Guide” ( see the Technical Interfaces Page of IESO‟s Web site) for 

instructions on browser interface use. 

125 The MIM MPI Applet is automatically downloaded after an individual browses to the 

IESO secure MPI Web site URL and presents their authentic digital certificate from 

the browser certificate database and establishes an SSL session. 

126 To enable access to the IESO MOSMIM Web Server, the IESO and ABB developed a 

Java Applet that uses IESO Digital Certificates and keys. To use the browser interface, 

certificates and keys must also be available within the browser certificate database. 

Browser based keys and certificates are generated by exporting a set of signing keys 

and certificate from the Entrust Profile file (EPF) into a file format the browser can 

understand (for example in the IESO environment, the PKCS#12 file format). Periodic 

certificate and key updates to the EPF and P12 files shall require re-importing of the 

certificates from the P12 file into the browser certificate database. When a market 

participant browses to the IESO MOSMIM Web Server, a SSL (Secure Socket Layer) 

session is started. The market participant uses the IESO digital certificate to 

authenticate to the IESO. The user is then logged in to the IESO Web site based on the 

individual “REGISTRATION profile” (see below for REGISTRATION Profile 




information). Figure 2-19 illustrates the conceptual architecture for the PKI / digital 

certificate solution. 

127 For Internet Explorer browser users, during the SSL handshake, and after the user has 

manually or automatically presented an IESO issued and valid browser based 

certificate, the MOSMIM Web Server identifies itself and requests that certain access 

permissions are granted by the user to enable downloading of the MIM MPI Applet 

and the running of that software. This means that the MOSWEB server requires that 

the user present his or her certificate previously imported into the Internet Explorer 

browser certificate database. The server will verify that the client certificate within 

Internet Explorer is a valid certificate issued by the IESO‟s Certification Authority 

through comparison with the CA certificate installed on the IESO‟s web server. In fact 

this happens to a large extent automatically and the user can only present IESO issued 

client certificates to the MOSWEB server. The client certificate information within the 

Internet Explorer browser presented for logon must also correspond in version, 

validity dates, and content with the EPF file to be used in the next step or logon will 

not be permitted. 

128 After establishment of an SSL session, the MIM MPI Applet is downloaded to user‟s 

workstation and the market participant user is taken to a main Web site where he/she 

is required to enter the name and path of an EPF file and the Passphrase (a string of 

words and characters that one types in to authenticate) for the EPF. The user at EPF 

creation with the IESO CLS application chose this passphrase. This gives the 

individual, rights to the necessary areas of the Web site. The process works like this; 

an End Entity at the market participant presents their digital certificate (encapsulated 

in an EPF) to the Certification Authority system via the MPI applet. The MPI applet 

completes some checks. A critical check is the validity check of the client‟s IESO 

digital certificate. To perform this check the MPI applet PKI code downloaded from 

the MOSMIM Web Server checks a current CRL (Certificate Revocation List) that 

resides on a X.500 directory at the Certification Authority under normal online mode 

operation. If the digital certificate passes the checks, a USERID value is parsed from 

the certificate and is used to allow access to predefined web sites. If the user‟s 

certificates require updating due to reaching the rollover point of the encryption or 

signing keys the EPF and P12 files shall be updated by the MPI applet PKI code and 

the keys and certificates will be renewed automatically upon login. 

129 The IESO may choose to operate the MPI in certificate offline mode if the need arises 

due to service outages at the Certificate Authority. The probability of this occurring is 

likely to be minimal and of short duration. The IESO maintains total control over the 

mode of operation, online or offline. Under such circumstance the Market Participant 

users will still be able to login to the Market systems and conduct business. No 

configuration changes are required on the part of Market Participants for the mode of 

MPI operation and it will be completely transparent. Under such circumstances the 

IESO issued certificates will not undergo CRL checks during login but will go through 

all other backend security checks as they do now. This does not impact the technical 

requirements for normal communications to the CA systems. 

130 The layout of the USERID is the REGISTRATION User Login Name, concatenated 

with an @ symbol, and finished with the REGISTRATION market participant 

Constant Shortname. See the Technical Interfaces Page of IESO‟s Web site for details 

on how the REGISTRATION User Login Name and REGISTRATION market 

participant Constant Shortname are created. Below is an example of the syntax of the 

UserID: 



REGISTRATION_User_Login_Name@REGISTRATION_MP_Shortname 

The required “REGISTRATION Profile” (Registration Profile) is accessed via the 

UserID. The UserID is stored in a non-critical extension in the digital certificate. In 

this instance the extension is an optional (“non-critical”) information storage place in 

the digital certificate. An important aspect of an extension is an OID (Object 

Identifier). The OID uniquely identifies the USERID (known as an “attribute type”). 

The OID for this IESO specific “attribute type” for the Cybertrust issued digital 

certificates is 1.3.6.1.4.1.6334.2.1.2.5.x. 

131 When an End Entity at the market participant authenticates, the USERID is parsed 

from the correct certificate and is used to fetch the “REGISTRATION Profile” from the 

MIM Netscape Directory Server. The “REGISTRATION Profile” is the access 

permissions given to the UserID by a specified, responsible individual at the market 

participant. For more information on the use of the REGISTRATION system please 

see the Technical Interfaces Page of IESO‟s Web site. 

132 See the Certificate Lifecycle System (below) for details on how keys and digital 

certificates are generated. 

133 The users, as noted previously, must have read/write access to their own digital 

certificate files (EPF and P12), wherever they are stored at the time of login to the 

MPI. Individual subscriber (person) certificates contained in the EPF and P12 files, 

when used on a consistent basis for login to the MPI applet via the Internet Explorer 

browser will be automatically updated by the MPI PKI code when required.. The 

update schedule for encryption and signing keys is currently every 12 months based 

on date of creation for each user. The triggering point for update is about 110 days 

before expiry. If the automatic update is successful, a dialogue window in the MPI 

will inform the user. The use of the Certificate Lifecycle System (CLS) is not 

required for update of certificates for users logging onto the MPI on a regular basis. If 

read/write access to the EPF and P12 files is not enabled, certificate updates, when 

triggered, will not complete successfully and access to the IESO secure systems by the 

user will be lost until certificate key recovery can be processed between the market 

participant and IESO LRA. The CLS is still required for initial certificate creation, 

P12 file export and recovery purposes. The CLS can be used for manual certificate 

update if it is known by the user that their certificate has passed its update trigger point 

and login to the MPI has not been done recently, is not required for some time, or will 

not occur until after certificate expiry. 

134 Bids and offers may be submitted via the browser in two ways: Template and HTML 

Form. When the bid or offer is submitted in the browser, the bid or offer data is signed 

with the private signing key from the EPF file of the individual that has been 

authenticated during the SSL session and a unique digital signature of the data is 

created in the process and stored with the unique transaction ID on the IESO systems. 

The transaction ID binds the submitted bids and offers to the signature as it is also 

embedded within the signature as well as the MIM database. 

135 The browser is also used to verify the digital signatures of Templates and HTML 

Forms. 

136 The MIM MPI Applet requires communications access 'via' the following ports to the 

PKI servers: 389 (LDAP protocol), 443 (SSL protocol) and 829 (PKIX-CMP protocol). 

Market participants with firewalls must have these ports open appropriately for 

communication with the IESO and its CA. Port 829 for communications with the 




appropriate CA Manager is extremely critical for certificate updates as secure PKI 

communications for certificate management is processed via this port. 

Portal TruePass Applet 

(Browser Based Solution) 

137 Market participants can download the “Identity Management Operations Guide” and 

the “Portal User Interface User‟s Guide” (see the Technical Interfaces Page of IESO) 

for instructions on browser interface use. 

138 The small TruePass Applet is automatically downloaded after an individual browses to 

the IESO Portal Web site URL, chooses to login with a digital certificate (instead of a 

User ID / Password) and presents their authentic digital certificate EPF file to login to 

the Portal. 

139 To enable digital certificate access to the IESO Portal, the IESO employs the Entrust 

TruePass Java Applet that uses IESO Digital Certificates and keys held in the EPF file. 

Periodic certificate and key updates to the EPF is handled by the TruePass product. 

When a market participant browses to the IESO Portal and chooses to login, a SSL 

(Secure Socket Layer) session is started. The market participant can then choose to 

login with a digital certificate instead of the standard User ID / password and uses the 

IESO digital certificate to authenticate to the IESO Portal. The user is then logged in to 

the IESO Portal based on the individual‟s access profile and authorization level”. 

140 After establishment of an SSL session when the user chooses to login with a digital 

certificate the TruePass Applet is automatically downloaded to user‟s workstation and 

the market participant user is taken to a web page where he/she is required to enter the 

name and path of an EPF file and the password for the EPF. The user at EPF creation 

with the Entrust Authority Administration tool chose this password. Once authenticated 

this gives the individual, rights to the authorized areas of the Portal web site. A critical 

check is the validity check of the client‟s IESO digital certificate. To perform this check 

the TruePass applet PKI code downloaded from the IESO Portal server checks a current 

CRL (Certificate Revocation List) that resides on a X.500 directory at the Certification 

Authority. If the digital certificate passes the checks, the user is logged in to the Portal 

with their authentication passed through to the Portal Identity Management system and 

Portal. If the user‟s certificates require updating due to reaching the rollover point of 

the encryption or signing keys the EPF file shall be updated by the TruePass applet and 

the keys and certificates will be renewed automatically upon login. 

141 The users, as noted previously, must have read/write access to their own digital 

certificate EPF file, wherever they are stored at the time of login to the Portal. 

Individual subscriber (person) certificates contained in the EPF file, when used on a 

consistent basis for login to the Portal via browser will be automatically updated by the 

TruePpass PKI code when required. The update schedule for encryption and signing 

keys is currently every 12 months based on date of creation for each user. The 

triggering point for update is about 110 days before expiry. If the automatic update is 

successful, a TruePass dialogue window / page will inform the user. If read/write 

access to the EPF file is not enabled, certificate updates, when triggered, will not 

complete successfully and access to the IESO Portal by the user will be lost until 

certificate key recovery can be processed between the market participant and IESO 

Identity Management Officer. The web based Entrust Authority Administration tool is 

still required for initial certificate creation and recovery purposes for digital certificates 

used with the IESO Portal. 



142 The Portal TruePpass applet only requires communications access 'via' port 443 (SSL 

protocol) to the IESO Portal server. Except for communications to the CA‟s web based 

Entrust Authority Administration tool, the IESO server based TruePass components 

proxy all communications between the Certification Authority systems and the market 

participant workstation. 

143 The IESO Portal User Interface User’s Guide should be referenced for Portal login 

procedures. 

MIM Programmatic API Application (Application Based Solution) 

144 Market participants can choose to use the application based MIM programmatic API 

solution. 

145 The MIM API Application can be downloaded from the IESO Web site as a part of the 

IDK (IESO Development Kit) (see the Technical Interfaces Page of IESO‟s Web site). 

146 An alternative route for accessing the MOSMIM Web Server is via the MIM 

programmatic API with a Market Participant custom application. This MIM 

programmatic API uses the same underlying code set as the MIM MPI Applet. There 

are two differences between the MIM programmatic API and the MIM MPI Applet. 

First, the MIM programmatic API does not need a browser-based certificate. This 

means no exporting and importing of the PKCS#12 browser based file format is 

required. (See MIM MPI Applet above for references to exporting and importing). 

Secondly, only Template based bids and offers may be submitted using the MIM 

programmatic API. HTML Form data cannot be submitted using the MIM 

programmatic API Application because HTML Form data is browser based and the 

MIM programmatic API Application is not using a browser. 

147 See MIM MPI Applet section for SSL Handshake details. 

148 See MIM MPI Applet section for UserID details. 

149 See MIM MPI Applet section for REGISTRATION Profile details. 

150 See MIM MPI Applet section for key generation reference. 

151 See MIM MPI Applet section for key storage recommendations. 

152 To enable access to the MOSMIM Web Server, the IESO & ABB developed a Java 

MIM programmatic API Application that uses IESO Digital Certificates. When a 

market participant uses the MIM programmatic API Application to access the IESO 

Web Server MOSMIM, a SSL (Secure Socket Layer) is session is started. The market 

participant uses an IESO digital certificate to authenticate to the IESO. The End Entity 

is able to automatically navigate the IESO site based on the End Entity‟s 

“REGISTRATION Profile.” Figure 2-21 illustrates the conceptual architecture for the 

PKI / digital certificate solution. 

153 Bids and offers may be submitted using the MIM programmatic API Application in 

Template form only. The bid or offer is signed with the private signing key of the End 

Entity that has been authenticated during the SSL session. 

154 See MIM MPI Applet for signature verification. 

155 The MIM programmatic API Application requires access to the following ports: 389 

(LDAP), 443 (SSL) and 829 (Entrust based CA). Market participants with firewalls 




must have these ports open for communication with the IESO and its CA. Port 829 for 

the appropriate CA Manager is extremely critical for certificate updates as secure PKI 

communications for certificate management is processed via this port. The “IESO 

Developer's Toolkit (IDK), Implementation Manual” should also be referenced for 

information on defining communications with the CA Manager. 

156 The IESO shall choose to control the mode that the API utilizes a certificate, as of 

September 2004 for enabling web access continuity. If and when the need arises due to 

service outages at the Certificate Authority, the IESO is able to set certificate use to 

offline mode. The probability of this occurring is likely to be minimal and of short 

duration. The IESO shall maintain total control over the mode of operation, online or 

offline. Under such circumstance the Market Participant users will still be able to login 

to the Market systems with the API and conduct business. In general this is centrally 

controlled by the IESO so that no configuration changes are required on the part of 

Market Participants for the mode of API operation and it shall be transparent. Under 

such circumstances the IESO issued certificates do not undergo CRL checks during 

login but will go through all other backend security checks as they do now. This does 

not impact the technical requirements for normal communications to the CA systems. 

157 „Application‟ (i.e. used by a computer application) certificates contained in the EPF 

file, when used only for login with the programmatic MIM API, can be updated 

automatically by the API. This will only occur if the appropriate CA Manager IP 

address and port is specified by the market participant as described in the “IESO 

Developer's Toolkit (IDK), Implementation Manual”. The custodian of the certificates 

must manually update the certificates using the CLS, if the CA Manager IP address 

information is not specified. The management of such is up to the market participant. 



IESO Conceptual Architecture 

for Secure Web Server 

Connectivity 

Client Custom 

Software 

EPF File 

Market Participant 

Users 

MIM programmatic API Application uses 

an EPF to authenticate and authorize End 

Entities to the site as well as sign bids 

and offers. 

Cybertrust CA 

Certification 

Authority 

Certificate 

Database 

CA 

X. 500 

Directory 

Server 

MIM 

Programmatic 

API 

MIM MPI 

Applet 

Internet 

Browser 

Certificate 

Client 

Browser 

MIM MPI Applet uses a 

browser certificate to authenticate and 

uses an EPF based certificate to authorize 

and sign bids and offers. 

SSL (Secure Socket Layer) 

Server and Client communications 

to Certification Authority and to 

the IESO. 

Firewall 

DMZ 

Thawte Web 

Server 

Certificate 

CA Parent 

Certificate 

MOSMIM MPI 

Web Server 

PLC 

Web Server 

Thawte Web 

Server 

Certificate 

Secure redirection and 

secure establishment of 

new SSL session 

Firewall 

Internal 

PLC User Profile is in 

this directory 

MIM Server 

(& Netscape 

Directory Server) 

Figure 2-21: MPI and MIM API Conceptual Architecture 

2.3.4 Portal SSO and Identity Management System 

158 In addition to Entrust digital certificates, Portal users can login with a User ID account 

credential where transactional read/write access privileges are not required. Any user 

who needs access for read–only purposes to confidential information can apply, register 

for and utilize a User ID account identity credential with the Portal. 

159 The Portal is protected by Oracle and Microsoft technologies. These components 

provide for single-sign-on, authentication, authorization and in conjunction with SSL 

protocols confidentiality and integrity of communications. 

160 All Portal identity management components for User ID account credentials are server 

based and only a web browser is required by the market participant, as specified in this 

document, to access the Portal with this type of identity credential. 

161 The IESO Portal User Interface User’s Guide should be referenced for Portal login 

procedures. 

2.3.5 Certificate Lifecycle System & Entrust Authority 

Administration Tool 

162 The Certificate Lifecycle System can be downloaded from the IESO Web site (see the 

Technical Interfaces Page of IESO‟s Web site). 




163 The Entrust Profile File (EPF) and P12 File for use with the MPI or MIM API (but not 

the Portal) are initially created by the end user using the Certificate Lifecycle System 

(CLS). The CLS is a Java software application supplied by ABB. The code used in the 

MIM MPI Applet and MIM programmatic API Application is the same underlying 

code set used in the CLS. The CLS lets the End Entity (i.e. user) interface with the 

Certification Authority for initialization, recovery, viewing and testing of EPF‟s. The 

CLS is a platform independent application, meaning it may be run on any operating 

system that supports a Java 2 Runtime Environment. 

164 To initialize or recover an EPF and P12 using the CLS, the end Entity needs Activation 

Codes. The Activation Codes consist of a Reference Number and an Authorization 

Code, which are good for a one-time use and for a limited time of 14 days. The 

Reference Number is e-mailed directly to the End Entity by the Certification Authority 

after the End Entity has been registered or recovered (see the Technical Interfaces Page 

of IESO‟s Web site for digital certificate registration information). The Authorization 

Code is sent from a designated officer at the IESO (i.e. a Local Registration Authority 

Officer (LRA Officer) (a.k.a. Market Coordinator) to the End Entity via a secure 

channel (ex: in person or via secure courier). 

165 The process of initialization employs the CLS in conjunction with the Activation 

Codes. New keys and certificates are created through secure Internet communications 

with the PKI infrastructure and stored in the chosen, secured media at the market 

participant. The keys are secured by entering a Passphrase meeting the required 

content rules within the CLS. The Passphrase is determined and set by the Individual 

Subscriber or Application Subscriber Custodian and only they and other formally 

authorized individuals at the market participant as applicable should know it. Please 

reference the Certificate Subscriber Agreement regarding market participant 

obligations regarding this. 

166 Recovery uses the CLS in conjunction with the Activation Codes. The Recovery 

function of the CLS application allows certificates and Encryption/Decryption keys to 

be recovered and stored with new Signing/Verification keys and certificate on the 

chosen, secured media at the market participant. The keys are secured by entering a 

Passphrase meeting the required content rules within the CLS. The original Passphrase 

can be changed at the time of recovery. 

167 The CLS requires access to be provided by the MP „to‟ the following ports at the 

Certification Authority: 389 (for the CA Directory Server LDAP calls), and 829 (for 

Entrust CA Manager functions). Market participants with firewalls must have these 

ports open for the specific Certification Authority IP addresses for communication with 

the IESO and its CA. The domain names, IP addressees for all test and production PKI 

systems are included in section 2.3.6 below. 

Installing & Operating the Certificate Lifecycle System 

168 An “Identity Management Operations Guide” has been provided on the IESO Web site 

(see the Technical Interfaces Page of IESO‟s Web site). This guide describes 

recommended procedures for an on-site System Administrator or End Entity to perform 

initial installation and operation of the CLS. 

Operating the Entrust Authority Administration Tool 

169 The “Identity Management Operations Guide” guide describes recommended 

procedures for an on-site System Administrator or End Entity to access and use the 



Certification Authority‟s web based “Entrust Authority Administration” tool which 

must be used for creating or recovering digital certificate EPF files used with the IESO 

Portal. 

2.3.6 Requirements for Browser and Digital Certificate Software 

Compatibility 

Workstation Platform for MPI Browser Client 

170 The browser clients recommended by the IESO for the MPI are Internet Explorer 6.0 

SP2, and Internet Explorer 7.0 on Windows XP-SP2 and Internet Explorer 7.0 on Vista. 

Workstation Platform for Portal Browser Client 

171 The browser client recommended by the IESO portal vendor (BEA) and supported by 

the IESO is as shown on the “IESO Supported Client Platform” web page. 

Recommended by the Portal vendor but not supported by the IESO is: : 

Internet Access 

Netscape 7.1, or 7.2, or 

Mozilla Firefox 1.0, 1.5 or 2.0.1 

Safari 2.0 

Any of these will work. The “IESO Supported Client Platform” web page shows the 

recommended OS/Browser /JRE combination for the Portal‟s “Entrust TruePass” 

component. Not supported but compatible are: 

Netscape Navigator 7.0 in combination with the Sun JVM 1.4.2 

Mozilla FireFox 1.0 in combination with Sun JVM 1.4.2 

172 Internet access is required for all market participants even those using the Private or 

Shared Network as described earlier in this document. For basic functionality and full 

utilization of the key management functionality of the Entrust PKI products, 

communication between the client (CLS, MIM MPI Applet, or MIM programmatic 

API Application) and the CA is necessary. The CLS, MIM MPI Applet and MIM 

programmatic API Application use calls to the CA Server and LDAP Servers that allow 

access to the MOSMIM Web Server and/or allow for digital signing of bids and offers. 

Certification Authority IP Addresses and Domain Names 

173 The Certification Authority system IP Addresses applicable are as follows: 

MPI/MIM Sandbox / Production Environments Prior to June May 13, 201009 Verizon 

Datacenter MoveIssuing CA Expiry 

Cybertrust Production System CA Manager - version 7.2 

Primary IP Address = 195.217.198.65 TCP ports 829 

Failover IP Address = 64.18.29.140 TCP ports 829 

Primary IP Address = 64.18.21.69 port 829 




Failover IP Address = 64.18.29.140 port 829 

Domain name = ccica1.idm.cybertrust.com 

Cybertrust Production System Directory Server - version 7.2 

Primary IP Address = 195.217.199.14 TCP ports 389 


Primary IP Address = 64.18.22.34 port 389 

Failover IP Address = 64.18.29.142 port 389 

Domain name = ccipdir.idm.cybertrust.com 

Production Root Certification Authority CRL Locations - version 7.2 

Globalsign Root Certificate CRL site URL : http://64.18.25.38/ port 80 

Domain name equivalent : http://crl.globalsign.net/ port 80 

The CRLs root.crl (http://64.18.25.38/root.crl and http://64.18.25.38/root_cat.crl 

at this location needs to be available to MPI and MIM IDK workstations through the 

firewall. 

MPI /MIM Production Environment After June 2009 For Replacement Verizon 

Datacenter MoveCA Servers – Starting early March 2010 

Cybertrust Production System CA Manager - version 7.2 

Primary IP Address = 195.217.198.67 195.217.198.65 TCP ports 829 


Domain name = ccica21.idm.cybertrust.com (no change) 

Cybertrust Production System Directory Server - version 7.2 

Primary IP Address = 195.217.199.26 195.217.199.14 TCP ports 389 


Domain name = ccipdir2.idm.cybertrust.com (no change) 

Production Root Certification Authority CRL Locations - version 7.2 

Globalsign Omniroot Root Certificate CRL site URL : http:// 64.18.30.7/ 64.18.25.38/ 

port 80 (no change) and http:// http:// 64.18.30.8/ port 80 

Domain name equivalent : http:// www.public-trust.com crl.globalsign.net/ port 80 

(no change) 

The CRLs - http://cdp1.public-trust.com/cgi-bin/CRL/202501/cdp.crl root.crl 

(http://64.18.25.38/root.crl and http://64.18.25.38/root_cat.crl 

at this location needs to be available to MPI and MIM IDK workstations through the 

firewall. 

Portal Sandbox/ Production Environments Prior to May 13, 2010 Verizon Issuing CA 

Expiry 

Cybertrust Production System CA Manager Domain - version 7.2 

Domain name = ccip.idm.cybertrust.com 



Access is transparently handled via https through IESO portal servers as all certificate 

management communication (except for creation and recovery) is proxied through the 

IESO to Verizon / Cybertrust. The IESO administers all IP address configuration for the 

Certification Authority systems used with the Portal. Therefore no changes are required 

on the part of the Market Participant for portal PKI capability to handle the Verizon 

Cybertrust data center move. Only the IESO needs to make the required changes on its 

servers. 

Portal Sandbox/ Production Environments for Replacement Verizon CA Servers – 

Starting early March 2010 

Cybertrust Production System CA Manager Domain - version 7.2 

Domain name = ccica2.idm.cybertrust.com 

Access is transparently handled via https through IESO portal servers as all certificate 

management communication (except for creation and recovery) is proxied through the 

IESO to Verizon / Cybertrust. The IESO administers all IP address configuration for the 

Certification Authority systems used with the Portal. Therefore no changes are required 

on the part of the Market Participant for portal PKI capability to handle the Verizon 

Cybertrust data center move. Only the IESO needs to make the required changes on its 

servers. 

Ports 

174 Port 443 must be open to allow access over SSL (Secure Socket Layer). Market 

participants with firewalls must have this port open for communication with the IESO 

systems and its Certification Authority. 

175 Port 389 must be open to allow access to the IESO's Certification Authority's LDAP 

Servers (Directory Server Domain) for the MPI. For the IESO Portal‟s TruePass 

component all CA directory communications are routed through the IESO systems via 

port 443 (https/SSL). LDAP Servers contain the following and more: 

Certificate Revocation Lists (CRL‟s) 

The CA's credentials 

The policy certificates 

The attribute certificates (if applicable) 

User Certificates 

Market participants with firewalls must have this port open for communication with the IESO 

Certification Authority. 

176 Port 829 must be open to allow access to the identified Certification Authority Manager 

(CA Manager Domain) systems. Market participants with firewalls must have this port 

open for the specific IP addresses/domains for communication with the IESO CA for 

the Certificate Management Protocol. This provides for automatic or manual updating 

of certificate files upon imminent expiry of certificate keys. Automatic certificate 

updates will be processed by the MPI (Market Participant Graphical User Interface) or 

MIM API and manual updates can be accomplished with the CLS. For the IESO 

Portal‟s TruePass component all CA management communications are routed through 




the IESO systems via port 443 (https/SSL). See Figure 2-22 Portal Conceptual 

Architecture 

177 Ports 20 & 21 should be open for market participants using FTP. 



Conceptual Architecture for 

Secure Portal Web Server Communications 

Cybertrust Entrust Authority version 7.2 

CA Directory 

Entrust 

Security 

Manager 

Entrust 

Authority 

Adminstratiion 

tool 

HTTP/HTTPS 

Port 443 

Web browser 

Entrust Truepass 

applet 

Client workstation 

User ID/ 

password 

EPF File 

PKIX CMP 

LDAP Port 829 

Port 389 

HTTP/HTTPS 

Port 443 

Internet 

LDAP 

Port 389 

PKIX CMP 

Port 829 

HTTP/HTTPS 

Port 443 

Firewall 

Truepass 

Session 

Validation 

Module 

IESO Portal Web Server 

Web 

Server 

COREid 

Webgate 

Web server 

COREid 

Webgate 

IESO DMZ – 

Zone 2 

Session 

Authentication 

COREid 

WebPass 

Thawte 

Server 

Certificate 

Firewall 

IESO DMZ – 

Zone 3 

Application 

Server 

Application 

Server 

Entrust 

Truepass 

Servlets 

Plumtree 

Portal 

Server 

IESO Portal Server 

MS IIS 6.0 

COREid 

Webgate 

COREid 

Access 

Server 

COREid 

Identity 

Server 

Secure 

LDAP 

Microsoft 

Active Directory 

IESO AD Server 

IESO Application Web 

Server 

COREid 

WebPass 

COREid 

Access 

Manager 

LDAP 

Microsoft 

ADAM 

IESO IDM Server 

IESO AD Server 

Firewall 

IESO Internal 

Zones 

Application 

IESO Application 

Backend Server 

Database 

IESO SQL Server Database Server 

Figure 2-22: IESO Portal Conceptual Architecture 




Other Documentation 

178 The relevant IESO/ABB, Market Participant Interface, IESO Portal and MIM 

programmatic API manuals should be referred to when appropriate. 



3.Dispatch Information 

IMO_MAN_0024 

3. Dispatch Information 

179 (For supporting rule references, please refer to “Appendix 2.2, Sections 1.1 & 

1.3 of the market rules” ) 

3.1 Dispatch Workstations 

180 This section provides description of the dispatch workstations required by 

market participants injecting into or withdrawing electrical power from the 

IESO-controlled grid or will receive and transmit information to the IESO. 

3.1.1 Hardware Requirements 

Platform 

181 The client software provided by the IESO is designed to be platform independent. The 

IESO has performed extensive testing of this software on the Windows XP and Vista 

operating systems. The software will also function on other versions of the Windows 

Operating System (i.e. Windows 98 or higher) but these are no longer formally 

supported by the IESO. Displays may be rendered incorrectly if a Windows Operating 

System is not used. 

182 For Windows XP, it is recommended that the client workstation hardware conform to 

Microsoft‟s specifications found at: 

http://www.microsoft.com/windowsxp/pro/evaluation/sysreqs.mspx 

and for Windows Vista at 

http://www.microsoft.com/windows/products/windowsvista/editions/systemrequiremen 

ts.mspx. 

For Windows 98 or NT, the following provides the minimum hardware requirements: 

Processor 

183 The minimum required processor speed is 300 MHz PII or equivalent, 

however 500MHz, PIII or equivalent is recommended. 

Memory 

184 The PC must have a minimum of 256 megabytes of internal RAM. For 

better performance however, 512 megabytes RAM is recommended. 

Hard Disk 

185 The PC must have at least four gigabytes of available disk space. 

Interface Cards 

186 The network card must support a high-speed (10 Mbps or greater) 

network, as it will be required to communicate over Ethernet to an 

IESO supplied router at the market participant site. The wiring 

between the dispatch workstation and the router is the responsibility of 




Monitor and Graphic Card 

Sound Card 

the market participant. The IESO supplied router will communicate 

over private network (frame relay) to the IESO. 

187 The supported monitor must be SVGA with a graphic card that is 

configurable to 1024 x 768 pixels with „small font‟ and 65536 colors 

at a minimum. A higher resolution of 1280 x 1024 pixels is however, 

recommended. 

188 The PC must include an appropriate sound card and speakers for 

receiving audible alarms. 

Printer 

189 The recommended printer is high resolution with at least 600 dpi and 

supports multiple fonts. 

Other Components 

3.1.2 Software Requirements 

Operating System 

Internet Browser 

Connectivity 

Power Supply 

190 Additional components that should be included with your PC are a 

compatible two-button mouse, keyboard, and 1.44 MB high-density 

floppy disk drive. 

191 The PC should be operating with Windows XP or Vista however it will run on 

Windows 98 / NT 4.0 with support for TCP/IP protocol. It is recommended that 

the latest operating system patches be maintained. 

192 For WEB based message exchange the PC should include the IE6 SP2 or IE 7 

browser. For older versions of Windows the minimum browser version is IE 

5.5. 

193 All dispatch workstations must maintain a live connection that will allow 

workstations to receive, send, and acknowledge the messages with the 

minimum throughput established by the IESO. 

194 Given its importance, it is strongly recommended that the market participant(s) 

provide an Uninterruptible Power Supply (UPS) to power the dispatch 

workstation. 



IMO_MAN_0024 

3.2 Dispatch Message Exchange 

3.2.1 Overview 

195 Market participants using a dispatch workstation will be integrating directly 

with the EMS systems at the IESO and will require interaction with the 

Message Exchange system. Market participants that require this module will be 

receiving the client software from the IESO via the network and will be 

instructed on its installation and application. 

196 Message Exchange information will be stored in the IESO Operations Database 

(ODB), for use by the Compliance Monitor. This verifies that the requested 

dispatch actually takes place based on the measurement availability. 

197 The market participant will: 

acknowledge receipt of the message; 

accept or refuse the dispatch request; and 

perform the requested control action. 

198 The Message Exchange function is used by the IESO to send dispatch 

instructions to the market participants. This function is triggered by the 

dispatch request of an application (such as energy dispatch) to issue a message 

either automatically by Inter-Control Center Communications Protocol (ICCP) 

or by WEB-based Message Exchange or manually (off-line by telephone or fax) 

by the Exchange Coordinator to a market participant. 

199 The Message Exchange function sends dispatch instruction to the IESO market 

participants using ABB‟s ICCP Block 4 capabilities or the WEB-based 

Message Exchange facilities. 

200 In order to interface with the Message Exchange using ICCP the market 

participants must also have ICCP Block 4 configured on their dispatch 

workstations and have specialized software to interpret and manage the ICCP 

block 4 messages. 

201 WEB-based Message Exchange is an alternative facility made available to the 

IESO market participants that can be use to support the Message Exchange 

requirements. The WEB-based Message Exchange adds additional capability to 

the existing Message Exchange functionality. WEB-Based Message Exchange 

permits dispatch instructions to be sent to the market participants using 

browser compatible user interface and application programming interface. 

These interfaces will be included with the delivery of this product. WEB-Based 

Message Exchange will be simpler to deploy than the ICCP-based Message 

Exchange and more cost effective for the market participants, however this 

may be a less reliable approach. 




202 Interfaces (see figure below) shows the relationship that Message Exchange 

(ME) has with other parts of the system. Most of the functions are internal to 

IESO however on the right of the diagram is the interface with the market 

participants. 

Resource 

Dispatch 

Operator ME 

Overview 

P 

A 

Interchange 

Scheduler 

Message 

Exchange 

ICCP 

Interface 

R 

T 

I 

C 

Application X 

Compliance 

Monitor 

WEB interface 

I 

P 

A 

N 

T 

Figure 3-1: Message Exchange Interfaces 

203 Specifics of ICCP Block 4 are discussed in the ICCP guidelines, which can be 

ordered from EPRI – Report TR-107176 over the Internet. 

204 A WEB-Based Message Exchange user guide has been posted on the IESO 

Web site. The user guide provides information on message displays, user 

actions and contract management message displays, etc. Market participants 

are encouraged to consult the Web site for further details and latest updates to 

the user guide. 

3.2.2 Functional Parts 

205 Message Exchange (ME) consists of several independent functional parts: 

a. An ICCP Server responsible for establishing and maintaining the communication between 

utilities using the ICCP protocol and maintains the communication parameters and status 

for each link. 

b. A Web Server (Servlet or Application Server) responsible for establishing and maintaining 

communication between market participants using the https protocol and managing user 

logins, client requests, publishing client response to SCADA (Supervisory Control and Data 

Acquisition), subscribing to & performing action requests from SCADA and publishing 

results of action requests to SCADA. 



IMO_MAN_0024 

c. A Web Client providing user interface for the WEB-Based Message Exchange java applet. 

The software as shown on the “IESO Supported Client Platform” web page is required in 

order to execute the Message Exchange Applet. 

d. The ME Database Server is responsible for storing and retrieving the messages and their 

status. This database will support both WEB & ICCP. 

e. The ME Application Server will co-ordinate the message exchange between different 

functions. It is responsible for message scheduling and tracking (both WEB and ICCP). 

3.2.3 Dispatch Messaging 

206 The dispatch messages are generated automatically by the dispatch algorithm 

every five minutes. The Exchange Coordinator (EC) monitors the dispatches 

and the EC can prevent the messages from being sent out in the event of a 

system disturbance while activating operating reserve. 

207 The availability and reliability of the supporting facilities must be such that the 

following criteria is met: 

a. The Exchange Coordinator (IESO BES Control Room Operator), in not more than sixty 

seconds after issuance of the dispatch message, must receive the acknowledgement and 

compliance indication after issuance of the dispatch instruction. 

b. The acknowledgement of receipt of a dispatch message is automatically performed by the 

Client application (either IESO provided or market participant). The compliance is a 

manual action by the market participant to accept or reject the instruction. 

c. The IESO shall manage and/or control the ICCP and Web-Based communications facilities 

that support the transmission of dispatch instructions to the market participants’ dispatch 

agent at the point of system injection. 

d. Failure of any of the facilities such that the dispatch message and/or the reply are not 

sent/received is alarmed through monitoring software to the Exchange Coordinator upon 

detection. The alarm is displayed within the message dispatch tool and it will be logged in 

the systems control log. The alarm indicates the actual, or most likely, reason for the failure. 

e. An outage to any of the supporting message dispatch facilities must be addressed with the 

highest priority. 

Dispatches Processed Through Message Exchange 

Energy Dispatch 

208 The IESO issues dispatch instructions for each registered facility, other than a 

boundary entity and an hour-ahead dispatchable load facility, prior to each 

dispatch interval, indicating for that dispatch interval: 

• The target energy level to be achieved (in MW) by the facility at the end of the dispatch interval 

at a rate, in the case of a dispatchable load, equal to the rate provided by the market participant 

as dispatch data, and in the case of a generation facility equal to the most limiting of: 

• The last dispatch instruction and offered ramp rate: or 

• Actual MW output and the generations facility’s effective ramp rate 

Reserve Dispatch 




Reserve Activation 

209 The IESO will process reserve dispatches through the Message Exchange. 

Reserve dispatches are targets for capacity, in the reserve class specified that 

are available from a market participant‟s resource after acceptance of the 

dispatch instruction. 

210 The IESO will process reserve activation dispatches through the Message 

Exchange. Energy dispatches are target energy output or load reduction from a 

market participant‟s resource. The market participant‟s resource is expected to 

follow the emergency ramp rate specified during registration of the resource 

and be at the target within the timeframe specified by the operating reserve 

market for which the dispatchable generation/load facility was scheduled. 

Automatic Generation Regulation Activation 

211 The IESO will specify AGC obligations of a resource through the Message 

Exchange. The AGC obligations include the Regulation Range and may 

include a specified Base Point that the market participant‟s resource is required 

to support for a specified period of time. 

Voltage Regulation Dispatch 

Invoking the Call Option 

212 IESO will be installing the capability to specify voltage regulation dispatches 

for Load and Generator market participants through the Message Exchange. 

Currently the IESO continues to manage the voltage regulation dispatches 

manually. Voltage regulation dispatches can be specified in terms of terminal 

voltage set point or MVAR output. Voltage regulation dispatches are targets 

for terminal voltage and MVAR output for a market participant‟s resource that 

should be reached within 5 minutes of acceptance of the dispatch instruction. 

213 IESO will be installing the capability to inform market participants that they 

are required for Must Run or Voltage Support through the Message Exchange. 

Currently the IESO continues to inform market participants, manually, that 

they are required for Must Run or Voltage Support. The Call dispatch will 

identify the dispatch period that the market participant‟s resource is required 

for. The market participant is expected to bid/offer into the market as define in 

the “Market Rules”, for the specified dispatch period. 

3.2.4 Dispatch Message Structure 

General Structure of All Dispatch Messages 

214 Dispatch messages are composed of a message header and a message b3.2ody. 

The content of messages is not „case sensitive‟. 

215 The message header identifies the message and is a common format for all 

messages. 

216 The HEARTOUT, HEARTIN, ACCEPT, REJECT, RECEIPT, 

CONFIRMATIONOK, AND CONFIRMATIONNOTOK only include the 

header information. 



IMO_MAN_0024 

217 AGC dispatch messages may be sent in one of two forms: 

(1) Dispatch Message Body – Regulation with Range Dispatch Only: will include 

the following fields: 

Persistent Resource 

DISPATCH_TYPE = „RGR‟ 

Startstop = „Start‟ 

RESOURCE_ID 

REGULATION_RANGE = The regulation range in MW expected 

from the resource. 

DELIVERY_START_TIME 

DELIVERY_STOP_TIME 

(2) Dispatch Message Body – Regulation with Range and Fixed Base-Point 

Dispatch: will include the following fields: 

Persistent Resource 

DISPATCH_TYPE = „RGS‟ 

Startstop = „Start‟ 

RESOURCE_ID 

AMOUNT = The fixed base point in MW that the unit will operate at 

while on AGC. 

REGULATION_RANGE = The regulation range in MW expected 

from the resource. 

DELIVERY_START_TIME 

DELIVERY_STOP_TIME 

218 For details of the Dispatch Message Structures and sample examples of all the 

message types, please refer to the “Web Based Message Exchange – Market 

Participant‟s Guide” document, which is available on IESO‟s web site (see the 

Technical Interfaces page of IESO‟s web site). 

3.2.5 Dispatch Message Scenarios 

219 Heart beat messages are sent by the IESO to determine whether the market 

participant is able to receive dispatch instructions from the IESO. 

IESO – Action MP –Response Comment 

HEARTOUT HEARTIN The IESO will send a HEARTOUT message 

every 60s to check for an active MP message 

exchange client. If the IESO does not receive 

the HEARTIN response from the client with a 

specified period of time (currently configured 

to 10s) the MP client is considered out of 

service and the Exchange Coordinator be 

informed of the problem. 




220 The following scenario demonstrates the Based on the bids and dispatch 

scheduling optimizer (DSO) dispatches GENERIC-LT.G2 to 268MW at 

2000/08/30 9:05 with the expectation that that the instruction will be met at 

2000/08/30 9:10. The dispatch MP accepts the dispatch and complies with the 

instruction. 

ENERGY DISPATCH: 

IESO – Action MP – Response Comment 

RESOURCE_ID=GENERIC-LT.G2 

DISPATCH_TYPE=ENG 

AMOUNT=268 

DELIVERY_DATE=2000/08/30 

DELIVERY_HOUR=10 

DELIVERY_INTERVAL=2 

RECEIPT 

The MP client should immediately send a 

RECEIPT message back to the IESO 

acknowledging that the message has been 

received. 

CONFIRMATIONOK 

ACCEPT 

The MP client should send an ACCEPT 

message to inform the IESO that they intend to 

comply with the dispatch. 

The IESO receives the ACCEPT message and 

initiates compliance monitoring of the 

requested dispatch. 

The COMFIRMATIONOK message is sent to 

confirm that the ACCEPT message was 

received and acknowledged by the IESO. 

221 The following scenario demonstrates what will happen when the market 

participant rejects a dispatch message. 



IMO_MAN_0024 





AMOUNT=268 




RECEIPT 




received. 

CONFIRMATIONOK 

REJECT 

The MP should send a REJECT message to 

inform that they do not intend to comply with 

the dispatch. 

The Exchange Coordinator is informed that the 

dispatch was rejected. 

The COMFIRMATIONOK message is sent to 

confirm that the REJECT message was 

received and acknowledged by the IESO. 

The Exchange Coordinator will assess the 

impact of the REJECT and choose alternate 

resources as required. 

The Exchange Coordinator will request 

additional information from the market 

participant to explain the reasoning behind the 

REJECT of the dispatch instruction. 


222 The following scenario demonstrates what will happen if the market participant 

does not respond to a dispatch instruction. 




AMOUNT=268 







received. If the RECEIPT message is not 

received within 20s the Exchange Coordinator 

will be made aware of the problem. 

If a response to the dispatch instruction is not 

received within 60 seconds, the dispatch 

instruction is considered to be in a timeout 

state, which locks out the MP client from 

further accepting or rejecting the dispatch 

instruction. If, within 30 seconds after a 

dispatch instruction has timed out, market 

participants call and request the IESO to 

manually accept or reject the dispatch 

instruction, the IESO will attempt to do so on 

their behalf. If, within those 30 seconds, the 

market participants do not request the IESO to 

manually accept or reject the dispatch 

instruction, the IESO will consider that the 

market participants have rejected the dispatch 

instruction. 




3.3 Real Time Network 

223 The Real Time Network will be used for: 

a. Real time data acquisition of power system data required by the IESO to operate the power 

system; 

b. Dispatch of automatic generation control (AGC) control commands; and 

c. Dispatch messaging. 

224 Function (a) and (b) above are typically executed by an RTU, and function (c) 

by a dispatch workstation. 

225 Real-time network communication with the IESO Control Center is via a Frame 

Relay communications network, except for dispatch messaging which will also 

use the Web as an alternative. This real-time network will be made available by 

the IESO to the market participant. In some cases, where the size and the 

location of the market participant’s electrical plant warrants, a secondary 

communications system for increased reliability will also be made available. 

226 The connection to the Real Time Network for an RTU or a functionally 

equivalent device e.g. PML meter, requires the market participant to provide 

the following: 

a. Access for the communications carrier to the market participant site to install a local loop 

and other customer premises equipment such as the DSU and FRAD. 

b. A dedicated dial-up telephone line connected to the FRAD to enable remote maintenance. 

c. Space to house the customer premises equipment in a suitable environment (e.g. dry, clean, 

0 – 40 C, free of Electro-Magnetic interference, etc.) 

d. A suitable power source for the customer premises equipment (typically a reliable source of 

120V ac, 60 Hz – usually from a UPS with a total load capacity of 500 Watts) with at least 

8 hours of survivability after loss of commercial power. 

e. Access for maintenance personnel as needed. 

f. Connectivity from the market participant equipment to the customer premises equipment as 

stated for the particular device. 

g. A point of contact (a person and telephone number) to enable the IESO to request repairs by 

the market participant for telemetry failures. 



IMO_MAN_0024 

Dial-up telephone line 

Local 

Telco 

Office 

Local 

Loop 

Telecom 

Isolating 

Device 

Telecom 

Internal Wiring 

DSU 

FRAD 

Telecom 

Room 

UPS 

UPS 

Interconnect 

Cable 

RTU 

Market Participant’s Premises 

Equipment Room 

(Legend: IESO responsibility Market Participant responsibility ) 

Figure 3-2: Responsibilities for Telecommunications and Site Readiness for RTUs 

227 The connection to the Real Time Network for a dispatch workstation requires 

the market participant to provide the following: 

a. Access for the communications carrier to the market participant site to install a local loop 

and other customer premises equipment. 

b. A dedicated dial-up telephone line connected to the Router to enable remote maintenance. 

c. Space to house the customer premises equipment (Router) in a suitable environment (e.g. 

dry, clean, 0 – 40 C, free of Electro-Magnetic interference, etc.) 

d. A suitable power source for the customer premises equipment, typically a reliable source of 

120V ac, 60 Hz. 

e. Access for maintenance personnel as needed. 

Local 

Telco 

Office 

Local 

Loop 

Telecom 

Isolating 

Device (if 

required) 

Telecom 

Room 

Dial-up Telephone Line 

Telecom 

Internal Wiring 

Router 

Interconnect 

Cable 

DWS 

RTU 

Market Participant’s Premises 

(Legend: IESO responsibility Market Participant responsibility ) 

Figure 3-3: Responsibilities for Telecommunications and Site Readiness for DWS 




3.4 Voice Communication Specifications 

228 Voice communications are broken into two categories: 

Normal-priority path market participants; and 

High-priority path market participants. 

229 The determination for whether a market participant requires a High Priority 

path is defined in the “Market Rules” Appendix 2.2. Regardless of the status of 

the market participant, all calls will be „caller identified‟ and handled through 

confidential links between sites. All calls involving IESO operations will be 

recorded by the IESO and must be responded to as set out in the market rules. 

230 In either category, voice communications between the IESO and market 

participants is critical for reliable and secure operations of the high-voltage 

electrical grid and is required by the “Market Rules” (Chapter 5, Section 12.2). 

1. The IESO uses MSAT telephone and data services. MSAT satellite telephone 

service is considered to be a High Priority path in that it does not use the Public 

Switched Telephone Network to complete calls between MSAT callers. It is 

therefore capable of providing an independent communication function between the 

IESO and new market participants. Other satellite telephone services are not 

considered because they require Public Switched Telephone Network links to 

either complete a call or to interconnect with IESO MSAT communications 

3.4.1 Normal-Priority PATH 

231 A normal priority path will be of a type and capacity that allows unblocked 

communication with the IESO. This will be the primary path used during the 

normal conduct of business between a market participant and the IESO. It may 

consist of a dedicated telephone number on the Public Switched Telephone 

Network (PSTN) to be used by the IESO only or an extension of a private 

network or Virtual Private Network (VPN) from either party. This path may 

involve connection to an IESO approved or administered network. Whatever 

mode is used this circuit will: 

a. provide inherent privacy for the users with the ability to add other parties by invitation only; 

b. interface with the IESO through the normally available PSTN facilities. Where available, 

caller identification will be available on this line. Such a facility shall be exempt from 

restriction by Line Load Control and/or have Priority Access for Dialing status; and 

c. not be routed by the market participant into an answering machine or Voice Mail that 

impedes or delays an immediate interactive conversation with a live person in attendance at 

the facility. 

3.4.2 High-Priority PATH 

232 A High Priority circuit will be of a type that provides backup communication 

between facilities. It must be „hardened‟ against failure due to loss of 

commercial power at any point (MSAT Synchronous satellite communication 

facilities may be considered as „hardened‟ facilities but are not desired as 

primary operating facilities due to the delay time involved in conversing over 



IMO_MAN_0024 

the link). In addition to the normal priority path requirements these facilities 

will: 

a. continue to operate for a minimum of eight hours after the loss of commercial power at any 

point; 

b. be protected against loss of service that may result from overload of the common carrier‟s 

public facilities; and 

c. be a circuit with physically diverse path from the Normal Priority path to eliminate any 

common point of failure. 

233 An „autoringdown‟ circuit and other similar dedicated facilities may be 

considered as High Priority and „hardened‟ depending on location. 

234 Connection to an IESO approved, administered, or operated network may also 

be considered acceptable as a High Priority path. The MSAT network is a 

presently approved network. Other satellite networks are not approved due to 

reliance on PSTN connectivity being required to either complete a call or to 

interconnect with MSAT telephones. 

235 All conversations between a market participant and the IESO are confidential 

and will ordinarily connect only the two concerned parties. Other parties may 

join the conversation by invitation only. 

236 The IESO will record all calls involving IESO operations. For all other cases, if 

a market participant desires call recording, it is the responsibility of that market 

participant to record the call. 

3.4.3 Security 

3.4.4 Diverse Path 

237 All communications between the IESO and the market participant are 

considered confidential and therefore it is recommended that unencrypted radio 

frequency transmitters, such as cellular phones and other wireless technologies, 

not be used for communications 

238 A diverse path will not use either the same physical path or equipment between 

sites. This does not include the end user devices. 




4. Operational Metering Equipment & AGC 

4. Operational Metering Equipment & 

AGC 

239 (For supporting rule references, please refer to “Appendix 2.2, Section 1.2 of 

the market rules”) 

4.1 Operational Metering Equipment 

4.1.1 Introduction 

240 This section covers operational metering requirements. It does not cover 

specific revenue metering requirements. 

241 Real-time operational information from market participants is required by the 

IESO for the operation of the high voltage electricity system. Market 

participants provide this information by using appropriate monitoring 

equipment that they supply. The information is sent to the IESO over IESO 

provided Real Time Network. 

242 Specifics for the types of monitoring equipment required by the IESO are 

detailed in the “Market Rules”, Chapter 4. The requirements in terms of 

quantities measured and performance for operational metering are mainly based 

on the facility ratings. 

243 Remote real-time data can be provided to the IESO by the market participants 

using two standard data transfer protocols: 

a. Distributed Network Protocol (DNP), and/or 

b. Inter Control Center Protocol (ICCP). 

4.1.2 Qualified Devices 

244 The standard device for collecting real-time information is the Remote 

Terminal Unit (RTU). Real-time information about the disposition of the 

market participants’ facility is collected from the market participant supplied 

RTU‟s and forwarded on a regular basis to the IESO Control Center. The 

Energy Management System (EMS) at the IESO Control Center polls the RTUs 

for information every two to four seconds. Total data latency must not exceed 

four seconds. 

245 The EMS communicates with the RTUs using the DNP 3.0 protocol. The 

Binary Input Data are Object 1, Qualifier 01, Variation 1 (normal) and 

Variation 2 (not normal). The Analog Input Data are Object 30, Qualifier 01, 

Variation 4 (normal) and Variation 2 (not normal) with Application Confirm 

Request. All data must show Data Quality Flags when not normal, such as Off 

Line, Restart, Communication Lost, Local/Remote Forced, Over-range. If data 

are derived from some intermediate devices, these flags must indicate any 

manual manipulation or failure of these data in these devices. Pseudo data do 

not require any Data Quality Flags. 


4. Operational Metering Equipment & AGC IMO_MAN_0024 

246 DNP (Distributed Network Protocol) is an open, standards-based protocol used 

in the electric utility industry to address interoperability between substation 

computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations. 

This protocol is based on the standards of the International Electrotechnical 

Commission (IEC). DNP 3.0 is the recommended practice by the IEEE C.2 

Task Force for RTU to IED communications. 

247 The document "DNP 3.0 Subset Definitions" is available to DNP User Group 

members at the DNP User Group Web site (http:/www.dnp.org). This 

document will help DNP implementers to identify protocol elements that 

should be implemented. 

248 The following RTU manufacturers using the DNP 3.0 protocol have been 

qualified for use by the IESO: 

249 Vendor Name: GE Energy / GE Harris 

250 Device Name: D20, D200, and D25 RTUs, 

251 Vendor Name: Quindar 

252 Device Name: XPPQ and Scout RTUs, 

253 Vendor Name: PML 

254 Device Name: 7330, 7500, 7600, 7700 and 8500 

255 Vendor Name: Cybectec 

256 Device Name: SMP Gateway 

257 Vendor Name: Schneider Electric 

258 Device Name: Quantum PLC System with a DNP3 Processor, 

259 Vendor Name: Bow Networks 

260 Device Name: Advantech Industrial PC Part # UNO-2160-IDA0 

261 Vendor Name: Schweitzer Engineering Laboratories, Inc. 

262 Device Name: SEL-3332 Intelligent Server. 

263 Vendor Name: Telvent 

264 Device Name: Sage 3030 Substation Automation Platform. 

265 Vendor Name: Schweitzer Engineering Laboratories, Inc. 

266 Device Name: SEL-3351, 3354 & 3530 System Computing Platform. 

267 Vendor Name: ABB 

268 Device Name: ABB RTU560 

269 Vendor Name: Subnet Solutions Inc. 

270 Device Name: SEL/SUBNET 1102 

271 Further information on additional qualified devices or assistance on RTU set-up 

and configuration is available from the IESO. 




272 The IESO may add qualified devices from other manufacturers. Market 

participants should contact the IESO to get information on the current set of 

qualified devices. 

273 If the market participant wishes to use more than one meter at a location for the 

transmission of real-time data to the IESO, the IESO requires that the data be 

combined to one data concentrator such as an RTU so that only one 

telecommunications connection is required. The data from a failed meter or 

device must show the Offline and Communication Lost Flags. 

274 If ICCP (Inter Control Center Protocol) is used for real-time data transfer to the 

IESO, the market participants will provide their own ICCP server and software. 

Co-ordination with the IESO is necessary to establish the communication link 

between the market participant and the IESO Control Centers. 

275 The overall requirements for reliability and performance of the monitoring and 

control equipment are specified in Chapter 4 of the “Market Rules”. 

4.1.3 Field Instrumentation Standards 

276 The field instrumentation standard focuses on overall accuracy of the 

measurements being reported to the IESO. The accuracy requirement is for an 

overall end-to-end measurement error no greater than two percent of full scale. 

277 This measurement error is the sum of all the errors in the measurement chain. 

Typically the measurement chain is comprised of: 

a. primary conversion by potential and/or current transformers; 

b. secondary conversion by transducers; and 

c. report by the RTU. 

278 Any load meter reading must accurately reflect the quantity being measured 

regardless of load balance across the phases. For generation, a minimum of 2 

metering elements is required. 



279 As a guideline to the market participants, the anticipated errors in the 

measurement chain described above are: 

a. Primary conversion 0.5% of full scale 

b. Secondary conversion (transducers) 0.5% of full scale 

c. Report by the RTU, comprising analogue to digital 

conversion by the RTU and quantification errors 

1.0% of full scale 

280 The above accuracy standards are expected to be met by all new installations. 

However, for existing installations, the existing instrumentation transformers 

and burdens will be accepted by the IESO, for the life of the instrumentation 

transformers, except where their accuracy is insufficient for monitoring 

quantities that affect the system limits of the IESO controlled electricity 

network. It is up to the market participant to ascertain with the IESO, during 

facility registration, whether the accuracy of their instrumentation transformers 

would have such impact. 

4.1.4 Data Specifications 

Analogue Points 

Status Points 

281 The specific data that needs to be made available to the IESO depends not only 

on the electrical capacity of the market participant facility and its participation 

in the market, but also on other factors that influence the safe operation of the 

IESO-controlled grid. The detailed requirements are available in Chapter 4 and 

associated Appendices of the “Market Rules” and through consultation with the 

IESO. 

282 In a generic sense, the data monitored falls into two classes – analogue and 

status. 

283 These are continuously varying measurements such as watts, volts and amps. 

Typically the measurements are derived from a primary conversion device such 

as potential or current transformer and a transducer. This measurement chain 

scales down the actual electrical value that the RTU can report, for example, 0 

– 100 MW to an analogue representation of 4-20 mA or 0-1 mA. Market 

participants may contact the IESO for more detailed information. 

284 Status points are typically discreet, binary values such as the open or closed 

status of a switch. This information is presented to the RTU by a contact whose 

state is representative of the state of the device being monitored. Market 

participants should check the RTU vendors‟ literature for available options in 

status monitoring. 

4.1.5 Power Supply Specification 

285 As the data received from the RTU is an integral piece to the operation of the 

electricity grid, the RTU and associated communications equipment requires 




connection to a secure source of power. Therefore the RTUs must be powered 

from an industrial grade uninterruptible Power Supply (UPS) or from 

continuously charged batteries. In case of a power failure, sufficient battery 

capacity must be provided to permit ongoing operation of the RTU for a 

minimum of eight hours. 

286 The RTUs must be operated in an environment of –40°C to +80°C and 95% 

non-condensing relative humidity. 

4.1.6 Communications Specification 

287 The RTUs can communicate with the IESO using either a serial port (operating 

in the range of 4.8 - 19.2 kbps) or an Ethernet port (10 Mbps) using IP - please 

check with the IESO at the time of your installation. Ethernet (IP) connections 

must comply with the specifications outlined by the DNP Users Group in the 

document entitled, “Transporting DNP3 over Local and Wide Area Networks." 

The communications port will be connected to the Real Time Network supplied 

by the IESO located at the market participant's facilities. 

288 The Real Time Network‟s customer premises equipment (FRAD and DSU) 

require a secure source of power supplying 115 Vac. The use of an inverter, 

backed with at least 8 hours of battery power, will normally provide this 

reliability. The inverter may also supply power to the RTU. If required, the 

IESO can recommend a dedicated inverter and a bypass-switch for powering 

the telecommunications equipment. In this case, the primary source of power 

will be a market participant provided dc supply to the inverter in the range of 

100-280 Vdc capable of supplying the load for at least 8 hours and a secondary 

115V ac source connected to the bypass switch. 

289 For the IESO supplied telecommunications equipment, the acceptable 

environment is 0°C to +40°C and 5% - 90% non-condensing relative humidity. 

4.1.7 RTU Site Certification 

290 The certification of an RTU site is composed of the following activities: 

a. Field Instrumentation Accuracy Audit; 

b. Environment Audit; 

c. Telecommunications connection; and 

d. RTU Check-In Service. 

291 Upon the successful completion of the site certification process by the IESO, 

the RTU Site is certified as acceptable for market use. Each of the above 

certification activities is described in more detail below. 

292 Field Instrumentation Accuracy Audit, which is the verification of all the errors 

in the measurement chain, may be required by the IESO. The market 

participant should be able to demonstrate that the overall measurement error is 

no greater than two percent of full scale. An acceptable method would involve a 

combination of manufacturers‟ specifications and calibration records. 

293 Environment Audit may be required to verify the physical and electrical 

environment for the RTU and IESO installed telecommunications equipment. 



The market participant may be required to demonstrate that the electrical power 

supplies meet the requirements. Also, the market participant may be required to 

demonstrate that the environment in which the RTU and telecommunications 

equipment is installed meets the manufacturer‟s environmental requirements. 

294 A telecommunication connection must be established between the market 

participant and IESO. Market participants will grant access to their premises to 

IESO staff or IESO designated staff to establish the required telecommunication 

connection. 

295 The work involved in establishing this connection typically includes: 

a. installation of a local loop between the RTU location and a telecommunications service 

provider; 

b. installation of telecommunication equipment at the market participant’s premises. Typically 

this equipment is comprised of three small modules, the Frame Relay Access Device 

(FRAD), the Digital Service Unit (DSU) and the dial-up modem; and 

c. verifying that the telecommunication connection is working properly. 

296 RTU Check-In Service is the final step in RTU Site Certification. This involves 

the verification of the accuracy of the RTUs database to ensure a proper 

correspondence between the actual field device such as a breaker or 

measurement and the representation in the RTU. The proper operation of the 

RTU with IESO‟s Energy Management System (EMS) and the verification of 

the RTU database being transmitted to the IESO will also be verified. Details of 

the check-in-service process are available from the IESO. 

4.2 AGC Operational RTU Specifications 

297 Automatic generation control (AGC) is a contracted ancillary service used by 

the IESO to fine-tune the match between generation and load. Specific details 

of implementation will be determined during the contracting process. 

298 The actual control of generators under AGC is accomplished by control signals 

sent directly by the IESO to the plant controller or RTU installed for data 

gathering and control. The IESO can send either pulse commands to raise or 

lower generation or it can send MW setpoint commands to change the 

current generation. The type of signal the sent to a specific unit that is 

providing AGC is determined by the IESO and is also dependent on the 

design of the unit’s governor system which controls the power input to the 

generator. A number of associated data inputs, such as generator status, 

generator output, etc. must also be telemetered by the RTU to the IESO Control 

Center. 

299 The control signals from the plant controller or RTU will issue raise/lower 

pulses using an output relay. These can be dry or wet contacts depending on the 

configuration. The pulses typically are one second in length. On receipt of a 

raise/lower pulse, the generating units under AGC control are expected to 

change their output MW by a pre-determined amount. 

300 Units which do not have remote MW setpoint capability in their governors will 

execute a power change based on the pulse width (time that the pulse is active) 

of the raise or lower pulse provided by the IESO’s AGC controller. The pulse 




width is used to change the position of the unit‟s power control device – usually 

a hydraulic gate or a steam turbine governor valve. The resulting power change 

may not be exactly what was intended by the AGC controller. During the next 

pass of the AGC controller (typically every 2 seconds) the error will be detected 

and a further adjustment made by the AGC controller to all the units 

participating in AGC. 

301 Units which have MW controllers with remote MW setpoint capability can 

choose to use either a pulse width to raise or lower the MW setpoint value or 

they can chose to use a direct MW setpoint value provided by the IESO’s AGC 

controller. A direct MW setpoint value is preferred because it eliminates any 

error in converting the pulse width into a MW value. This specification applies 

to those units that have a MW controller with remote MW setpoint capability. 

A typical block diagram of the entire AGC control loop is shown in Figure 4-1 

below. 



Figure 4- 1 Block Diagram of Typical AGC Control Arrangement for Generation units With 

Remote MW Setpoint Control Capability 

302 The information necessary to control the generation facility under the terms and 

conditions of the AGC contract will reside and operate in the EMS according to 

the existing control schemes. 

303 It is the market participant’s responsibility to protect their equipment from 

damage due to erroneous pulses or spurious signals that may cause the 

equipment to operate beyond its designed parameters, regardless of how these 

signals were generated or transmitted. 

304 Two models of RTU have been qualified for use by the IESO for AGC. These 

are GE models D20/200 and D25 RTUs. 





5. Market Applications IMO_MAN_0024 

5. Market Applications 

5.1 Market Application Systems Information 

5.1.1 Overview of Dataflow Systems 

305 The figure below provides an overview of the dataflow from the market 

participants to the IESO systems. The following paragraphs also provide 

technical details of various market applications and application interfaces. It is 

not intended to provide procedural information, being outside the purview of 

this document. Procedural information is available in the relevant market 

manuals. 




Energy Bids & Offers (Gen, Ld, Imp, Exp) 

Energy Schedules (Int, Slf, NonD) 

Bilaterals 

Operating Reserve Offers (Gen, Imp, Load) 

Standing Bids for Energy, OR & Sched 

SUBMIT, REVISE, DELETE, REVIEW 

Revenue Metering System 

Market Participants 

Market Results: 

Accepted Amounts 

Clearing Prices 

Acceptance of Submission 

Transaction Code 

Errors if any 

Invoices 

CR- Reports 

HandOff for MV-Star 

Data Requests 

Energy Bids & Offers 

OR Offers 

Schedules 

Contracts 

MIS System 

Financial Bids & Offers 

Standing Bids 

SUBMIT, REVISE, DELETE, REVIEW 

Interface System (MIM*) 


Clearing Prices & Volumes 

Constraints 

Shadow Prices? 


Schedules? 

EMS System 

Public Information 

System Forecasts 

System Status 

Market Prices & Volumes 

MIS Constraints 

FEM Schd & Prc 

RTEM Schd & Prc 

OR Schd & Prc 

CR Schd & Prc 

BIlaterals 

RTEM Prc Crvs 

OR Prc Crvs 

RTEM Zonal Prc 

OR Zonal Prc 

Invoices 

CR Reports 

Commercial Reconciliation 

Market Participants 

& 

Public Info 

Figure 5-1: Overview of Dataflow from the MP to IESO systems 

5.1.2 Bidding Application 

306 The Market Information Management (MIM) system at the IESO is responsible 

for receiving market participant bids and schedules, and then publishing market 

results. Commercial settlement reports and invoices may be downloaded via the 

IESO Reports Web Server. The market participant may communicate with the 

system using three mechanisms: 

a. Through a Default IESO provided GUI using Web Page based Forms; 

b. Through a Default IESO provided GUI by uploading and downloading ASCII data files; 

and/or 

c. Through a programmatic interface via an IESO provided API (IDK). 



Bidding Templates 

Template Format 

Template File Structure 

307 There will be upwards of 25 data template file formats for submitting and 

downloading data. All template files are simple Comma Separated Text (CST) 

files containing only ASCII characters with no hidden formatting information. 

308 These CST files will be subject to validation. The extension of the file is NOT 

important as the file format described in the data template and validation rule 

documents, which are located on the Technical Interfaces page of IESO‟s Web 

site, determines whether the file is accepted. Three types of validation rules are 

recognized, which consist of: syntax validation, technical feasibility checks, 

and commercial acceptability checks. Invalid data will be rejected with the 

appropriate error messages being posted to the sender. 

309 A single transmission file may contain one or more bids. The entire file will be 

considered as one transaction. Each file must have a file header with 

information common to the entire file. The file header can be followed by one 

or more bids. Each bid begins with a bid header followed by one bid body. The 

file header defines the application process and in some cases the market process 

and the data that is common to bids that belong to the transaction. Data 

associated with a bid is entered into a data template in a predefined structure. 

Rules for Submitting Data & Using Template Files 

310 Except where otherwise mentioned, the following rules are common to all the 

data template files: 

a. A template file is a simple comma separated text file containing only ASCII characters. No 

hidden formatting information is allowed. 

b. PM keyword in the file header indicates that the transaction is targeted for the physical 

market. The FM keyword in the file header indicates that the transaction is targeted for the 

Financial Market. 

c. RTEM, SCHEDULE, BILATERAL, OPER_RESV or CAP_RESV keyword in the 

transaction header of PM template file indicates that the transaction is targeted for the realtime 

energy market, real-time schedule market, bilateral contract market, operating reserve 

market or the capacity reserve market respectively. The DAEFM keyword in the transaction 

header of FM template file indicates that the transaction is targeted for the day-ahead 

financial market. The above markets may contain all 24 hours data or data for a range of 

hours or just the data for a particular hour. 

d. The Bid_Type field describes the type of resource submitting the bid/offer. The following 

keywords, and their assigned definitions, are used within the context of these templates: 

GENERATOR: A generation resource located within the IESO-controlled grid in 

Ontario. 

LOAD: A load located within the IESO-controlled grid in Ontario. 

INJECTION: A generation resource located outside Ontario. Can also be considered as 

imports by IESO. 




OFFTAKE: A load located outside Ontario. Can also be considered as exports by 

IESO. 

e. Standard time will be used for the date fields. There will be no 23-hour short days and no 

25-hour long days. All days will have 24 hours. 

f. Blank lines are permitted in the data files, and are ignored. White space is also ignored. 

Comma is used as the only data field separator. 

g. Comment lines must begin with \\. Comments can also be added at the end of a data line but 

it must be preceded by \\. Any text following \\ will be interpreted as comment and will be 

ignored. Comments cannot extend past across multiple lines unless each line begins with a 

\\. 

h. A semi-colon is a record terminator. It will be used as a file header, bid header, and bid 

body delimiter. The record terminator is not needed for those records that are comment 

lines. A data record must be on a single line. There is no maximum length for a line in an 

incoming file so long as a record terminator is specified for record termination. The record 

terminator signals the end of the record instead of the end-of-line character. 

i. The asterisk character is used to separate multiple bids/offers in a single file. The asterisk 

character should be used before and after each bid, which can contain up to 24 hours of 

data. 

j. All data information in a given template must be included in exactly the same order as 

listed. Any additional information or omissions will be considered as an error and will be 

rejected. 

k. An optional field can have a value or null. If a value has been entered, it will take 

precedence over the default value. All fields are mandatory if not specified otherwise. 

Optional fields are denoted with field names enclosed within [square brackets] in the 

template definitions. 

l. All mandatory fields must have values entered. If there is no data for a particular field then 

NULL value should be submitted. For example, „value1,,value2‟ contains a NULL value 

between value1 and value2. 

m. Each tuplet of data, as in the case of (Price, Quantity) or (RampBreakQuantity, RampUp, 

RampDown) must be enclosed within parentheses. The entire set of tuplets, i.e. the curve 

itself, must be enclosed within curly brackets. For the RTEM, the Price/Quantity data for 

an hour or range of hours can have up to 20 tuplets of values with a minimum of two 

tuplets. For Energy Ramp Rate tuplets, the maximum is 5 tuplets with a minimum of 1 

tuplet. Whatever the number of tuplets is, the data must be included first within parenthesis 

and then within curly brackets. As an example „1, {(23.50,0), (23.50,70)}‟ means that the 

price curve for 1AM has a two P, Q pairs. 

n. A shorthand notation can be used for specifying bid data that does not change across a 

contiguous range of hours. The format of the shorthand notation is „x-y‟ for an hour field 

and „{(p1, q1), (p20, q20)}‟ for a price curve, where x and y are the start and end hours that 

have the same value or the same curve. As an example, the shorthand notation „1-5, 70‟ 

implies that the value 70 is valid for all hours from 1 AM through 5AM. This shorthand 

notation is valid for incoming bids. This data, once received, will be stored on a per hour 

basis. This also implies that outgoing data will be given on an hourly basis. 

o. When using shorthand notation the hours must be in ascending order only. If there are any 

overlaps the records are invalid and will be rejected. As an example 



1-5 

7-10 

2-3 will be rejected 

1-5 

7-10 

6 will be rejected 

p. Rejected records will be identified to the market participant through a report created at the 

end of the transmission, identifying the rejected records and the reason for rejection. 

q. Output data templates may use the letters 'N/A' to indicate that the data value is not 

available. 

r. Data that is in the form of text strings must be entered within double quotes (i.e. “ ”). Such 

data cannot have double quotes embedded within it. For example field „other_reason‟, 

which is a text string should be submitted within double quotes (i.e. “ ”). 

s. All bid submission templates can be used for download purposes also. The valid bid data 

that will be downloaded will be in a similar format as it is during an upload. As mentioned 

above, hour ranges will not be used to download data but on a per hour basis. The 

downloaded data can be updated/modified, if needed, and then resubmitted without having 

to make any formatting changes. 

Bid Data Validation 

311 There is no sequence, template files can be submitted at any time. Submissions 

are checked for date and all other validations. Submissions for bids in the 

mandatory window must be made not later than 10 minutes before the 

mandatory hour closing. 

312 Data coming in to the Market Operating System (MOS) is subject to validation. 

Three types of validation rules are recognized: syntax validation, technical 

feasibility checks, and commercial acceptability checks. Invalid data will be 

rejected with the appropriate error messages being posted to the sender. 

313 Bids/offers submitted during the mandatory or restricted window will require 

IESO operator approval/rejection. In case of acceptance of a bid/offer that is 

submitted during the mandatory/restricted window and which exceeds the 

change tolerances, the IESO operator will communicate the decision to the 

market participant as a system log message. This bid/offer will then also be 

included in the valid bid report. If the bid is rejected by the Exchange 

Coordinator, the decision is communicated to the market participant via a 

system log message. 

Template Description and Samples 

314 All sample data templates (described below) and associated data sample files 

are provided at the IESO Web site under Technical Interfaces (Market 

Participant Submissions) for viewing or downloading. Comment lines may be 

included within the template to explain its structure. Comments are not 

required in the actual templates. Data values are included to illustrate the 

structural characteristics. Since these values were randomly chosen, there may 

not be a logical consistency across the data fields. In addition, some data, such 

as Market participant ID and Resource ID have been edited for confidentiality 

reasons. 




The Energy Template is used to specify the bids or offers for various resources like generators, 

loads, off-takes and injections. This template can be used for data submission in any window 

and can be used to view the energy data. These will be version sensitive and new versions 

will be available to all Market participants when available. Older versions cannot be used 

when a new version is issued. 

The Bilateral Contract Template is used to specify the hourly amount exchanged between 

two Market participants. This template can also be used to view the bilateral contract data. 

Real Time Energy Schedule Template is used to specify the schedules for various 

resources. Market participants will use this template to send their schedule data to the IESO. 

This template can also be used to view the schedule data. This template can be used by 

market participants that are: 

Self-scheduling generators, or 

Intermittent generators 

Operating Reserve Template is used by market participants to send their bid/offer data to 

the IESO. It can also be used to view the operating reserve data. All operating reserve 

ancillary service data loading use the same template. There are 3 types of Reserves 

supported and they are 10-min Non-Spin Reserve, 10-min Spin Reserve & 30-min Reserve. 

The Capacity Reserve Bid Template is used to send bid/offer data to IESO. This template 

can also be used to view the bid/offer data. 

Note: The Capacity Reserve Market is not yet implemented. 

Public Market Information, which is available on the Technical Interfaces page of IESO‟s 

Web site, is used by Market participants to view the public market information and/or the 

market results. 

Private Market Participant Information, which is available via through the MPI or API is 

used by market participants to view their dispatch information. 

315 Although the IESO is not bound to rigorously follow any particular ISO 

standard it recognizes the benefit of taking some of them into account. ISO 

9001 regulations are considered in the attempt for achieving quality interfaces. 

5.1.3 Settlements Application 

316 The current Commercial Reconciliation system produces settlement statements. 

The IESO Funds Administration (FA) applications group produces invoices. 

Market participants have the ability to review and/or download the invoices 

through the IESO Reports web server. Settlement statements are similarly 

available through the IESO Reports web server. 

317 Detailed information regarding the precise format of settlement statement files 

and supporting data files is detailed on the Technical Interfaces page of IESO‟s 

Web site. 

318 Further information regarding charge type calculations may be found on the 

Technical Interfaces page of the IESO‟s Web site. 



Settlement Statement Files 

319 The settlement statement files and supporting data files contain settlement 

amounts and the underlying data used in those calculations for a market 

participant. The data included mostly pertains to a particular trading date (the 

primary trade date), but it may also contain missing charges from prior trading 

dates. Content, field usage, and format are detailed, in “Format Specification 

for Settlement Statement Files and Data Files”, and may be found on the 

Technical Interfaces page of the IESO‟s Web site. 

320 Some general notes about the statement files are listed below: 

Market participants will download the files through the IESO Reports web server. 

The timeline for generating the preliminary and final statements for the financial and physical 

markets is detailed in the “Settlement Manual”. In general terms however, their issuance is 

based on a business day timeline rather than on a calendar day timeline and is specifically 

governed by: 

The IESO Settlement Schedule & Payment Calendar (“Market Rules” Ch. 9 Section 6.2, 

“Market Manual 5: Settlements Part 5.1: Settlement Schedule and Payment Calendars 

(SSPCs)”); and 

Any emergency procedures that may have to be invoked by the IESO under the IESO 

“Market Rules”. 

The companion data files are issued following the same timeline as the Statement Files. 




RT Preliminary 

Settlement 

Statement 

EFM/TR 

Preliminary 

Settlement 

Statement 

RT 

Preliminary 

Settlement 

Statement 

File 

RT 

Preliminary 

Data File 

EFM/TR 

Preliminary 

Settlement 

Statement 

File 

RT Final 

Settlement 

Statement 

EFM/TR Final 

Settlement 

Statement 

RT Final 

Settlement 

Statement 

File 

RT Final 

Data File 

EFM/TR 

Final 

Settlement 

Statement 

File 

Real-time Market Settlement Statements and Data Files 

Energy Forward Market Settlement Statements and Data Files 

(including TR auction settlement) 

Figure 5-2: Schematic Overview for Settlement Statements and Data Files 

321 The preliminary settlement statement provides each market participant with an 

opportunity to review all settlement amounts that have been calculated for a 

particular trading day and raise a notice of disagreement if necessary. After a 

predetermined notice of disagreement period, a final statement is generated. 

322 Information regarding the format of the settlement statement files and 

supporting data files is provided in, “Format Specification for Settlement 

Statement Files and Data Files”. 

Settlement Statement Supporting Data Files 

323 The timeline for issuing the preliminary and final data files for a given trading 

date are detailed in the “Settlement Manual”. In general terms however, their 

issuance is based on a business day timeline rather than on a calendar day 

timeline and is specifically governed by: 

The IESO Settlement Schedule & Payment Calendar (“Market Rules” Ch. 9 Section 6.2, 

“Market Manual 5: Settlements Part 5.1: Settlement Schedule and Payment Calendars 

(SSPCs)”); and 

Any emergency procedures that may have to be invoked by the IESO under the IESO 

“Market Rules”. 



With each set of settlement statement files, each market participant will receive a data file. 

Each data file will correspond to a statement, and will have the same settlement statement 

ID. 

The data contained in the supporting data file provides each market participant supporting 

data that is used in calculating the preliminary settlement for a particular trading date in the 

physical market. The final settlement data file contains the supporting data that is used in 

calculating the final settlement. 

5.1.4 Application Interfaces 

324 The Market Information Management (MIM) site is one of the Web sites that 

allow the market participant to interface with the IESO. Specifically, the MIM 

represents the secure internet-based client gateway to functionality provided by 

the IESO energy bidding system. 

325 The market participants can interact with the MIM using the following two 

methods: 

Internet Explorer browser. The browser is GUI based and interprets tag languages such as 

HTML. It allows client interaction through the keyboard/mouse; and 

MIM Client API (IAPI). The API emulates the functions of the browser. It allows Clients 

programmatic access to the MIM functionality using third party applications. 

326 Application Interface (API) code will allow market participants to customize 

their interface to interact with the IESO. Using the Java interface, these API‟s 

provide access to MIM. They act as wrappers to validate and normalize 

parameters passed to the MIM system through Java class libraries. It is these 

same class libraries that also run within the Communicator browser 

environment and are fetched when the secure MIM site is first visited. These 

library routines provide the following functionality: 

Template Upload; 

Template Download; 

System Message Download; and 

Market Status Download; and 

327 To support platform independence, as of IDK 1.46 a Java interface is supported 

by the IESO. To download the latest version of the IDK visit the Technical 

Interfaces page of the IESO‟s Web site. 

328 Also, client-side certificates will be required to access the MIM. An API, such 

as SSL, will be necessary to establish the SSL session with the MIM Web 

server. 

329 In summary the following hardware/software recommendations are made : 

Minimum 128 MB of system memory; 

Intel based PC running Windows XP SP2, or higher; 

Java 2 Runtime Environment at a minimum as shown on the “IESO Supported Client 

Platform” Web Page. This contains the required JVM and runtime classes; 

Internet Explorer to download the IAPI bundle; and 




Client-side digital certificates and the software to establish a secure (e.g. SSL) session with 

the MIM server. 

330 Detailed information on these functions can be found in the “IESO Developer's 

Toolkit (IDK), Implementation Manual” which is available at on the Technical 

Interfaces page of IESO‟s Web site. It provides details of the following six 

functions: 

Login to MIM; 

Upload Bids; 

Download Bids; 

Download System Messages; and 

Download Market Status Information. 

5.2 Funds Administration 

5.2.1 HTML and Text File Invoices 

5.2.2 E-mail 

331 Invoices will be distributed to the market participants via XML, HTML or text 

files hosted on the IESO Reports web server The market participant using any 

standard web browser over the web can view these XML, HTML or text files. 

The market participant can also download and save the XML, HTML or text 

file and print the invoice. 

332 Descriptions of the XML and text file invoice may be found in the technical 

interface document entitled, “Text File Invoice Format Specification”. 

333 Emailing of invoices and statements will not be available as an option. 

5.2.3 Fund Transfers 

334 Banks used by the market participants must have electronic funds transfer 

capability. Electronic funds transfer is a computerized mode for payment and 

withdrawal used in transferring funds from the market participant’s bank 

account to the IESO and vice versa. 

335 There are 3 types of electronic funds transfer used by banks including EDI, 

Wire Transfers, and pay-only electronic funds transfer (Direct Deposit). The 

amount of information passed to the IESO with each of these types of payment 

is different. The short time frame within which the IESO is required to remit 

payment to the credit side of the market makes it important to identify the 

source and relevant invoices associated with payments made to the IESO as 

quickly as possible. The EDI and Wire transfer approaches to electronic funds 

transfer provide the IESO with sufficient detail to make identification possible. 

Pay-only electronic funds transfer (Direct Deposit), however, can not provide 

the IESO with the needed information. The IESO is therefore requesting market 



participants using pay-only electronic funds transfer to send a fax to the IESO 

Finance Department with the details of the payment provided (market 

participant name, invoice number(s), amount of payment). 




Appendix A: Forms 

Appendix A: Forms 

This appendix contains a list of the forms and agreements associated with Participant Technical 

Reference Manual. These are available on the IESO public Web site on the Market Entry Page. The 

forms and agreements included are as follows: 

Form Name 

IESO Certificate Subscriber Request Form 

IESO Certificate Subscriber Registration Officer Request 

Form 

IESO Certificate Subscriber Agreement 

Form Number 

IMO_FORM_1276 

IMO_FORM_1277 

IMP_AGR_0016 


Issue 21.1 – March 15, 2010 - estimated Public A–1


Appendix B: List of Commonly Used Acronyms 

Appendix B: List of Commonly Used 

Acronyms 

ANSI 

AGC 

API 

BES 

BOC 

Bps 

DAEFM 

DMI 

DSU 

EDI 

EMS 

FIS 

GUI 

ICCP 

ICG 

IEEE 

IESO 

IP 

ISO 

IT 

KB 

Kbps 

LAN 

MB 

Mbps 

MIM 

MMP 

MPI 

MSP 

MW 

NERC 

OS 

PC 

PSTN 

PKI 

PLC 

RTU 

RTEM 

SCADA 

American National Standards Institute 

Automatic generation control 

Application Program Interface 

Bulk Electricity System 

Backup Operating Center 

Bits per second 

Day Ahead Energy Financial Market 

Desktop Management Interface 

Digital Service Unit 

Electronic Data Interchange 

Energy Management System 

Financial Information Systems 

Graphical User Interface 

Inter Control Center Protocol 

IESO-Controlled Grid 

Institute of Electrical and Electronics Engineers 

Independent Electricity System Operator 

Internet Protocol 

International Standards Organization 

Information Technology 

Kilobytes 

Kilobits per second 

Local Area Network 

Megabytes 

Megabits per second 

Market Information Management 

Metered Market Participant 

Market Participant Interface 

Meter Service Provider 

megawatts 

North American Electric Reliability Council 

Operating Systems 

Personal Computer (IBM compatible) 

Public Switched Telephone Network 

Public Key Infrastructure 

Participant Life Cycle or Registration System 

Remote Terminal Unit 

Real-Time Energy Market 

Supervisor Control and Data Acquisition 

Issue 21.1 – March 15, 2010 - estimated Public B–1

Appendix B: List of Commonly Used Acronyms 

IMO_MAN_0024 

TCP 

UPS 

URL 

VAr 

Transmission Control Protocol 

Uninterruptible Power Supply 

Uniform Resource Locator 

Volt-Ampere-Reactive 


B–2 Public Issue 21.1 – March 15, 2010 - estimated


References 

References 

DNP 3.0 Subset Definitions 

Java 2 Runtime Environment 

Market Rules 

Document Name 

Market Manual 3: Metering; Part 3.0: Metering Overview 

Market Manual 1: Market Entry, Maintenance & Exit; Part 

1.3: Identity Management Operations Guide 

Format Specifications for Settlement Statement Files and 

Data Files 

Market Manual 5: Settlements Part 5.0: Settlements 

Overview 

Market Manual 5: Settlements Part 5.1: Settlement Schedule 

and Payment Calendars (SSPCs) 

Market Participant Graphical User Interface User‟s Guide 

IESO Portal User Interface User‟s Guide 

IESO Developer's Toolkit (IDK), Implementation Manual 

Web Based Message Exchange – Market Participant‟s Guide 

Document ID 

Non-IESO (www.dnp.org) 

Non-IESO (http://java.sun.com/) 

MDP_RUL_0002 

MDP_MAN_0003 

IMP_GDE_0088 

IMP_SPEC_0005 

MDP_MAN_0005 

MDP_PRO_0031 

IMO_GDE_0003 

IESO_GDE_0209 

IMO_MAN_0023 

IMP_MAN_0031 

– End of Document – 

Issue 21.1 – March 15, 2010 - estimated Public References–1

Participant Technical Reference Manual - IESO

Create successful ePaper yourself

Delete template?

Save as template?