Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword or section
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 82|Likes:
Published by aqua01

More info:

Published by: aqua01 on Sep 01, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





June 1999Volume 2, Number 2
A Quarterly Technical Publication forInternet and Intranet Professionals
 In This Issue
 From the Editor.......................1Peering and Settlements...........2Firewalls and InternetSecurity..................................24Was the Melissa VirusSo Different?..........................33Book Review..........................36Call for Papers.......................38Fragments..............................39
 From The Editor
 In this issue, Geoff Huston concludes his two-part article on Intercon-nection, Peering, and Settlements. Last time Geoff discussed thetechnical aspects for Internet Service Provider (ISP) interconnection. Thistime he examines the associated business relationships that arise out of ISP peering arrangements. He also looks at some future directions forthe ISP interconnection environment, particularly with respect to Qual-ity-of-Service considerations.A recurring theme in this journal has been the traditional lack of secu-rity in Internet technologies and systems. We have examined severalways in which security has been added at all levels of the protocol stack.This time we look at
 a popular way to segregate internal cor-porate intranet traffic from Internet traffic while still maintainingInternet connectivity. Fred Avolio gives the history of firewalls, their cur-rent state, and future directions.Computer viruses have probably existed for as long as we have hadcomputers. However, the ease with which viruses can be distributed asInternet e-mail attachments has made the problem more prevalent. Re-cently, the
 virus achieved some notoriety because of its “self-replication” properties. Barbara Fraser, Lawrence Rogers, and Linda Pe-sante of the Software Engineering Institute at Carnegie MellonUniversity examines some of the issues raised by this kind of virus.This issue is the first anniversary issue of 
The Internet Protocol Journal 
 (IPJ). You can find all of our back issues in PDF format at the IPJ Website:
 . Please let us know if you have suggestionsfor articles, books you want to review, or general feedback for this jour-nal. Our contact address is:
  —Ole J. Jacobsen, Editor and Publisher
 You can download IPJback issues and findsubscription information at:
The Internet Protocol Journal
 Interconnection, Peering and Settlements—Part II
 by Geoff Huston, Telstra
 n Part I we examined the business drivers behind the adoption of the exchange model as the common basis of interconnection, andalso examined the advantages and pitfalls associated with the opera-tion of such exchanges within the public Internet. (See
The Internet Protocol Journal,
 Volume 2, No. 1, March 1999.) In continuing our ex-amination of the technology and business considerations that aresignificant within the subject of Internet Service Provider (ISP) intercon-nection, in this part we focus on the topic from a predominately businessperspective.
Interaction Financials: Peering and Settlements
Any large multiprovider distributed service sector has to address the is-sue of cost distribution at some stage in its evolution. Cost distribution isthe means by which various providers can participate in the delivery of aservice to a customer who purchases a service from a single provider,and providers can each be compensated for their costs in an equitablestructure of interprovider financial settlement.As an example, when an airline ticket is purchased from one air serviceprovider, various other providers and service enterprises may play a rolein the delivery of the service. The customer does not separately pay theservice fee of each airport baggage handler, caterer, or other form of ser-vice. The customer’s original fare, paid to the airline, is distributed toother providers who incurred cost in providing components of the totalservice. These costs are incurred through sets of service contracts, andare the subject of various forms of interprovider financial settlements, allof which are invisible to the customer.The Internet is in a very similar situation. Some 50,000 constituent net-works must interconnect in one fashion or another to providecomprehensive end-to-end service to each client. In supporting a datatransaction between two clients, the two parties often are not clients of the same network. Indeed, the two-client service networks often do notdirectly interconnect, and one or more additional networks must act in atransit provider role to service the transaction. Within the Internet envi-ronment, how do all the service parties to a transaction who incur cost insupporting the transaction receive compensation for their cost? What isthe cost distribution model of the Internet?Here, we examine the basis for Internet interprovider cost distributionmodels and then look at the business models currently used in the inter-provider Internet environment. This area commonly is termed
financial settlement,
 a term the Internet has borrowed from the telephonyindustry.
The Internet Protocol Journal
 The Currency of Interconnection
What exactly is being exchanged between two ISPs who want to inter-connect? In the sense of the meaning of currency as the circulatingmedium, the question is: What precisely is being circulated at the ex-change and within the realm of interconnection? The technical answerto the question is:
routing entries.
 When two parties exchange routingentries, the outcome is that traffic flows in response to the flow of rout-ing entries. The route advertisement and traffic flows move in oppositedirections, as indicated in Figure 1, and a bilateral routing-mediatedflow occurs only when routes are passed in both directions.
 Figure 1: Routing and Traffic Flows 
 Within the routing environment of an ISP there are many differentclasses of routes, with the classification based predominately on the wayin which the route has been acquired by the ISP:
 Client routes
 are passed into the ISP’s routing domain by virtue of aservice contract with the client. The routes may be staticallyconfigured at the edge of the ISP’s network, learned by a
BorderGateway Protocol 
 (BGP) session with the client, or they may consti-tute part of an ISP pool of addresses that are dynamically assigned tothe client as part of the dialup session.
 Internal ISP routes
 fall into numerous additional categories. Someroutes correspond to client services operated by the ISP, solely foraccess to the clients of the ISP, such as Web caches,
Post Office Pro-tocol 
 (POP) mail servers, and game servers. Some routes correspondto ISP-operated client services that require Internet-wide access, suchas
Domain Name System
 (DNS) forwarders and
Simple Mail Trans-fer Protocol 
 (SMTP) relay hosts. Lastly are internal services with novisibility outside the ISP network, such as
Simple Network Manage-ment Protocol 
 (SNMP) network management platforms.
 Upstream routes
 are learned from upstream ISPs as part of a transitservice contract the ISP has executed with the upstream provider.
 Peer routes
 are learned from exchanges or private interconnections,corresponding to routers exported from the interconnected ISP.How then should the ISP export routes so that the inbound traffic flowmatches the outbound flows implied by this route structure? The routeexport policy is generally structured along the following lines:
  D  i r e c  t  i o no  fr o u  t ea d  v e r  t  i s e  m e n  tf  l o  w
Packet from D addressed to from D to C, to B, to A for deliveryRoute Advertisement of from A to B, to CDCBA172.16.1.0/24
  D  i r e c  t  i o no  f  t r a  f  f  i cf  l o  w

Activity (4)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
Dan liked this
Dan liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->