JP2012175198A - Circulation route setting system and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To cause a traffic to circulate in respectively different circulation path for each VPN for a site (a common site) belonging to plural VPNs.SOLUTION: In a provider edge PE accommodating a common site, a VPN is generated on a physical network and stored on second storage means with the VPN correlated with a virtual routing/transfer VRF instance associated with respective site for each service; based on an address obtained from a customer edge or another provider edge, path information of a global routing table storing all edge path information and router path information is retrieved, and path information stored in a VRF corresponding to the VRN applicable to each router for each VPN is retrieved for each VPN stored in second storage means; and, based on the retrieved path information, a packet is transferred using an MP-iBGP.

Description

  The present invention relates to a distribution route setting system and method, and more particularly, to a distribution route setting system and method for distributing traffic using different distribution routes for each service.

Specifically, a network that provides network services for general subscribers (Internet connection, IP phone, IPTV, etc.) distributes addresses necessary for services such as subscriber addresses, server addresses, and gateway addresses to the network. Provide connectivity between each service provider and subscriber. Here, the term “service” refers to providing subscribers with connectivity to a specific service provider so that traffic can be distributed.
Normally, in such a network, the traffic of each service is mixed on the physical network, and the route is determined by a common route control algorithm. However, since the bandwidth and reliability conditions required for each service are different, common route control is not always suitable. That is, it may be necessary to adopt a route control method in which traffic is distributed using a different distribution route for each service.

  There are two typical methods for distributing traffic using different distribution routes for each service.

  First, there is a method of executing the following policy-based routing in each router. In other words, each router performs the operations of (1) identifying the service using the source address and QoS identifier of each packet, (2) determining the next hop from the destination, and outputting the packet from the appropriate interface. .

  For (1) and (2), it is necessary to perform static route setting in advance for each router in an amount proportional to the number of services x the number of destinations.

  Next, there is a method of configuring a plurality of virtual private networks (VPNs) capable of independent path control for each service on a common network. As a typical implementation, a virtual router is configured for each service in each router, and virtual routers of the same service are connected by a tunnel, a logical interface, or the like. In this case, as many routing instances as VPNs operate in each router.

  The above-described method based on policy-based routing has a problem that the amount of setting in advance for each router for realizing the routing operation becomes enormous.

  In addition, the method using the virtual router has a problem that processing overhead becomes very large because a plurality of routing instances independently perform route exchange and routing operation.

  There is a BGP (Border Gateway Protocol) / MPLS (Multi Protocol Label Switching) VPN (see, for example, Non-Patent Document 1) as a logical network division method with a small amount of setting and processing overhead. This is similar to the method using a virtual router, but the infrastructure route information and user route information are handled separately, and the user route information is exchanged in a common session using MP-BGP, thereby reducing the overhead. In addition, each VPN instance in each router performs destination-based dynamic routing, so there is less effort for pre-configuration.

  For these reasons, it seems to be an alternative to the policy-based routing method and the virtual router method.

  However, since this technology is a technology for connecting multiple sites such as corporate bases with VPN, it is possible to duplicate VPNs and have connectivity to a specific site at the same time. In this case, there is a restriction that all routes from each site accommodated in the same provider edge (PE) to the common site are the same.

IETF RFC2547

  The above-mentioned restrictions of BGP / MPLS VPN occur as follows.

  Consider a network with VPN A including site A and common sites a, b, c, and d and VPN B including site B and common sites a, b, c, and d as shown in FIG.

  At this time, one VRF (Virtual Routing Forwarding) instance is created in the PE that accommodates the common site (VRF1, VRF2). A VRF is a routing instance associated with each site. Here, since the common site a and the common site b have common routing information, they are summarized as VRF1.

  Similarly, PE3 that aggregates customer edges (CE) connected to sites A and B creates VRF for each site A and B (VRF3 and VRF4). Each VRF has an independent routing table and exchanges routes with CEs of each connected site A and B. VRF3 then exchanges routes with VRF1 and VRF2 to form VPN A {VRF1, VRF2, VRF3}.

  Similarly, VRF4 also exchanges routes with VRF1 and VRF2, and configures VPN B {VRF1, VRF2, VRF4}.

  In addition, a tunnel for forwarding traffic is defined in each PE. Here, one-way tunnels (T1, T2) from PE3 to PE1 and PE2 are shown, but tunnels from PE1, PE2 to PE3 are also required to actually distribute traffic in both directions. It is. T1 is a tunnel to the loopback address of VRF1, and T2 is a tunnel to the loopback address of VRF2. These need to be set in the PE3 global routing instance.

In FIG.
(1) Assume that packets are sent from site A and site B to common site a.

  (2) A search for the next hop for the destination address of the common site a is performed on VRF3. Since VRF3 has received the address of the common site a from VRF1, the loopback address of VRF1 is selected as the next hop.

  (3) Similarly, the next hop search for the destination address of the common site a is also performed on the VRF 4. Since VRF4 receives the address of the common site a from VRF1, the loopback address of VRF1 is selected as the next hop.

  (4) Next, for both the VRF3-derived packet and the VRF4-derived packet, the next hop for the loopback address of PE1's VRF1 is searched in the PE3 global routing table (recursive Brookup). Then, since it is understood that the connection is made by T1 defined in advance, T1 is selected as the output destination.

  Thus, the packet from site A and the packet from site B are similarly sent to the loopback address of VRF1 using T1. Even if PE3 has a tunnel T3 going to VRF1 that is different from T1, and traffic from VRF3 uses T1, traffic from VRF4 wants to use T3, as long as it is processed on the global routing instance, In this case, since route selection in consideration of VRF cannot be performed, either T1 or T3 is commonly used.

Accordingly, when a plurality of VPNs are connected to a common site as in the network shown in FIG. 7, there arises a problem that independent distribution routes cannot be controlled for each VPN.
For example, in a network that provides network services for general subscribers (Internet connection, IP phone, IPTV, etc.), the subscriber is a common site. BGP / MPLS VPN cannot be used for the purpose of controlling distribution channels independently.

  The present invention has been made in view of the above points, and a distribution route setting system capable of distributing traffic through a separate distribution route for each VPN with respect to sites (common sites) belonging to a plurality of VPNs, and It aims to provide a method.

In order to solve the above-mentioned problems, the present invention provides a site having a customer edge at a gateway of each site and a common site, a router that aggregates the customer edge as a provider edge, and a provider router that is a router that relays between the provider edges. A connected distribution channel setting system,
The customer edge is
A first storage means storing route information of a site to which the customer edge belongs;
Publicity means for notifying the provider edge of the path information of the first storage means via a different interface for each virtual closed network (Virtual Private Network: VPN) capable of independent path control for each service;
Have
The provider edge PE that accommodates the common site is:
A global routing table that stores all edge route information and router route information;
A table generating means for generating a VPN on a physical network and storing the VPN in a second storage means in association with a virtual routing forwarding (VRF) instance associated with each site for each service;
Based on the destination address, the route information stored in the VRF corresponding to the corresponding VPN of each router for each VPN for each VPN stored in the second storage means and the route information in the global routing table And a packet transfer means for transferring a packet by MP-iBGP (MP-internal Border Gateway Protocol) based on the searched route information.

  By using the present invention, it is possible to remove the restriction that traffic cannot be distributed from a plurality of VPNs using different distribution routes to a site connected to the plurality of VPNs of BGP / MPLS VPN. As a result, a network that distributes traffic from a plurality of VPNs to a common site using different distribution routes can be configured more efficiently than in the conventional method.

  Specifically, infrastructure route information and user route information are handled separately, and user route information is exchanged in a common session using MP-BGP. Less overhead for route exchange.

  In addition, each VPN performs destination-based dynamic routing, so pre-configuration requires only a VPN definition for each service, and requires less time for pre-configuration than policy-based routing.

2 is a configuration of a network system and a packet transfer process to a common site according to an embodiment of the present invention. It is a block diagram of CE (customer edge) in one embodiment of the present invention. It is a block diagram of (provider edge) in an embodiment of the present invention. It is an example of the table in PE in one embodiment of this invention. It is the process of packet transfer from the common site in one embodiment of this invention. It is a figure which shows the method in which the route exchange part in one embodiment of this invention acquires the route information advertised from CE. It is a network block diagram of the 1st Example of this invention. It is a network block diagram of the 2nd Example of this invention. This is a restriction on route selection to a common site in the conventional BGP / MPLS VPN.

  Embodiments of the present invention will be described below with reference to the drawings.

  Below, the gateway of each site is called a customer edge (CE). A router that aggregates CEs is called a provider edge (PE), and a router that relays between provider edges is called a provider (P) router.

  FIG. 1 shows a configuration of a network system and a packet transfer process from a common site according to an embodiment of the present invention.

  CE, PE, and P are connected as shown in FIG. 1, and a plurality of virtual private networks (VPNs) are configured on the physical network. It is assumed that there is VPN A including site A and common sites a, b, c and d, and VPN B including site B and common sites a, b, c and d.

  As shown in FIG. 2, each of the CEs 1 to 4 has a routing table 11 and a route information advertising unit 12, and holds the route information of the site to which it belongs in the routing table 11. The route information advertising unit 12 of the CEs 1 to 4 advertises route information possessed by itself to the PE. Normally, this advertisement may be performed in one session for each PE from each site. However, in the present invention, the CEs 1 to 4 of the common sites a, b, c, and d correspond to the corresponding VPN to the PE. Each corresponding route information is advertised by a different interface. For example, when there are three VPNs and the common sites a, b, c, and d use all three VPNs, the information on the route X is advertised to each VPN through three different logical interfaces for each VPN. This interface may be any interface that the router recognizes as another interface, and may be physically the same and separated as a logical interface, or may be physically different. A logical interface based on IEEE 802.1Q is considered.

  FIG. 3 shows a configuration of PE (provider edge) in an embodiment of the present invention.

  Each of the PEs 1 to 3 includes a global routing table 21, a route exchange unit 22, and a VRF.

  As shown in FIG. 4, the global table 21 holds the identification information of the destination VRF and the identification information of the output destination tunnel in association with each other.

  The route exchange unit 22 has a function of acquiring route information advertised from the CE, a function of creating a VRF, a function of exchanging a route with the VRF, and a function of searching for a tunnel.

  A method of acquiring the route information advertised from the CE will be described later with reference to FIG.

  The VRF creation function is created as a process on the router OS as the VRF function defined in “http://www.ietf.org/rfc/rfc4364.txt”.

  The function for exchanging routes with the VRF uses the multiprotocol BGP “htt: //tools.iet.org/html/rfc4760” to exchange routes by the method described in RFC4363.

  The tunnel search function searches for a tunnel set in the local PE from the global routing table 21.

  Also, the PE that exchanges routes with the common sites a, b, c, and d sets the VRF (VPN Routing and Forwarding) for each VPN, not for each common site, and for routing that associates the interface connected to the common site. The table 23 is held, and the path exchanging unit 22 refers to the routing table 23 and the global table 21 and performs path exchanging for each VRF. As shown in FIG. 4, the routing table 23 holds the identification information of the destination site (common site, general site) and the identification information of the next hop VRF in association with each other, and also identifies the CE identification information of the destination site. And the interface to the CE of the site associated with the own VRF.

  In the example of FIG. 4, “VRF1” is associated with the interface connected to the common site a and the common site b.

  A PE that exchanges routes with normal sites (Site A and Site B) creates a VRF for each site and associates the site with it. This VRF is also per VPN.

  Then, the route exchange unit 22 exchanges route information stored in the VRF of the corresponding VPN of each router for each VPN between the PEs by MP-iBGP. VRF1, VRF2, and VRF3 exchange paths with each other, and VRF4, VRF5, and VRF6 exchange paths with each other.

  In addition, a tunnel for passing traffic through the PE-PE connection is defined and set in the VRF routing table. In each PE, a tunnel is defined for each VRF of the common sites a, b, c, and d. For example, in PE3, the tunnel to VRF1 and the tunnel to VRF2 are defined as different.

  The detailed packet transfer operation process is as follows.

  This will be described below with reference to FIGS.

  (1) First, in FIG. 1, consider a case where a packet is sent from the site A and the site B to the common site a.

  (2) The route exchange unit 22 of the PE 3 searches for the next hop (VRF 1) for the destination address of the common site a on the VRF 3 routing table 23 of the PE 3 for the packet from the site A. Since VRF3 receives the address of common site a from VRF1 of PE1, the loopback address of VRF1 is selected as the next hop.

  (3) Similarly, the route exchange unit 22 of the PE 3 searches for the next hop for the destination address of the common site a on the routing table 23 of the VRF 4 of the PE 3 for the packet from the site B. Since VRF4 has received the address of common site a from VRF5 of PE1, the loopback address of VRF5 is selected as the next hop.

  (4) Next, the route exchange unit 22 of PE3 searches the routing table 23 for the next hop for the loopback address of VRF1 for the packet derived from VRF3 of PE3 (recursive Brookup). Then, since it is understood that the connection is made through the tunnel T1 defined in the global routing table 21 of VRF3 in advance, T1 is selected as the output destination.

  (5) On the other hand, for the packet derived from VRF4 of PE3, the next hop for the loopback address of VRF5 is searched on the routing table 23. Then, since it is understood that the connection is made by the tunnel T2 defined in the global routing table 21 of the VRF 3 in advance, T2 is selected as the output destination.

  (6) In this way, the packet is transferred between PE3 and PE1 using different routes T1 and T2 depending on whether the packet is from the site A or the packet from the site B. A packet that reaches each VRF of PE1 is transferred to the common site a according to the routing table 23 of each VRF.

  FIG. 5 shows a process of packet transfer from a common site according to an embodiment of the present invention.

  (1) Consider a case where a packet directed from the common site a to the site A and a packet directed to the site B are transmitted.

  (2) Since the CE of the common site a learns the arrival route to the site A from the interface connected to the VRF1, the packet to the site A is transmitted from the interface connected to the VRF1. Then, the route switching unit 22 of PE1 searches the next hop for the destination address of Site A on the routing table 23 of VRF1 of PE1, and selects the loopback address of VRF3 as the next hop.

  (3) Similarly, since the CE of the common site a learns the route to reach Site B from the interface connected to VRF5, the packet to Site B is sent from the interface connected to VRF5. Sent out. Then, the route exchange unit 22 of PE1 searches for the next hop for the destination address of the site B on the routing table 23 of VRF5, and selects the loopback address of VRF4 as the next hop.

  (4) Next, for a packet derived from VRF1, the route switching unit 22 of PE1 searches the next routing for the loopback address of VRF3 on the global routing table 21 of PE1. Then, since it is understood that the connection is made by the tunnel T5 defined in the routing table 23 of VRF3 in advance, T5 is selected as the output destination.

  (5) On the other hand, for the packet derived from VRF5, the route switching unit 22 of PE1 searches the global routing table 21 for the next hop for the loopback address of VRF4. Then, since it is understood that the connection is made through the tunnel T6 defined in the routing table 23 in advance, T6 is selected as the output destination.

  (6) As described above, the packet is transferred between PE1 and PE3 using different routes T5 and T6 depending on whether the packet is to the site A or the packet to the site B. A packet that reaches each VRF of PE3 is transferred to the common site a according to the routing table 23 of each VRF.

  FIG. 6 shows a method for acquiring route information advertised from CE by the route exchange unit according to the embodiment of the present invention.

  As methods for acquiring route information, there are two methods of acquiring a route using a routing protocol and statically setting a route, as shown in FIGS.

  The method shown in (A) of FIG. 2 receives a route by a routing protocol (BGP, IS-IS, OSPF, etc.) that establishes an adjacency relationship with the CE, and the PE receives a packet describing the route information transmitted from the CE. Import the route into the VRF associated with the received interface. FIG. 2A shows an example of eBGP connection. In the figure, eBGP peering is performed between the interface 1 of PE3 and the interface 2 of CE. The CE advertises the route by eBGP (sends a BGPupdate packet describing the route with itself as the next hop to the interface 1). As a result, PE3 receives the route from interface 1 and stores it in the routing table 23 of VRF3.

  In the method shown in FIG. 5B, a route that can be reached by the corresponding CE is set in the PE itself. In the example shown in the figure, a route with CE as the next hop is set in the routing table 23 of VRF3. Unlike the method (A) described above, no route information packet is received from the CE.

  In FIG. 1 and FIG. 5, the global routing table 21 is described only in PE3 (PE1, PE2), but this shows only the table related to the traffic flow. In practice, every router always has a global routing table.

[First embodiment]
As an embodiment of the present invention, FIG. 7 shows an example of a network that provides IP video distribution, IP telephone, and Internet connection to general subscribers.

  In this embodiment, each service is converted into a VPN, and traffic of each service is distributed using a total of three VPNs. Also, using the method of the present invention, a VRF connected to the CE is created for each VPN in the PE, and connected to the CE through a different interface for each VRF. In FIG. 7, VRF1 and VRF4 constitute a video delivery service VPN. Similarly, {VRF2, VRF5} constitutes a VPN for telephone service, and {VRF3, VRF6} constitutes a VPN for Internet connection service.

  By setting MPLS TE LSP tunnels to the loopback addresses of these VRFs between PEs and PEs, traffic is distributed through different distribution routes for each VPN.

[Second Embodiment]
In the present embodiment, an example will be described in which a native P2P communication service between subscribers and a native connection by default route advertisement from an external network are provided.

  The example of FIG. 8 is a configuration example for realizing path control for each service in a network that provides a native P2P communication service between subscribers and a native connection by default route advertisement from the external network 10. In this example, the subscriber uses the assigned global address (IPv4 address or IPv6 address) in common for P2P communication and external network communication.

  Further, it is assumed that the connection to the external network 10 is provided by a plurality of operators, and a default route from the connection gateway (GW) to each operator to the external network is advertised in the network. Here, the external network 10 shows two companies, Company A and Company B, but in principle there is no limit on the number of operators.

  Here, there are three types of subscribers. In other words, a subscriber (A user) who has contracted with A company to provide external network connection, a subscriber (B user) who has contracted with B company to provide external network connection, and has not contracted to provide external network connection, but through this network A subscriber (P2P user) who subscribes to a P2P communication service. A user and B user can also use the P2P communication service.

  In this example, the VPN for company A (VRF1, VRF2, VRF3, VRF7) and the VPN for company B (VRF4, VRF5, VRF6) are configured independently. The VPN for Company A is a VPN that imports only the default route information to the user A and the external network connection point of Company A (company A connection point). Similarly, the VPN for company B is a VPN that imports only the default route information to the user B and the connection point of company B. Separately, P2P VPN is also configured. This is a VPN that imports route information for all A users, B users, and P2P users.

  In other words, the CEs of the common sites a and b advertise the route information of all accommodated subscribers that corresponds to the A user to the VPN for Company A, and the CE that corresponds to the B user to the VPN for Company B. To do. It also advertises all route information to the VPN for P2P.

  Furthermore, the CEs of the common sites a and b receive only the route information from the P2P VPN from the interface associated with the corresponding VRF. Routes from Company A's VPN and Company B's VPN (default routes and user routes) are not received. When each CE at the common site receives a packet for a destination that is not listed in its routing table, if the source address is A user, it forwards it to VPN for Company A. Policy-based routing that is forwarded to Company B's VPN. This setting can be realized only by setting the amount proportional to the number of operators in each CE of the common sites a and b if the user addresses are effectively aggregated.

  Further, the CE at the connection point has a default route for the external network 10. Then, the default route is advertised to the corresponding VPN of the PE (for example, the CE for the A company connection point to the VPN for A company). Furthermore, route information of each user is imported from each company VPN. P2P user routes are not imported.

  In this way, it is possible to distinguish between P2P communication and communication for external networks, and in each company VPN, routing to the connection point is performed according to the default route.

The up traffic from user A to the external network 10 is
A user a-CE-VRF1-VRF3-CE-A company connection point-external network. The reverse traffic from the external network toward user A is the opposite. In addition, when there are multiple connection points of Company A, such as Site A1 and Site A2, either site is selected as a route to external network 10 by some route selection algorithm or static setting in each VRF of Company A VPN. The For example, A user a can use site A1, and A user b can use site A2.

  Communication between P2P users is performed like P2P user a-CE-VRF8-VRF9-CE-P2P user b. Communication between A user and B user is also performed using VPN for P2P. For example, communication between the B user a and the A user b is performed like the B user a-CE-VRF8-VRF9-CE-A user b.

  In addition, the operation of each common site, each PE, and the components in each site in the above embodiment is constructed as a program, installed in a computer used as each common site, each PE, and each site, and executed. Alternatively, it can be distributed via a network.

  The present invention is not limited to the above-described embodiments and examples, and various modifications and applications are possible within the scope of the claims.

10 External network 11 Routing table (within CE)
12 Route information advertising part 21 Global routing table (in PE)
22 Route conversion part (in PE)
23 Routing table (in VRF)
T1-T8 tunnel
PE1 to PE3 Provider edge
VRF1 to VRF9 Virtual routing forwarding
VPN A to VPNB Virtual closed network

Claims (4)

A distribution path setting system in which a site having a customer edge and a common site at a gateway of each site, a router that aggregates the customer edge as a provider edge, and a provider router that is a router that relays between the provider edges are connected.
The customer edge is
A first storage means storing route information of a site to which the customer edge belongs;
Publicity means for notifying the provider edge of the path information of the first storage means via a different interface for each virtual closed network (Virtual Private Network: VPN) capable of independent path control for each service;
Have
The provider edge PE that accommodates the common site is:
A global routing table that stores all edge route information and router route information;
A table generating means for generating a VPN on a physical network and storing the VPN in a second storage means in association with a virtual routing forwarding (VRF) instance associated with each site for each service;
Based on the destination address, the route information stored in the VRF corresponding to the corresponding VPN of each router for each VPN for each VPN stored in the second storage means and the route information in the global routing table A packet transfer means for searching and transferring a packet by MP-iBGP (MP-internal Border Gateway Protocol) based on the searched route information;
A distribution channel setting system characterized by comprising: The provider edge is
2. The distribution route setting system according to claim 1, further comprising means for defining a tunnel for transferring traffic in both directions of the provider edge for each VRF and storing it in the second storage means. A distribution route setting method in a router network in which a site having a customer edge at a gateway of each site and a common site, a router that aggregates the customer edge as a provider edge, and a provider router that is a router that relays between the provider edges are connected. And
In the provider edge PE that accommodates the common site,
A VPN is generated on the physical network, is associated with a virtual routing forwarding (VRF) instance associated with each site for each service, and is stored in the second storage means.
Based on the destination address acquired from the customer edge or other provider edge, the route information of the global routing table storing all edge route information and router route information, and the VPN stored in the second storage means For each VPN, the route information stored in the VRF corresponding to the corresponding VPN of each router is searched for, and based on the searched route information, the packet is transmitted by MP-iBGP (MP-internal Border Gateway Protocol). The distribution route setting method characterized by transferring. In the provider edge,
For each VRF, define a tunnel for forwarding traffic in both directions of the provider edge and store it in the second storage means,
4. The distribution route setting method according to claim 3, wherein a tunnel defined in the second storage means is an output destination of the packet.

Images