Table of Contents - ee.iitb.ac.inprakshep/Ippipn_report.pdf · Table of Contents Sr no. Content ......

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Table of Contents

Sr no. Content Page no.

1 Introduction 1 1.1 Network Externalities 1 1.2 Peering and Transit 1

1.2.1 Private peering 3 1.2.2 Advanced Peering 3 1.2.3 Transit 4

1.3 Interconnection issues 5 1.3.1 Common Carrier Regulation

5

2 ISP’s Protocol: Border Gateway Protocol 6 2.1 Introduction of EBGP and IBGP 7

2.2 BGP attributes 7 2.3 BGP path selection

12

3 MPLS Overview 12 3.1 BGP/MPLS Virtual Private Networks 14 3.2 MPLS based VPNs through Multiple Autonomous Systems

15

4 Summary

18

5 Acknowledgement

18

6 References

18

List of acronyms IBP: Internet Backbone Providers ISP: Internet Service Provider NAP: Network Access Point QoS: Quality of Services BGP: Border Gateway Protocol EBGP: Exterior BGP IBGP: Interior BGP AS: Autonomous System MED: Multi-exit discriminator IETF: Internet Engineering Task Force BW: Bandwidth MPLS: Multi-Protocol Label Switching LSP: Label-Switched Paths FEC: Forwarding Equivalence Class VPI/VCI: Virtual Path Identifier/Virtual Channel Identifier DLCI: Data link connection Identifier CoS: Class of Services VPN: Virtual Private Networks RFC: Request for comment VRF: VPN routing and forwarding table IPv4: Internet Protocol version 4 NLRI: Network Layer Reachability Information ASBR: EBGP Border Edge Router

List of Figures Figure 1 Peering

2

Figure 2 Hot Potato Routing

3

Figure 3 Peering through NAP

3

Figure 4 Private Peering 3

Figure 5 Transit

4

Figure 6 Free Ride

6

Figure 7 External and Interior BGP

7

Figure 8 BGP Weight Attribute

8

Figure 9 BGP Local Preferences Attribute

8

Figure 10 BGP Local Preferences Attribute to force traffic on Primary Link

9

Figure 11 BGP MED Attribute

9

Figure 12 BGP AS Path Attribute

10

Figure 13 BGP Next Hop Attribute

11

Figure 14 No export community

11

Figure 15 No advertise community

11

Figure 16 Internet community

11

Figure 17 Packet traversing Label Switched Path

13

Figure 18 MPLS based VPN Approach

14

Figure 19 MPLS based VPNs through Multiple Autonomous Systems

16

Figure 20 EBGP Connections between Two Autonomous Systems 17

Project Report EE612 Telematics 1

1. Introduction

Internet is not a monolithic and uniform but it is network of networks owning by different internet backbone providers (IBP). In order to provide universal connectivity they need to interconnect. End users communicate with each other using internet and also access the information form different content providers. The connection to the end users will be provided by ISPs. ISPs will in turn get connectivity from IBPs who are having their big fiber-optic or other network. Content provider will take leased line which will enable end users to access the information round the clock. Many IBPs are vertically integrated, functioning as ISP by providing service to end users and as well as having ISPs as customers. Currently IBPs and ISPs are not governed by any industry specific rules but they make the rules through commercial negotiations. The rules will be based on their benefits weighted by various factors. There are three types of interconnections strategies between IBPs namely Peering, Advanced peering and Transit [3] The driving force behind the need for providing universal access is known as network externalities [1]. 1.1 Network Externalities Network externalities arise when the value, or utility, that a consumer derives from a product or service increases as a function of the number of other consumers of the same or compatible products or services[1]. They are called network externalities because they generally arise for networks whose purpose is to enable each user to communicate with other users; as a result, by definition the more users there are, the more valuable the network. These benefits are externalities because a user, when deciding whether to join a network, only takes into account the private benefits that the network will bring to that user, and will not consider the fact that his joining to this network increases the benefit of the network for other users. This latter effect is an externality.

Network externalities can be direct or indirect. Network externalities are direct for networks that consumers use to communicate with one another; the more consumers that use the network, the more valuable the network is for each consumer. Network externalities are indirect for systems that require both hardware and software in order to provide benefits. As more consumers buy hardware, this will lead to the production of more software compatible with this hardware, making the hardware more valuable to users. Internet will provide both direct and indirect externalities [1]. Users using email like applications are direct externalities because more customers more valuable the network is. Users using content based services will fall in the category of indirect externalities because more number of users using content based service, it is likely that content providers will make it more interesting and increase the data base so in turn end users will have more benefit of this. 1.2 Peering and Transit “During the early development of the Internet, there was only one backbone, and therefore interconnection between backbones was not an issue. In 1986, the National Science Foundation (NSF) funded the NSFNET, a 56-kilobit per second (Kbps) network created to enable long-distance access to five supercomputer centers across the country. In 1987, a partnership of Merit Network, Inc., IBM, and MCI began to manage the NSFNET, which became a T-1 network


