WO2001082021A2 - Systeme et procede de simplification de la negociation de largeur de bande - Google Patents

Systeme et procede de simplification de la negociation de largeur de bande Download PDF

Info

Publication number
WO2001082021A2
WO2001082021A2 PCT/IB2001/000917 IB0100917W WO0182021A2 WO 2001082021 A2 WO2001082021 A2 WO 2001082021A2 IB 0100917 W IB0100917 W IB 0100917W WO 0182021 A2 WO0182021 A2 WO 0182021A2
Authority
WO
WIPO (PCT)
Prior art keywords
buyer
router
exchange
order
seller
Prior art date
Application number
PCT/IB2001/000917
Other languages
English (en)
Other versions
WO2001082021A3 (fr
Inventor
Alexander Mashinsky
Original Assignee
Alexander Mashinsky
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alexander Mashinsky filed Critical Alexander Mashinsky
Priority to AU56601/01A priority Critical patent/AU5660101A/en
Publication of WO2001082021A2 publication Critical patent/WO2001082021A2/fr
Publication of WO2001082021A3 publication Critical patent/WO2001082021A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/64—Distributing or queueing
    • H04Q3/66—Traffic distributors
    • H04Q3/665—Circuit arrangements therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/787—Bandwidth trade among domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1313—Metering, billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13141—Hunting for free outlet, circuit or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13148—Maximum profit routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13332—Broadband, CATV, dynamic bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Definitions

  • the invention relates to a system and method for trading telecommunications services. More specifically, the invention relates to a system and method for matching buyers and sellers of Internet bandwidth services and for controlling the provision of such services to efficiently utilize network resources.
  • the Internet is a global system of interconnected physical networks including local area networks (LANs), wide area network (WANs), and routers that ,. connect two or more such networks.
  • a router is typically a special purpose computer that transmits and receives data packets, called, datagrams, that are formatted in accordance with a suite of internetworking'protocols including .the Transmission Control ⁇ • . Protocol/Internet Protocol or TCP/IP.
  • These internetworking protocols allow computers; on different networks, called hosts, to communicate with each other even if the two networks use incompatible hardware and message formats.
  • Each host comprises communications hardware and software ' that interfaces with the particular physical network or networks to which the host attaches.
  • Each data packet comprises a header and a payload.
  • the header comprises the Internet Protocol (IP) address of the first host, the IP address of the second host, and additional information necessary to provide proper routing of the datagram.
  • IP Internet Protocol
  • the payload comprises a portion of the message to be sent.
  • the first host cannot transmit the datagram directly to the second host named in the datagram header. Rather, each datagram must be routed via one or more routers or through other computers. Collectively, these routers or other computers define a route connecting the two hosts. Thus, for example, if two networks are connected by a single router, the first host may transmit the datagram to the router which then forwards the datagram to the second host.
  • the route connecting the two hosts may comprise several "hops.”
  • a first host 102 connected to a first physical network 104 and a second host 106 connected to a second physical network 108 may be connected via a first route (route A) that comprises four hops.
  • Route A To transmit a datagram from host 102 to host 106, host 102 creates the datagram and transmits it to router 110 which then forwards the datagram to the next router in the route, router 112.
  • Router 112 forwards the datagram to router 114 which forwards the datagram to its ultimate destination, host 106, through network 108.
  • each router in the route receives the datagram, it forwards the datagram to the next router or other computer in the route until the datagram reaches its ultimate destination host 106.
  • datagrams transmitted by host 102 to host 106 in the internet shown in Fig. 1 may be routed via the route defined by routers 110, 112, 114 (route A), or by routers 110, 118, 116 (route B), or routers 110, 116 (route C): formulate . •
  • That dedicated connection carries 100% of the information transmitted between those two points. Consequently, if that connection is disabled, communication ceases completely and an entirely new route must be formed and assigned.
  • Internet communications are limited by available bandwidth. As Internet usage has grown, it has become more important for Internet service providers to ensure that they have access to adequate bandwidth resources to satisfy the needs of their customers. Accordingly, a number of large Internet service providers have grouped together into private peering arrangements forcing smaller Internet service providers to pay a high premium for bandwidth or be relegated to low bandwidth service.
  • bandwidth purchasers must purchase bandwidth based on their best estimate of their future bandwidth needs. When those estimates are inaccurate, the purchaser may find itself unable to use some of the purchased bandwidth or facing a shortage of bandwidth to meet its demand.
  • the disclosed system addresses these drawbacks of the prior art by providing a spot market for purchase, sale, and delivery of Internet bandwidth and by facilitating the efficient management of Internet bandwidth use so as to minimize cost and maximize other business objectives.
  • bandwidth is traded via an
  • - exchange comprising a server and a router.
  • Buyers and sellers submit buy and selLorders . ⁇ for.bandwidth to the exchange server.
  • the exchange server matches the buy and. sell* . . ' orders. and generates a route plan for the exchange router on the basis of these matched orders.
  • the route plan causes the exchange router to route traffic from each buyer to the seller with whom it was matched.
  • Fig. 1 is a block diagram illustrating a prior art architecture comprising a plurality of distinct physical networks connected by routers to create an internet
  • Fig. 2 is a block diagram illustrating an architecture of a preferred embodiment of the present system
  • Fig. 3 is a block diagram illustrating in more detail a portion of the system shown in Fig. 2;
  • Fig. 4 is a flowchart depicting a preferred embodiment for establishing a customer base
  • Fig. 5 is a flowchart depicting a first preferred trading embodiment of the present invention
  • Fig. 6 is a preferred embodiment of a seller's template for inputting a sell order
  • Fig. 7 is a preferred embodiment of a buyer's template for inputting a buy order
  • Fig. 8 is a schematic diagram of a preferred embodiment of a market book created by the present system.
  • Fig. 9 is a flowchart depicting a preferred embodiment for matching buy orders and sell orders
  • Fig. 10 is a schematic diagram of a preferred embodiment of the buy side of the market book of Fig. 8;
  • Fig. 11 is a schematic diagram of a preferred embodiment of the sell side of the market book of Fig. 8;
  • Fig. 12 is a schematic diagram of a preferred embodiment of a list of sell
  • Fig. 13 is a- schematic diagram of a preferred embodiment of the match list of the market book of Fig. 8; ⁇ " .' ⁇ ⁇
  • Fig. 14 is a block diagram illustrating a first preferred embodiment of an aspect of the architecture of the present system
  • Fig. 15 is a block diagram illustrating a second preferred embodiment of the aspect of the architecture of the present system.
  • Fig. 16 is a block diagram illustrating a third preferred embodiment of the aspect of the architecture of the present system
  • Fig. 17 is a flowchart depicting a second preferred trading embodiment of the present invention
  • Fig. 18 is a chart depicting a preferred embodiment of class definitions employed by the present invention.
  • Fig. 19 is a preferred embodiment of a seller's input template
  • Fig. 20 is a preferred embodiment of a buyer's input template
  • Fig. 21 is a flowchart depicting a third preferred trading embodiment of the present invention
  • Fig. 22 is a block diagram illustrating a preferred embodiment of a multiple-exchanges embodiment of the present invention
  • Fig. 23 is a flowchart depicting a multiple-exchanges trading embodiment of the present invention
  • Fig. 24 is a block diagram of a preferred graphical user tool for use in the present system
  • Fig. 25 is a flowchart depicting a preferred embodiment for using the graphical user tool.
  • Fig. 26 is a series of views depicting a preferred embodiment of the graphical images that may be displayed to a user during use of the graphical user tool.
  • Fig. 2 is a block diagram illustrating a preferred embodiment of the present system.
  • the present system preferably comprises a plurality of Internet users 202.
  • Internet users 202 each connect to a respective Internet service provider 204 via respective communication links 206.
  • Communication links 206 may, for example, comprise a telephone link provided by the user's Local Exchange Carrier 208 (LEC) or Competing Local Exchange Carrier (CLEC) 210.
  • Internet users 202 may connect directly to the exchange 218 via communication line 220 without going through an Internet service provider 204.
  • the present system further comprises a plurality of portals 212 ⁇ S P owned, typically, by ISPs 204.
  • ISPs 204 provide Internet access to their users 202 by transmitting and receiving information from and to users 202 via portals 212 ⁇ sp.
  • Each portal 212 18 p may have associated with it a web server 214K P that hosts a web site comprising a home page that is displayed to the user when the user logs on to the
  • the architecture shown in Fig. 2 further comprises additional portals 212OTH operated by entities that are not necessarily Internet service providers (e.g., Yahoo (TM)). Each such portal 212 0 TH may also have associated with it a web server 214OTH that hosts a web site comprising a home page displayed to the user when the user "goes to" the website.
  • entities that are not necessarily Internet service providers (e.g., Yahoo (TM)).
  • Each such portal 212 0 TH may also have associated with it a web server 214OTH that hosts a web site comprising a home page displayed to the user when the user "goes to" the website.
  • FIG. 2 Also shown in Fig. 2 are an additional plurality of web servers 214R each of which may host a web site.
  • Web servers 214 R may, for example, be operated by retailers or other entities that wish to provide information, products, or services to users 202 via the Internet.
  • users 202 may "surf" the Internet and reach the home page of a desired web site by either clicking on a link to the site displayed on a page that they are viewing or by entering on a command line the universal resource locator (URL) of the desired web site's home page.
  • URL universal resource locator
  • Each portal 212 preferably comprises one or more routers for receiving and routing Internet datagrams in accordance with a route plan.
  • Portals 212 are linked to each other and web servers 214 via respective communications links 216.
  • portals 212 and web servers 214 are further connected to an exchange 218 via respective communication links 220.
  • lines 220 in fact represent two distinct links: a first traffic- carrying link for transmitting IP datagrams to and from exchange 218, and a second signaling link for transmitting control and signaling information to and from exchange 218, as described in more detail below.
  • Fig.: 3 is a. block diagram illustrating a preferred embodiment of exchange 218.
  • exchange 218 preferably comprises a plurality of exchange routers 222 connected to portals.212,and web servers 214 via communication links 220(a).
  • exchange 218 preferably comprises an exchange server 224 that is connected to routers 222 via communication links 226 and to portals 212 and web servers 214 via communication links 220(b).
  • Exchange server 224 preferably comprises a timer 228 used in certain operating embodiments as described in more detail below.
  • the above-described architecture facilitates the trading and efficient usage of Internet bandwidth, as described below.
  • system operation comprises several aspects: First, exchange 218 establishes a relationship with a plurality of entities that become its customers. Second, exchange 218 collects buy and sell orders for communications bandwidth from these entities and matches them.
  • exchange 218 uses the matched orders to create route plans for exchange routers 222 that implement the matched trades.
  • exchange 218 routes traffic from buyers to sellers via exchange routers 222.
  • the first aspect of system operation is described in section B below.
  • the second, third, and fourth aspects of system operation are described in section C below.
  • exchange 218 enters into a contractual arrangement with each of a plurality of entities. These entities typically include suppliers and users of communications bandwidth, such as portals 212 and web servers 214.
  • exchange 218 may also establish contractual relationships with commodities traders, market makers, and others who help maintain market liquidity by buying and selling bandwidth via exchange 218, but who do not themselves expect to provide or use the communications services they buy or sell.
  • each entity, that wishes to become a customer thereof include terms specifying the -rights ;. -• .and-responsibilities i ⁇ f each, party to the contract.
  • each customer establishes one or more physical connections with exchange 218.
  • this physical connection preferably comprises two components, a traffic-carrying component and a signaling component.
  • the traffic carrying component preferably comprises one or more links 220(a) connecting one or more routers belonging to the customer to one or more of exchange routers 222.
  • the signaling component preferably comprises a link 220(b) connecting the customer to exchange 218 for carrying information concerning market information and the customer's available resources and needs, as described in more detail below.
  • the traffic-carrying connection 220(a) may comprise any known type of communication link such as electrical, optical, wireless, etc.
  • the protocol for transmitting packets from the customer to exchange routers 222 may be any known protocol such as TCP.
  • exchange 218 is provided with means for recognizing the type of hardware connection and protocol connecting the customer to exchange 218 and translating these appropriately so that the customer's traffic may be carried by any other customer of exchange 218.
  • FIG. 5- A first preferred trading embodiment is now described in connection with Fig. 5-. As will be explained in* detail below; this. preferred embodiment employs timer 228 to define a plurality of trading cycles. At the conclusion of each trading cycle, exchange 218 matches pending buy and sell orders and uses the matched orders to create route plans for exchange routers 222.
  • exchange server 224 sets timer 228 to a time T.
  • timer 228 begins to count down from time T to zero.
  • the trading cycle concludes.
  • Time T is preferably chosen as a function of the processing speed of exchange server 224, as well as the number of exchange routers 222 and current trading volume.
  • time T is preferably greater than the amount of time required by exchange server 224 to match all pending buy and sell orders and update the route plans for exchange routers 222 so that these tasks may be completed before the end of the next trading cycle.
  • a trading cycle of approximately 5 minutes may be desirable.
  • different values may make a cycle time as short as approximately 10 seconds appropriate.
  • each portal 212 that wishes to sell Internet bandwidth via exchange 218 transmits a sell order comprising a plurality of parameters to exchange server 224 via a communication link 220(b), as shown in step 506.
  • the plurality of parameters may comprise: termination location(s); origination location(s); duration; time of day; day of week; minimum price; capacity; maximum latency; maximum packet loss; circuit availability; protocol; and hardware.
  • the termination location(s) parameter specifies the location or locations at which traffic may be terminated under the terms of the sell order.
  • this parameter may be specified either as a physical termination location (e.g., a specific portal 112), as a plurality of physical termination locations (e.g., any one of a set of 250,000 IP addresses), or as a virtual destination location (e.g., termination to some AOL router without specifying which):
  • this parameter may be specified as a virtual destination with some physical limitation.
  • the termination location(s) may specify that traffic must be delivered to an AOL router in the United States without specifying the specific physical router.
  • the seller may specify this parameter to be "any location.” In this case, traffic may be terminated at any location under the terms of the sell order.
  • the origination location(s) parameter specifies the location or locations from which traffic may originate under the terms of the sell order.
  • the origination location of a data packet may be identified by examining, for example, the sender address in the data packet.
  • this parameter may be specified either as a physical origination location (e.g., a specific portal 112), as a plurality of physical origination locations (e.g., any one of a set of 250,000 IP addresses), or as a virtual origination location (e.g., origination from some AOL router without specifying which).
  • the origination location may be specified as a virtual location with some physical limitation.
  • the origination location may specify that traffic must originate from an AOL router in the United States without specifying the specific physical router.
  • the seller may specify this parameter to be "any location.” In this case, traffic may originate from any origination location under the terms of the sell order.
  • the duration parameter specifies the calendar period for which service is offered.
  • the time-of-day parameter specifies the time of day (typically in hours Universal time) for which service is offered.
  • the day-of-week parameter specifies the days of the week for which service is offered.
  • the sell order may specify the particular days of the week for which service is offered (e.g., the order may offer service for Sunday, Tuesday, and Wednesday only) or may offer service for business days, weekend days, holidays, etc.
  • the minimum-price parameter specifies the minimum price at which service is offered.
  • the capacity parameter specifies the maximum capacity offered under the terms of the sell order.
  • the maximum-latency parameter specifies the maximum latency for packets transmitted under the terms of the sell order.
  • the maximum-packet-loss parameter specifies the maximum packet loss rate for packets transmitted under the terms of the sell order.
  • the circuit-availability parameter specifies the minimum amount of time that a circuit will be available to deliver traffic (typically as a percentage of the entire period specified by the duration, time of day, and day of week specified in the sell order) under the terms of the sell order.
  • the protocol parameter specifies the protocol used to carry packets over the sellers connection 220(a) to exchange 218.
  • the hardware parameter specifies the type of hardware connection that connects the seller to exchange 218.
  • the sell order may also comprise additional parameters. These may include: preferred buyers; and my network status;
  • the preferred-buyers parameter specifies entities whose traffic the seller would prefer to carry. For example, the seller might prefer to carry the traffic of a particular entity if the seller's peering arrangement with the entity requires it to carry a certain amount of the entity's traffic.
  • the my-network-status parameter specifies conditions for the sell order relating to the operating condition of the seller's network. For example, the seller may specify a first price for carrying traffic if its network congestion is below a certain level, and a second price for carrying traffic if its network congestion is above that level.
  • a first price for carrying traffic if its network congestion is below a certain level For example, the seller may specify a first price for carrying traffic if its network congestion is below a certain level, and a second price for carrying traffic if its network congestion is above that level.
  • template.600 ⁇ preferably comprises a plurality of fields for entering information concerning the parameters described above. In a preferred embodiment, some of the entries shown in Fig.
  • the seller's computer 6 may be automatically filled in by the seller's computer.
  • the seller's computer may preferably fill in the hardware and protocol entries automatically since they do not change from order to order.
  • the seller's computer may be adapted to automatically fill in default values for one or more entries based on past sell orders submitted by the seller. These default entries may then be adopted by the seller or changed if the seller wishes.
  • fields of the sell order that relate to the quality of the offered service may be populated or verified by the exchange on the basis of historical quality information collected by the exchange as described below.
  • each portal 212 that submitted a sell order downloads information concerning its available communications resources and needs to exchange server 224.
  • information is downloaded to exchange server 224.
  • exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources.
  • exchange server 224 is given access to portal 212's confidential communications information
  • additional confidentiality features may preferably be associated with the collection, storage, and usage of this data to ensure that the owner of portal 212 feels comfortable releasing the data to exchange 218 and to ensure that the data is not misused or obtained by entities that are not entitled to it.
  • these additional safety features may include transmission via stronger encryption techniques than those that may be employed in connection with other system transmissions.
  • these safety features may comprise storage of a portal 212's proprietary data in a secure location with limited access by specified personnel. The entity
  • each portal 212 or web server 214 that wishes to purchase IP bandwidth (i.e., wishes to pay another entity to route its traffic to a particular destination), transmits a buy order to exchange server 224 via a respective communication link 220(b).
  • the buy orders may take the form of continuous limit orders.
  • a continuous limit order is an order by a buyer to purchase, on a continuing basis, any IP bandwidth meeting the parameters specified in the buy order as long as such purchase does not conflict with some other business objective specified by the buyer to exchange server
  • a buy order may comprise the following parameters: termination location(s); origination location(s); time of day; day of week; maximum price; minimum capacity; maximum latency; maximum packet loss; minimum circuit availability; protocol; and hardware.
  • the termination location(s) parameter specifies the termination location or locations for service is requested. As noted, this parameter may be specified as one or more physical termination locations, a virtual termination location, a virtual destination with some physical limitation, or as "any location”.
  • the origination location(s) parameter specifies the origination location or locations for which service is requested. As noted, this parameter may be specified either as one or more physical origination locations, a virtual origination location, a virtual location with some physical limitation; or as '-'any location.”
  • the time-of-day parameter specifies the time of day (typically in hours Universal time) for which service is requested.
  • the day-of-week parameter specifies the days of the week for which service is requested. As noted, this parameter may specify each day separately (e.g., Sunday,
  • the maximum-price parameter specifies the maximum price that the seller is willing to pay for service.
  • the minimum-capacity parameter specifies the minimum capacity acceptable to the buyer under the terms of the buy order.
  • the maximum-latency parameter specifies the maximum latency acceptable to the buyer.
  • the maximum-packet-loss parameter specifies the maximum packet loss rate acceptable to the buyer.
  • the minimum-circuit-availability parameter specifies the minimum amount of time that the circuit must be available to deliver traffic (typically as a percentage of the entire period specified by the duration, time of day, and day of week specified in the buy order) under the terms of the buy order.
  • the protocol parameter specifies the protocol used to carry packets over the buyer's connection 220(a) to exchange 218.
  • the hardware parameter specifies the type of hardware connecting the buyer and exchange 218 (e.g., ATM, SDH, etc.).
  • the buy order may also comprise additional parameters. These may include: preferred sellers; and my network status;
  • the preferred-sellers parameter specifies entities whose service the buyer would prefer to use. For example, the buyer might prefer to have its traffic carried by a particular entity if , under the buyer's peering arrangement with the entity, the entity is required to route a certain amount of the buyer's traffic.
  • the my-network-status parameter specifies conditions for the buy order relating tosthe operating condition of the buyer' s network.. For example, the buyer may specify a first price that it is willing to pay for service if its network congestion's below a certain level, and a second price for carrying traffic if its network congestion is above that level.
  • buyers may submit buy orders that specify a duration during which service is desired.
  • buy orders that specify a duration during which service is desired.
  • all buy orders discussed in the remainder of this specification will be assumed to be continuous limit orders unless otherwise noted. It will be understood, however, that the discussion below may be tailored to apply to buy orders that specify a duration.
  • Fig. 7 illustrates a suitable arrangement for such a template.
  • template 700 preferably comprises a plurality of fields for entering information concerning the parameters described above.
  • some of the entries shown in Fig. 7 may be automatically filled in by the buyer's computer. For example, when the buyer has only a single traffic-carrying connection to exchange 218, the buyer's computer may preferably fill in the hardware and protocol entries automatically since they do not change from order to order.
  • the buyer's computer may be adapted to automatically fill in default values for one or more entries based on past buy orders submitted by the buyer.
  • each portal 212 and web server 214 that submitted a buy order downloads information concerning its available communications resources and needs to exchange server 224.
  • this information is downloaded to exchange server 224.
  • exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources. Since, in this preferred embodiment, exchange server 224 is given access to portal 212's- confidential communications, information, additional confidentiality features may preferably be associated with the collection, storage, and usage of this data as described above.
  • step 514 timer 228 expires. At that time, two events occur. First, the system branches back to step 502 to reset timer 228 and begin a new trading cycle.
  • exchange server 224 begins a series of steps to match current sell orders and buy orders and update the route plans of exchange routers 222 (steps 516-522).
  • exchange server 224 uses the received sell orders and buy orders to update a market "book" 800 that provides a snapshot of the market for Internet bandwidth services.
  • market book 800 is schematically illustrated in Fig. 8.
  • market book 800 preferably comprises three sections: a sell side 802, a buy side 804, and a match list 806.
  • Sell side 802 stores all pending unfilled sell orders received by exchange server 224 during this and previous trading cycles.
  • Buy side 804 stores all pending unfilled buy orders received by exchange server 224 during this and previous trading cycles.
  • match list 806 stores a list of matched buy and sell orders. Each entry in the list represents a set of market and network conditions under which the buyer and seller have agreed to route the buyer's traffic, as described in more detail below.
  • exchange server 224 matches sell orders from sell side 802 to buy orders from buy side 804 to create match list 806.
  • a preferred algorithm for matching sell orders and buy orders will now be described in connection with Fig. 9.
  • exchange server 224 determines whether the market is a buyer's market (i.e., supply exceeds demand) or a seller's market (i.e., demand exceeds supply). This determination may significantly affect the algorithm used to match buy orders and sell orders. In particular, it should be recognized that in a buyer's market it is typically not necessary to prioritize the buy orders before matching them, because sell side 802 contains adequate capacity to satisfy all of the demand represented by buy side 804. In a seller's market, by contrast, buy orders are preferably prioritized before matching because there is inadequate supply to fill every buy order.
  • buy orders when prioritization of buy orders is necessary, they may be prioritized first on the basis of price, and then on the basis of other parameters such as minimum acceptable capacity and maximum acceptable latency. Buy orders specifying higher tolerance levels are preferably given higher priority since such orders will remain matchable despite fluctuations in latency, capacity, etc. in sell orders submitted by sellers. Alternatively, buy orders may be prioritized on a first-come first-served basis. Thus, the buyer who first submitted a bid matching one or more sell-orders may be allocated bandwidth specified in those orders before other buyers.
  • exchange server 224 may identify all buy orders received within a specified period of time (e.g., one second, one minute, 10 minutes, etc.) and allocate available bandwidth to those buy orders in a manner designed to maximize the total amount of bandwidth sold. Also, exchange server 224 may employ an auction methodology, such as, for example, a Nickrey-style auction, for allocating available bandwidth between competing buy orders.
  • a specified period of time e.g., one second, one minute, 10 minutes, etc.
  • exchange server 224 may employ an auction methodology, such as, for example, a Nickrey-style auction, for allocating available bandwidth between competing buy orders.
  • step 902 exchange server 224 determines that there exists a buyer's market
  • the system proceeds to step 904 where exchange server 24 identifies every sell order that matches a buy order, as will be described below.
  • step 902 exchange server 224 determines that there exists a seller's market
  • the system proceeds to a processing branch (not shown) where buyer's orders would be prioritized.
  • the above analysis may be applied on a submarket by submarket basis. For example, demand for a particular type or quality of service may outstrip supply (traffic for determination at APL), while demand for another type or quality of service may be inadequate to fill the available supply.
  • the system may be designed to distinguish in step 902 between buyer's submarkets and seller's submarkets, and to treat each such submarket independently in accordance with the principles described above.
  • step 904 exchange server 224 identifies, for each pending buy order, every sell order on sell side 802 that matches the buy order.
  • Fig. 10A is an illustrative example of buy side 804 before step 904 is performed.
  • Exchange server 224 preferably sorts the received buy orders by, e.g., termination destination and develops a data structure comprising information concerning buy orders that it has received.
  • the data structure shown in Fig. 10A will typically constitute only a fraction of the total data structure created by exchange server 224 to categorize unfilled buy orders.
  • Buy side 804 shown in Fig. 10A comprises five buy orders 1002-1010.
  • buy orders 1002-1010 comprise the preferred parameters specified above. It will be recognized, however, that the principles elucidated in this example may be applied to buy and sell orders containing additional or other parameters.
  • FIG. 11 A is an illustrative example of sell side 804 before step 904 is performed.
  • Exchange server 224 preferably sorts the received information by, e.g., termination destination and develops a data structure comprising information concerning the available bandwidth for sale specified in unfilled sell orders that it has received.
  • the data structure shown in Fig. 11A will typically constitute only a fraction of the total data structure created by exchange server 224 to categorize unfilled sell orders.
  • Sell side 804 shown in Fig. 11A comprises seven sell orders 1102-1114.
  • sell orders 1102-1114 comprise the preferred parameters described above. It will be recognized, however, that the principles elucidated in this example may be applied to buy and sell orders containing additional or other parameters.
  • exchange server 224 identifies, for each buy order, every sell order that meets the buy order's criteria.
  • exchange server 224 identifies sell orders 1;104, 1106;: and 1-112 as satisfying buy order 1002 and sell orders 1102, 1108, and lllO as not satisfying buy order 1002.
  • FigM2A illustrates the list of orders that exchange server 224 would create in performing step 904 for buy order 1002 in this illustrative example.
  • exchange server 224 determines whether there are any buy orders that do not have matching sell orders. It should be noted that because, as described above, bandwidth oversupply is the typical case in the present state of the art, one would not expect a buy order to have no matching sell orders unless it specified a price below market price (e.g. buy order 1006). In any event, if no matching sell orders are identified for a particular buy order, the system proceeds to step 916 to inform the buyer that it must modify its buy order if it wishes to purchase bandwidth via the exchange, as described in more detail below.
  • exchange server 224 proceeds to step 908 where it prioritizes the sell orders identified as satisfying the buy order on the basis of one or more parameters.
  • the identified sell orders may first be prioritized on the basis of price and then on the basis of other parameters.
  • the other parameters may include specificity of address block offered, latency, packet type, stream type, specifics such as UDP, TCP, duration, day of week, and time of day.
  • the order of parameters employed by exchange server 224 to prioritize the list of satisfying sell orders may be specified by the buyer. For example, if the buyer who submitted buy order 1002 specified that it wishes matching sell orders to be prioritized on the basis of price, latency, and capacity, in that order, then exchange server 224 will prioritize sell orders 1104, 1106, 1112, on this basis.
  • Fig. 12B illustrates the prioritized list of sell orders that would be created for buy order 1002 by exchange server 224 in performing step 908 in this illustrative example.
  • exchange server 224 matches buy order 1002 to the highest rated sell order in the prioritized list and enters the match on match list 806 of market book 800.
  • the system may allocate the sell order's capacity to one or more of the buy orders
  • the system. may employ a protocol that allocates 5 available ; bandwidth to buyers on a first-come first-served. basis..'
  • the first buyer to submit a bid . matching one or more sell-orders may be allocated the available bandwidth specified, in ..- those orders.
  • it may employ a protocol that identifies all buy orders received within a specified period of time (e.g., one second, one minute, 10 minutes, etc.) and allocates available bandwidth to those buy orders in a manner designed to maximize the total amount of bandwidth sold.
  • the protocol may employ an auction methodology such as, for example, a Nickrey-style auction, for allocating available bandwidth between competing buy orders.
  • Fig. 13 represents the state of match list 806 after exchange server 224 performs step 910.
  • exchange server 224 updates buy side 804 to reflect the fact that buy order 1002 has been matched. It should be noted that because buy order 1002 is, in this preferred embodiment, a continuous limit order, exchange server 224 does not delete or otherwise modify buy order 1002 other than to indicate that the order has been matched for this trading cycle.
  • Fig. 10B represents the state of buy side 804 after exchange server 224 performs step 912 for buy order 1002 in this illustrative example.
  • exchange server 224 updates sell side 802 to reflect the match.
  • exchange server 224 updates the capacity field of sell order 1106 to indicate the decreased available capacity as a result of the commitment to carry the traffic specified in buy order 1002.
  • buy order 1002 asked for 20 Mb/s of capacity
  • sell order 1106 offered 100 Mb/s of capacity.
  • exchange server 224 decreases the offered capacity in sell order 1106 from 100 Mb/s to 80 Mb/s to indicate that 20% of the capacity offered in sell order 1106 has been allocated.
  • Fig. 11B represents the state of sell side 802 after exchange server 224 performs step 914.
  • exchange server 224 determines that there are no matching sell orders for a buy order, the system branches to step 916 where exchange server 224 transmits a message to the buyer that its order cannot be matched under current market conditions, and recommends that the buyer modify its buy order.
  • the message may be transmitted by e-mail.
  • message may be transmitted as a pager message.
  • an employee of the buyer may be provided with a two-way pager that permits the buyer to immediately respond to the pager message with a modified order. ' -
  • the system may recommend a particular modification that would improve the buyer's likelihood of matching with a sell order.
  • exchange server 224 may accept a modification to the buyer' s buy order during the trading cycle and attempt to immediately match the modified buy order to ensure that the buyer does not need to go an entire trading cycle without receiving service.
  • exchange server 224 uses matched list 806 to create a route plan for each exchange router 222.
  • a preferred embodiment for creating these route plans is now described in connection with Fig. 14. This description will continue to employ the illustrative example described above in which buy order 1002 was matched to sell order 1106. It will be assumed that buy order 1002 was submitted by a buyer 1402 and sell order 1106 was submitted by a seller 1404, shown in Fig. 14. As shown in Fig. 14, buyer 1402 maintains a router 1406 under control of a server 1408. Router 1406 is connected to a first port 1410 of exchange router 222 via link 220(a).
  • Server 1408 is connected to exchange server 224 via link 220(b).
  • seller 1404 maintains a router 1412 under control of a server 1414.
  • Router 1412 is connected to a second port 1416 of exchange router 222 via a link 220(a).
  • Server 1414 is connected to exchange server 224 via a link 220(b). Because, in this illustrative example, buyer 1402 submitted a buy order that was matched with 20% of the capacity specified in seller 1404's sell order, exchange server 224 specifies in the route plan for exchange router 222 that traffic received on router port 1410 should be routed out via router port 1416 to seller 1404's router 1412. This process is repeated for each matched set of orders in matched list 806.
  • exchange server 224 loads the route plans created in step 520 into exchange routers 222.
  • exchange routers 222 may issue Border Gateway Protocol (BGP) announcements regarding their routing plans.
  • BGP Border Gateway Protocol
  • a description of BGP may be found in "A Border Gateway Protocol 4 (BGP-4)," RFC 1771 (Y. Rekhter & T. Li, Eds., March 1995), which is incorporated herein by reference.
  • BGP-4 Border Gateway Protocol 4
  • each exchange router 222 begins to route traffic delivered to it as specified in its respective route plan.
  • market book 800 and the route plans ⁇ In a preferred embodiment, market book 800 and the route plans ⁇ .
  • exchange server 224 specifies that traffic received by router 222 that is addressed to a host on the first network should be routed to router 1412, and traffic addressed to a host on the second network should be routed to router 1502.
  • each of buyer router 1406 and seller routers 1412, 1502 are connected to the same exchange router 222. It will be recognized, however, as illustrated in Fig.16, that in some cases buyer router 1406 may be connected to a first exchange router 222a while seller routers 1412, 1502 may be connected to a different exchange router 222b.
  • exchange server 224 instructs router 222a (via its route plan) to route traffic received from router 1406 to exchange router 222b via an internal exchange link 226, and instructs router 222b (via its route plan) to route that incoming traffic to an appropriate one of routers 1412, 1502.
  • exchange 218 is preferably provided with conversion modules for translating incoming data packets from the buyer into a format that is compatible with the seller's equipment.
  • the system ensures that buyers actually receive the level of service or quality of service that they have purchased.
  • service monitoring may be achieved using one or more of a plurality of monitoring tools.
  • exchange server 224 may run continuous ping and other quality measurement utilities that mimic actual data transfer in order to record each seller's performance. This data may also be used instead of data submitted by the seller in prioritizing sell orders as described in step 506 above.
  • exchange server 224 determines whether a particular service has degraded beyond an acceptable level.
  • the buyer may specify what constitutes an unacceptable level of degradation of service.
  • the buyer may specify unacceptable levels of service as a percentage difference between the actual level of service that it is receiving and the level of service specified in its buy order.
  • the buyer's buy order may specify a latency no greater than a specified amount, but the buyer may further specify that, during a trading cycle, it is willing to accept fluctuations in this value of 20% or less.
  • the buyer may specify acceptable levels of service as a percentage change from the mean level available in the market. For example, rather than specify a particular maximum latency, the buyer may specify that it is willing to accept any latency within 20% of the mean latency in the market as a whole for the type of service that it has purchased.
  • the buyer may specify acceptable levels of service as a percentage change from the mean of a group of parameters. For example, if the buyer's buy order specified a latency no greater than a first specified amount and packet loss no greater than a second specified amount, the buyer may specify that it is willing to accept any degradation in service during a trading cycle as long as the composite change in those two parameters is not greater than 20%.
  • step 528 service has not degraded to a point requiring action by the system
  • the system returns to step 526 to continue monitoring service quality provided by each seller. If, however, an unacceptable degradation of service is detected, the system proceeds to step 530 where it is determined whether, given the current stage in the trading cycle, it is worthwhile to block the seller from continuing to provide service to the' buyer. For example, if only a few seconds remain before the conclusion of a five minute trading cycle, the system may determine not to take action, but simply to allow the cycle to conclude (step 531).
  • step 530 the system proceeds to step 532 where the buyer is notified of the change in conditions.
  • exchange server 224 instructs exchange router 222 to artificially congest port 1410 in order to decrease the amount of traffic transmitted to exchange router 222 by buyer 1402's router 1406.
  • Such artificial congestion may be effected in a variety of ways.
  • artificial congestion may be effected using the ICMP error reporting mechanism associated with the IP protocol.
  • exchange server 224 may instruct exchange router 222 to transmit an ICMP source quench message to router 1406.
  • router 1406 receives a source quench message it is required under the IP protocol to reduce the rate at which it transmits datagrams to exchange router 222.
  • router 1406 automatically begins to route some of the traffic intended for the termination destination specified in the datagram via alternate routes available to router 1406, such as link 1418 to router 1420 (step 536).
  • the system may use TCP congestion control mechanisms to artificially congest port 1410.
  • exchange server 224 may instruct exchange router 222 to cease sending acknowledgment (ack) messages when it receives packets from router 1406.
  • ack acknowledgment
  • router 1406 will interpret its failure to receive an ack message from exchange router 222 as an indication of packet loss and will decrease its packet transmissions to exchange router 222.
  • exchange server 224 may instruct exchange router 222 to transmit an ack message specifying an input buffer window of zero.
  • router 1406 when router 1406 receives such a message it will cease transmitting packets to exchange router 222 until it receives a second ack message specifying a window greater than zero.
  • exchange server 224 may also transmit a data message via communication link 220(b) to server 1408 instructing it to redirect traffic from router 1406 via alternative routes that. are available to buyer 1402, such as via a ⁇ outer- •
  • Trading in an exchange model is typically conducted in accordance with contractual agreements between participating service sellers and buyers. Therefore, it is important that such agreements be standardized so that they have uniform meaning among all participants.
  • the exchange operator is responsible for monitoring service quality to ensure that it continues to meet the requirements specified by the buyer. In practice, this monitoring may reveal significant deviations between the promised and delivered quality of service. In that event, the exchange may swap, in real time 5 service- meeting .'the contracted for parameters in place of a service that violatesthe ; . contract.. When the number of possible combinations -of parameters is large, the probability of finding a suitable substitute service in real time is small.
  • the system assigns each buy and sell order received from a buyer or seller to one of a plurality of defined matchable service classes.
  • exchange server 224 begins a trading cycle.
  • a sell order may comprise a plurality of parameters.
  • the plurality of parameters may comprise: termination location; origination location; duration; day of week;, time of day; minimum price; capacity; maximum latency; maximum packet loss; ' circuit availability; protocol; and hardware.
  • the sell order may also comprise additional business parameters such as preferred buyers.
  • exchange server 224 evaluates each received sell order and assigns the sell order to a previously defined matchable service class defined by exchange 218.
  • An illustrative set of class definitions that may be defined by exchange server 224 is now described in connection with Fig. 18A-D.
  • exchange 218 has divided Internet service into four matchable service classes: class A, class B, class C, and class D. For each class, exchange 218 specifies the values of one or more parameters that define the service class. In a preferred embodiment, the parameters included in the class definitions correspond to the parameters specified in sell orders submitted by sellers.
  • exchange 218 may publish its class definitions.
  • an entity submitting a sell order may itself determine the class of service that it is proposing to sell by comparing its service parameters to parameter ranges specified in the class definitions.
  • a sell order may preferably comprise the following fields: termination location; origination location; duration; minimum price; capacity; class of service; and . specific factors.
  • the class definitions specified by exchange 218 may.beiterrnination specific.
  • each; termination location may associated therewith a series of class definitions that specify the classes of service for carrying traffic to and from the termination location.
  • these termination locations may be physical locations, virtual locations, or combinations of the two.
  • exchange server 224 may also verify the seller's class designation by testing and evaluating the parameters of the offered service to see if the parameter values meet the class definition.
  • each portal 212, web server 214 or Internet user 202 that wishes to purchase IP bandwidth transmits a buy order to exchange server 224 via communication link 220(b).
  • the buy orders may take the form of continuous limit orders.
  • a buy order may comprise the following parameters: termination location; origination location; duration; maximum price; minimum capacity; maximum latency; maximum packet loss; and minimum circuit availability.
  • a buy order may comprise additional parameters such as preferred sellers.
  • exchange server 224 evaluates each received buy order and assigns the order to one of its previously defined matchable service classes on the basis of the desired parameters specified in the buy order.
  • exchange 218 may, in an alternative embodiment, publish its class definitions.
  • buyers may themselves determine the desired class of service and specify that class of service in their buy orders.
  • a buy order may preferably comprise the following fields: termination location; origination location; duration; day of week, time of day; maximum price; minimum capacity; class of service; and specific factors.
  • step 1712 the trading cycle ends as described, for example, in the first embodiment described above. After the trading cycle ends, two events follow. First, exchange server 224 goes back to step 1702, and a new trading cycle begins. Second, in step 1714, exchange server 224 updates market book 800 of Fig. 8 with received sell and buy orders. The market book operation may proceed in the same manner as previously described with respect to Fig. 8. In step 1716, exchange server 224 prioritizes and matches sell and buy orders as previously described in connection with Figs. 9, 10, 11 and 12.
  • exchange server 224 creates a route plan according to the match list of market book 800.
  • the process of creating a route plan may proceed in the same manner as described previously with respect to Fig. 13.
  • exchange server 224 loads the route plans into exchange routers 222.
  • exchange routers 222 route traffic according to the route plan. Because of the dynamic nature of Internet bandwidth services, exchange server 224 monitors service conditions to see that requirements of matched buy orders are met during trading cycles, as shown in step 1724.
  • exchange server 224 may notify the buyer of the change in condition and cause the buyer's other resources to handle the traffic, as in step 1726.
  • exchange server 224 waits until the next trading cycle to implement a new route plan to meet the new condition. If the change (e.g. price changes beyond what buyer was willing to pay) requires a new order from the buyer, exchange server 224 may notify the buyer to submit a new order and waits for a new order before implementing a new route, plan for the buyer.
  • change e.g. price changes beyond what buyer was willing to pay
  • each portal 212 that wishes to sell Internet bandwidth via exchange 218 transmits a sell order comprising a plurality of parameters to exchange server 224 via a communication link 220(b).
  • the plurality of parameters may comprise: termination location; minimum price; and quantity available; maximum latency; maximum packet loss; and circuit availability.
  • the sell order may also comprise additional business parameters such as preferred buyers.
  • the termination location may be specified either as a physical termination location (e.g., a specific portal 112) or as a virtual destination location (e.g., termination to some AOL router without specifying which).
  • the destination location may be specified as a virtual destination with some physical limitation.
  • the termination destination may specify that the traffic will be delivered to an AOL router in the United States without specifying the specific physical router.
  • exchange server 224 evaluates each received sell order and assigns the order to a previously defined matchable service class defined by exchange 218, as described above.
  • exchange 218 may publish its class definitions.
  • an entity submitting a sell order may itself determine the class of service that it is proposing to sell by comparing its service parameters to parameter ranges specified in the class definitions.
  • class definitions specified by exchange 218 may be termination specific and may specify the termination location as a physical location, virtual location, or combination of the two.
  • sellers may submit sell orders via a template 500 which may be accessed at a secure web site maintained by exchange' server- 224.
  • exchange server 224 downloads from each portal 212 and web server 214 that submitted a sell order information concerning its available communications resources and needs to exchange server 224.
  • a sell order information concerning its available communications resources and needs to exchange server 224.
  • this information is downloaded to exchange server 224.
  • exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources.
  • exchange server 224 is given access to portal 212's confidential communications information
  • additional confidentiality features may preferably be associated with the collection, storage, and usage of this data to ensure that the owner of portal 212 feels comfortable releasing the data to exchange 218 and to ensure that the data is not misused or obtained by entities that are not entitled to it.
  • these additional safety features may include transmission via stronger encryption techniques than those that may be employed in connection with other system transmissions.
  • these safety features may comprise storage of a portal 212's proprietary data in a secure location with limited access by specified personnel. The entity that owns exchange 218 may also obligate itself by contract to protect this sensitive information and may undertake specific sanctions if the information is improperly used or otherwise disclosed to others.
  • exchange server 224 uses the received sell orders to populate sell side 802 of market book 800, as described above.
  • each portal 212 or web server 214 that wishes to purchase IP bandwidth i.e., wishes to pay another entity to route its traffic to a particular destination
  • the buy orders take the form of continuous limit orders.
  • a buy order may comprise the following parameters: termination destination (physical, virtual, or mixed); maximum price; maximum acceptable latency; ' maximum acceptable packet loss; minimum circuit availability.
  • a buy order may comprise additional parameters such as preferred seller;
  • exchange server 224 evaluates each received buy order and assigns the order to one of its previously defined matchable service classes as described above.
  • exchange 218 may publish its class definitions.
  • buyers may themselves determine the desired class of service and specify that class of service in their buy orders.
  • exchange server 224 downloads from each portal 212 and web server 214 that submitted a buy order, information concerning its available communications resources and needs.
  • this information is downloaded to exchange server 224.
  • exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources.
  • exchange server 224 is given access to confidential portal 212's communications information
  • additional confidentiality features may preferably be associated with the collection, storage, and usage of this data to ensure that the owner of portal 212 feels comfortable releasing the data to exchange 218 and to ensure that the data is not misused or obtained by entities that are not entitled to it.
  • these additional safety features may include transmission via stronger encryption techniques than those that may be employed in connection with other system transmissions.
  • these safety features may comprise storage of a portal's proprietary data in a secure location with limited access by specified personnel. The entity that owns exchange 218 may also obligate itself by contract to protect this sensitive information and may undertake specific sanctions if the information is improperly used or otherwise disclosed to others.
  • exchange server 224 utilizes the information collected from the buyers to create the second component 804 of market book 800, as described above.
  • exchange server 224 matches unfilled sell orders to unfilled buy orders to create matched buy-sell orders in accordance with a protocol such as the protocols described above.
  • exchange server 224 uses this list to create a route plan for each exchange router 222 as described above.
  • exchange server 224 loads the route plans created in step 2118 into exchange routers 222.
  • each exchange router 222 begins to route traffic delivered to it as specified in its respective route plan.
  • exchange 218 continuously monitors the level of service provided by each seller to ensure that it does not fall below the level of service specified for the service class allegedly being provided. If the level of service provided falls below that specified for the service class, the system responds by rerouting the buyer's traffic via alternative routes, as described above.
  • exchange server 224 determines whether an event has occurred that requires a change in the manner that traffic is routed via one or more of exchange routers 222.
  • an event is a degradation in service provided by a seller.
  • the system is preferably adapted to recognize and respond to a plurality of distinct events. These may include: 1. quality of service provided degrades below an acceptable level, as described above;
  • step 2126 If, in step 2126, an event requiring a change in the routing plan is not identified, the system returns to step 2124 to continue monitoring service quality provided by each seller.. If, however, an event requiring a change in the routing plan is identified, the . system proceeds to step 212-8 where.it is determined whether, given the buyer's current buy order, the exchange can meet the buyer's service needs under the new conditions.
  • step 2130 exchange server 224 generates a new route plan for exchange routers 222.
  • this new route plan is loaded into exchange routers 222, and in step 2134, each exchange router
  • step 2128 the system determines that it can no longer meet the buyer's service requirements, the system branches to step 2136 where the buyer is notified of the change in conditions.
  • exchange server 224 instructs exchange router 222 to artificially congest port 1410 using the techniques described above in order to decrease the amount of traffic transmitted to exchange router 222 by buyer's router 1406.
  • exchange server 224 may transmit a data message via communication link 220(b) to server 1408 instructing it to redirect traffic from router 1406 via alternative routes that are available to buyer 1402, such as via a router 1418, as shown in step 2140.
  • exchange server 224 transmits a message to the buyer suggesting that the buyer submit a new buy order if it wishes to continue to receive service from exchange 218. If the buyer wishes, it may submit a new order in step 2144. In that event, the system returns to step 2128 where exchange server 224 determines whether it can meet the buyer's service needs under present system conditions.
  • exchange server 224 detects this in step 2126 and determines whether changes are needed in the route plans of exchange routers 222 in light of this change in conditions. If changes are necessary and exchange router 224 can meet a buyer's bandwidth needs given the buyer's current limit order (step 2128), it modifies the route plans of exchange routers 222 as necessary to minimize'the buyer's cost and maximize other business objectives (steps 2130- 2134). Otherwise, in steps 2138-2142, exchange server 224 causes exchange routers 222 to artificially congest their input ports and notifies the buyer that it needs to modify its buy order.
  • the system may comprise multiple exchanges 218 each of which is connected to a central server.
  • the central server preferably maintains a market book 800 that comprises the information stored in the market books 800 of each exchange 218 as well as additional information.
  • Fig. 22 is a block diagram of a preferred network architecture for this preferred embodiment of the present system and Fig. 23 is a flow diagram that depicts system operation in this preferred embodiment.
  • network architecture 2202 preferably comprises a plurality of exchanges 218 each of which maintains a market book 800, as described above.
  • these exchanges 218 are distributed around the globe.
  • exchange 218 ⁇ may be located in New York
  • exchange 218 may be located in Los Angeles
  • exchange 218 3 may be located in Tokyo
  • exchange 218 4 may be located in London.
  • Each exchange 218 preferably has a plurality of customers 212, 214, as described above.
  • Network architecture 2202 further preferably comprises a central server 2204 that is connected to each exchange 218 by respective communication links 2206. Exchanges 218 are also linked to each other by traffic-carrying links 2208.
  • traffic-carrying links 2208 are maintained by entities that wish to participate in the present system as bandwidth sellers who offer connectivity between exchanges 218. In an alternative embodiment, traffic-carrying links 2208 may be maintained by one or more of exchanges
  • each exchange 218 creates a market book 800. This step may preferably be performed in accordance with any of the preferred operating embodiments described above.
  • each exchange 218 transmits a copy of its market book to central server 2204.
  • each entity that maintains one or more of traffic-carrying links 2208 submits a sell order to central server 2204 that specifies the parameters and conditions under which the seller is willing to carry traffic between exchanges 218.
  • central server 2204 is able to create a market book 800 that describes the overall state of the market for bandwidth.
  • this complete market book represents a snapshot of the world- wide bandwidth market.
  • central server 2204 uses one of the matching algorithms described above to match buy orders and sell orders and thus identify routes to carry each buyer's traffic to its desired destination.
  • central server may create a composite route combining the services offered in the two sell orders to provide connectivity to a buyer connected to second exchange 218 2 who wishes to transmit traffic to the termination location.
  • central server 2204 responds by matching buy orders from first exchange 218i to composite sell orders, as described above.
  • this feature of the present embodiment increases the robustness of world-wide communications by permitting traffic to be rerouted via alternative exchanges when serious network events occur in a particular location. If, for example, a seller's network at a particular exchange goes down, traffic that it might have carried may be rerouted via other- exchanges to the desired termination location. Moreover, this rerouting is performed in an-econ ⁇ mically efficient manner because central server 2204 will not begin to match buy orders to composite sell orders until the cost of the composite sell orders is below the cost of delivering the traffic directly via a seller connected to the affected exchange 218. In step 2310, central server 2204 transmits the match information to appropriate exchanges 218.
  • each exchange 218 receives the match information from central server 2204 and creates a route plan for its exchange routers 222, as described above.
  • the system then proceeds to route traffic and monitor service quality as described in the preferred operating embodiments above.
  • the system may comprise a graphical tool for use by network managers to manage their network capacity.
  • a graphical tool for use by network managers to manage their network capacity.
  • a first preferred embodiment of such a graphical tool is described in connection with Figs. 24-26.
  • Fig. 24 shows a graphical tool 2402 comprising a PC 2404 running appropriate software (not shown) including software to implement the functionalities described below.
  • PC 2404 comprises a processing unit 2406, a keypad 2408, a mouse 2410, and a monitor 2412.
  • FIG. 25 is a flowchart depicting a preferred method of operation for graphical tool 2402. The steps in Fig. 25 are explained in conjunction with Figs. 26A-H, which are a series of figures that show the image displayed by monitor 2412 at various points during use of graphical tool 2402.
  • step 2502 the user, typically a network manager, initializes graphical tool 2402, by, for example, clicking on an icon displayed on monitor
  • graphical tool 2402 when graphical tool 2402 is first initialized by the user, it causes a graph 2602 depicting network usage (as a percentage of total network capacity) for a particular network and time period to be displayed on monitor 2412.
  • the network and time period that are the subject of graph 2602 may preferably be identified for the user in a pair of windows 2604 and 2606, respectively.
  • Predicted network usage may be based, for example, on historical data for this and other -networks, and may also be a function of additional factors ⁇ that are expected to affect network usage during the displayed period.
  • step 2504 the user uses his or her mouse to graphically define bandwidth for which he or she wishes to submit a sell order.
  • Fig. 26B illustratively shows how the display might appear after the user blocked an area of bandwidth available during a peak usage period.
  • graphical tool 2402 causes a sell-order window 2608 to pop open on monitor 2412.
  • this window may preferably comprise a plurality of fields for entering and displaying sell-order parameters for the bandwidth that the user wishes to sell.
  • many of the parameters defining the sell order e.g., latency, protocol
  • the capacity, duration, day of week, and time of day fields may also be automatically filled in by graphical tool 2402 when they are defined by the block of capacity selected by the user.
  • the user fills in the remaining fields in window 2608.
  • Fig. 26D shows window 2608 after completion of step 2508.
  • step 2510 the user clicks on the submit button in window 2608 to submit the order.
  • graphical tool 2402 preferably displays the portion of the graph that corresponds to the sell order in a different color from other portions of the screen, such as those corresponding to unsold bandwidth (see, e.g., Fig. 26E).
  • graphical tool 2402 may display all information concerning the order when, for example, the user moves the mouse over the identified area or, alternatively, when the user clicks on the identified area, as shown in Fig. 26F.
  • graphical tool 2402 permits the user to modify the order at any time by simply clicking on an area corresponding to a sell order. When the user clicks on such an area, window 2608 pops up and the user is permitted to modify one or more parameters of the sell order, and then click the submit button to submit the modified order.
  • the user may instead or additionally mark unused bandwidth for sale at a variable price depending on congestion levels of the user's network. As shown, for example, in Fig.
  • the user may specify that he or she wishes to sell all unused capacity for 1 cent/Mb/s when network usage is at or below 40%, for 2 cents/Mb/s when network usage is below 50%, for 3 cents/Mb/s when network usage is at or below 60%', etc:
  • the user may specify some range of network capacity (e.g., 5%) above predicted usage that it does not wish to sell in- 1 order to preserve an operating cushion in case actual usage exceeds predicted usage.
  • the user may call up an updated display showing all submitted sell orders for a particular day or other period by entering the desired time period at an appropriate prompt.
  • monitor 2412 may display a series of views as nested windows (see, e.g., Fig. 26A), and the user may call up a desired view by clicking on the portion of the view visible on the screen. The user may then submit new sell orders for that time period or modify existing displayed sell orders, as described above.
  • entities have been described as either buyers or sellers, it should be recognized that any given entity may act as both a buyer and a seller of bandwidth depending on its bandwidth needs and resources at a particular time for a particular class of service, origination location, etc., or for other business reasons.
  • the exchange 218 maintains a running account with each buyer and seller. Thus, once a transaction has been authorized, the exchange 218 adjusts the balances of each buyer and seller to reflect the purchase and sale of bandwidth. Periodically (e.g. monthly), the exchange 218 sends bills to the buyers and/or sellers with negative balances and forwards payments to buyers and/or sellers with positive balances. In this way, the exchange 218 manages settlement of all accounts.
  • the server node also manages credit risks associated with the transactions. This may be accomplished in combination with a financial services company.
  • the identity of the buyers and sellers are not revealed to each other, at least prior to the transfer of ownership of the transaction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé de négociation de largeur de bande IP en utilisant une plate-forme informatique en réseau global. A cet effet, on établit une pluralité de connexions entre un premier routeur et une pluralité de routeurs additionnels. Puis on spécifie une pluralité de paramètres de description des services de largeur de bande IP. Une fois que la plate-forme a reçu d'un vendeur une offre de fourniture d'un volume de largeur de bande IP et d'un acheteur un ordre d'achat de ce volume de largeur de bande IP, la plate-forme crée un plan d'acheminement définissant un ensemble pour la transmission de trafic de données entre les réseaux de l'acheteur et du vendeur.
PCT/IB2001/000917 2000-04-26 2001-04-26 Systeme et procede de simplification de la negociation de largeur de bande WO2001082021A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU56601/01A AU5660101A (en) 2000-04-26 2001-04-26 System and method for facilitating the trading of bandwidth

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US19990000P 2000-04-26 2000-04-26
US60/199,900 2000-04-26

Publications (2)

Publication Number Publication Date
WO2001082021A2 true WO2001082021A2 (fr) 2001-11-01
WO2001082021A3 WO2001082021A3 (fr) 2003-03-20

Family

ID=22739475

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2001/000917 WO2001082021A2 (fr) 2000-04-26 2001-04-26 Systeme et procede de simplification de la negociation de largeur de bande

Country Status (2)

Country Link
AU (1) AU5660101A (fr)
WO (1) WO2001082021A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2411257A (en) * 2004-02-17 2005-08-24 George Osborne Secondary market in and associated routing of communications traffic
WO2011141330A1 (fr) * 2010-05-10 2011-11-17 Nokia Siemens Networks Oy Mécanisme de transaction commerciale
US20130054298A1 (en) * 2010-05-10 2013-02-28 Nokia Siemens Networks Oy Selling mechanism
US9558518B2 (en) 2011-12-29 2017-01-31 Empire Technology Development Llc Method, system, and computer-readable medium for bandwidth auctions with bandwidth bid requests based mobile device application tables

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5917897A (en) * 1997-02-24 1999-06-29 Summit Telecom System, Inc. System and method for controlling a telecommunication network in accordance with economic incentives
US6005925A (en) * 1997-02-24 1999-12-21 Summit Telecom Systems, Inc. Bidding for telecommunications traffic over route segments
US6055571A (en) * 1997-11-20 2000-04-25 Nec Usa, Inc. Computer network with microeconomic flow control
US6144727A (en) * 1997-08-29 2000-11-07 Anip, Inc. Method and system for global telecommunications network management and display of market-price information
US6226365B1 (en) * 1997-08-29 2001-05-01 Anip, Inc. Method and system for global communications network management and display of market-price information

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5917897A (en) * 1997-02-24 1999-06-29 Summit Telecom System, Inc. System and method for controlling a telecommunication network in accordance with economic incentives
US6005925A (en) * 1997-02-24 1999-12-21 Summit Telecom Systems, Inc. Bidding for telecommunications traffic over route segments
US6144727A (en) * 1997-08-29 2000-11-07 Anip, Inc. Method and system for global telecommunications network management and display of market-price information
US6226365B1 (en) * 1997-08-29 2001-05-01 Anip, Inc. Method and system for global communications network management and display of market-price information
US6055571A (en) * 1997-11-20 2000-04-25 Nec Usa, Inc. Computer network with microeconomic flow control

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2411257A (en) * 2004-02-17 2005-08-24 George Osborne Secondary market in and associated routing of communications traffic
WO2011141330A1 (fr) * 2010-05-10 2011-11-17 Nokia Siemens Networks Oy Mécanisme de transaction commerciale
US20130054298A1 (en) * 2010-05-10 2013-02-28 Nokia Siemens Networks Oy Selling mechanism
US9558518B2 (en) 2011-12-29 2017-01-31 Empire Technology Development Llc Method, system, and computer-readable medium for bandwidth auctions with bandwidth bid requests based mobile device application tables

Also Published As

Publication number Publication date
AU5660101A (en) 2001-11-07
WO2001082021A3 (fr) 2003-03-20

Similar Documents

Publication Publication Date Title
US7236575B2 (en) System and method for IP bandwidth trading
Semret et al. Pricing, provisioning and peering: dynamic markets for differentiated Internet services and implications for network interconnections
US7984156B2 (en) Data center scheduler
US20060167703A1 (en) Dynamic resource allocation platform and method for time related resources
US20040111308A1 (en) Dynamic resource allocation platform and method for time related resources
US20040165605A1 (en) System and method for automated provisioning of inter-provider internet protocol telecommunication services
US20020004788A1 (en) Commodity trading of bandwidth
CA2448374A1 (fr) Interface entre vendeurs et clients mettant en oeuvre des agents intelligents
AU2002341301A1 (en) An interface between vendors and customers that uses intelligent agents
US7742960B2 (en) Method and device for calculating a price for using a specific link in a network
US20180308167A1 (en) System and Method for Multi-Market Risk Control in a Distributed Electronic Trading Environment
CA2568970A1 (fr) Gestion de l'information dans un systeme multi-noeud de planification multilaterale et gestion de chaine d'approvisionnement
WO2001082021A2 (fr) Systeme et procede de simplification de la negociation de largeur de bande
Cisco Packet, Second Quarter 1997
Cisco Cisco Systems Users Magazine
Cisco Cisco Systems Users Magazine
Cisco Cisco Systems Users Magazine
US11790435B2 (en) Dynamic computer marketplace system and method
Ferreira A model for interconnection of IP networks
Macedo et al. Distributed Auction-Based SFC Placement in a Multi-domain 5G Environment
Werder Pricing in the service-oriented it world
WO2003038562A2 (fr) Systeme et procede de fourniture de services de reseau
Zhang Data network pricing under quality of service (QoS) guarantee: Single class and multiple classes
Johnsen et al. e-Commerce impacts on Service and Network Operations and Management
Shelford et al. QRP01-1: Optimal Routing of Dynamically Priced Network Services

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP