eProcurement White Paper Final

Insight Matters:
Global Network
Considerations
for eProcurement
and Extranets

Prepared by
James E. deMin
Infonet Services Corporation

e P r o c u r e m e nt

Vo lum e 1

w w w . i n f o n e t . c o m

I n t r o d u c t i o n

eProcurement is another name for B2B (Business-to-Business) purchasing of goods and

services through extranet trading exchanges, direct ERP-to-ERP and internet connections

with suppliers. According to Fortune magazine, manufacturers spend an average of 55

percent of their revenues on goods and services, and service companies spend more

than 15 percent. The Boston Consulting Group (BCG) predicts that one-fourth of all

B2B purchases will take place online by the end of 2003. MNCs (Multinational

Corporations) are cutting costs and increasing profits by exploiting the power of

eProcurement techniques. Already a well established technique for optimising an

enterprise’s supply chain and reducing procurement expenses, eProcurement necessi-

tates three fundamental requirements; (1) re-thinking organisational assumptions

regarding procurement processes, (2) re-engineering MRO (Materials, Repairs and

Operations) business processes, and (3) optimising enterprise applications and the

supporting IT infrastructure to ensure the systems deliver unimpeded around-the-clock

availability and optimum performance.

For suppliers, eProcurement provides functions that include electronic workflow to track

orders through fulfillment and billing, methods for collecting payment (e.g. electronic

invoicing, credit cards, electronic data interchange and electronic funds transfer), etc.

As with buyers, suppliers seeking to undertake an eProcurement initiative must overhaul

their business processes and adopt common procedures that cross industry, geographic

and other boundaries, as well as be able to accommodate security and multi-language

challenges. While the technologies offered by specialised e-Procurement software

vendors (e.g. Ariba, Commerce One, etc.) and more traditional ERP vendors (e.g. SAP,

Oracle and PeopleSoft, etc.) provide a vast array of functional capabilities, these must

now be extended globally to accommodate the demands of integrated logistics chains,

supplier hubs, extended supply chains, etc.

However, for all the importance of eProcurement and the supporting infrastructure, all

too often insufficient attention is paid to the wide area network (WAN). For example,

if pre-deployment and/or upgrade testing of the supporting software is limited to only

the campus LAN environment, the software’s true WAN performance only comes to light

as the application begins to be promoted into production and users are being added to a

live system. Also, leading up to production rollout, network managers are often

e P r o c u r e m e nt

provided with very limited requirements (e.g. number of users and "go-live" date) from

which they must size the required network. They are also often not made aware of

software’s interfaces with other applications, which drive application-to-application or

"A2A" transactional traffic. When users complain about disconnects or slow response

times, all focus is upon the network. In fact, Gartner, Inc. estimates that more than

80% of application availability and performance problems are being blamed upon the

network. Precious time, valuable resources, and scarce IT funding are then spent

on trial-and-error quick-fixes (e.g. server upgrades, database tuning, etc.) until

performance is improved.

This unfortunate situation can be avoided by understanding more about the network

profiles of enterprise-class applications and what choices are available for optimising

performance over WANs. Most software vendors are now touting their new browser-

based "n-tier designs" where little or no software is resident on the client workstations.

Despite the desktop support advantages of such architectures, remote presentation can

add traffic to the network while making end-user performance more vulnerable to

network delay. Web access, underlying both the HTML and network computing approaches,

rely upon HTTP, as well as XML, which have performance issues over the WAN.

e P r o c u r e m e nt

Figure 1 - Market Places, Hubs and Extended Supply Chains

Fragmented logistics

chain

Market Place

Integrated logistics

chain

Collaborative

Strategies

e p r o c u r e m e nt o v e r v i e w

eProcurement is all about cost savings and efficiency,

spanning the entire vertical spectrum of industries, from

chemicals to manufacturing and airlines to agriculture.

The reach of an enterprise’s eProcurement processes must

extend as far as its suppliers, customers, and internal

operational lines of business and administrative organisa-

tions. For MNCs this then means even greater levels of

dependency upon their global network and service

providers, if the potential opportunities of eProcurement

are to be realised (refer to Figure 2).

e P r o c u r e m e nt

Figure 2 – Advantages of eProcurement

Source: AMR, 2001

Advantages for the distributor

Store management

Stock management

Increase in sales

Reduction in logistics costs