connecting thirteen sites in 1988. The issue of interconnection arose only when a number of commercial backbones came into being, and eventually supplanted the NSFNET” [1]. At the time that commercial networks began appearing, general commercial activity on the NSFNET was prohibited by an Acceptable Use Policy, thereby preventing these commercial networks from exchanging traffic with one another using the NSFNET as the backbone. In 1995 commercial backbones and Naps permanently replaced the NSFNET.

The commercial backbone providers developed a system known as peering [1]. Following are its distinctive characteristics: 1. Peering partners only exchange traffic that originates with the customer of one backbone and

terminates with the customer of the other peered backbone. In Figure 1, customers of backbones A and C can trade traffic as a result of a peering relationship between the backbones, as can the customers of backbones B and C, which also have a peering arrangement. As part of a peering arrangement, a backbone would not, act as an intermediary and accept the traffic of one peering partner and transmit this traffic to another peering partner. Thus, referring back to Figure 1, backbone C will not accept traffic from backbone A destined for backbone B.

Figure 1 Peering

2. The only cost that backbone provider has to pay for its own equipment installation at the other

end for ‘peering’ communication. Additional characteristics of peering relate to the routing of information from one backbone to another. Peering partners generally meet in a number of geographically dispersed locations. In order to decide where to pass traffic from one backbone to another in a consistent and fair manner, they have adopted what is known as “hot-potato routing,” [2] whereby a backbone will pass traffic to another backbone at the earliest point of exchange. As an example, in Figure 2 backbones A and B are interconnected on the West and East coasts, when a customer of ISP X on the East coast requests a web page from a site connected to ISP Y on the West coast, backbone A passes this request to backbone B on the East coast, and backbone B carries this request to the West coast. Likewise, the responding web page is routed from backbone B to backbone A on the West coast, and backbone A is responsible for carrying the response to the customer of ISP X on the East coast. A final characteristic of peering is that the recipients of traffic only promise to undertake “best efforts” when terminating traffic, rather than guarantee any level of performance in delivering packets received from peering partners.


Figure 2 Hot Potato Routing

1.2.1 Private peering Initially all the exchange of traffic was done at the NAPs but as the no. of backbone increased NAPs got congested. Eventually, system started incurring delays and dropped packets. Due to this problem IBPs have started exchanging traffic at remote places in place of meeting at a NAP [1]. This kind of peering is known as private peering. Private peering has i) reduced the load at NAPs. ii) Made the traffic exchange simplified. For example if there are two end users communicating from the same city but having connection form two different backbone providers than their traffic must be routed through the NAP which may not be in that city. This will incur unnecessary burden on communication links but with private peering there is no need to communicate in this way and delay, packet loss can also be reduced. Here Figure 3 is showing peering and Figure 4 is showing the private peering among backbone providers.

Figure 3 Peering through NAP Figure 4 Private Peering 1.2.2 Advanced Peering This is similar to the internet exchange model in which there are virtual links between peers over a shared ATM or ethernet switching fabric. In this case, however, the shared switching fabric is MPLS network. In operation, each ISP, cable operator or content company connects to this network wherever convenient. Once connected, each user determines who they want to peer with

Response ISP Y

ISP X

East coast

West coast

Backbone A

Backbone B Request


and enters into bilateral agreements in the same way as with traditional peering. Users then establish virtual links across the MPLS backbone and begin to exchange traffic. Multiple applications and traffic types: internet and non-internet can be supported by this network. Advanced peering delivers a number of benefits over traditional models. On the macro 'industry health' level, for example, it's much more efficient to concentrate traffic across fewer networks and achieve higher utilisation levels. Advanced peering offers lower per transit costs than conventional peering. The advantage is ISPs don't need to set up a peering infrastructure network Unlike traditional peering with self-provided access infrastructure, advanced peering users only pay for service they actually consume. This is because internet traffic often traverses peering links, which means ISP can carry the cost for both origination and termination of the traffic, but will be compensated entirely by one customer. In advanced peering, ISPs originates and terminates the traffic between two customers. These two customers in essence share the cost of the connection. ISP's costs are approximately the same as if it delivered the traffic to a peering point, but the cost is shared between the two customers. 1.2.3 Transit The alternative of peering is transit [1]. In transit backbone provider will charge for the transit connection to ISPs (its customer). In the case of transit, unlikely as peering, IBP has to exchange the data from its peering partner to its transit customer and vice- versa. In turn transit will reduce the number of peering connection. For e.g. in Figure 5, backbone A is a transit customer of backbone C; thus, the customers of backbone A can have access to both the customers of backbone C as well as to the customers of all peering partners of backbone C, such as backbone B. If backbone A and backbone C were peering partners, as in Figure 1, backbone C would not accept traffic from backbone A that was destined for backbone B. Many IBPs also use hybrid connection both peering and transit together to have global access. There are some top-tier backbone provider who only uses peering and does not require transit connection but they are very few. For e.g. i) Cable and Wireless ii) World com iii) AT&T iv) Sprint v) Genuity.

Figure 5 Transit

There is no accepted convention that who should peer and who should have transit. Generally two equal sized networks should peer, but how to decide about the size of network. It is a subjective question and it may take in to account geographical spread, capacity, traffic volume or number of customers serviced. 1.3 Interconnection issues


Now we will discuss “why there are no industry specific rules for interconnection”. 1.3.1 Common Carrier regulation The traditional rationale for regulating network industries such as telecom was the almost overwhelming economies in the provision of such services. Economic theory says that there is a chance of arising monopolist in such industries if there is not open market.. It may be efficient because there won’t be installation of duplicative facilities. It has also disadvantages like [1]

1. Monopolist can directly raise retail price or can degrade quality. 2. It will not allow market to be competitive. 3. It may deny access to its network in anti-competitive manner.

In competitive environment such situation will not arise. So there is no such regulatory rule imposed on the service providers who provides services that combine telecom together with computers. Internet backbone providers have conflicting incentives. On one hand they want to co-operate with one another to have universal connectivity and on another hand they want to compete with one another. Is backbone’s refusal to peer with another backbone is likely to be anti-competitive? Anti-competitive is defined as to keep the price more than that would have been in the case of open market. It is some times legitimate to refuse for peering with smaller backbone providers because peering should be done if both partners will get equal advantage out of it. One reason a backbone may refuse to peer is that it believes that peering would enable the other backbone to free ride on its infrastructure investments [1]. Figure 6 illustrates this situation. In the figure, backbone B, a national backbone, has a presence on both coasts. Backbone A, in contrast, is a regional backbone with a presence only on the East coast. If the two backbones peered on the East coast, when a customer of backbone A requests a web page from a customer of backbone B whose server is on the West coast, then backbone B would carry the request from the East coast to the West coast and also carry the response back to the East coast. The national backbone may thus refuse to peer on the grounds that it would otherwise bear the expense for a national infrastructure from which the regional carrier could then benefit at no cost.


Figure 6 Free Ride

An important point is that whether the IBP is refusing to give connection or just refusing for peering. Smaller backbone providers can have transit connection form bigger backbone providers. They can get it in competitive manner because there is competition among the backbone provides to increase their transit customers. While doing peering one will also have to take into account the number of transit customer the backbone provider is supporting. Smaller backbone provider now can grow using the transit connection. They can expand and make their selves eligible for peering connection. They can grow by providing good QoS to its customers. Now they will also have incentive to invest in infrastructure, this will in turn increase competition in the market by increasing number of backbone providers. Today there are many services available on internet which will require specific performance guarantee e.g. video conferencing, video on demand, voIP. These kinds of services are sensitive to delay and jitter. As a result QoS is becoming a critical issue for IBP and ISPs. The overall internet connectivity will be good only if there is good connection between backbone providers. For maintain good quality some efficient protocol must be used for peering or transit. There may be problem in the interconnecting like due to various reasons like power outages, natural disasters, miss-configuration and intentional attacks (Denial of Service) [3]. So directly connected backbone providers must look at it to cooperate for fault detection and removing it. In order to do this they must properly configure their routers with efficient protocols like Border Gateway Protocol which is able to detect link failure or looping in the routing. We will discuss how BGP can do this.

2. ISP’s Protocol: Border Gateway Protocol

The Border Gateway Protocol (BGP) is the routing protocol used between ISPs. The algorithm provides network stability, guarantees that if one network connection goes down, the network can quickly adapt to send packets through another connection. The Border Gateway Protocol is used in an inter-Autonomous System communication. An autonomous system is one network or set of networks under a single administrative control. Companies and organizations might own more

Response ISP Y

ISP X

East coast

West coast

Backbone A

Backbone B Request


than one autonomous system, but the idea is that each autonomous system is managed independently with respect to BGP [4] [5] [6] [7].

2.1 Introduction of EBGP and IBGP BGP is used to exchange routing information for the Internet and is the protocol used between Internet service providers (ISP). Customer networks, such as universities and corporations, usually employ an Interior Gateway Protocol (IGP) such as RIP or OSPF for the exchange of routing information within their networks. Customers connect to ISPs, and ISPs use BGP to reach at other ISP’s customers. When BGP is used between autonomous systems (AS), the protocol is referred to as External BGP (EBGP). If a service provider is using BGP to exchange routes within an AS, then the protocol is referred to as Interior BGP (IBGP). Figure 7 illustrates that IBGP is used within the organization and EBGP is used between two organizations [8].