Average expected savings

10 to 40%

12 to 30%

2 to 10%

5 to 10%

Advantages for the producer

Reduction in stock

Acceleration of restocking cycles

Increase in sales

Better customer service

Average expected savings

2 to 8%

10 to 40%

5 to 20%

3 to 4%

The objectives of eProcurement include the following:

To improve service levels to buyers, suppliers and users.

To develop a more integrated approach to procurement

across the enterprise’s supply chain.

To minimise the transaction costs associated with

procurement through standardisation, streamlining and

automation of the procurement processes within, and

where appropriate across agencies and sectors.

To promote competition among suppliers while

maintaining reliable sources of supply.

To optimise inventory levels through the adoption of

efficient procurement practices.

To make effective use of human resources in the

procurement process.

To reduce off-contract spending by using technology to

increase user awareness of existing contract facilities

and by making it easier to order against them.

To leverage buying power by using technology to support

identification of opportunities for aggregation and by

facilitating the aggregation of user requirements within

and across lines of business.

Reduce transaction costs by using technology to auto-

mate processes, which are currently paper-based, and to

streamline and standardise processes and documentation.

Interenterprise Data Warehouse - Workflow Mgmt. - Data Transmission - Business Messaging

Discussion - News - Reference Library - Employment - Advertising

Product Catalog - Performance Scorecard - Benchmarking - Management Alerts

e P r o c u r e m e nt

The organisational assumptions and business processes

involve internal alignment of control over procurement poli-

cies, procedures, and supplier relationships. To achieve fully

leveraged buying volume, an enterprise must put into place:

Centralised control of supplier relationships, including a

reduction in the supplier-base, the establishment of corpo-

rate preferred suppliers, and negotiated agreements based

upon volume.

Predominantly standardised procedures and policies.

Supporting software applications linked internally with

operational lines of business and administrative depart-

ments, and externally with suppliers, trading exchanges

(e.g. TradeRanger, Elemica, etc.) and extranet partners.

In a highly integrated end-to-end eProcurement process

(refer to Figure 3), the applications of suppliers not only

receive orders without re-entering them, but also respond

with availability, delivery dates, and status reports.

This requires integrated order-fulfillment and supply

chain systems, with robust and properly sized networks.

Suppliers must also find the best means of creating and

maintaining electronic catalogues that suit the buyers’

needs. This may include catalogues customised for the

buyers’ eProcurement applications, the marketplaces they

use, and the supplier’s website catalogues. Consequently

the transactions that must traverse the networkbetween

these geographically disperse parties are extremely complex

and the amount of data moved can vary significantly from

one application to another. To illustrate this point, consider

the data categories involved in the procurement process

(Refer to Figure 4 on page 6).

Figure 3 - End-to-end eProcurement Process

Procurement

Supply Chain Management

Customer Relations

Direct-

Spot Purchase

Direct-

Replenishment

MRO /

Shared

Auction /

Reverse Auction

VMI / Co-managed Inventory

CPFR

Promotions /

Deal Mgmt.

Market Data

Collection

Buyer

Aggregation

Returns

Allocation

Demand

Forecasting

Asset / Excess

Inventory

Sales

Due

Diligence

Market

Making

Contract

Management

Transpor-

tation

Shipment

Tracking

Supplier

Aggregation

Risk

Management

POs /

Releases

Auction /

Reverse Auction

e P r o c u r e m e nt

Contract Management

Customer Records

Price Lists

Sales Quotes/Sales Orders

Project Estimating

Sales/Project Invoicing

Credit Notes

Integrated Reporting

Capacity Forecasting

Contract Management

SPEC 2000/ANSI X12 Customer EDI

Materials Management

Supplier Records

Quote/Purchase Order Processing

Material Planning

Stock Status by Stock Type/Warehouse

Allocations Control

Consumable Kits

GRN Generation

Returns Picking/Packing List

Part Master Control (ATA configuration)

Multi-Warehouse/Stock Locations

Serialized/Life Control

Bar Coded Stock Control/DCS

Lot Control

Warranty Generation and Tracking

SPEC 2000/ANSIx12 Supplier EDI

Personnel

Employee Records

Labor Collection

Integrated Reporting

Time and Attendance Module

Training and Certifications

Scheduling & Planning

Work Center Setup

View/Update WIP