Figure 7 External and Interior BGP

The policies to decide which path to be preferred can be set with BGP parameters, called attributes.

2.2 BGP Attributes The decision of setting the value of the attribute depends on Path length, reliability, delay, bandwidth, load, and communication cost [9]. This section describes the attributes that BGP uses in the route selection process: The BGP attribute are Weight, Local preference, Multi-exit discriminator, Origin, AS path and Next hop Community.

Weight Weight is a Cisco-defined attribute that is local to a router. The weight attribute is not advertised to neighboring routers. If the router learns about more than one route to the same destination, the route with the highest weight will be preferred. In Figure 8, Router A is receiving an advertisement for network 172.16.1.0 from routers B and C. When Router A receives the advertisement from Router B, the associated weight is set to 50. When Router A receives the advertisement from Router C, the associated weight is set to 100. Both paths for network 172.16.1.0 will be in the BGP routing table, with their respective weights. The route with the highest weight will be installed in the IP routing table.

AS1

AS2EBGP

IBGP


Figure 8 BGP Weight Attribute

The local preference Attribute is used to prefer an exit point from the local autonomous system (AS). Unlike the weight attribute, the local preference attribute is propagated throughout the local AS. If there are multiple exit points from the AS, the local preference attribute is used to select the exit point for a specific route. In Figure 9, AS 5 is receiving three advertisements for network 13.13.0.0 from AS 2, AS3 and AS 4. When Router A receives the advertisement for network 13.13.0.0, the corresponding local preference is set to 100. When Router B receives the advertisement for network 13.13.0.0, the corresponding local preference is set to 90. When Router C receives the advertisement for network 13.13.0.0, the corresponding local preference is set to 80. These local preference values will be exchanged between routers A, B and C. Because Router A has a higher local preference than Router B and C, Router A will be used as the exit point from AS 5 to reach network 13.13.0.0 in AS 1. Local Preference used only in IBGP.

Figure 9 BGP Local Preferences Attribute

AS 1AS 2

AS 4

AS 3

13.13.0.0/16

local pref = 80

local pref = 100

local pref = 90

AS 5

A

B

C


Figure 10 BGP Local Preferences Attribute to force traffic on Primary Link

The local preference attribute can be used to use primary link. In case if primary link fails, backup link is used. The backup link implementation is shown in figure 1.4 with local preference. Multi-Exit Discriminator The multi-exit discriminator (MED) or metric attribute is used as a suggestion to an external AS regarding the preferred route into the AS that is advertising the metric. The term suggestion is used because the external AS that is receiving the MEDs may be using other BGP attributes for route selection. In Figure 11, Router C is advertising the route 192.44.78.0 with a metric of 15, while Route D is advertising 192.44.78.0 with a metric of 56. The lower value of the metric is preferred, so AS 1 will select the route to router C for network 192.44.78.0 in AS 2. MEDs are advertised throughout the local AS. MEDs must be considered before IGP distance. Here we should note that some provider will not listen to MEDs and MEDs need not be tied to IGP distance.

Figure 11 BGP MED Attribute

Origin The origin attribute indicates how BGP learned about a particular route. The origin attribute can have one of three possible values:

1. IGP-The route is interior to the originating AS. This value is set when the network router configuration command is used to inject the route into BGP.0

2. EGP-The route is learned via the Exterior Border Gateway Protocol (EBGP). 3. Incomplete-The origin of the route is unknown or learned in some other way. An

origin of incomplete occurs when a route is redistributed into BGP.

AS 1

Primary link Backup link

Set Local Pref = 100 for all routes from AS 1 AS 2

Set Local Pref = 50 for all routes from AS 1

15 56

172865

Heavy Content Web Farm

192.44.78.0/24

192.44.78.0/24 MED = 15

192.44.78.0/24 MED = 56

Prefer lower MED values

DC

AS 1

AS 2 AS 3


AS_path When a route advertisement passes through an autonomous system, the AS number is added to an ordered list of AS numbers that the route advertisement has traversed. Figure 12 shows the situation in which a route is passing through three autonomous systems. AS1 originates the route to 135.207.0.0 and advertises this route to AS 2, with the AS_path attribute equal to {1}. AS 2 will advertise this route to AS 3 and AS 5 with AS-path attribute {2, 1}, and AS 2 will advertise back to AS 1 with AS-path attribute {2, 1}. AS 1 will reject these routes when its own AS number is detected in the route advertisement. This is the mechanism that BGP uses to detect routing loops. AS 3 and AS 5 propagate the route to other with their AS numbers added to the AS_path attribute. The AS6 will install the route (5 2 1) in the IP routing table because (5,2,1) is the shortest AS path compare to route (7,4,3,2,1).