Capacity Planning/Forecasting

Repetitive Schedules

Finance Management

A/P Invoicing

Financial Holds

Applied Costing

WIP Journal to Cost of Sale

Period Details/Period End Control

Asset Depreciation

Fixed Assets

Project Costing

Job Cost Analysis

Detailed and Summary G/L

SPEC 2000/ANSIx12 Customer

MRO

Quotations

Planned Arrivals

Work Scope Details

Life Control/Full Process Package

Project Inspection

Maintenance Planning

Components

Tooling

Material Kitting

Project Control

Non-Routine Task Cards

WIP

Complex Assemblies

Rework

ATA Chapter – Section

Loaner Exchange

Repair Survey

Quality

Receipt Inspection Control

Technical Manual Control

Authorized Release Certificates

Tooling Calibration Tracking

Tooling Reporting

Administration

User Profiles

Permissions

Company Setup

Security

Figure 4 - eProcurement Data Categories

e P r o c u r e m e nt

As noted in Figure 4, the data categories involved in

eProcurement are not only voluminous, but also represent

complex processes, relationships, interdependencies,

potential inconsistencies in definitions, units of measure,

language differences, etc. These then result in the need for

the supporting applications software to provide sophisticated

edits/validations, pick-lists, and other system-level func-

tions, which contribute to extremely large and highly-complex

transaction sets. Consequently, eProcurement applications

and their associated transactions are among the most com-

plex and challenging from a networkdesign perspective.

N a t u r e o f

e p r o c u r e m e nt Tr a n s a c t i o n

eProcurement transactions also have highly complex network

traffic patterns and size characteristics, influenced by such

factors as the complexity of the client’s business processes,

geographic locations of buyers/suppliers, languages, edits,

validations, security, etc.

Typically, these transactions fit into one of the

following categories:

>> Ping-Pong Transactions:

numerous small packets

exchanged between servers in the enterprise

application’s n-tier architecture

>> Unidirectional Data Transfers:

consisting of a large

number of packets sent between servers or from

the server to the client, and a small number of

acknowledgement packets sent from the client or

server to another server

>> Hybrid Transactions:

hybrids consisting of ping-pong and

unidirectional bulkdata transfer transactions

Similarly, the characteristics of these transactions can

vary widely between the individual levels in the enterprise

application’s n-tier architectures.

Under most circumstances, these servers (refer to Figure 5)

will be co-located geographically on a clients’ local Ethernet

LAN, which greatly enhances performance and simplifies the

networkrequirements. One possible exception could be

locating a Web server closer to remote users. The complex

eProcurement processes for which the enterprise application

software is deployed, requires communications with suppli-

ers’ applications almost always located outside of clients’

campus LAN environments.

Figure 5 - Example of Transactions Between Servers in n-Tier Architecture

Order-Entry

Application

Server

Data Server

Storage

Requests
Responses

Web Server

0.8 KBS

0.2 KBS

Up to 105 KBS

Up to 6.1 Meg

Up to 112 KBS

Up to 191 Turns

Up to 1,017 Turns

Up to 112 Turns

KBS

e P r o c u r e m e nt

To illustrate this point, consider the following example

showcasing step-by-step, the completion of an order-entry

transaction initiated in the UK:

The UK-based buyer’s software application must commu-

nicate with a supplier’s inventory application based in

the U.S. in order to validate product availability.

The transaction is completed by receipt of a shipping

confirmation from a logistics provider based in the U.S.

Hence, the eProcurement process necessitates numerous

transactions between several software applications locat-

ed in different geographies, which must be transacted over

the WAN infrastructure. The physical location of the initi-

ating users has a minimal impact on the overall number of

transactions traversing the WAN in this example. It is the

geographic location of the other application’s servers that

will control the overall performance of the transactions

supporting the placement of the order.

Applications are typically interfaced with other applica-

tions using an Enterprise Application Integration (EAI)

technology such as those offered by Tibco, SeeBeyond

and others. Also, enterprise-class applications are inter-

faced to each other via application servers (refer to Figure

6). As a result, transactions that were designed and

optimised to interface with each application’s own Web

server (connected via a LAN) are now being executed over

the WAN between their respective application servers.

These transactions are referred to as A2A transactions.

Figure 6 - Application-to-Application (A2A) Transactions

Buy

er's

Order-Entry

Data Server

Storage

Requests
Responses

KBS

Web Server

0.8 KBS

0.2 KBS

Up to 105 KBS

Up to 6.1 Meg

Up to 112 KBS

Up to 191 Turns

Up to 1,017 Turns

Up to 112 Turns

Supplier s

Inventory

Application

Server

Data Server

Storage

Requests
Responses

Web Server

1.2 KBS

0.4 KBS

Up to 1.9 Meg

Up to 7.1 Meg

Up to 61 KBS

Up to 291 Turns

Up to 1,113 Turns

Up to 211 Turns

1.8

KBS

In this simple example, a number of dramatic observations

should be made:

>> Request and Response Transactions Can Vary

Widely in Size

— Enterprise-class application software

request transactions can be sub-kilobyte, whereas the

response transactions can be multiple megabytes in size.

This is a result of the great functional richness of the soft-

ware’s transactions, which is achieved by returning large

amounts of data and content. Moving this data back

upstream to the user’s client workstation is achieved by

numerous round-trips or "turns." These characteristics

create some very challenging demands upon the network,

which must accommodate the associated bandwidth and

latency effects.

>> Total Number of Transactions is Largely Independent of the

Number of Users

— The total number of transactions to

complete an eProcurement process is entirely a function of

process-complexity and not the number of actual system

users. Complex processes such as eProcurement can gen-

erate literally hundreds of transactions initiated by only a

single order-entry transaction, with the majority of transac-

tions being between applications to applications (A2A).

>> Co-location of Servers is Not Always Possible

— Since the

eProcurement process requires the software applications

to exchange data with other applications (often using EAI

technology) that are not on the campus LAN, A2A

transactions will generate WAN traffic between the

geographies where the servers are domiciled. This may

seem obvious, but the physical location of application

servers for interfaced applications is often overlooked

during system design activities.

>> Inter-Applications Transactional Characteristics

—

Finally, applications exchange transactions with other

applications by executing each other’s transaction sets,

which were designed and optimised by vendors for

communicating with their own Web server (co-located on

the campus LAN), not other vendors’ application servers

accessed over the WAN. As a result, A2A transactional

traffic may have characteristics that represent a vexing

challenge to the network group (refer to Figure 7).

Therefore, the first step in sizing and optimising a network

on behalf of an eProcurement process is to recognise that

the network is not only influenced by the direct users

accessing the procurement application, but also by the

complexity of the business processes, interfacing applica-

tions and the location of their servers. Additionally, as

previously noted, the transaction characteristics of software

vendor’s n-tier applications can vary widely in terms of sen-

sitivity to latency and bandwidth, depending upon the

specific vendor’s software modules and the data intensity

of the transactions being executed.

e P r o c u r e m e nt

Figure 7 - Profile of a Single Enterprise Application Transaction (Application Server Layer)

Transaction Profile

834 Bytes

Up to 6,431,215 Bytes

Up to 1,041 Turns

Request

Response

1-to-7,711 Ratio

e P r o c u r e m e nt

L a t e n c y S e n s i t i v e V e r s u s

B a n d w i d t h - S e n s i t i v e

Individual transactions may be latency-sensitive, band-

width-sensitive, or a combination of both. This means that

the WAN design must exhibit the performance characteris-

tics that best matches the individual transaction’s unique

needs. With latency-sensitive transactions, small varia-

tions in network latency, such as an alternate route that

adds up to 25 milliseconds (ms) of incremental latency,

will increase transaction total response time. Transactions

sensitive to latency are almost always challenging to tune

over the WAN because traditional tuning methods, such

as bandwidth upgrades and router prioritisation, will not

typically improve performance. The root-cause of such

latency often lies within the coding of the application’s

internal logic, as well as the information intensity of the

transactions’ edits, validations and other complex

business processes that are transparent to all but the

system architect. Finally, applications vendors design

and optimise their software for a local environment

where all servers in the n-tier architecture are co-located,

versus diverse locations connected via a WAN.

Ping-pong transactions are always latency sensitive as a

result of hundreds of data packets passing across the

WAN, with user response time slowed while the user waits

for all these packets to be exchanged. To illustrate this

point, consider a billing transaction that requires 500

ping-pong transactions across the WAN to execute.

A 25ms increase in latency (due to network issues,

client and server delays, or router delays) will result