Figure 12 BGP AS Path Attribute

Next-Hop The EBGP next-hop attribute is the IP address that is used to reach the advertising router. For EBGP peers, the next-hop address is the IP address of the connection between the peers. For IBGP, the EBGP next-hop address is carried into the local AS, as illustrated in Figure 13. Router D advertises network 135.207.0.0 with a next hop of 192.0.2.1. When Router C propagates this route within its own AS, router A and router B the EBGP next-hop information is preserved. If Routers A and B does not have routing information regarding the next hop, the route will be discarded. Therefore, it is important to have an IGP running in the AS to propagate next-hop routing information. In AS1 router A stores forwarding table (destination 192.0.2.0/30 and next hope 10.10.10.10) and EGP table (destination 135.207.0.0/16 and next hope 192.0.2.1).

AS2135.207.0.0/16 AS Path =1

AS 3

AS 4

AS 5

135.207.0.0/16AS Path = 2 1

135.207.0.0/16 AS Path = 5 2 1

AS 1

135.207.0.0/16

Prefix Originated

AS 6

AS 7

135.207.0.0/16AS Path =2 1

135.207.0.0/16 AS Path = 3 2 1

135.207.0.0/16AS Path = 4 3 2 1

135.207.0.0/16AS Path = 7 4 3 2 1


Figure 13 BGP Next Hops Attribute

Community The community attribute provides a way of grouping destinations, called communities, to which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route maps are used to set the community attribute. Predefined community attributes are 1.no-export—Do not advertise this route to EBGP peers, 2.no-advertise—Do not advertise this route to any peer and 3.internet—Advertise this route to the Internet community; all routers in the network belong to it. Figure 14 illustrates the no-export community. AS 1 advertises 172.16.1.0 to AS 2 with the community attribute no-export. AS 2 will propagate the route throughout AS 2 but will not send this route to AS 3 or any other external AS.

Figure 14 No export community

Figure 15 No advertise community Figure 16 Internet community Figure 15 AS 1 advertises 172.16.1.0 to AS 2 with the community attribute no-advertise. Router B in AS 2 will not advertise this route to any other router. Figure 16 demonstrates the internet community attribute. The setting of above attributes is under the control of network administrator. The method of finding the best destination route can be derived from normalizing metric distance formula [10]

AS 1 AS 2 192.0.2.1

135.207.0.0/16

10.10.10.10

135.207.0.0/16 Next Hop = 192.0.2.1

CBD

A

192.0.2.0/30

AS 3


M = (1 / min (BWi)) + ∑di

Where BWi is the minimum bandwidth obtained in ith path route and di is the sum of delay occurred between successive AS to reach the destination. The path with minimum value of M is better choice of selection. One of the limitations of BGP-4 was originally designed to carry routing information only for the IPv4 address family. Realizing this limitation, the IETF is standardizing the Multiprotocol extensions for BGP-4 to carry routing information for multiple Network Layer protocols (IPv6, IPX, and VPN-IPv4). 2.3 BGP Path Selection BGP could possibly receive multiple advertisements for the same route from multiple sources. BGP selects only one path as the best path. When the path is selected, BGP puts the selected path in the IP routing table and propagates the path to its neighbors. BGP uses the following criteria, in the order presented, to select a path for a destination:

• If the path specifies a next hop that is inaccessible, drop the update. • Prefer the path with the largest weight. • If the weights are the same, prefer the path with the largest local preference. • If the local preferences are the same, prefer the path that was originated by BGP running

on this router. • If no route was originated, prefer the route that has the shortest AS_path. • If all paths have the same AS_path length, prefer the path with the lowest origin type

(where IGP is lower than EGP and EGP is lower than incomplete). • If the origin codes are the same, prefer the path with the lowest MED attribute. • If the paths have the same MED, prefer the external path over the internal path. • If the paths are still the same, prefer the path through the closest IGP neighbor. • Prefer the path with the lowest IP address, as specified by the BGP router ID.

BGP does not provide various classes of services. It selects the best path based on policy set by ISPs. ISPs have to accommodate different type of customers who has varying requirement. If he fulfills these varying requirements than only he can grow faster and can make his place in the market. In order to satisfy this requirement some technique is required which can accommodate different kind of traffic e.g. different bandwidth. We will discuss Multi-protocol label switching (MPLS) technique which is able to fulfill this kind of requirements through its efficient traffic engineering and its dynamic nature of selecting appropriate LSP.