in an additional 6-second delay (i.e. 250 transactions x

25ms/transaction). Therefore, if in the previous example

the order-to-bill process requires an interface transaction

to the billing application, this latency must be considered

in the network design and expectation for end-to-end

performance for the intended business process.

By contrast, bulk data transfer transactions are almost

always bandwidth-sensitive, since they involve a very large

number of data packets. Additional WAN bandwidth will

usually enable these packets to traverse the WAN more

quickly and improve response time. Therefore, transac-

tions containing large amounts of data such as photos,

billing history, detail product specifications, etc. can be

optimised by allocating greater bandwidth.

Infonet has extensive experience with eProcurement

implementations using SAP, Oracle and other applications

with which these are likely to be interfaced, and having

performed in-depth network profiles of numerous

off-the-shelf and custom applications can design

network solutions that are optimised to satisfy client’s

eProcurement business requirements. Infonet’s

Application-Defined Networking (ADN) approach and solu-

tions portfolio can be used to minimise the complex

impacts of latency and bandwidth through solutions

such as Asymmetric Committed Information Rate (CIR).

Infonet also offers Class of Service (CoS) features on three

separate global network platforms: Global Frame Relay,

IP VPN Secure and Global ATM. MNCs are increasingly

implementing CoS features in order to maximise the

performance of their enterprise applications. By working

closely with the client, the ADN methodology enables

Infonet to determine which VPN service (Global Frame

Relay, IP VPN Secure or Global ATM) is the right

solution for their operational environment.

E s t i m a t i n g B a n d w i d t h

The bandwidth requirements associated with deployments

of eProcurement applications can be reliably planned as

long as basic information is available regarding the appli-

cation’s transaction characteristics and the estimated

number of users. Infonet’s patent-pending Network

Analysis Program (NAP) methodology is used to measure

and profile enterprise applications, such as Oracle and SAP

e P r o c u r e m e nt

with the voluminous data captures resulting in very precise

transaction characterisations. These can then be used to

model expected performance prior to implementing or

upgrading the supporting application software.

In estimating bandwidth requirements for ping-pong trans-

actions, there are several key variables:

= the number of expected concurrently

active users at a location

= user think-time (the amount of time a user needs

between successive transaction executions)

= the number of packets per transaction in any one

direction

= the number of bytes per packet in any

one direction

= one-way network latency

Using these data points the calculation of estimated band-

width in any one direction is as follows:

Estimated Bandwidth=

(8 bits/byte) x (N) x (K) x (M) ÷ (K x P + T) bits/sec

The estimated bandwidth requirements for such a transac-

tion between two geographic locations is then derived by

calculating the maximum of the estimated bandwidth in

both directions. That is, the time between successive

transactions generated by a single active user is

(K) x (P) + T, because (K) x (P) is the total network latency

for the K packets (assuming a one-to-one ping-pong

exchange), and T is the time between transactions. During

this time (i.e. K x P + T), the user will have submitted, in

the specified direction, K x M x 8 bits of data. Finally, the

number of active users (N) is applied to derive the total

estimated bandwidth for the intended user population.

Expanding upon the original example, assume that the

buyer physically located in the UK initiates order-entry

transactions (server domiciled in the UK), which exchange

transactions with the supplier’s SAP inventory application

domiciled in the U.S.). Such an example would result in a

ping-pong effect for both application’s transactions, with

the variables being as follows:

= 25 active users

= 120,000 milliseconds

(2 minutes, which is common)

= 100 packets inbound, 120 packets outbound

= 60 bytes per inbound packet, 200 bytes

per outbound packet

(plus 48 bytes for the WAN overhead)

= 150ms (one-way latency)

Therefore, 43Kbits/sec would be the peak bandwidth

usage between the UK and the U.S. for the SAP inventory

validation. Furthermore, if a 70 percent maximum planned

utilisation threshold were to be assumed in engineering

this circuit, the bandwidth required would be 43Kbits/sec

divided by 0.7, or approximately 64Kbits/sec.

Hence, the end-to-end performance of the eProcurement

process is a function of not only the initiating request tran-

sition, but also all of the other transactions included in the

business process workflow rules, such as the validation of

inventory. The network design must adequately address

all of these factors in order to yield a predictable and

reliable user-experienced response time.

The bottom line is that in order to accurately estimate the

bandwidth requirements for eProcurement these interface

transactions must also be taken into consideration, as

well as the network profile or application characteristics

(e.g. latency) of the applications with which SAP, Oracle,

etc. is interfaced. The geographic locations of buyers/

suppliers and the servers on which their interfaced

e P r o c u r e m e nt

applications are running must be clearly identified and

the business processes understood. Infonet’s ADN

methodology incorporates these factors into the design of

clients’ networks and further refines bandwidth require-

ments, based upon unique insights into the performance

characteristics of the supporting technologies.

(8 bits/byte) x (25 users) x (100 packets) x (108 bytes/packet)

(100 packets) x (150 milliseconds) + 120,000 milliseconds

= 16 Kbits/second

The estimated inbound bandwidth required to support the user-initiated order-entry transactions, then, is approximately

16Kbits/sec, calculated as follows:

Similarly, the estimated outbound bandwidth is approximately 43Kbits/sec, calculated as follows:

(8 bits/byte) x (25 users) x (120 packets) x (248 bytes/packet)

(120 packets) x (150 milliseconds) + 120,000 milliseconds

= 43 Kbits/second

Figure 8 - A2A WAN Transaction

Order-Entry User

SAP Order-Entry

Supplier

Inventory

A2A

Transaction

Worldwide Headquarters

Asia-Pacific

391 A Orchard Road

#13-08 Ngee Ann City

Tower A

Singapore 238873

Tel: +65 838 5215

Fax: +65 734 5223

Europe, Middle East & Africa

350/358 Avenue Louise

Box 3

B-1050 Brussels, Belgium

Tel: +32 2 627 39 11

Fax: +32 2 640 97 41

Latin America

Mardoqueo Fernandez 128

Piso 7

Providencia, Santiago, Chile

Tel: +56 2 368 9400

Fax: +56 2 368 9415

North America

2160 East Grand Avenue

El Segundo, California

90245-1022 usa

Tel: +1 310 335 4700

Fax: +1 310 335 4507

An ISO Registered Firm

Infonet, DialXpress, Global Connect and The World Network are registered trademarks of Infonet Services Corporation. DialXpressway, PerspeXion and Insight Matters are trade-
marks of Infonet Services Corporation. Other product names that may be used herein are for identification purposes only and may be trademarks of their respective companies.
Copyright © 2002, Infonet Services Corporation. All rights reserved. 01/03

MP-WP011-01.

S U M M A R Y

eProcurement initiatives make tremendous demands of an IT organisation’s network

infrastructure. In order to ensure the success of these business-critical processes, it’s

crucial that the networking group is involved at an early enough stage, so that they may

plan the deployment of a reliable, scalable, resilient and intelligent infrastructure. This

will help ensure that the eProcurement initiative meets the highest expectations of busi-

ness managers, users, extranet partners, interfaced applications, etc. Infonet Services

Corporation has unique insights into the network performance characteristics of enter-

prise-class software, gained through years of profiling these applications in clients’

real-world environments, and designing network solutions to optimise performance.

Networks designed using Infonet’s ADN approach represent the best value to multi-

nationals seeking to optimise their eProcurement processes and yield ROI from their

technology investments.

A b o u t I n f o n e t

Infonet Services Corporation, known for its quality of service, is a leading provider of

managed network communications services for nearly 3,000 multinational enterprises.

Employing a unique consultative approach, Infonet offers integrated solutions

optimising the complex relationship between enterprise applications and the global

network. Extensive project management capabilities are the foundation for the services

and solution offerings (broadband, Internet, intranet, multimedia, remote and local

access, provisioning, application and consulting services) positioning Infonet as the

ideal single-source partner for multinationals. In particular, Infonet IP VPN solutions

offer multinationals a unique combination of Private and Public IP services as well as

a full set of Managed Security Services.

Rated "Best in Class" overall in Telemark’s survey of Global Managed Data Network

Services, Infonet has also won "Best Customer Care" and "Best Carrier" at the World

Communication Awards. Founded in 1970, Infonet owns and operates The World

Network

, accessible from more than 180 countries, and provides local service

support in over 70 countries and territories.

Infonet's stock is traded on the New York and Frankfurt Stock Exchanges under the

symbol IN. Additional information about the company is available at www.infonet.com.

Wyszukiwarka

Podobne podstrony:

więcej podobnych podstron