3 MPLS Overview MPLS [11] [12] is the latest step in the evolution of multilayer switching in the Internet. It is an IETF Standards based approach built on the efforts of the various proprietary multilayer switching solutions. The forwarding component of MPLS is based on a label-swapping forwarding algorithm. MPLS uses the control-driven model to initiate the assignment and distribution of label bindings for the establishment of label-switched paths (LSPs) A label is a short, fixed length value carried in the packet’s header to identify Forwarding Equivalence Class (FEC). A label is analogous to a connection identifier, such as an ATM VPI/VCI or a Frame Relay DLCI, because it has only link local significance, does not encode information from the network layer header, and maps traffic to a specific FEC. An FEC is a set of packets that are forwarded over the same path through a network even if their ultimate destinations are different.


The label swapping forwarding algorithm requires packet classification at the ingress edge of the network to assign an initial label to each packet. In Figure 17, the ingress label switch receives an unlabeled packet with a destination address of 192.4.2.1. The label switch performs a longest match routing table lookup and maps the packet to an FEC 192.4/16. The ingress label switch then assigns a label (with a value of 5) to the packet and forwards it to the next hop in the label switched path (LSP).

Figure 17 Packet traversing Label Switched Path

An LSP is equivalent to a virtual circuit because it defines an ingress to egress path through a network that is followed by all packets assigned to a specific FEC. The first label switch in an LSP is called the ingress label switch and the last label switch in an LSP is called the egress label switch. In the core of the network, label switches ignore the packet’s network layer header and simply forward the packet using the label-swapping algorithm. When a labeled packet arrives at a switch, the forwarding component uses the input port number and label to perform an exact match search of its forwarding table. When a match is found, the forwarding component retrieves the outgoing label, the outgoing interface, and the next-hop address from the forwarding table. The forwarding component then replaces the incoming label with the outgoing label and directs the packet to the output interface for transmission to the next hop in the LSP. Label swapping provides a significant number of operational benefits when compared to conventional hop-by-hop network layer routing: 1. Label swapping gives service provider flexibility in the way that it assigns packets to

FECs. For example, to simulate conventional IP forwarding, the ingress label switch can be configured to assign a packet to an FEC based on its destination address. However, packets can also be assigned to an FEC based on number of policy based considerations like the source address alone, the application type, the point of entry into the label-swapping network, the point of exit from the label-swapping network, the CoS defined in packet header, or any combination of the above.

2. Service providers can construct LSPs that support specific application requirements.

LSPs can be designed to minimize the number of hops, meet certain bandwidth requirements, and support precise performance requirements, bypass potential points of congestion, direct traffic away from the default path selected by the IGP, or force traffic across certain links or nodes in the network.


3. The most important benefit of the label-swapping forwarding algorithm is its ability to take traffic from any type of user and associate with it an FEC. These in turn are mapped to LSP that has been specifically designed to satisfy the FEC’s requirements. This level of control results in a network that operated in a predictable way.

The most important benefit of MPLS is that it provides a foundation that permits ISPs to deliver new services that cannot be readily supported by conventional IP routing techniques. ISPs face the challenge of not only delivering superior service, but also providing new services that distinguish them from their competition. MPLS allows service providers to control costs, provide better levels of base service, and offer new revenue-generating customer services. With careful planning, MPLS provides ISPs a finer level of control over traffic [13] [14] [15], resulting in a network that is more efficiently operated and can offer the flexibility required to meet constantly changing customer expectations. 3.1 BGP/MPLS Virtual Private Networks With the above advantages, MPLS is the future routing technology of the internet. An additional key benefit of MPLS is its support for Virtual Private Networks (VPNs), thus allowing service providers to sell internet based networking services to large corporate customers. One of the types of VPN supported by MPLS is called BGP/MPLS VPNs (RFC-2547bis) [16] [17]. It entirely works on layer-3 and use extensions to the existing routing protocol of Internet (BPG-4) to interconnect remote locations. These VPNs are contingent on MPLS LSPs, so they provide the user with all benefits associated with this technology.

Figure 18 MPLS based VPN Approach

Consider figure 18. An architectural paradigm is described in which services are implemented at the edge of the network. The VPNs only exist at the edge of the service provider’s network. The core routers do not participate in the actual VPNs, they just continue to forward packets over various LSPs. The customer’s routers also do not participate in the VPNs, since they simply continue to route IP packets in according to the customer’s established addressing and routing schemes.


CE Routers These are the Customer Edge devices. These routers are customer owned routers. They run the routing protocols of the customer’s choice, and they support the IP address scheme implemented by the customer. These routers are unaware of the existence of the MPLS protocol or the VPNs. However, the “next hop” router from the CE’s perspective is the PE router. P Routers The P Routers are the Provider routers in the core of the network. These are the label switch routers (LSRs) referred to in the MPLS overview section above. These routers switch MPLS packets over established LSPs. These, too, are entirely unaware of the existence of RFC 2547 VPNs. PE Routers All of the functions associated with establishing, maintaining and operating MPLS VPNs take place in the PE routers. A PE router is directly connected to the customer edge (CE) routers. Typically, a PE device will be connected to multiple CE devices supporting different customers. These routers must run BGP-4, including the BGP/MPLS VPN extensions. Thus, the PE router will participate in the customers' Layer 3 networks; it will learn all of the customers’ routes and will deliver packets derived from that information. The PE router also must communicate with other PE routers to exchange reachability information. To accomplish this task, PE routers run Multi-Protocol BGP on their wide area links. The PE routers will also need to initiate and terminate LSPs for MPLS traffic to be routed across the backbone (via the P routers). This means PE routers must also implement the MPLS protocol as edge LSRs. RFC 2547 VPNs address security by supporting traffic separation and segmentation. When properly implemented, and when the service provider’s routers are all correctly provisioned, each individual customer is represented by a unique VRF. Traffic destined for each VRF will carry its own inner label value. Therefore, Company A’s data traffic will be logically and physically separated from Company B’s information. This method is directly analogous to the security offered by a Frame Relay network. Additional measures can be implemented to supplement the basic security features associated with RFC 2547 VPNs. Encryption is probably the most desirable method for ensuring data security; most IP encryption mechanisms can reside seamlessly on top of an MPLS infrastructure. 3.2 MPLS based VPNs through Multiple Autonomous Systems In some cases, VPNs need to reside on different autonomous systems in different geographic areas. Also, some VPNs need to extend across multiple service providers [19]. Regardless of the complexity and location of the VPNs, the connection between autonomous systems must be seamless to the customer and should be able to provide the required performance guarantees.


Figure 19 MPLS based VPNs through Multiple Autonomous Systems As shown in the figure 19, suppose CE A-1 connected to service provider A wants to communicate with CE A-3 connected to another service providers network B, there are two possibilities in which it can take place:

1. At PE-A the label is removed and communication between PE-A and PE-B takes place through tradition routing using BGP. The scope of Traffic Engineering is very limited in this method. When the packet reaches PE-B, a new label is inserted according to available FEC in network B and it routed through LSPs to PE and to CE A-3.

2. At PE-A the Label is not removed and the same Label information is passed to PE-B.

This has been proposed in RFC-3107 [18], “Carrying Label Information in BGP-4”. When BGP is used to distribute a particular route, it can be also be used to distribute a MPLS label which is mapped to that route. Label distribution can be piggybacked in the BGP Update message by using the BGP-4 Multiprotocol Extensions attribute.

If somehow there is a way in which the FEC information is exchanged between the network providers, the PEs receiving packets from another provider network can map the incoming packets to FECs available in its network according to the required performance criteria, one would be able to offer best effort end-to-end performance guarantees and service providers will have more flexibility for Traffic Engineering in VPNs spanning through multiple providers network. The MPLS VPN through different autonomous systems can provide the following benefits:

1. Present MPLS VPN could only traverse a single BGP autonomous system service provider backbone. The proposed inter autonomous system feature allows multiple autonomous systems to form a continuous and seamless network between customer sites of a service provider.

2. Having all VPN traffic flow through one cross point allows for better rate control of

network traffic between different areas.


3. It can make IBGP meshing in an autonomous system more organized and manageable. We can divide a large autonomous system into multiple sub-autonomous systems and then classify them into a single confederation. This capability allows a service provider to offer MPLS VPNs across the confederation because it supports the exchange of labeled VPN-IPv4 NLRI between the sub-autonomous systems that form the confederation.

Cisco and Juniper Networks has come up with the concept of using dedicated routers known as Border Edge Router (EBGP) for interconnecting two different service provider networks or two sites for same service providers [19] as shown in figure 20. The next hop address for ASBR1 is the address of ASBR2 and vice versa. The task of ASBR1 and ASBR2 is to exchange label information and to advertise VPN IPv4 external routes.

Figure 20 EBGP Connections between Two Autonomous Systems

Teleglobe which is considered as the third largest backbone in the world has deployed MPLS directly over IP core. MPLS functionalities allow Teleglobe to launch range of new services ranging from VPNs to interprovider VPNs that require QoS guarantees which public IP network cannot support. But analysts say that MPLS based peering agreements that would make the public Internet capable of carrying business grade applications that require better-than-best-effort delivery quality are still ages away. For now, inter carrier agreements for specific applications, such as VPNs, are more economically viable.

MPLS peering means interprovider capability to provide MPLS-based services not only through different autonomous systems owned by particular provider but to establish this capability with other providers. This in turn can be termed as many-to-many carrier peering, if all carriers


involved could agree on the exact nature of MPLS parameters peered and schedules for their settlement in different countries.

The chances of this business are very slim because ‘Carriers’ in this field namely Teleglobe and others with MPLS powered services including AT&T, Global Crossing, Infonet and Level 3 Communications have no financial incentive to do such many-to-many peering. They earn on the CoS provided and every company defines class of service differently. So until unless every provider go one by one in each country with each carrier partner and find together what you will agree to treat as class of services, MPLS based peering is not possible. Also the enterprise customers who will buy the QoS enhanced services will have to keep in mind the geographic reach of their provider and its interconnection partners.

Summary In this paper we tried to investigate strategies for interconnecting Internet Backbones. The two best established models for internet traffic exchange are peering and transit. Peering is settlement free whereas Transit is paid connnection. We discuss technical and non technical issues involved for interconnecting Backbone providers. We have explained the role of BGP for offering best-effort performance guarantees and how the policies for giving connection to other provider, are decided by ISP. The concept of MPLS based VPNs which are prerequiste for MPLS based peering connection has been discussed. In this context we have tried to explore how the advantages offered by MPLS technology can indeed be useful for ISPs interconnections. We have also given our views on non-technical issues like whom should peer, who should take transit and reasons for refusing peering connection. Acknowledgement We are thankful to Dr. Vishal Sharma for providing this opportunity to do this research project. His periodic and precise guidance has helped us to gain a deeper insight in this topic. His regular encouragement kept us focused on the main topics of this project. He has widen our knowledge of current issues in this field. Reference [1] Michael Kende, “The Digital Handshake: Connecting Internet Backbones”, September 2000

[Online]. Available: http://www.fcc.gov/Bureaus/OPP/working_papers/oppwp32.pdf accessed on March 18, 2005

[2] K. Cukier, “Peering and Fearing: ISP Interconnection and Regulatory Issues”, [online].

Available: http://macross.dynodns.net/idr/Cukier.html accessed on March 18, 2005 [3] Network Reliability and Interoperability Council V, Focus Group 4: Interoperability, “Service

Provider Interconnection for Internet Protocol Best Effort Service”, [online]. Available: http://www.nric.org/fg/fg4/ISP_Interconnection.doc accessed on March 24, 2005

[4] Internet Routing-Border Gateway Protocol, [online]. Available:

http://livinginternet.com/i/iw_route_egp_bgp.htm accessed on March 5, 2005 [5] BGP – The Border Gateway protocol, Advanced Internet Routing Resources, [online].

Available: http://www.bgp4.as accessed on March 5, 2005


[6] Paul Ferguson, “A Introduction to Border Gateway Protocol (BGP)”, September 1997, [online]. Available: http://www.academ.com/nanog/feb1997/BGPTutorial accessed on February 24, 2005

[7] Y Rekhter, T. Li, “A Border Gateway Protocol 4 (BGP-4)”, RFC 1771, March 1995 [8] Documentation, “Internetworking Case Studies”, Cisco Systems, [online]. Available:

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics accessed on March 20, 2005 [9] William B Norton, “A Business case for ISP peering”, February 2002, [online]. Available: www.equinix.com/pdf/whitepapers/Business_case.pdf accessed on April 10, 2005 [10] Anton Riedl, “A Hybrid Genetic Algorithm for Routing Optimization in IP Networks

Utilizing Bandwidth and Delay Metrics”

[11] Multiprotocol Label Switching (MPLS), On-Line Education, IEC, [online]. Available: http://www.iec.org/online/tutorials/mpls/index.html accessed on April 10, 2005

[12] MPLS-An Introduction to Multiprotocol Label Switching, Nortel Networks [13] George Swallow, “MPLS Advantages for Traffic Engineering”, IEEE Communication

Magazine, December 1999 [14] Xipeng Xiao, Alan Hannan, Brook Bailey and Lionel M. Ni, “Traffic Engineering with

MPLS in the Internet” [15] Robert Pulley, Peter Christensen, Netplane System, Inc., “A Comparison of Multiprotocol

Label Switching (MPLS) Traffic – Engineering Initiatives” [16] Chuck Semeria, Juniper Network, Inc., “RFC 2547bis: BGP/MPLS VPN Fundamentals” [17] Joel Repiquet, LambdaNet, Inc., “Keep it Simple with BGP/MPLS Virtual Private

Networks”, White paper, May 2002 [18] Y. Rekhter, E. Rosen, “Carrying Label Information in BGP-4”, RFC 3107, May 2001. [19] Interprovider and Carrier-of-Carrier VPNs Overview, Chapter 17, “JUNOS 6.4 VPNs

Configuration Guide”

Table of Contents - ee.iitb.ac.inprakshep/Ippipn_report.pdf · Table of Contents Sr no. Content ......

Documents

Transcript of Table of Contents - ee.iitb.ac.inprakshep/Ippipn_report.pdf · Table of Contents Sr no. Content ......