US20060126644A1 - VPN router and VPN identification method by using logical channel identifiers - Google Patents
VPN router and VPN identification method by using logical channel identifiers Download PDFInfo
- Publication number
- US20060126644A1 US20060126644A1 US11/349,154 US34915406A US2006126644A1 US 20060126644 A1 US20060126644 A1 US 20060126644A1 US 34915406 A US34915406 A US 34915406A US 2006126644 A1 US2006126644 A1 US 2006126644A1
- Authority
- US
- United States
- Prior art keywords
- vpn
- protocol
- lan
- packet
- router
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims description 28
- 239000002775 capsule Substances 0.000 claims description 65
- 238000012545 processing Methods 0.000 claims description 56
- 230000005641 tunneling Effects 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims 8
- 230000003287 optical effect Effects 0.000 claims 4
- 230000001360 synchronised effect Effects 0.000 claims 4
- 101100048435 Caenorhabditis elegans unc-18 gene Proteins 0.000 description 25
- 238000010586 diagram Methods 0.000 description 10
- 238000005538 encapsulation Methods 0.000 description 9
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- -1 LAN4 Proteins 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- RGNPBRKPHBKNKX-UHFFFAOYSA-N hexaflumuron Chemical compound C1=C(Cl)C(OC(F)(F)C(F)F)=C(Cl)C=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F RGNPBRKPHBKNKX-UHFFFAOYSA-N 0.000 description 1
- 230000013011 mating Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000000275 quality assurance Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
- H04L2012/5621—Virtual private network [VPN]; Private-network - network-interface (P-NNI)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
- H04L2012/5669—Multiprotocol over ATM [MPOA]
Definitions
- VPN Virtual Private Network
- One implementation method of reliable data transmission across a VPN is such that data encapsulation is performed at the entrance to a network of an Internet service provider (hereinafter referred to as ISP) that provides the VPN.
- ISP Internet service provider
- the encapsulated data is transferred across the ISP's network, according to the capsule header, and this header is removed at the exit of the network.
- VPN-specific encapsulation headers for datagrams that pass across the Internet, VPNs with ensured security can be formed.
- Practically used encapsulation protocols are IP capsule, Multi Protocol Over ATM (MPOA), Multi Protocol Label Switching (MPLS), and other ones.
- MPOA Multi Protocol Over ATM
- MPLS Multi Protocol Label Switching
- IETF Internet Engineering Task Force
- IP addresses are divided into global IP addresses and private IP addresses.
- Global IP addresses are globally defined unique addresses, whereas private IP addresses can be freely defined by a corporation. Private IP addresses are often used in intra-corporation networks. Thus, it is desirable that private IP addresses can be used when corporations use VPN service. If there are a plurality of VPNs and private IP addresses are used in the VPNs, it may happen that an IP address used in one VPN is also used in another VPN. If IP address duplication exists among a plurality of VPNs, a router that is placed at the entrance to the ISP network and interconnects Local Area Networks (LANs) belonging to the VPNs (this router is hereinafter referred to as a VPN edge router) must hold routing tables separately created for the VPNs in order to properly forward packets across the VPNs.
- LANs Local Area Networks
- the VPN edge router Upon the reception of a packet, the VPN edge router finds one of the VPNs to which one of the LANs belongs across which the packet passed. Then, the VPN edge router searches the routing table for the thus found VPN, determines the forwarded-to-destination of the packet across the ISP network, and encapsulates the packet. Because the VPN edge router holds the routing tables separately created for the VPNs, even if it receives packets passed across different VPNs, but having a same destination IP address, it can forward the packets to their correct destinations without mistaking one for another.
- VPN identification is performed on a physical interface by interface basis, wherein correspondence of one physical interface to one VPN is required.
- one physical line connects a corporate network to the ISP network.
- the VPN edge router that interconnects the VPNs must have as many physical interfaces as the number of the VPNs. Consequently, a problem arises that expansion of VPNs interconnected by the VPN edge router expands the physical interfaces of the VPN edge router and eventually additional routers are required.
- a plurality of logical channels are multiplexed and terminated to one physical interface at the entrance of the ISP network. These multiplexed logical channels cannot be identified by VPN identification by physical interface and this is another problem due to the limitation of the previous VPN identification method.
- An object of the present invention is to enable VPN identification by using the identifiers of logical channels multiplexed and terminated to a physical interface.
- Another object of the present invention is to enable VPN identification by using different kinds of VPN identifiers proper for a plurality of different protocols that are used as lower layer protocols below IP predefined for LANs that are interconnected by the router.
- the VPN edge router of the present invention identifies VPNs by using the identifiers of logical channels multiplexed and terminated to a physical interface.
- the logical channel identifiers information for lower layer protocols below IP is used; e.g., information equivalent to layer 2 prescribed in an OSI model.
- the logical channel identifiers are expressed in combined VPI and VCI values specified in the header of packets if an ATM protocol is the lower layer protocol of the IP packets or DLCI values if a frame relay is the lower layer protocol.
- IP packets are encapsulated with an L2TP header prescribed by a Layer2 Tunneling Protocol (L2TP)
- L2TP Layer2 Tunneling Protocol
- information (such as tunnel ID and session ID) specified in the L2TP header can be used as logical channel identifiers.
- the lower layer is an Ethernet and VPN identification is performed by using VLAN Tag prescribed in IEEE802.1Q
- VLAN Tag is used as logical channel identifiers.
- IP packets are encapsulated with a capsule header prescribed by a PPP Over Ethernet encapsulation protocol, information (such as session ID) specified in the capsule header prescribed by the above protocol is used as logical channel identifiers.
- the VPN edge router holds a VPN ID indication table into which what kinds of VPN identifiers are used for VPN identification are registered.
- the VPN edge router is provided with a user interface. Assume the ATM protocol to be the lower layer below IP as an example. If physical interfaces are used for VPN identification, a “physical interface number” is set in the above VPN ID indication table. If “VPI, VCI” values are used for VPN identification, a “VPI, VCI” value is set in this table.
- the VPN ID indication table may contain settings for all physical interfaces or settings for all interface cards, each of which may accommodate a plurality of lines under a same lower layer protocol. If a plurality of logical channels under different lower layer protocols are multiplexed and terminated to one physical interface (for example, a frame relay channel and a PPP channel are multiplexed on a line by time division), the VPN ID indication table may contain settings for all combinations of a physical interface and a lower layer protocol below IP.
- the edge router searches the routing table for the VPN across which the received packet passed, determines the next forwarded-to-destination of the packet across the ISP network, and generates a capsule header containing information to be used for VPN identification in the network.
- the VPN edge router attaches this header to the packet and sends the packet to the determined next forwarded-to-destination.
- VPN identification is performed by using the identifiers of logical channels multiplexed and terminated to a physical interface as described above. Therefore, it is not necessary to provide the VPN edge router with physical interfaces corresponding to VPNs interconnected by the router.
- To connect one corporate network to a plurality of VPNs according to the invention preparing as many logical channels as the number of VPNs is only required, but preparing as many physical lines as the number of VPNs is not necessary. Even when an ATM network or a frame relay provided by another ISP or carrier is used as intermediate access means from a corporate network to the ISP network that provides VPN service, the present invention enables building a network system having VPNs because the VPNs are identified by their logical channels to the VPN edge router.
- the present invention allows the ISP network administrator to select a VPN identifier type proper for each VPN-specific lower layer protocol below IP and register it in the VPN ID indication table. Therefore, a network system can be built to comprise VPNs that run under various kinds of lower layer protocols.
- FIG. 1 is a schematic diagram for explaining a preferred embodiment of forming VPNs interconnected by VPN edge routers according to the present invention.
- FIG. 2 is a schematic diagram for explaining an example of modification to the network topology embodiment example shown in FIG. 1 .
- FIG. 3 is a schematic diagram for explaining another example of modification to the network topology embodiment example shown in FIG. 1 .
- FIG. 4 is a diagram showing an example of the configuration of the VPN edge router offered by the present invention.
- FIG. 5 is a diagram showing an example of the configuration of a packet layer processor.
- FIG. 6 shows example contents of the VPN ID indication table.
- FIG. 7 shows example contents of the VPN identification table.
- FIG. 8 shows example contents of a routing table for VPN.
- FIG. 9 shows another example of the configuration of the VPN edge router offered by the present invention.
- FIG. 10 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in a packet processing card when an ATM interface card attaches to the packet processing card.
- FIG. 11 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in the packet processing card when a POS interface card attaches to the packet processing card.
- FIG. 12 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when an interface card for time division multiplex line attaches to the packet processing card.
- FIG. 13 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when interface cards for different lower layer protocols attach to the packet processing card.
- FIG. 14 illustrates an example of the procedure for customizing the internal settings of the packet processing card.
- FIG. 15 illustrates a general operation flow of the VPN edge router offered by the present invention.
- FIG. 1 is a schematic diagram for explaining a preferred embodiment of forming VPNs interconnected by VPN edge routers according to the present invention.
- a lower layer will mean a protocol for encapsulating datagrams in IP packets. Even if an IP header is used to encapsulate datagrams of IP packets, this capsule header will be represented as a lower layer header for convenience.
- An ISP network ( 5 ) has edge routers ( 9 and 10 ) positioned at the boundaries of the network and a core router ( 17 ) positioned in the core of the network. Although a single core router ( 17 ) is shown in FIG. 1 , the number of core routers is not limited to one. Datagrams are assumed to be encapsulated by MPLS (for ATM) to pass across the ISP network ( 5 ), thus implementing reliable data transmission across VPNs. Not only this encapsulation protocol but also other encapsulation protocols mentioned above may be used.
- the ISP network ( 5 ) interconnects LAN 1 ( 1 ) and LAN 2 ( 2 ) via the edge router ( 9 ) and LAN 3 ( 3 ) and LAN 4 ( 4 ) via the edge router ( 10 ).
- the LAN 1 ( 1 ) and the LAN 3 ( 3 ) are assumed to be possessed by corporation A and one VPN is formed to cover these LANs.
- the LAN 2 ( 2 ) and the LAN 4 ( 4 ) are assumed to be possessed by corporation B and another VPN is formed to cover these LANs.
- the corporation A's VPN is to be called VPNA ( 7 ) and the corporation B's VPN is VPNB ( 8 ).
- the LAN 1 and LAN 2 are logically multiplexed on a line ( 11 ) and connected to the edge router ( 9 ) via an ATM network ( 6 ) that is provided by another ISP or carrier separately from the ISP network ( 5 ).
- a physical interface ( 12 ) interfaces the line ( 11 ) and the edge router ( 9 ).
- the physical interface means the point of connection between the router and the line.
- the LAN 3 ( 3 ) and LAN 4 ( 4 ) are connected to the edge router ( 10 ) with lines ( 13 ) and ( 14 ) respectively by using PPP Over SONET (POS) prescribed in RFC2615.
- Physical interfaces ( 15 ) and ( 16 ) interface the lines ( 13 ) and ( 14 ) with the edge router respectively.
- VPI and VCI values are used as identifiers to identify one VPN to which the LAN 1 belongs and another VPN to which the LAN 2 belongs.
- a “VPI, VCI” value shall be set in the VPN ID entry field for the physical interface ( 12 ).
- the edge router ( 10 ) uses numbers assigned to the physical interfaces as identifiers to identify one VPN to which the LAN 3 belongs and another VPN to which the LAN 4 belongs.
- a “physical interface number” shall be set in the VPN ID entry fields for the physical interfaces ( 15 ) and ( 16 ). The VPN ID indication table will be detailed later.
- the edge router ( 9 ) also internally holds a VPN identification table that maps a specific VPN ID to information that indicates what VPN across which the packet with the VPN ID passed (this information is hereinafter referred to as a VPN number).
- the above-mentioned VPNA and VPNB are used as VPN number.
- the edge router ( 9 ) internally holds routing tables that map a destination IP address of the packet to an output route number and capsule header information.
- the router holds the routing table prepared for VPNA and the routing table prepared for VPNB.
- the VPN identification table and the routing tables will also be detailed later.
- the edge router ( 9 ) When the edge router ( 9 ) receives an IP packet that is sent from the LAN 1 to the LAN 3 , it determines that “VPI, VCI” values are used as VPN identifiers, according to the setting in the VPN ID indication table. After determining the VPN identifier type, the edge router ( 9 ) searches the VPN identification table that maps “VPI, VCI” values to VPNs and finds that the packet passed across the VPNA. Then, the edge router ( 9 ) searches the routing table for VPNA for a match with the search key of the destination IP address of the packet and determines the core router ( 17 ) as the next forwarded-to-destination. At this time, the capsule header that is to be attached to the packet passed across VPNA and to be forwarded to the core router is determined as well. After this capsule header is attached to the packet, the packet is forwarded to the core router ( 17 ).
- the core router ( 17 ) has a routing table that maps capsule headers, that is, “VPI, VCI” values to next forwarded-to-destinations.
- the core router ( 17 ) searches this routing table for a match with the search key of the information in the capsule header of the received packet and determines the next forwarded-to-destination (edge router ( 10 )) and the next capsule header.
- the core router ( 17 ) attaches the next capsule header to the packet and sends the packet to the edge router ( 10 ).
- the edge router ( 10 ) which is configured identically to the edge router ( 9 ), searches its VPN identification table for a match with the search key of the information in the capsule header of the received packet and finds that the packet passed across the VPNA as the edge router ( 9 ) does. Then, the edge router ( 10 ) searches its routing table for VPNA for a match with the search key of the destination IP address of the packet and determines the forwarded-to-destination. The edge router ( 10 ) removes the capsule header from the packet and forwards the packet to the LAN 3 .
- the edge router ( 9 ) identifies a VPN by finding the VPN ID out of the identifiers of the logical channels multiplexed and terminated to the physical interface and then searches the routing table for the VPN, one of the logically multiplexed VPNs on one physical line can be identified. In this way, packets can be forwarded to their correct destinations even if an IP address used in the corporation A's network is also used in the corporation B's network.
- the sending is performed by following the same procedure as described above, except that the edge router ( 10 ), when receiving the IP packets sent from the LAN 4 to the LAN 2 , uses physical interface numbers as VPN identifiers.
- FIG. 2 is a schematic diagram for explaining an example of modification to the network topology embodiment example shown in FIG. 1 .
- the LAN 1 and LAN 2 are directly connected to a multiplexer ( 20 ) in the ISP network ( 5 ) with separate lines ( 18 ) and ( 19 ).
- a multiplexer ( 20 ) In the multiplexer ( 20 ), different “VPI, VCI” values are assigned to the VPNA and VPNB networks.
- the edge router ( 9 ) uses “VPI, VCI” values to identify the VPNs.
- FIG. 3 is a schematic diagram for explaining another example of modification to the network topology embodiment example shown in FIG. 1 .
- LAN 5 ( 21 ) is added to the network topology shown in FIG. 1 and the VPNB is formed to cover the LAN 2 , LAN 4 , and LAN 5 .
- the LAN 5 ( 21 ) uses POS and is connected to the edge router ( 9 ) with a line ( 22 ).
- a physical interface ( 23 ) interfaces the line ( 22 ) and the edge router ( 9 ).
- the edge router ( 9 ) uses “VPI, VCI” values as identifiers to identify one VPN to which the LAN 1 belongs and another VPN to which the LAN 2 belongs. At the same time, the edge router ( 9 ) uses a physical interface number as the identifier of the VPN to which the LAN 5 belongs. In the VPN ID indication table that the edge router ( 9 ) holds inside, a “physical interface number” shall be set in the VPN ID entry field for the physical interface ( 23 ). In this third embodiment, the edge router ( 9 ) internally holds two VPN identification tables; one table that maps “VPI, VCI” values to VPNs and the other table that maps physical interface numbers to VPNs. These tables will be detailed later.
- the edge router ( 9 ) receives an IP packet sent from the LAN 5 to the LAN 4 , it determines that physical interface numbers are used as VPN identifiers, according to the setting in the VPN ID indication table. After determining the VPN identifier type, the edge router ( 9 ) searches the VPN identification table that maps physical interface numbers to VPNs for a match with the search key of the “physical interface number” across which it received the packet and finds that the IP packet passed across the VPNB. Then, the edge router ( 9 ) searches the routing table for VPNB for a match with the search key of the destination IP address of the packet and determines the core router ( 17 ) as the next forwarded-to-destination. At this time, the capsule header to be attached to the packet to be sent to the determined core router is determined as well. After this capsule header is attached to the packet, the packet is forwarded to the core router ( 17 ).
- the procedure according to this embodiment is as follows. When setting up the edge router to interconnect VPNs that use different lower layer protocols, register VPN identifier types proper to the lower layer protocols into the VPN ID indication table. Register discrete VPN identifiers into VPN identification tables separately created for VPN identifier types. In this way, the edge router can be set up to interconnect VPNs, coping with various kinds of lower layer protocols that are different for different VPNs.
- the topology having networks may be diversified besides the network topology examples shown in FIGS. 1 to 3 .
- the VPN edge router of the present invention will be discussed as the one configured to have more general application rather than the restricted application to the network system examples shown in FIGS. 1 to 3 .
- FIG. 4 is a diagram showing an example of the configuration of the VPN edge router ( 9 ) offered by the present invention.
- a controller ( 50 ) to which lower layer processors ( 53 and 54 ), packet layer processors ( 52 ), and a switch ( 51 ) are connected, executes overall control of the VPN edge router and routing processing.
- the lower layer processors ( 53 and 54 ) accommodate lines ( 55 and 56 ) and execute the termination of a lower layer protocol below IP.
- the packet layer processors ( 52 ) receive lower layer information and an IP packet from the lower layer processors ( 53 and 54 ) and determine a forwarded-to-destination of the packet by using the lower layer information and the information in the header of the IP packet.
- the switch ( 51 ) has a plurality of input/output ports that are connected to the packet layer processors.
- the switch ( 51 ) comprises, for example, a crossbar switch.
- the switch ( 51 ) receives a packet from either of the packet layer processors ( 52 ), it outputs the packet to the output port for the forwarded-to-destination of the packet as determined by the packet layer processor ( 52 ).
- a control terminal ( 57 ) is connected to the above-mentioned controller ( 50 ). This control terminal allows the router administrator to register settings into the VPN ID indication table, the VPN identification tables, and the routing tables retained in the router. Points at which input lines 55 - 1 , 55 - 2 , 55 - 3 , and 55 - 4 connect to the router ( 9 ) are assigned physical interface numbers 1 , 2 , 3 , and 9 , respectively.
- FIG. 5 is a diagram showing an example of the configuration of a packet layer processor ( 52 ).
- Lower layer processor interfaces (IFs) 100 and 106 ) interface with the lower layer processors ( 53 and 54 ).
- Switch IFs ( 103 and 109 ) interface with the switch ( 51 ).
- a controller IF ( 110 ) interfaces with the controller ( 50 ).
- the router holds a VPN ID indication table ( 150 ), a VPN identification table ( 151 ), and routing tables for VPNs ( 152 ). These tables are stored into storage. They may be stored into different physical storage devices or different areas in a single storage device. How these tables are stored is not an essential matter of implementing the present invention.
- the VPN ID indication table ( 150 ), VPN identification table ( 151 ), and routing tables ( 152 ), and how other blocks, not described here, work and the structures thereof will be described in the following wherein how the router ( 9 ) handles packets will be explained.
- the lower layer processor ( 53 ) When the lower layer processor ( 53 ) receives a packet from a LAN, it terminates the lower layer protocol below IP for the packet. To a packet forwarding processor ( 101 ), the lower layer processor ( 53 ) transfers the IP packet and the information relevant to the packet including the physical interface number at which the packet was received (hereinafter referred to as a receiving physical interface number), the lower layer protocol type, and the capsule header information for the lower layer to be used as the VPN identifier. The packet forwarding processor ( 101 ) extracts the IP header information from the IP packet it received and transfers the IP header information, the receiving physical interface number, the lower layer protocol type, and the capsule header information for the lower layer to be used as the VPN identifier to a VPN identification table/routing table look-up processor ( 102 ). The IP packet itself is temporally accumulated in the packet forwarding processor ( 101 ).
- the VPN identification table/routing table look-up processor ( 102 ) first searches the VPN ID indication table ( 150 ) for a match with the search key of the receiving physical interface number or the lower layer protocol type and determines what the VPN identifier is.
- FIG. 6 shows example contents of the VPN ID indication table ( 150 ).
- the table contains the entries of physical interface number ( 200 ), lower layer protocol ( 203 ), and VPN ID ( 201 ).
- For “ATM” entries as the lower layer protocol CLP subfields for indicating packet forwarding priority are also included in the table shown in FIG. 6 , but the CLP subfields may be deleted from the table.
- the administrator of the edge router ( 9 ) can register VPN ID settings into this table via the control terminal ( 57 ).
- the VPN identification table/routing table look-up processor ( 102 .) searches this table for a match with the search key of the receiving physical interface number and determines what the VPN ID ( 201 ) is.
- the receiving physical interface number is 1
- it is determined that the VPN ID is “VPI, VCI.”
- the receiving physical interface number is 3
- it is determined that the VPN ID is “physical interface number.”
- the table includes the CLP subfields, as embodied in this example, a combination of “VPI, VCI” and “CLP” or a combination of “physical interface number” and “CLP” may be used as the VPN ID. Advantages of including the CLP ( 204 ) in the VPN ID will be described later.
- VPN Voice over IP
- a lower layer protocol for the packet is ATM
- VPN what VPN across which that packet passed can be identified by using “VPI, VCI” values as VPN identifiers.
- packets passed cross one VPN are exclusively terminated to one physical interface, the VPN can be identified by the receiving physical interface number.
- a combination of a lower layer protocol ( 203 ) and a physical interface number ( 201 ) may be used.
- the line connected to physical interface number 4 is a time division multiplex line and packets transmitted by frame relay as the lower layer protocol and packets transmitted by Point to Point Protocol (PPP) as the lower layer protocol are multiplexed on the line.
- PPP Point to Point Protocol
- a “DLCI” value is set as the VPN ID entry for “frame relay” as the lower layer protocol entry and a “time slot number” is set as the VPN ID entry for “PPP” as the lower layer protocol entry.
- a look-up for VPN ID with the search key of only the receiving physical interface number 4 cannot distinctly find whether the VPN ID is “DLCI” or “time slot number.” Therefore, the search key of the combination of a lower layer protocol and a physical interface number should be applied to the look-up for VPN ID.
- the VPN identification table/routing table look-up processor searches the VPN identification table ( 151 ) for a match with the search key of the VPN ID and determines a VPN across which the received packet passed.
- FIG. 7A and FIG. 7B show example contents of the VPN identification table ( 151 ). Both examples of the VPN identification table contain the entries of VPN ID ( 201 ) and VPN number ( 250 ).
- FIG. 7A shows an example of the VPN identification table where “VPI, VCI” values are used as VPN ID ( 201 ).
- CLP subfields ( 204 ) and internal priority information fields ( 251 ) included in the table shown in FIG. 7A may be deleted from the table.
- the internal priority information fields ( 251 ) are used to indicate information on packet handling priority within the router.
- the VPN identification table/routing table look-up processor ( 102 ) searches the VPN identification table for a match with the search key of the VPN identification information included in the packet header in accordance with the VPN ID as the other search key determined by searching the above VPN ID indication table and determines what the VPN number ( 250 ) is.
- the VPN identification table ( 151 ) includes the CLP subfields ( 204 ) and the internal priority information subfields ( 251 ), as embodied in this example, a combination of “VPI, VCI” and CLP ( 204 ) that indicates packet forwarding priority may be used as the search key.
- CLP internal priority information
- FIG. 7B shows an example of the VPN identification table where physical interface number ( 252 ) is used as the VPN ID ( 201 ). Unless packet handling priority control is executed, the internal priority information subfields ( 251 ) shown in FIG. 7B are not necessary.
- VPN identification table may be reorganized appropriately, but basically the same as those shown in FIGS. 7A and 7B . Specifically, a discrete VPN identification table ( 151 ) is created for each VPN ID type and values to be set in the table shall be entered via the control terminal ( 54 ). VPN identification tables ( 151 ) created for all VPN ID types may be stored in a single storage device or different storage devices.
- the VPN identification table/routing table look-up processor searches the routing table ( 152 ) that is for the VPN designated by the VPN number and determines an output route and capsule header information to send packet that is to be attached to the packet sorted under that VPN number.
- FIG. 8 shows example contents of a routing table ( 152 ) for VPN.
- the VPN identification table/routing table look-up processor ( 102 ) holds separate routing tables ( 152 ) for the VPNs interconnected by the router. These routing tables ( 152 ) separately created for the VPNs may be stored into a single storage device or different storage devices.
- Any routing table ( 152 ) for VPN contains the entries of destination IP address ( 300 ), output route number ( 301 ), and output capsule header information ( 302 ).
- the output route number ( 301 ) is the intra-router identifier of a route across which the switch forwards the packet to a predetermined interface.
- the output capsule header information ( 302 ) is the information for capsule header that is used to send the packet across the ISP network ( 5 ).
- the VPN identification table/routing table look-up processor ( 102 ) searches the routing table for the VPN designated by the VPN number ( 250 ) determined by searching the above VPN identification table for a match with the search key of the destination IP address included in the IP packet header, thereby determining what the output route number ( 301 ) and the output capsule header information ( 302 ) are. Because the router in the present embodiment holds separate routing tables ( 152 ) for the VPNs interconnected by the router, correct output route can be determined even if an IP address used in one VPN is also used in another VPN.
- the VPN identification table/routing table look-up processor ( 102 ) transfers the determined output route number ( 301 ) and output capsule header information ( 302 ) to the packet forwarding processor ( 101 ).
- the packet forwarding processor ( 101 ) transfers the IP packet itself accumulated there, the output route number ( 301 ), and the output capsule header information ( 302 ) to the switch ( 51 ) through the switch IF ( 103 ).
- the switch ( 51 ) outputs the IP packet itself and the output capsule header information ( 302 ) received from the packet forwarding processor ( 101 ) to the output port designated by the output route number.
- the packet layer processor ( 52 ) connected to the above output port that is, the receiving-end packet layer processor ( 52 ) receives the IP packet itself and its output capsule information ( 302 ) sent from the preceding packet layer processor ( 52 ) through the switch IF ( 104 ).
- the packet forwarding processor ( 105 ) transfers them to the lower layer processor ( 54 ) through the lower layer processor IF ( 106 ).
- the lower layer processor ( 54 ) On receiving the IP packet itself and its output capsule header information ( 302 ), the lower layer processor ( 54 ) generates a capsule header, based on the output capsule header information, and encapsulates the IP packet in another IP packet with the capsule header, and sends the new IP packet that contains the capsule header and the encapsulated packet to the core router ( 17 ).
- the VPN edge router configured as shown in FIGS. 4 to 8 was discussed above as one example of its configuration. By using the router embodied in the above example, even if packets are sent across different VPNs and terminated to a same physical interface, the VPNs across which the packets passed can be identified. Even if a same edge router interconnects a plurality of LANs that use network-specific lower layer protocols below IP, VPN identifiers proper for lower layer protocols can be set in the VPN ID indication table and this increases the freedom of organizing VPNs into a network system.
- output capsule header information is directly obtained by searching the routing table for VPN
- the table entry can be altered so that a output capsule number may be obtained.
- This output capsule number is an infra-router identifier that specifies a capsule header to be attached to the packet in the lower layer processor to which the output line attaches. If capsule numbers are used, the lower layer processor to which the output line attaches must hold a header generation table that contains capsule number and capsule header pairs. The above lower layer processor searches the header generation table for a match with the search key of a capsule number and determines the mating capsule header.
- Look-up algorithm typically known as tree structure may be used as a table search method or structure by using a Content Addressable Memory (CAM) and a sequential table search method may be taken.
- CAM Content Addressable Memory
- time slot numbers may be added to the information to be transferred from the lower layer processor to the packet layer processor besides the information items described in the above router example.
- a “time slot number” may be set as a VPN ID entry in the VPN ID indication table.
- a time slot number may be used as the search key for searching the VPN identification table.
- VLAN Tag information may be added to the information to be transferred from the lower layer processor to the packet layer processor besides the information items described in the above router example.
- a “VLAN Tag” value may be set as a VPN ID entry in the VPN ID indication table.
- VLAN Tag information may be used as the search key for searching the VPN identification table.
- L2TP Layer2 Tunneling Protocol
- appropriate information contained in the L2TP header may be set as a VPN ID entry in the VPN ID indication table.
- information contained in the capsule header may be added to the information to be transferred from the lower layer processor to the packet layer processor besides the information items described in the above router example.
- appropriate information such as session ID
- the capsule header prescribed by the PPP Over Ethernet encapsulation protocol may be set as a VPN ID entry in the VPN ID indication table.
- FIG. 9 shows another example of the configuration of the VPN edge router ( 9 ) offered by the present invention.
- Each of interface cards ( 400 and 401 ) accommodates lines for datagrams of same lower layer protocol.
- the interface card ( 900 ) is for ATM datagrams and accommodates ATM lines ( 402 ).
- the interface card ( 401 ) is for POS datagrams and accommodates POS lines ( 403 ).
- the interface cards ( 400 and 401 ) can be mounted and removed if necessary and the router administrator can mount the required number of interface cards for lower layer protocols required for router operation on the router.
- lower layer processors ( 405 and 406 ) are installed to execute processing specific to the lower layer protocols.
- the lower layer processors ( 905 and 406 ) operate in the same way as the lower layer processors ( 53 and 54 ) shown in FIG. 4 do.
- Packet processing cards ( 407 ) receive IP packets and related information from the above interface cards and execute packet layer processing.
- the packet processing cards ( 407 ) can be mounted and removed if necessary and the router administrator can mount the required number of the cards.
- the packet layer processors ( 52 ) described with FIGS. 4 and 5 are installed.
- the administrator can flexibly set the contents of the VPN ID indication table, VPN identification tables, routing tables for VPNs in the packet processing cards ( 407 ) via the control terminal ( 57 ).
- the VPN edge router embodied in this way also handles packets as explained with FIGS. 4 to 8 .
- FIGS. 10 through 12 are schematic representations of the relation between an interface card that attaches to one of the packet processing cards ( 907 ) shown in FIG. 9 and the contents of the VPN ID indication table, VPN identification table (s), and routing tables for VPNs held in the packet processing card.
- FIGS. 10 through 12 show the LANs interconnected by the edge router and only the interface card and the packet processing card out of the components of the edge router ( 9 ).
- the VPN ID indication table, VPN identification table(s), and routing tables for VPNs in the packet processing card are logical tables. In FIGS. 10 through 12 , it is assumed that all physical interfaces on a same interface card are assigned VPN identifiers of same type.
- the physical interface number entry as the search key is omitted. If different types of VPN identifiers are used for VPNs terminated to interfaces on a same interface card, it is advisable to use the physical interface number entry as the search key for the VPN ID indication table as described for the preceding router embodiment.
- FIG. 10 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in the packet processing card when an ATM interface card ( 400 ) attaches to the packet processing card ( 407 ).
- LAN 1 ( 450 ) and LAN 2 ( 451 ) are assumed to belong to VPNA and VPNB, respectively.
- Packets from the LAN 1 and LAN 2 are multiplexed by a multiplexer ( 452 ) and carried across a line ( 453 ) to the ATM interface card ( 400 ).
- the packets from the LAN 1 and LAN 2 are assigned a value of “a” for LAN 1 and a value of “b” for LAN 2 as “VPI, VCI” identifiers.
- VPN, VCI values are used to identify VPNs.
- a “VPI, VCI” value is set as the VPN ID entry.
- a “VPI, VCI” value is set as the search key entry.
- routing tables ( 455 ) for VPNs the packet processing card holds the routing table for VPNA ( 457 ) and the routing table for VPNB ( 458 ).
- the lower layer processor ( 405 ) of the ATM interface card ( 400 ) terminates the ATM protocol and transfers the IP packet itself and related information including the “VPI, VCI” identifier and the physical interface number to the packet processing card ( 407 ).
- the VPN identification table/routing table look-up processor of the packet processing card ( 407 ) searches the VPN ID indication table ( 455 ) and determines that “VPI, VCI” values are used as VPN identifiers.
- the look-up processor searches the VPN identification table ( 456 ) for a match with the search key of “a” that is the value of “VPI, VCI” of the received packet and finds that the received packet passed across the VPNA. Then, the look-up processor searches the routing table for VPNA ( 457 ) and determines the appropriate output route and output capsule header information.
- FIG. 11 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in the packet processing card when a POS interface card ( 401 ) attaches to the packet processing card ( 407 ).
- the LAN 1 ( 450 ) and LAN 2 ( 451 ) are assumed to belong to VPNA and VPNB, respectively.
- the LAN 1 and LAN 2 are connected to the POS interface card ( 401 ) with lines ( 500 ) and ( 501 ), respectively.
- Physical interfaces that interface the lines ( 500 ) and ( 501 ) and the POS interface card ( 401 ) are assigned physical interface numbers 1 and 2 , respectively.
- a “physical interface number” is set as the VPN ID entry in the VPN ID indication table ( 455 ) in the packet processing card ( 407 ).
- a “physical interface number” is set as the search key.
- the packet processing card holds the routing table for VPNA ( 457 ) and the routing table for VPNB ( 458 ). Processing within the packet processing card ( 407 ) is the same as that explained with FIG. 10 , except that physical interface numbers instead of “VPI, VCI” values are used as VPN identifiers.
- FIG. 12 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when an interface card for time division multiplex line ( 550 ), which is not shown in FIG. 8 , attaches to the packet processing card ( 407 ).
- LAN 1 ( 450 ), LAN 2 ( 451 ), LAN 3 ( 551 ), and LAN 4 ( 552 ) are assumed to belong to VPNA, VPNB, VPNC, and VPND, respectively.
- the lower layer protocol for the LAN 1 and LAN 2 is assumed to be frame relay and that for the LAN 3 and LAN 4 is assumed to be Point to Point Protocol (PPP).
- PPP Point to Point Protocol
- Packets from the LAN 1 and packets from the LAN 2 are respectively assigned “10” and “20” as DLCI values and multiplexed on a line ( 554 ) by a frame relay multiplexer ( 553 ). Moreover, a time division multiplexer ( 555 ) multiplexes lines ( 554 ), ( 556 ), and
- DLCI values are used as VPN identifiers for the LAN 1 and LAN 2
- time slot numbers are used as VPN identifiers for the LAN 3 and LAN 9 .
- a “DLCI” ( 560 ) value is set as the VPN ID entry for “frame relay” as the lower layer protocol ( 559 ) entry.
- a “time slot number” ( 561 ) is set as the VPN ID entry for “PPP” as the lower layer protocol entry.
- the packet processing card holds two VPN identification tables: that is, one VPN identification table ( 562 ) that maps DLCI values to VPN numbers; and another VPN identification table ( 563 ) that maps time slot numbers to VPN numbers.
- the card also holds four routing tables for VPNs: that is, a routing table for VPNA ( 457 ), a routing table for VPNB ( 458 ), a routing table for VPNC ( 564 ), and a routing table for VPND ( 565 ).
- Processing within the packet processing card ( 407 ) is the same as that explained with FIG. 10 , except the following.
- the VPN ID indication table is searched with the search key of lower layer protocol ( 559 ).
- the “DLCI” VPN identifiers are used for packets received from the LAN 1 and LAN 2 and the “time slot number” VPN identifiers are used for packets received from the LAN 3 and LAN 4 .
- FIG. 13 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when interface cards for different lower layer protocols attach to the packet processing card ( 407 ).
- the interface cards are assumed to be the ATM interface card ( 400 ) and the POS interface card ( 401 ). For FIG. 13 , it is assumed that all physical interfaces on a same interface card are assigned VPN identifiers of same type. Because a plurality of interface cards attach to the packet processing card in this example, the interface cards ( 400 ) and ( 401 ) assigned card numbers 1 and 2 , respectively. Card number ( 602 ) is set as the search key for the VPN ID indication table ( 455 ).
- LAN 1 ( 450 ), LAN 2 ( 951 ), LAN 3 ( 551 ), and LAN 4 ( 552 ) are assumed to belong to VPNA, VPNB, VPNC, and VPND, respectively.
- Packets from the LAN 1 and LAN 2 are multiplexed by a multiplexer ( 452 ) and carried across a line ( 953 ) to the ATM interface card ( 400 ).
- the packets from the LAN 1 and LAN 2 are assigned a value of “a” for LAN 1 and a value of “b” for LAN 2 as “VPI, VCI” identifiers. In this case, it is advisable to use “VPI, VCI” values to identify VPNs.
- a “VPI, VCI” value is set as the VPN ID entry ( 603 ) for card number 1 .
- the LAN 3 and LAN 4 are connected to the POS interface card ( 401 ) with lines ( 500 ) and ( 501 ), respectively.
- Physical interfaces that interface the lines ( 500 ) and ( 501 ) and the POS interface card ( 401 ) are assigned physical interface numbers 1 and 2 , respectively. In this case, it is advisable to use physical interface numbers to identify VPNs.
- a “physical interface number” is set as the VPN ID entry ( 604 ) for card number 2 .
- the packet processing card holds one VPN identification table ( 600 ) that maps “VPI, VCI” values to VPN numbers and another VPN identification table ( 601 ) that maps physical interface numbers to VPN numbers.
- the card holds a routing table for VPNA ( 457 ), a routing table for VPNB ( 458 ), a routing table for VPNC ( 464 ), and a routing table for VPND ( 465 ).
- Processing within the packet processing card ( 407 ) is the same as that explained with FIG. 10 , except that the VPN ID indication table is searched with the search key of card number ( 602 ).
- ATM and POS interface cards attach to the packet processing card in this example, the combination of the interface cards may be varied.
- the POS interface card can be replaced by an interface card for FR.
- packets from the LAN 3 and LAN 4 are multiplexed on one line and carried to the interface card for FR in the same manner as for the packets from the LAN 1 and LAN 2 and DLCI values are used to identify VPNs.
- the router embodied as explained above with FIGS. 9 to 13 allows the router administrator to flexibly set the contents of the VPN ID indication table, VPN identification tables, routing tables for VPNs in the packet processing cards ( 907 ) via the control terminal ( 57 ), according to the attached interface card type. Because VPNs are identified by identifiers assigned to multiplex logical channels terminated to a physical interface, when the router receives one of the packets that are sent across the VPNs and logically multiplexed on one line, it can identify a VPN across which the packet passed.
- FIG. 14 illustrates an example of the procedure for customizing the internal settings of the packet processing card ( 407 ) fit for an interface card that is newly installed.
- VPN IDs are automatically registered in the following way.
- the interface card When an interface card is installed to attach to the packet processing card, the interface card is set to communicate with the packet processing card.
- the interface card automatically finds lower layer protocols specific to the IP packets to terminate to it and notifies the packet processing card of the lower layer protocols. Then, VPN IDs predefined for the lower layer protocols thus notified can be automatically registered into the VPN ID indication table.
- FIG. 15 illustrates a general operation flow of the router.
- the VPN edge router When the VPN edge router receives a packet in which an IP packet is encapsulated by a network-specific protocol from a LAN (step 801 ), it looks up for VPN ID in the VPN ID indication table (step 802 ) and determines a VPN ID of the received packet (step 803 ). Logical channel identifiers such as “VPI, VCI” values are generally used as VPN IDs, whereas combinations of one of these identifiers and physical interface numbers may be used as VPN IDs, depending on the lower layer protocols for VPNs interconnected by the router. Then, the router looks up for VPN in the VPN identification table, using the determined VPN ID as the search key (step 804 ) and determines a VPN across which the received packet passes (step 805 ).
- VPN ID indication table step 802
- VPN ID of the received packet step 803 .
- Logical channel identifiers such as “VPI, VCI” values are generally used as VPN IDs, whereas combinations of one of these identifiers and physical interface numbers may be
- the VPN identification table is searched for a match of the search key of the value of “VPI, VCI” assigned to the received packet and thereby the VPN across which the packet passed is determined. Finally, the routing table for the thus determined VPN is looked up (step 806 ) and an output route and an output capsule header are determined (step 807 ).
- VPNs are identified by identifiers assigned to multiplex logical channels terminated to a physical interface.
- the number of VPNs to be interconnected by the router can be increased without increasing the physical lines.
- VPN IDs proper for the protocols can be registered with the router so that the router can identify VPNs.
Abstract
The present invention provides a VPN edge router with the ability of identifying VPNs by using the identifiers of logical channels multiplexed on a single input line.
Description
- The present application is a continuation of application Ser. No. 09/811,440, filed Mar. 20, 2001, the contents of which are incorporated herein by reference.
- The present invention relates to routers, particularly, a router that interconnects Virtual Private Networks (VPNs) to build a network system via the Internet, a method of packet forwarding control to be used on the router, and a method of registering routing and related settings with the router.
- When networking a plurality of intra-corporation networks existing in different areas, corporations conventionally used private lines to interconnect these networks, thus forming a network system that is isolated from external networks (to ensure network security). This, however, posed a problem that the use of private lines increases the networking cost. As a result, along with the prevalence of the Internet that can be used at a low charge, there have been increasing needs for an art of forming a low-cost Virtual Private Network (hereinafter referred to as VPN) by using the Internet. This art is to virtually build private networks via the Internet by using the Internet Protocol (IP) facilities provided by IP networks and the facilities of lower layer protocols below IP. This art enables building a safe network that is isolated from external networks and can provide quality assurance service of any level even via the Internet.
- One implementation method of reliable data transmission across a VPN is such that data encapsulation is performed at the entrance to a network of an Internet service provider (hereinafter referred to as ISP) that provides the VPN. The encapsulated data is transferred across the ISP's network, according to the capsule header, and this header is removed at the exit of the network. By using VPN-specific encapsulation headers for datagrams that pass across the Internet, VPNs with ensured security can be formed. Practically used encapsulation protocols are IP capsule, Multi Protocol Over ATM (MPOA), Multi Protocol Label Switching (MPLS), and other ones. The Internet Engineering Task Force (IETF) and other organizations for standardization are working toward the standardization of the encapsulation protocols as of May 2000.
- IP addresses are divided into global IP addresses and private IP addresses. Global IP addresses are globally defined unique addresses, whereas private IP addresses can be freely defined by a corporation. Private IP addresses are often used in intra-corporation networks. Thus, it is desirable that private IP addresses can be used when corporations use VPN service. If there are a plurality of VPNs and private IP addresses are used in the VPNs, it may happen that an IP address used in one VPN is also used in another VPN. If IP address duplication exists among a plurality of VPNs, a router that is placed at the entrance to the ISP network and interconnects Local Area Networks (LANs) belonging to the VPNs (this router is hereinafter referred to as a VPN edge router) must hold routing tables separately created for the VPNs in order to properly forward packets across the VPNs. Upon the reception of a packet, the VPN edge router finds one of the VPNs to which one of the LANs belongs across which the packet passed. Then, the VPN edge router searches the routing table for the thus found VPN, determines the forwarded-to-destination of the packet across the ISP network, and encapsulates the packet. Because the VPN edge router holds the routing tables separately created for the VPNs, even if it receives packets passed across different VPNs, but having a same destination IP address, it can forward the packets to their correct destinations without mistaking one for another.
- As a method of identifying the above VPNs, for example, the method is known in which a VPN ID is assigned to a user line interface for unique VPN identification and VPN identification is performed by VPN ID, as described in the Oct. 18, 1999, issue of “Nikkei Communication,” p. 100. According to this method, VPN identification is performed on a physical interface by interface basis, wherein correspondence of one physical interface to one VPN is required.
- In the above method, however, it is required that one physical line connects a corporate network to the ISP network. In order to connect one corporate network to a plurality of VPNs, as many physical lines as the number of the VPNs must be prepared. At the same time, the VPN edge router that interconnects the VPNs must have as many physical interfaces as the number of the VPNs. Consequently, a problem arises that expansion of VPNs interconnected by the VPN edge router expands the physical interfaces of the VPN edge router and eventually additional routers are required.
- In a case where an ATM network or a frame relay network provided another ISP or carrier is used as intermediate access means from a corporate network to the ISP network that provides VPN service, a plurality of logical channels are multiplexed and terminated to one physical interface at the entrance of the ISP network. These multiplexed logical channels cannot be identified by VPN identification by physical interface and this is another problem due to the limitation of the previous VPN identification method.
- An object of the present invention is to enable VPN identification by using the identifiers of logical channels multiplexed and terminated to a physical interface.
- Another object of the present invention is to enable VPN identification by using different kinds of VPN identifiers proper for a plurality of different protocols that are used as lower layer protocols below IP predefined for LANs that are interconnected by the router.
- In order to solve the above problems, the VPN edge router of the present invention identifies VPNs by using the identifiers of logical channels multiplexed and terminated to a physical interface. As the logical channel identifiers, information for lower layer protocols below IP is used; e.g., information equivalent to
layer 2 prescribed in an OSI model. For example, the logical channel identifiers are expressed in combined VPI and VCI values specified in the header of packets if an ATM protocol is the lower layer protocol of the IP packets or DLCI values if a frame relay is the lower layer protocol. Furthermore, if IP packets are encapsulated with an L2TP header prescribed by a Layer2 Tunneling Protocol (L2TP), information (such as tunnel ID and session ID) specified in the L2TP header can be used as logical channel identifiers. If the lower layer is an Ethernet and VPN identification is performed by using VLAN Tag prescribed in IEEE802.1Q, VLAN Tag is used as logical channel identifiers. If IP packets are encapsulated with a capsule header prescribed by a PPP Over Ethernet encapsulation protocol, information (such as session ID) specified in the capsule header prescribed by the above protocol is used as logical channel identifiers. - Furthermore, the VPN edge router holds a VPN ID indication table into which what kinds of VPN identifiers are used for VPN identification are registered. To allow the ISP network administrator, who administrates the VPN edge router to register VPN identifier settings into this table, the VPN edge router is provided with a user interface. Assume the ATM protocol to be the lower layer below IP as an example. If physical interfaces are used for VPN identification, a “physical interface number” is set in the above VPN ID indication table. If “VPI, VCI” values are used for VPN identification, a “VPI, VCI” value is set in this table.
- The VPN ID indication table may contain settings for all physical interfaces or settings for all interface cards, each of which may accommodate a plurality of lines under a same lower layer protocol. If a plurality of logical channels under different lower layer protocols are multiplexed and terminated to one physical interface (for example, a frame relay channel and a PPP channel are multiplexed on a line by time division), the VPN ID indication table may contain settings for all combinations of a physical interface and a lower layer protocol below IP.
- How the VPN edge router actually operates will be explained below, using the case where the ATM protocol is used as the lower layer below IP for VPNs interconnected via the ISP network and VPN identifiers are expressed in “VPI, VCI” values as an example. When the VPN edge router receives a packet, it first determines the VPN identifier type, according to the setting (in this example, “VPI, VCI”) in the VPN ID indication table, and determines what VPN identification table is to be searched next. In this example, the VPN edge router next searches the VPN identification table that maps “VPI, VCI” values to VPNs. By searching the VPN identification table for a match with the search key of the “VPI, VCI” value specified in the packet header, the VPN edge router finds a VPN across which the received packet passed. Once the VPN has been found out, the edge router searches the routing table for the VPN across which the received packet passed, determines the next forwarded-to-destination of the packet across the ISP network, and generates a capsule header containing information to be used for VPN identification in the network. The VPN edge router attaches this header to the packet and sends the packet to the determined next forwarded-to-destination.
- In the present invention, VPN identification is performed by using the identifiers of logical channels multiplexed and terminated to a physical interface as described above. Therefore, it is not necessary to provide the VPN edge router with physical interfaces corresponding to VPNs interconnected by the router. To connect one corporate network to a plurality of VPNs according to the invention, preparing as many logical channels as the number of VPNs is only required, but preparing as many physical lines as the number of VPNs is not necessary. Even when an ATM network or a frame relay provided by another ISP or carrier is used as intermediate access means from a corporate network to the ISP network that provides VPN service, the present invention enables building a network system having VPNs because the VPNs are identified by their logical channels to the VPN edge router.
- Furthermore, when the router is set up to interconnect VPNs, the present invention allows the ISP network administrator to select a VPN identifier type proper for each VPN-specific lower layer protocol below IP and register it in the VPN ID indication table. Therefore, a network system can be built to comprise VPNs that run under various kinds of lower layer protocols.
- Other objects and advantages of the invention will become apparent during the following discussion of the accompanying drawings, wherein:
-
FIG. 1 is a schematic diagram for explaining a preferred embodiment of forming VPNs interconnected by VPN edge routers according to the present invention. -
FIG. 2 is a schematic diagram for explaining an example of modification to the network topology embodiment example shown inFIG. 1 . -
FIG. 3 is a schematic diagram for explaining another example of modification to the network topology embodiment example shown inFIG. 1 . -
FIG. 4 is a diagram showing an example of the configuration of the VPN edge router offered by the present invention. -
FIG. 5 is a diagram showing an example of the configuration of a packet layer processor. -
FIG. 6 shows example contents of the VPN ID indication table. -
FIG. 7 shows example contents of the VPN identification table. -
FIG. 8 shows example contents of a routing table for VPN. -
FIG. 9 shows another example of the configuration of the VPN edge router offered by the present invention. -
FIG. 10 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in a packet processing card when an ATM interface card attaches to the packet processing card. -
FIG. 11 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in the packet processing card when a POS interface card attaches to the packet processing card. -
FIG. 12 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when an interface card for time division multiplex line attaches to the packet processing card. -
FIG. 13 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when interface cards for different lower layer protocols attach to the packet processing card. -
FIG. 14 illustrates an example of the procedure for customizing the internal settings of the packet processing card. -
FIG. 15 illustrates a general operation flow of the VPN edge router offered by the present invention. -
FIG. 1 is a schematic diagram for explaining a preferred embodiment of forming VPNs interconnected by VPN edge routers according to the present invention. Hereinafter, a lower layer will mean a protocol for encapsulating datagrams in IP packets. Even if an IP header is used to encapsulate datagrams of IP packets, this capsule header will be represented as a lower layer header for convenience. - An ISP network (5) has edge routers (9 and 10) positioned at the boundaries of the network and a core router (17) positioned in the core of the network. Although a single core router (17) is shown in
FIG. 1 , the number of core routers is not limited to one. Datagrams are assumed to be encapsulated by MPLS (for ATM) to pass across the ISP network (5), thus implementing reliable data transmission across VPNs. Not only this encapsulation protocol but also other encapsulation protocols mentioned above may be used. The ISP network (5) interconnects LAN1 (1) and LAN2 (2) via the edge router (9) and LAN 3 (3) and LAN4 (4) via the edge router (10). The LAN1 (1) and the LAN3 (3) are assumed to be possessed by corporation A and one VPN is formed to cover these LANs. The LAN2 (2) and the LAN4 (4) are assumed to be possessed by corporation B and another VPN is formed to cover these LANs. The corporation A's VPN is to be called VPNA (7) and the corporation B's VPN is VPNB (8). - The LAN1 and LAN2 are logically multiplexed on a line (11) and connected to the edge router (9) via an ATM network (6) that is provided by another ISP or carrier separately from the ISP network (5). A physical interface (12) interfaces the line (11) and the edge router (9). The physical interface means the point of connection between the router and the line. Meanwhile, the LAN3 (3) and LAN4 (4) are connected to the edge router (10) with lines (13) and (14) respectively by using PPP Over SONET (POS) prescribed in RFC2615. Physical interfaces (15) and (16) interface the lines (13) and (14) with the edge router respectively.
- In the present embodiment, combined VPI and VCI values are used as identifiers to identify one VPN to which the LAN1 belongs and another VPN to which the LAN2 belongs. In the VPN ID indication table that the edge router (9) holds inside, a “VPI, VCI” value shall be set in the VPN ID entry field for the physical interface (12). Meanwhile, the edge router (10) uses numbers assigned to the physical interfaces as identifiers to identify one VPN to which the LAN3 belongs and another VPN to which the LAN4 belongs. In the VPN ID indication table that the edge router (10) holds inside, a “physical interface number” shall be set in the VPN ID entry fields for the physical interfaces (15) and (16). The VPN ID indication table will be detailed later.
- The edge router (9) also internally holds a VPN identification table that maps a specific VPN ID to information that indicates what VPN across which the packet with the VPN ID passed (this information is hereinafter referred to as a VPN number). The above-mentioned VPNA and VPNB are used as VPN number. Moreover, the edge router (9) internally holds routing tables that map a destination IP address of the packet to an output route number and capsule header information. The router holds the routing table prepared for VPNA and the routing table prepared for VPNB. The VPN identification table and the routing tables will also be detailed later.
- When the edge router (9) receives an IP packet that is sent from the LAN1 to the LAN3, it determines that “VPI, VCI” values are used as VPN identifiers, according to the setting in the VPN ID indication table. After determining the VPN identifier type, the edge router (9) searches the VPN identification table that maps “VPI, VCI” values to VPNs and finds that the packet passed across the VPNA. Then, the edge router (9) searches the routing table for VPNA for a match with the search key of the destination IP address of the packet and determines the core router (17) as the next forwarded-to-destination. At this time, the capsule header that is to be attached to the packet passed across VPNA and to be forwarded to the core router is determined as well. After this capsule header is attached to the packet, the packet is forwarded to the core router (17).
- The core router (17) has a routing table that maps capsule headers, that is, “VPI, VCI” values to next forwarded-to-destinations. The core router (17) searches this routing table for a match with the search key of the information in the capsule header of the received packet and determines the next forwarded-to-destination (edge router (10)) and the next capsule header. The core router (17) attaches the next capsule header to the packet and sends the packet to the edge router (10).
- The edge router (10), which is configured identically to the edge router (9), searches its VPN identification table for a match with the search key of the information in the capsule header of the received packet and finds that the packet passed across the VPNA as the edge router (9) does. Then, the edge router (10) searches its routing table for VPNA for a match with the search key of the destination IP address of the packet and determines the forwarded-to-destination. The edge router (10) removes the capsule header from the packet and forwards the packet to the LAN3.
- Because the edge router (9) identifies a VPN by finding the VPN ID out of the identifiers of the logical channels multiplexed and terminated to the physical interface and then searches the routing table for the VPN, one of the logically multiplexed VPNs on one physical line can be identified. In this way, packets can be forwarded to their correct destinations even if an IP address used in the corporation A's network is also used in the corporation B's network.
- When packets are sent from the
LAN 4 to theLAN 2 across the VPNB, similarly, the sending is performed by following the same procedure as described above, except that the edge router (10), when receiving the IP packets sent from theLAN 4 to theLAN 2, uses physical interface numbers as VPN identifiers. -
FIG. 2 is a schematic diagram for explaining an example of modification to the network topology embodiment example shown inFIG. 1 . In this modified embodiment, theLAN 1 andLAN 2 are directly connected to a multiplexer (20) in the ISP network (5) with separate lines (18) and (19). At the multiplexer (20), different “VPI, VCI” values are assigned to the VPNA and VPNB networks. As does in the case ofFIG. 1 , the edge router (9) uses “VPI, VCI” values to identify the VPNs. -
FIG. 3 is a schematic diagram for explaining another example of modification to the network topology embodiment example shown inFIG. 1 . InFIG. 3 , LAN5 (21) is added to the network topology shown inFIG. 1 and the VPNB is formed to cover the LAN2, LAN4, andLAN 5. The LAN5 (21) uses POS and is connected to the edge router (9) with a line (22). A physical interface (23) interfaces the line (22) and the edge router (9). - As described for
FIG. 1 , the edge router (9) uses “VPI, VCI” values as identifiers to identify one VPN to which the LAN1 belongs and another VPN to which the LAN2 belongs. At the same time, the edge router (9) uses a physical interface number as the identifier of the VPN to which the LAN5 belongs. In the VPN ID indication table that the edge router (9) holds inside, a “physical interface number” shall be set in the VPN ID entry field for the physical interface (23). In this third embodiment, the edge router (9) internally holds two VPN identification tables; one table that maps “VPI, VCI” values to VPNs and the other table that maps physical interface numbers to VPNs. These tables will be detailed later. - For example, if the edge router (9) receives an IP packet sent from the
LAN 5 to the LAN4, it determines that physical interface numbers are used as VPN identifiers, according to the setting in the VPN ID indication table. After determining the VPN identifier type, the edge router (9) searches the VPN identification table that maps physical interface numbers to VPNs for a match with the search key of the “physical interface number” across which it received the packet and finds that the IP packet passed across the VPNB. Then, the edge router (9) searches the routing table for VPNB for a match with the search key of the destination IP address of the packet and determines the core router (17) as the next forwarded-to-destination. At this time, the capsule header to be attached to the packet to be sent to the determined core router is determined as well. After this capsule header is attached to the packet, the packet is forwarded to the core router (17). - In the third embodiment, different types of VPN identifiers are set for different lower layer protocols and separate VPN identification tables for VPN identifier types are created. In this method, the freedom of one router to cope with different lower layer protocols is increased. Specifically, the procedure according to this embodiment is as follows. When setting up the edge router to interconnect VPNs that use different lower layer protocols, register VPN identifier types proper to the lower layer protocols into the VPN ID indication table. Register discrete VPN identifiers into VPN identification tables separately created for VPN identifier types. In this way, the edge router can be set up to interconnect VPNs, coping with various kinds of lower layer protocols that are different for different VPNs.
- Next, the detail of the VPN edge router offered by the present invention will be described below. For the implementation of organizing VPNs into a network system, the topology having networks may be diversified besides the network topology examples shown in FIGS. 1 to 3. In the following, therefore, the VPN edge router of the present invention will be discussed as the one configured to have more general application rather than the restricted application to the network system examples shown in FIGS. 1 to 3.
- An example of the configuration of the VPN edge router (9) will be explained with reference to FIGS. 4 to 8. The following description also applies to the configuration of the VPN edge router (10).
-
FIG. 4 is a diagram showing an example of the configuration of the VPN edge router (9) offered by the present invention. A controller (50), to which lower layer processors (53 and 54), packet layer processors (52), and a switch (51) are connected, executes overall control of the VPN edge router and routing processing. The lower layer processors (53 and 54) accommodate lines (55 and 56) and execute the termination of a lower layer protocol below IP. The packet layer processors (52) receive lower layer information and an IP packet from the lower layer processors (53 and 54) and determine a forwarded-to-destination of the packet by using the lower layer information and the information in the header of the IP packet. The switch (51) has a plurality of input/output ports that are connected to the packet layer processors. The switch (51) comprises, for example, a crossbar switch. When the switch (51) receives a packet from either of the packet layer processors (52), it outputs the packet to the output port for the forwarded-to-destination of the packet as determined by the packet layer processor (52). A control terminal (57) is connected to the above-mentioned controller (50). This control terminal allows the router administrator to register settings into the VPN ID indication table, the VPN identification tables, and the routing tables retained in the router. Points at which input lines 55-1, 55-2, 55-3, and 55-4 connect to the router (9) are assignedphysical interface numbers -
FIG. 5 is a diagram showing an example of the configuration of a packet layer processor (52). Lower layer processor interfaces (IFs) (100 and 106) interface with the lower layer processors (53 and 54). Switch IFs (103 and 109) interface with the switch (51). A controller IF (110) interfaces with the controller (50). One of the features of the present invention embodied as described herein is that the router holds a VPN ID indication table (150), a VPN identification table (151), and routing tables for VPNs (152). These tables are stored into storage. They may be stored into different physical storage devices or different areas in a single storage device. How these tables are stored is not an essential matter of implementing the present invention. The VPN ID indication table (150), VPN identification table (151), and routing tables (152), and how other blocks, not described here, work and the structures thereof will be described in the following wherein how the router (9) handles packets will be explained. - Assume that packets are received across the line (55) to the lower layer processor (53) and forwarded across the line (56) from the lower layer processor (54). Using this case as an example, how the router (9) handles packets will be explained below.
- When the lower layer processor (53) receives a packet from a LAN, it terminates the lower layer protocol below IP for the packet. To a packet forwarding processor (101), the lower layer processor (53) transfers the IP packet and the information relevant to the packet including the physical interface number at which the packet was received (hereinafter referred to as a receiving physical interface number), the lower layer protocol type, and the capsule header information for the lower layer to be used as the VPN identifier. The packet forwarding processor (101) extracts the IP header information from the IP packet it received and transfers the IP header information, the receiving physical interface number, the lower layer protocol type, and the capsule header information for the lower layer to be used as the VPN identifier to a VPN identification table/routing table look-up processor (102). The IP packet itself is temporally accumulated in the packet forwarding processor (101).
- The VPN identification table/routing table look-up processor (102) first searches the VPN ID indication table (150) for a match with the search key of the receiving physical interface number or the lower layer protocol type and determines what the VPN identifier is.
-
FIG. 6 shows example contents of the VPN ID indication table (150). The table contains the entries of physical interface number (200), lower layer protocol (203), and VPN ID (201). For “ATM” entries as the lower layer protocol, CLP subfields for indicating packet forwarding priority are also included in the table shown inFIG. 6 , but the CLP subfields may be deleted from the table. As described above, the administrator of the edge router (9) can register VPN ID settings into this table via the control terminal (57). The VPN identification table/routing table look-up processor (102.) searches this table for a match with the search key of the receiving physical interface number and determines what the VPN ID (201) is. For example, if the receiving physical interface number is 1, it is determined that the VPN ID is “VPI, VCI.” If the receiving physical interface number is 3, it is determined that the VPN ID is “physical interface number.” If the table includes the CLP subfields, as embodied in this example, a combination of “VPI, VCI” and “CLP” or a combination of “physical interface number” and “CLP” may be used as the VPN ID. Advantages of including the CLP (204) in the VPN ID will be described later. If there are a plurality of VPNs terminated to one physical interface and different protocol packets to pass across different VPNs are logically multiplexed and sent to the physical interface, when one of these packets is received, what VPN across which that packet passed cannot be determined by the receiving physical interface number. However, if the lower layer protocol for the packet is ATM, what VPN across which that packet passed can be identified by using “VPI, VCI” values as VPN identifiers. Meanwhile, if packets passed cross one VPN are exclusively terminated to one physical interface, the VPN can be identified by the receiving physical interface number. As the search key for the above table, a combination of a lower layer protocol (203) and a physical interface number (201) may be used. For example, assume that the line connected tophysical interface number 4 is a time division multiplex line and packets transmitted by frame relay as the lower layer protocol and packets transmitted by Point to Point Protocol (PPP) as the lower layer protocol are multiplexed on the line. In the above table, assume that a “DLCI” value is set as the VPN ID entry for “frame relay” as the lower layer protocol entry and a “time slot number” is set as the VPN ID entry for “PPP” as the lower layer protocol entry. In this case, a look-up for VPN ID with the search key of only the receivingphysical interface number 4 cannot distinctly find whether the VPN ID is “DLCI” or “time slot number.” Therefore, the search key of the combination of a lower layer protocol and a physical interface number should be applied to the look-up for VPN ID. - Once VPN ID has been determined, the VPN identification table/routing table look-up processor searches the VPN identification table (151) for a match with the search key of the VPN ID and determines a VPN across which the received packet passed.
-
FIG. 7A andFIG. 7B show example contents of the VPN identification table (151). Both examples of the VPN identification table contain the entries of VPN ID (201) and VPN number (250). -
FIG. 7A shows an example of the VPN identification table where “VPI, VCI” values are used as VPN ID (201). CLP subfields (204) and internal priority information fields (251) included in the table shown inFIG. 7A may be deleted from the table. The internal priority information fields (251) are used to indicate information on packet handling priority within the router. The VPN identification table/routing table look-up processor (102) searches the VPN identification table for a match with the search key of the VPN identification information included in the packet header in accordance with the VPN ID as the other search key determined by searching the above VPN ID indication table and determines what the VPN number (250) is. If the VPN identification table (151) includes the CLP subfields (204) and the internal priority information subfields (251), as embodied in this example, a combination of “VPI, VCI” and CLP (204) that indicates packet forwarding priority may be used as the search key. By including the CLP in the search key, different internal priority information can be set for packets sorted under a same VPN number: e.g., if “VPI, VCI”=a and CLP=0, internal priority information=a; if “VPI, VCI”=a and CLP=1, internal priority information=b. -
FIG. 7B shows an example of the VPN identification table where physical interface number (252) is used as the VPN ID (201). Unless packet handling priority control is executed, the internal priority information subfields (251) shown inFIG. 7B are not necessary. - If VPN IDs other than the above, such as VPN IDs in DLCI values and time slot numbers, are used, the VPN identification table may be reorganized appropriately, but basically the same as those shown in
FIGS. 7A and 7B . Specifically, a discrete VPN identification table (151) is created for each VPN ID type and values to be set in the table shall be entered via the control terminal (54). VPN identification tables (151) created for all VPN ID types may be stored in a single storage device or different storage devices. - One a VPN number has been determined, the VPN identification table/routing table look-up processor searches the routing table (152) that is for the VPN designated by the VPN number and determines an output route and capsule header information to send packet that is to be attached to the packet sorted under that VPN number.
-
FIG. 8 shows example contents of a routing table (152) for VPN. The VPN identification table/routing table look-up processor (102) holds separate routing tables (152) for the VPNs interconnected by the router. These routing tables (152) separately created for the VPNs may be stored into a single storage device or different storage devices. Any routing table (152) for VPN contains the entries of destination IP address (300), output route number (301), and output capsule header information (302). The output route number (301) is the intra-router identifier of a route across which the switch forwards the packet to a predetermined interface. The output capsule header information (302) is the information for capsule header that is used to send the packet across the ISP network (5). The VPN identification table/routing table look-up processor (102) searches the routing table for the VPN designated by the VPN number (250) determined by searching the above VPN identification table for a match with the search key of the destination IP address included in the IP packet header, thereby determining what the output route number (301) and the output capsule header information (302) are. Because the router in the present embodiment holds separate routing tables (152) for the VPNs interconnected by the router, correct output route can be determined even if an IP address used in one VPN is also used in another VPN. - Once the appropriate output route number (301) and output capsule header information (302) have been determined, the VPN identification table/routing table look-up processor (102) transfers the determined output route number (301) and output capsule header information (302) to the packet forwarding processor (101).
- The packet forwarding processor (101) transfers the IP packet itself accumulated there, the output route number (301), and the output capsule header information (302) to the switch (51) through the switch IF (103). The switch (51) outputs the IP packet itself and the output capsule header information (302) received from the packet forwarding processor (101) to the output port designated by the output route number.
- The packet layer processor (52) connected to the above output port, that is, the receiving-end packet layer processor (52) receives the IP packet itself and its output capsule information (302) sent from the preceding packet layer processor (52) through the switch IF (104). On receiving the IP packet itself and its output capsule information (302), the packet forwarding processor (105) transfers them to the lower layer processor (54) through the lower layer processor IF (106). On receiving the IP packet itself and its output capsule header information (302), the lower layer processor (54) generates a capsule header, based on the output capsule header information, and encapsulates the IP packet in another IP packet with the capsule header, and sends the new IP packet that contains the capsule header and the encapsulated packet to the core router (17).
- The VPN edge router configured as shown in FIGS. 4 to 8 was discussed above as one example of its configuration. By using the router embodied in the above example, even if packets are sent across different VPNs and terminated to a same physical interface, the VPNs across which the packets passed can be identified. Even if a same edge router interconnects a plurality of LANs that use network-specific lower layer protocols below IP, VPN identifiers proper for lower layer protocols can be set in the VPN ID indication table and this increases the freedom of organizing VPNs into a network system.
- Although, in the router embodiment discussed above, output capsule header information is directly obtained by searching the routing table for VPN, the table entry can be altered so that a output capsule number may be obtained. This output capsule number is an infra-router identifier that specifies a capsule header to be attached to the packet in the lower layer processor to which the output line attaches. If capsule numbers are used, the lower layer processor to which the output line attaches must hold a header generation table that contains capsule number and capsule header pairs. The above lower layer processor searches the header generation table for a match with the search key of a capsule number and determines the mating capsule header.
- The tables discussed above are logical tables. Look-up algorithm typically known as tree structure may be used as a table search method or structure by using a Content Addressable Memory (CAM) and a sequential table search method may be taken.
- If a time division multiplex line is connected to the VPN edge router, time slot numbers may be added to the information to be transferred from the lower layer processor to the packet layer processor besides the information items described in the above router example. In this case, a “time slot number” may be set as a VPN ID entry in the VPN ID indication table. As the search key for searching the VPN identification table, a time slot number may be used.
- If an Ethernet is connected to the VPN edge router and packets to pass across the Ethernet are VLAN encapsulated in compliance with IEEE802.1Q, VLAN Tag information may be added to the information to be transferred from the lower layer processor to the packet layer processor besides the information items described in the above router example. In this case, a “VLAN Tag” value may be set as a VPN ID entry in the VPN ID indication table. As the search key for searching the VPN identification table, VLAN Tag information may be used.
- If received IP packets are encapsulated with a L2TP header prescribed in Layer2 Tunneling Protocol (L2TP), appropriate information contained in the L2TP header (such as tunnel ID, session ID, etc.) may be set as a VPN ID entry in the VPN ID indication table.
- If received IP packets are encapsulated with a capsule header prescribed by a PPP Over Ethernet encapsulation protocol, information contained in the capsule header may be added to the information to be transferred from the lower layer processor to the packet layer processor besides the information items described in the above router example. In this case, appropriate information (such as session ID) specified the capsule header prescribed by the PPP Over Ethernet encapsulation protocol may be set as a VPN ID entry in the VPN ID indication table.
-
FIG. 9 shows another example of the configuration of the VPN edge router (9) offered by the present invention. Each of interface cards (400 and 401) accommodates lines for datagrams of same lower layer protocol. For example, the interface card (900) is for ATM datagrams and accommodates ATM lines (402). The interface card (401) is for POS datagrams and accommodates POS lines (403). The interface cards (400 and 401) can be mounted and removed if necessary and the router administrator can mount the required number of interface cards for lower layer protocols required for router operation on the router. On the interface cards, lower layer processors (405 and 406) are installed to execute processing specific to the lower layer protocols. The lower layer processors (905 and 406) operate in the same way as the lower layer processors (53 and 54) shown inFIG. 4 do. Packet processing cards (407) receive IP packets and related information from the above interface cards and execute packet layer processing. The packet processing cards (407) can be mounted and removed if necessary and the router administrator can mount the required number of the cards. On the packet processing cards (407), the packet layer processors (52) described withFIGS. 4 and 5 are installed. According to the attached interface card type and the organization of intermediate access networks between the LANs and the interface cards, the administrator can flexibly set the contents of the VPN ID indication table, VPN identification tables, routing tables for VPNs in the packet processing cards (407) via the control terminal (57). The VPN edge router embodied in this way also handles packets as explained with FIGS. 4 to 8. -
FIGS. 10 through 12 are schematic representations of the relation between an interface card that attaches to one of the packet processing cards (907) shown inFIG. 9 and the contents of the VPN ID indication table, VPN identification table (s), and routing tables for VPNs held in the packet processing card.FIGS. 10 through 12 show the LANs interconnected by the edge router and only the interface card and the packet processing card out of the components of the edge router (9). The VPN ID indication table, VPN identification table(s), and routing tables for VPNs in the packet processing card are logical tables. InFIGS. 10 through 12 , it is assumed that all physical interfaces on a same interface card are assigned VPN identifiers of same type. Therefore, because it is not necessary to set a physical interface number as the search key for the VPN ID indication table, the physical interface number entry as the search key is omitted. If different types of VPN identifiers are used for VPNs terminated to interfaces on a same interface card, it is advisable to use the physical interface number entry as the search key for the VPN ID indication table as described for the preceding router embodiment. -
FIG. 10 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in the packet processing card when an ATM interface card (400) attaches to the packet processing card (407). LAN1 (450) and LAN 2 (451) are assumed to belong to VPNA and VPNB, respectively. Packets from the LAN1 and LAN2 are multiplexed by a multiplexer (452) and carried across a line (453) to the ATM interface card (400). When multiplexed, the packets from the LAN1 and LAN2 are assigned a value of “a” for LAN1 and a value of “b” for LAN2 as “VPI, VCI” identifiers. In this example, “VPI, VCI” values are used to identify VPNs. In the VPN ID indication table (455) in the packet processing card (407), a “VPI, VCI” value is set as the VPN ID entry. In the VPN identification table (456), a “VPI, VCI” value is set as the search key entry. As routing tables (455) for VPNs, the packet processing card holds the routing table for VPNA (457) and the routing table for VPNB (458). For example, when the router receives a packet from the LAN1, the lower layer processor (405) of the ATM interface card (400) terminates the ATM protocol and transfers the IP packet itself and related information including the “VPI, VCI” identifier and the physical interface number to the packet processing card (407). The VPN identification table/routing table look-up processor of the packet processing card (407) searches the VPN ID indication table (455) and determines that “VPI, VCI” values are used as VPN identifiers. The look-up processor then searches the VPN identification table (456) for a match with the search key of “a” that is the value of “VPI, VCI” of the received packet and finds that the received packet passed across the VPNA. Then, the look-up processor searches the routing table for VPNA (457) and determines the appropriate output route and output capsule header information. -
FIG. 11 shows example contents of the VPN ID indication table, VPN identification table, and routing tables for VPNs in the packet processing card when a POS interface card (401) attaches to the packet processing card (407). The LAN1 (450) and LAN2 (451) are assumed to belong to VPNA and VPNB, respectively. The LAN1 and LAN2 are connected to the POS interface card (401) with lines (500) and (501), respectively. Physical interfaces that interface the lines (500) and (501) and the POS interface card (401) are assignedphysical interface numbers FIG. 10 , except that physical interface numbers instead of “VPI, VCI” values are used as VPN identifiers. -
FIG. 12 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when an interface card for time division multiplex line (550), which is not shown inFIG. 8 , attaches to the packet processing card (407). LAN1 (450), LAN2 (451), LAN3 (551), and LAN4 (552) are assumed to belong to VPNA, VPNB, VPNC, and VPND, respectively. The lower layer protocol for the LAN1 and LAN2 is assumed to be frame relay and that for the LAN3 and LAN4 is assumed to be Point to Point Protocol (PPP). Packets from the LAN1 and packets from the LAN2 are respectively assigned “10” and “20” as DLCI values and multiplexed on a line (554) by a frame relay multiplexer (553). Moreover, a time division multiplexer (555) multiplexes lines (554), (556), and - (557) on a line (558). When multiplexed, datagrams carried across the lines (554), (556), and (557) are assigned
time slot numbers FIG. 10 , except the following. The VPN ID indication table is searched with the search key of lower layer protocol (559). As the result of the VPN ID indication table search, the “DLCI” VPN identifiers are used for packets received from the LAN1 and LAN2 and the “time slot number” VPN identifiers are used for packets received from the LAN3 and LAN4. - For
FIG. 9 through 12, examples where one interface card attaches one packet processing card were discussed, whereas a plurality interface cards may attach to a packet processing card. Interface cards that are for different lower layer protocols can be attached to one packet processing card. -
FIG. 13 shows example contents of the VPN ID indication table, VPN identification tables, and routing tables for VPNs in the packet processing card when interface cards for different lower layer protocols attach to the packet processing card (407). The interface cards are assumed to be the ATM interface card (400) and the POS interface card (401). ForFIG. 13 , it is assumed that all physical interfaces on a same interface card are assigned VPN identifiers of same type. Because a plurality of interface cards attach to the packet processing card in this example, the interface cards (400) and (401) assignedcard numbers card number 1. The LAN3 and LAN4 are connected to the POS interface card (401) with lines (500) and (501), respectively. Physical interfaces that interface the lines (500) and (501) and the POS interface card (401) are assignedphysical interface numbers card number 2. The packet processing card holds one VPN identification table (600) that maps “VPI, VCI” values to VPN numbers and another VPN identification table (601) that maps physical interface numbers to VPN numbers. As routing tables for VPNs, the card holds a routing table for VPNA (457), a routing table for VPNB (458), a routing table for VPNC (464), and a routing table for VPND (465). Processing within the packet processing card (407) is the same as that explained withFIG. 10 , except that the VPN ID indication table is searched with the search key of card number (602). Although ATM and POS interface cards attach to the packet processing card in this example, the combination of the interface cards may be varied. For example, the POS interface card can be replaced by an interface card for FR. In this case, it may be preferable that packets from the LAN3 and LAN4 are multiplexed on one line and carried to the interface card for FR in the same manner as for the packets from the LAN1 and LAN2 and DLCI values are used to identify VPNs. - The router embodied as explained above with FIGS. 9 to 13 allows the router administrator to flexibly set the contents of the VPN ID indication table, VPN identification tables, routing tables for VPNs in the packet processing cards (907) via the control terminal (57), according to the attached interface card type. Because VPNs are identified by identifiers assigned to multiplex logical channels terminated to a physical interface, when the router receives one of the packets that are sent across the VPNs and logically multiplexed on one line, it can identify a VPN across which the packet passed.
-
FIG. 14 illustrates an example of the procedure for customizing the internal settings of the packet processing card (407) fit for an interface card that is newly installed. After an interface card is installed on the VPN edge router (9), set VPN IDs into the VPN ID indication table (455) (steps 701 and 702). The administrator can customize the contents of the VPN ID indication table (455), according to the kind of the installed interface card. Then, set the VPN identification tables for each VPN ID set in VPN indication table (step 703). Finally, set routing tables for each of the VPNs interconnected by the router (step 704). - It is also feasible that VPN IDs are automatically registered in the following way. When an interface card is installed to attach to the packet processing card, the interface card is set to communicate with the packet processing card. The interface card automatically finds lower layer protocols specific to the IP packets to terminate to it and notifies the packet processing card of the lower layer protocols. Then, VPN IDs predefined for the lower layer protocols thus notified can be automatically registered into the VPN ID indication table.
- How the VPN edge router of the present invention operates was explained above with reference to FIGS. 1 to 14. As the summary of the above description,
FIG. 15 illustrates a general operation flow of the router. - When the VPN edge router receives a packet in which an IP packet is encapsulated by a network-specific protocol from a LAN (step 801), it looks up for VPN ID in the VPN ID indication table (step 802) and determines a VPN ID of the received packet (step 803). Logical channel identifiers such as “VPI, VCI” values are generally used as VPN IDs, whereas combinations of one of these identifiers and physical interface numbers may be used as VPN IDs, depending on the lower layer protocols for VPNs interconnected by the router. Then, the router looks up for VPN in the VPN identification table, using the determined VPN ID as the search key (step 804) and determines a VPN across which the received packet passes (step 805). If the VPN ID is, for example, “VPI, VCI,” the VPN identification table is searched for a match of the search key of the value of “VPI, VCI” assigned to the received packet and thereby the VPN across which the packet passed is determined. Finally, the routing table for the thus determined VPN is looked up (step 806) and an output route and an output capsule header are determined (step 807).
- By using the router of the present invention, VPNs are identified by identifiers assigned to multiplex logical channels terminated to a physical interface. Thus, the number of VPNs to be interconnected by the router can be increased without increasing the physical lines.
- Even if the router interconnects a plurality of LANs running under different lower layer protocols below IP, VPN IDs proper for the protocols can be registered with the router so that the router can identify VPNs.
- While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details can be made therein without departing from the spirit and scope of the invention.
Claims (20)
1. A router connected to a core network, a first local area network (LAN) belonging to a first virtual private network (VPN), a second Local Area Network (LAN) belonging to a second VPN, a third LAN belonging to a third VPN and a fourth LAN belonging to a fourth VPN, comprising:
a first interface for accommodating a first line connected to the first LAN and the second LAN, and for receiving Internet Protocol (IP) packets from the first and the second LANs via the first line, the IP packets from the first and the second LANs being encapsulated by a first protocol;
a second interface connected to the core network; and
means for identifying which of the first VPN and the second VPN to which an IP packet received at the first interface belongs based on correspondence information between header information of the first protocol and a VPN identifier,
wherein IP packets from the third and the fourth LANs being encapsulated by a second protocol different from the first protocol.
2. The router according to claim 1 , further comprising:
a first routing information of the first VPN for mapping each IP addresses used in the first VPN to each of capsule headers used in the core network;
a second routing information of the second VPN for mapping each IP addresses used in the second VPN to each of capsule headers used in the core network; and
a processing unit for adding an capsule header used in the core network to an IP packet belonging to the first VPN by referring to the first routing information, and adding a capsule header used in the core network to an IP packet belonging to the second VPN by referring to the second routing information.
3. The router according to claim 1 , wherein the first protocol is an asynchronous transfer mode protocol and the header information is expressed in combined VPI and VCI values, and
wherein the second protocol is a Point-to-point Protocol (PPP) over a Synchronous Optical Network (SONET).
4. The router according to claim 1 , wherein the first protocol is an Layer2 Tunneling Protocol (L2TP) and the header information is expressed in L2TP encapsulating header.
5. The router according to claim 1 , wherein the first protocol is Ethernet and the header information is expressed as VLAN Tag based on IEEE802.1Q.
6. A router connected to a core network, a first local area network (LAN) belonging to a first virtual private network (VPN), a second LAN belonging to a second VPN, a third LAN belonging to a third VPN and a fourth LAN belonging to a fourth VPN, comprising:
means for receiving Internet Protocol (IP) packets from the first and the second LANs being encapsulated by a first protocol;
a first interface connected to the core network;
a second interface for accommodating a first line connected to the third LAN and a second line connected to the fourth LAN, and for receiving IP packets from the third LAN via the first line and the IP packets from the fourth LAN via the second line, the IP packets from the third and the fourth LANs being encapsulated by a second protocol different from the first protocol; and
means for identifying which of the third VPN and the fourth VPN to which an IP packet received at the second interface belongs based on correspondence information between the VPN identifier and physical interface numbers assigned to interface between the second interface and the first line and interface between the second interface and the second line.
7. The router according to claim 6 , further comprising:
a first routing information of the third VPN for mapping each IP addresses used in the third VPN to each of capsule headers used in the core network;
a second routing information of the fourth VPN for mapping each IP addresses used in the fourth VPN to each of capsule headers used in the core network; and
a processing unit for adding an capsule header used in the core network to an IP packet belonging to the third VPN by referring the first routing information, and adding an capsule header used in the core network to an IP packet belonging to the fourth VPN by referring the second routing information.
8. The router according to claim 6 , wherein the first protocol is an asynchronous transfer mode protocol and the header information is expressed in combined VPI and VCI values, and
wherein the second protocol is a Point-to-point Protocol (PPP) over a Synchronous Optical Network (SONET).
9. The router according to claim 6 , wherein the second protocol is an Layer2 Tunneling Protocol (L2TP).
10. The router according to claim 6 , wherein the first protocol is Ethernet VLAN Tag based on IEEE802.1 Q.
11. A method of transferring a packet in a router connected to a core network, a first local area network (LAN) belonging to a first virtual private network (VPN), a second LAN belonging to a second VPN, a third LAN belonging to a third VPN and a fourth LAN belonging to a fourth VPN, wherein the router receives IP packets from the first and the second LANs via a first line, the IP packets from the first and second LANs being encapsulated by a first protocol, receives IP packets from the third LAN via a second line and IP packets from the fourth LAN via a third line, the Internet Protocol (IP) packets from the third and the fourth LANs being encapsulated by a second protocol different from the first protocol, the method comprising the steps of:
identifying which of the first VPN and the second VPN to which an IP a packet received from the first line belongs on the basis of the correspondence information between header information of the first protocol and a VPN identifier.
12. The method of transferring a packet in a router according to claim 11 , wherein the router comprising:
a first routing information of the first VPN for mapping each IP addresses used in the first VPN to each of capsule headers used in the core network;
a second routing information of the second VPN for mapping each IP addresses used in the second VPN to each of capsule headers used in the core network; and
a processing unit for adding an capsule header used in the core network to an IP packet belonging to the first VPN by referring the first routing information, and adding an capsule header used in the core network to an IP packet belonging to the second VPN by referring the second routing information.
13. The method of transferring a packet in a router according to claim 11 , wherein the first protocol is an asynchronous transfer mode protocol and the header information is expressed in combined VPI and VCI, and
wherein the second protocol is a Point-to-point Protocol (PPP) over a Synchronous Optical Network (SONET).
14. The method of transferring a packet in a router according to claim 11 , wherein the first protocol is an Layer2 Tunneling Protocol (L2TP) and the header information is expressed in L2TP encapsulating header.
15. The method of transferring a packet in a router according to claim 11 , wherein the first protocol is Ethernet and the header information is expressed as VLAN Tag based on IEEE802.1Q.
16. A method of transferring a packet in a router connected to a core network, a first local area network (LAN) belonging to a first virtual private network (VPN), a second LAN belonging to a second VPN, a third LAN belonging to a third VPN and a fourth LAN belonging to a fourth VPN, wherein the router receives IP packets from the first and the second LANs via a first line, the IP packets from the first and second LANs being encapsulated by a first protocol, receives IP packets from the third LAN via a second line and IP packets from the fourth LAN via a third line, the Internet Protocol (IP) packets from the third and the fourth LANs being encapsulated by a second protocol different from the first protocol, the method comprising the steps of:
identifying which of the third VPN and the fourth VPN to which an IP a packet received from the second line belongs based on correspondence information between the VPN identifier and physical interface numbers assigned to interface between the router and the first line and interface between the router and the second line.
17. The method of transferring a packet in a router according to claim 16 , wherein the router comprising:
a first routing information of the third VPN for mapping each IP addresses used in the third VPN to each of capsule headers used in the core network;
a second routing information of the fourth VPN for mapping each IP addresses used in the fourth VPN to each of capsule headers used in the core network; and
a processing unit for adding an capsule header used in the core network to an IP packet belonging to the third VPN by referring the first routing information, and adding an capsule header used in the core network to an IP packet belonging to the fourth VPN by referring the second routing information.
18. The method of transferring a packet in a router according to claim 16 , wherein the first protocol is an asynchronous transfer mode protocol and the header information is expressed in combined VPI and VCI, and
wherein the second protocol is a Point-to-point Protocol (PPP) over a Synchronous Optical Network (SONET).
19. The method of transferring a packet in a router according to claim 16 , wherein the first protocol is an Layer2 Tunneling Protocol (L2TP) and the header information is expressed in L2TP encapsulating header.
20. The method of transferring a packet in a router according to claim 16 , wherein the first protocol is Ethernet and the header information is expressed as VLAN Tag based on IEEE802.1Q.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/349,154 US20060126644A1 (en) | 2000-06-02 | 2006-02-08 | VPN router and VPN identification method by using logical channel identifiers |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000170414A JP4099930B2 (en) | 2000-06-02 | 2000-06-02 | Router device and VPN identification information setting method |
JP200-170414 | 2000-06-02 | ||
US09/811,440 US7054319B2 (en) | 2000-06-02 | 2001-03-20 | VPN router and VPN identification method by using logical channel identifiers |
US11/349,154 US20060126644A1 (en) | 2000-06-02 | 2006-02-08 | VPN router and VPN identification method by using logical channel identifiers |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/811,440 Continuation US7054319B2 (en) | 2000-06-02 | 2001-03-20 | VPN router and VPN identification method by using logical channel identifiers |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060126644A1 true US20060126644A1 (en) | 2006-06-15 |
Family
ID=18673142
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/811,440 Expired - Lifetime US7054319B2 (en) | 2000-06-02 | 2001-03-20 | VPN router and VPN identification method by using logical channel identifiers |
US11/349,154 Abandoned US20060126644A1 (en) | 2000-06-02 | 2006-02-08 | VPN router and VPN identification method by using logical channel identifiers |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/811,440 Expired - Lifetime US7054319B2 (en) | 2000-06-02 | 2001-03-20 | VPN router and VPN identification method by using logical channel identifiers |
Country Status (2)
Country | Link |
---|---|
US (2) | US7054319B2 (en) |
JP (1) | JP4099930B2 (en) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030095548A1 (en) * | 2001-11-16 | 2003-05-22 | Nec Corporation | System for retrieving destination of a packet with plural headers |
US20040085951A1 (en) * | 2002-10-15 | 2004-05-06 | Ramin Rezaiifar | Method and apparatus for the use of micro-tunnels in a communications system |
US20050265308A1 (en) * | 2004-05-07 | 2005-12-01 | Abdulkadev Barbir | Selection techniques for logical grouping of VPN tunnels |
US20070280243A1 (en) * | 2004-09-17 | 2007-12-06 | Hewlett-Packard Development Company, L.P. | Network Virtualization |
US20080285592A1 (en) * | 2007-04-11 | 2008-11-20 | Arris | Extended layer two tunneling protocol applications and architectures |
US7492714B1 (en) * | 2003-02-04 | 2009-02-17 | Pmc-Sierra, Inc. | Method and apparatus for packet grooming and aggregation |
US7519735B1 (en) * | 2001-05-08 | 2009-04-14 | Juniper Networks, Inc. | Single board routing arrangement |
US20090158420A1 (en) * | 2007-12-14 | 2009-06-18 | Ks Girish | Selective desktop control of virtual private networks (vpn's) in a multiuser environment |
US20090274156A1 (en) * | 2008-04-29 | 2009-11-05 | Arris | Carrier ethernet over docsis |
CN111294270A (en) * | 2018-12-07 | 2020-06-16 | 华为技术有限公司 | Method, device, equipment and system for accessing data center |
US10715803B2 (en) * | 2012-04-11 | 2020-07-14 | Texas Instruments Incorporated | Virtual boundary processing simplification for adaptive loop filtering (ALF) in video coding |
US10812980B2 (en) | 2016-10-10 | 2020-10-20 | Huawei Technologies Co., Ltd. | Communication method, security node network element, and terminal |
Families Citing this family (87)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3390384B2 (en) * | 1999-11-04 | 2003-03-24 | 日本電気通信システム株式会社 | Connection setting method and method in TCP / IP |
JP4099930B2 (en) * | 2000-06-02 | 2008-06-11 | 株式会社日立製作所 | Router device and VPN identification information setting method |
EP1758311B1 (en) * | 2000-06-16 | 2009-08-19 | Fujitsu Limited | Communication device including VPN accomodation function |
AU2001267551B2 (en) * | 2000-06-22 | 2005-12-15 | 3M Espe Ag | Device for producing dental workpieces |
ATE291803T1 (en) * | 2000-06-30 | 2005-04-15 | Cit Alcatel | METHOD AND APPARATUS FOR COMMUNICATING WITH DEVICES THAT DO NOT BELONG TO THE SAME VIRTUAL PRIVATE NETWORK (VPN). |
US6778498B2 (en) * | 2001-03-20 | 2004-08-17 | Mci, Inc. | Virtual private network (VPN)-aware customer premises equipment (CPE) edge router |
US20020138427A1 (en) * | 2001-03-20 | 2002-09-26 | Trivedi Prakash A. | Systems and methods for communicating from an integration platform to a billing unit |
US20030115480A1 (en) * | 2001-12-17 | 2003-06-19 | Worldcom, Inc. | System, method and apparatus that employ virtual private networks to resist IP QoS denial of service attacks |
WO2002080493A1 (en) * | 2001-03-29 | 2002-10-10 | British Telecommunications Public Limited Company | Protocol conversion |
JP4484190B2 (en) * | 2001-04-19 | 2010-06-16 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Router search system, router search method, and router search program |
US7099912B2 (en) * | 2001-04-24 | 2006-08-29 | Hitachi, Ltd. | Integrated service management system |
JP3945297B2 (en) * | 2001-04-24 | 2007-07-18 | 株式会社日立製作所 | System and management system |
US7152115B2 (en) * | 2001-07-12 | 2006-12-19 | Nortel Networks Limited | Virtual private networks |
US7239642B1 (en) * | 2001-07-16 | 2007-07-03 | Network Appliance, Inc. | Multi-protocol network interface card |
JP2003092586A (en) * | 2001-09-18 | 2003-03-28 | Fujitsu Ltd | Layer 2-vpn relaying system |
US7085827B2 (en) * | 2001-09-20 | 2006-08-01 | Hitachi, Ltd. | Integrated service management system for remote customer support |
US7484003B2 (en) * | 2001-11-17 | 2009-01-27 | Redback Networks Inc. | Method and apparatus for multiple contexts and layer 3 virtual private networks |
US7813346B1 (en) * | 2001-11-21 | 2010-10-12 | Juniper Networks, Inc. | Filter-based forwarding in a network |
JP3885573B2 (en) * | 2001-12-04 | 2007-02-21 | 株式会社日立製作所 | Packet processing method and apparatus |
US7533183B1 (en) * | 2001-12-28 | 2009-05-12 | Nortel Networks Limited | Central control of multiple address domains within a router |
GB0200838D0 (en) * | 2002-01-15 | 2002-03-06 | Xchangepoint Holdings Ltd | Virtual local area network interconnection |
US7984157B2 (en) * | 2002-02-26 | 2011-07-19 | Citrix Systems, Inc. | Persistent and reliable session securely traversing network components using an encapsulating protocol |
JP3898535B2 (en) * | 2002-03-14 | 2007-03-28 | 株式会社日立製作所 | Data transfer device |
US7188365B2 (en) | 2002-04-04 | 2007-03-06 | At&T Corp. | Method and system for securely scanning network traffic |
US7203957B2 (en) * | 2002-04-04 | 2007-04-10 | At&T Corp. | Multipoint server for providing secure, scaleable connections between a plurality of network devices |
FR2838590B1 (en) * | 2002-04-16 | 2005-12-30 | St Microelectronics Sa | ROUTING METHOD FOR A TELECOMMUNICATION NETWORK AND ROUTER FOR IMPLEMENTING SAID METHOD |
JP2003318936A (en) * | 2002-04-18 | 2003-11-07 | Crosswave Communications Inc | Vlan-id rewriting system in ethernet (r) frame including vlan-id |
JP2003338843A (en) * | 2002-05-21 | 2003-11-28 | Genetec Corp | Routing apparatus and routing method |
US7937471B2 (en) * | 2002-06-03 | 2011-05-03 | Inpro Network Facility, Llc | Creating a public identity for an entity on a network |
US7688823B2 (en) * | 2002-06-04 | 2010-03-30 | Alcatel-Lucent Usa Inc. | Efficient mechanism for wire-tapping network traffic |
US7362744B2 (en) * | 2002-08-15 | 2008-04-22 | International Business Machines Corporation | Database management system and method of using it to transmit packets |
US8234358B2 (en) * | 2002-08-30 | 2012-07-31 | Inpro Network Facility, Llc | Communicating with an entity inside a private network using an existing connection to initiate communication |
US7515592B2 (en) * | 2002-10-07 | 2009-04-07 | Broadcom Corporation | Fast-path implementation for transparent LAN services using double tagging |
JP2004153706A (en) * | 2002-10-31 | 2004-05-27 | Fujitsu Ltd | Communication equipment and network interface device |
JP2004158973A (en) * | 2002-11-05 | 2004-06-03 | Fujitsu Ltd | Packet relaying apparatus |
US7574738B2 (en) * | 2002-11-06 | 2009-08-11 | At&T Intellectual Property Ii, L.P. | Virtual private network crossovers based on certificates |
US7397827B2 (en) * | 2002-12-11 | 2008-07-08 | Tellabs Operations, Inc. | Systems and methods for switching multi-rate communications |
EP2365667A1 (en) | 2003-02-03 | 2011-09-14 | Nippon Telegraph And Telephone Corporation | Data transfer apparatus and data transfer system |
US7949785B2 (en) * | 2003-03-31 | 2011-05-24 | Inpro Network Facility, Llc | Secure virtual community network system |
JP3778446B2 (en) * | 2003-06-20 | 2006-05-24 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | Ethernet switch |
US7983820B2 (en) | 2003-07-02 | 2011-07-19 | Caterpillar Inc. | Systems and methods for providing proxy control functions in a work machine |
US7516244B2 (en) * | 2003-07-02 | 2009-04-07 | Caterpillar Inc. | Systems and methods for providing server operations in a work machine |
US7532640B2 (en) * | 2003-07-02 | 2009-05-12 | Caterpillar Inc. | Systems and methods for performing protocol conversions in a machine |
US8572249B2 (en) * | 2003-12-10 | 2013-10-29 | Aventail Llc | Network appliance for balancing load and platform services |
JP4074851B2 (en) * | 2003-12-25 | 2008-04-16 | 株式会社日立製作所 | Communication relay method and relay device |
US8007847B2 (en) | 2004-01-13 | 2011-08-30 | Eytan Biderman | Feeding formula appliance |
FI117033B (en) * | 2004-02-24 | 2006-05-15 | Valtion Teknillinen | Distributed Dynamic Routing |
JP4416593B2 (en) * | 2004-07-21 | 2010-02-17 | 富士通株式会社 | Network connection control method and network connection control system |
US7451486B2 (en) * | 2004-09-30 | 2008-11-11 | Avaya Inc. | Stateful and cross-protocol intrusion detection for voice over IP |
JP4401942B2 (en) * | 2004-12-08 | 2010-01-20 | 株式会社日立コミュニケーションテクノロジー | Packet transfer device and communication network |
JP2008529325A (en) * | 2005-01-16 | 2008-07-31 | ズランゴー リミテッド | Communication network system and method for using the same |
JP2008527563A (en) | 2005-01-16 | 2008-07-24 | ズランゴー リミテッド | Iconic communication |
WO2007080558A2 (en) | 2006-01-16 | 2007-07-19 | Zlango Ltd. | Communications network system and methods for using same |
US7535917B1 (en) * | 2005-02-22 | 2009-05-19 | Netapp, Inc. | Multi-protocol network adapter |
US7688829B2 (en) * | 2005-09-14 | 2010-03-30 | Cisco Technology, Inc. | System and methods for network segmentation |
JP4615435B2 (en) * | 2005-12-26 | 2011-01-19 | 三菱電機株式会社 | Network relay device |
US7894451B2 (en) * | 2005-12-30 | 2011-02-22 | Extreme Networks, Inc. | Method of providing virtual router functionality |
EP1977312A2 (en) | 2006-01-16 | 2008-10-08 | Zlango Ltd. | Iconic communication |
EP1977617A2 (en) | 2006-01-16 | 2008-10-08 | Zlango Ltd. | Activating an application |
JP4732974B2 (en) * | 2006-07-27 | 2011-07-27 | 株式会社日立製作所 | Packet transfer control method and packet transfer apparatus |
JP4751811B2 (en) * | 2006-11-07 | 2011-08-17 | 富士通株式会社 | Network setting method, network system, and relay device |
EP2109964B9 (en) * | 2007-01-19 | 2013-10-02 | Orange | Packet assembly in a communication network supporting virtual networks |
US20090154349A1 (en) * | 2007-12-12 | 2009-06-18 | Bernard Marc R | Method and apparatus for managing traffic flow of forwarding entries through a virtual forwarding database of a network node |
JP5493926B2 (en) * | 2010-02-01 | 2014-05-14 | 日本電気株式会社 | Interface control method, interface control method, and interface control program |
US8935427B2 (en) * | 2010-09-23 | 2015-01-13 | Microsoft Corporation | Providing virtual networks using multi-tenant relays |
US9049140B2 (en) * | 2010-11-18 | 2015-06-02 | Microsoft Technology Licensing, Llc | Backbone network with policy driven routing |
JP5621639B2 (en) * | 2011-02-08 | 2014-11-12 | 村田機械株式会社 | Relay server and relay communication system |
US8605732B2 (en) | 2011-02-15 | 2013-12-10 | Extreme Networks, Inc. | Method of providing virtual router functionality |
US20120224579A1 (en) * | 2011-03-01 | 2012-09-06 | Futurewei Technologies, Inc. | Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) Over Routed Ethernet Backbone |
US9288524B2 (en) * | 2011-12-21 | 2016-03-15 | Sony Corporation | Using TV over VPN to present remote device application graphics |
US9479433B1 (en) * | 2013-04-30 | 2016-10-25 | Cisco Technology, Inc. | Interconnecting virtual private networks |
JP6299119B2 (en) * | 2013-09-02 | 2018-03-28 | 富士通株式会社 | Transmission apparatus, transmission system, and transmission method |
US9825884B2 (en) | 2013-12-30 | 2017-11-21 | Cavium, Inc. | Protocol independent programmable switch (PIPS) software defined data center networks |
US9516145B2 (en) | 2014-06-19 | 2016-12-06 | Cavium, Inc. | Method of extracting data from packets and an apparatus thereof |
US9438703B2 (en) | 2014-06-19 | 2016-09-06 | Cavium, Inc. | Method of forming a hash input from packet contents and an apparatus thereof |
US9473601B2 (en) | 2014-06-19 | 2016-10-18 | Cavium, Inc. | Method of representing a generic format header using continuous bytes and an apparatus thereof |
US9497294B2 (en) | 2014-06-19 | 2016-11-15 | Cavium, Inc. | Method of using a unique packet identifier to identify structure of a packet and an apparatus thereof |
US9961167B2 (en) | 2014-06-19 | 2018-05-01 | Cavium, Inc. | Method of modifying packets to a generic format for enabling programmable modifications and an apparatus thereof |
US9531848B2 (en) | 2014-06-19 | 2016-12-27 | Cavium, Inc. | Method of using generic modification instructions to enable flexible modifications of packets and an apparatus thereof |
US10616380B2 (en) | 2014-06-19 | 2020-04-07 | Cavium, Llc | Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof |
US9531849B2 (en) | 2014-06-19 | 2016-12-27 | Cavium, Inc. | Method of splitting a packet into individual layers for modification and intelligently stitching layers back together after modification and an apparatus thereof |
US10050833B2 (en) | 2014-06-19 | 2018-08-14 | Cavium, Inc. | Method of reducing latency in a flexible parser and an apparatus thereof |
US9635146B2 (en) | 2014-06-19 | 2017-04-25 | Cavium, Inc. | Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof |
US9742694B2 (en) | 2014-06-19 | 2017-08-22 | Cavium, Inc. | Method of dynamically renumbering ports and an apparatus thereof |
US9628385B2 (en) | 2014-06-19 | 2017-04-18 | Cavium, Inc. | Method of identifying internal destinations of networks packets and an apparatus thereof |
US9606781B2 (en) | 2014-11-14 | 2017-03-28 | Cavium, Inc. | Parser engine programming tool for programmable network devices |
US11153276B1 (en) * | 2018-11-15 | 2021-10-19 | N3Xtwork, Llc | Secure data routing and randomization |
Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020097725A1 (en) * | 1998-07-27 | 2002-07-25 | Nec Corporation | Resource and protocol management for virtual private networks within multiprocessor ATM switches |
US6522627B1 (en) * | 1998-11-12 | 2003-02-18 | Nortel Networks Limited | Managing internet protocol connection oriented services |
US6594704B1 (en) * | 1999-12-15 | 2003-07-15 | Quarry Technologies | Method of managing and using multiple virtual private networks in a router with a single routing table |
US6614791B1 (en) * | 1999-05-11 | 2003-09-02 | Nortel Networks Limited | System, device, and method for supporting virtual private networks |
US6633571B1 (en) * | 1999-05-27 | 2003-10-14 | Hitachi, Ltd. | VPN composing method, interwork router, packet communication method, data communication apparatus, and packet relaying apparatus |
US6636516B1 (en) * | 1999-03-17 | 2003-10-21 | Nec Corporation | QOS-based virtual private network using ATM-based internet virtual connections |
US6751220B1 (en) * | 2000-06-12 | 2004-06-15 | Nortel Networks Limited | Apparatus and method of managing virtual private network routing data |
US6751191B1 (en) * | 1999-06-29 | 2004-06-15 | Cisco Technology, Inc. | Load sharing and redundancy scheme |
US6771662B1 (en) * | 2000-05-30 | 2004-08-03 | Hitachi, Ltd. | Label switching type of packet forwarding apparatus |
US6788681B1 (en) * | 1999-03-16 | 2004-09-07 | Nortel Networks Limited | Virtual private networks and methods for their operation |
US6879680B2 (en) * | 1999-07-29 | 2005-04-12 | Mc, Inc. | Method of and system for extending internet telephony over virtual private network direct access lines |
US6956858B2 (en) * | 2000-06-30 | 2005-10-18 | Mayan Networks Corporation | Network routing table and packet routing method |
US7002976B2 (en) * | 2000-11-01 | 2006-02-21 | Marconi Intellectual Property (Ringfence) Inc. | Virtual ethernet ports with automated router port extension |
US7028204B2 (en) * | 2000-09-06 | 2006-04-11 | Schneider Automation Inc. | Method and apparatus for ethernet prioritized device clock synchronization |
US7054319B2 (en) * | 2000-06-02 | 2006-05-30 | Hitachi, Ltd. | VPN router and VPN identification method by using logical channel identifiers |
US7072346B2 (en) * | 2000-11-27 | 2006-07-04 | Fujitsu Limited | Network and edge router |
US7136374B1 (en) * | 2001-03-19 | 2006-11-14 | Juniper Networks, Inc. | Transport networks supporting virtual private networks, and configuring such networks |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3384319B2 (en) | 1998-03-27 | 2003-03-10 | 日本電気株式会社 | Virtual private network construction system |
JP3228249B2 (en) | 1998-12-04 | 2001-11-12 | 日本電気株式会社 | Router device |
-
2000
- 2000-06-02 JP JP2000170414A patent/JP4099930B2/en not_active Expired - Lifetime
-
2001
- 2001-03-20 US US09/811,440 patent/US7054319B2/en not_active Expired - Lifetime
-
2006
- 2006-02-08 US US11/349,154 patent/US20060126644A1/en not_active Abandoned
Patent Citations (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020097725A1 (en) * | 1998-07-27 | 2002-07-25 | Nec Corporation | Resource and protocol management for virtual private networks within multiprocessor ATM switches |
US6522627B1 (en) * | 1998-11-12 | 2003-02-18 | Nortel Networks Limited | Managing internet protocol connection oriented services |
US6788681B1 (en) * | 1999-03-16 | 2004-09-07 | Nortel Networks Limited | Virtual private networks and methods for their operation |
US6636516B1 (en) * | 1999-03-17 | 2003-10-21 | Nec Corporation | QOS-based virtual private network using ATM-based internet virtual connections |
US6614791B1 (en) * | 1999-05-11 | 2003-09-02 | Nortel Networks Limited | System, device, and method for supporting virtual private networks |
US20040095947A1 (en) * | 1999-05-11 | 2004-05-20 | Luciani James V. | System, device, and method for supporting virtual private networks |
US6633571B1 (en) * | 1999-05-27 | 2003-10-14 | Hitachi, Ltd. | VPN composing method, interwork router, packet communication method, data communication apparatus, and packet relaying apparatus |
US20040008706A1 (en) * | 1999-05-27 | 2004-01-15 | Kenichi Sakamoto | VPN composing method, interwork router, packet communication method, data communication apparatus, and packet relaying apparatus |
US6751191B1 (en) * | 1999-06-29 | 2004-06-15 | Cisco Technology, Inc. | Load sharing and redundancy scheme |
US6879680B2 (en) * | 1999-07-29 | 2005-04-12 | Mc, Inc. | Method of and system for extending internet telephony over virtual private network direct access lines |
US6594704B1 (en) * | 1999-12-15 | 2003-07-15 | Quarry Technologies | Method of managing and using multiple virtual private networks in a router with a single routing table |
US6771662B1 (en) * | 2000-05-30 | 2004-08-03 | Hitachi, Ltd. | Label switching type of packet forwarding apparatus |
US7054319B2 (en) * | 2000-06-02 | 2006-05-30 | Hitachi, Ltd. | VPN router and VPN identification method by using logical channel identifiers |
US6751220B1 (en) * | 2000-06-12 | 2004-06-15 | Nortel Networks Limited | Apparatus and method of managing virtual private network routing data |
US6956858B2 (en) * | 2000-06-30 | 2005-10-18 | Mayan Networks Corporation | Network routing table and packet routing method |
US7028204B2 (en) * | 2000-09-06 | 2006-04-11 | Schneider Automation Inc. | Method and apparatus for ethernet prioritized device clock synchronization |
US7002976B2 (en) * | 2000-11-01 | 2006-02-21 | Marconi Intellectual Property (Ringfence) Inc. | Virtual ethernet ports with automated router port extension |
US7072346B2 (en) * | 2000-11-27 | 2006-07-04 | Fujitsu Limited | Network and edge router |
US7136374B1 (en) * | 2001-03-19 | 2006-11-14 | Juniper Networks, Inc. | Transport networks supporting virtual private networks, and configuring such networks |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7519735B1 (en) * | 2001-05-08 | 2009-04-14 | Juniper Networks, Inc. | Single board routing arrangement |
US7212529B2 (en) * | 2001-11-16 | 2007-05-01 | Nec Corporation | System for retrieving destination of a packet with plural headers |
US20030095548A1 (en) * | 2001-11-16 | 2003-05-22 | Nec Corporation | System for retrieving destination of a packet with plural headers |
US20040085951A1 (en) * | 2002-10-15 | 2004-05-06 | Ramin Rezaiifar | Method and apparatus for the use of micro-tunnels in a communications system |
US7701963B2 (en) * | 2002-10-15 | 2010-04-20 | Qualcomm Incorporated | Method and apparatus for the use of micro-tunnels in a communications system |
US7492714B1 (en) * | 2003-02-04 | 2009-02-17 | Pmc-Sierra, Inc. | Method and apparatus for packet grooming and aggregation |
US20050265308A1 (en) * | 2004-05-07 | 2005-12-01 | Abdulkadev Barbir | Selection techniques for logical grouping of VPN tunnels |
US8223770B2 (en) * | 2004-09-17 | 2012-07-17 | Hewlett-Packard Development Company, L.P. | Network virtualization |
US20070280243A1 (en) * | 2004-09-17 | 2007-12-06 | Hewlett-Packard Development Company, L.P. | Network Virtualization |
US20090129385A1 (en) * | 2004-09-17 | 2009-05-21 | Hewlett-Packard Development Company, L. P. | Virtual network interface |
US20080225875A1 (en) * | 2004-09-17 | 2008-09-18 | Hewlett-Packard Development Company, L.P. | Mapping Discovery for Virtual Network |
US8274912B2 (en) | 2004-09-17 | 2012-09-25 | Hewlett-Packard Development Company, L.P. | Mapping discovery for virtual network |
US8213429B2 (en) | 2004-09-17 | 2012-07-03 | Hewlett-Packard Development Company, L.P. | Virtual network interface |
US9338024B2 (en) * | 2007-04-11 | 2016-05-10 | Arris Enterprises, Inc. | Extended layer two tunneling protocol applications and architectures |
US20080285592A1 (en) * | 2007-04-11 | 2008-11-20 | Arris | Extended layer two tunneling protocol applications and architectures |
US8661524B2 (en) | 2007-12-14 | 2014-02-25 | Novell, Inc. | Selective desktop control of virtual private networks (VPN's) in a multiuser environment |
US20090158420A1 (en) * | 2007-12-14 | 2009-06-18 | Ks Girish | Selective desktop control of virtual private networks (vpn's) in a multiuser environment |
US8005095B2 (en) | 2008-04-29 | 2011-08-23 | Arris Group, Inc. | Carrier ethernet over DOCSIS |
US20090274156A1 (en) * | 2008-04-29 | 2009-11-05 | Arris | Carrier ethernet over docsis |
US10715803B2 (en) * | 2012-04-11 | 2020-07-14 | Texas Instruments Incorporated | Virtual boundary processing simplification for adaptive loop filtering (ALF) in video coding |
US11812014B2 (en) | 2012-04-11 | 2023-11-07 | Texas Instruments Incorporated | Virtual boundary processing simplification for adaptive loop filtering (ALF) in video coding |
US10812980B2 (en) | 2016-10-10 | 2020-10-20 | Huawei Technologies Co., Ltd. | Communication method, security node network element, and terminal |
CN111294270A (en) * | 2018-12-07 | 2020-06-16 | 华为技术有限公司 | Method, device, equipment and system for accessing data center |
Also Published As
Publication number | Publication date |
---|---|
US7054319B2 (en) | 2006-05-30 |
JP4099930B2 (en) | 2008-06-11 |
JP2001345864A (en) | 2001-12-14 |
US20010050914A1 (en) | 2001-12-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7054319B2 (en) | VPN router and VPN identification method by using logical channel identifiers | |
US9124531B2 (en) | VPN composing method, interwork router, packet communication method, data communication apparatus, and packet relaying apparatus | |
USRE44775E1 (en) | VLAN frame format | |
US7489700B2 (en) | Virtual access router | |
US7079544B2 (en) | Apparatus and method for interworking between MPLS network and non-MPLS network | |
KR100612318B1 (en) | Apparatus and method for implementing vlan bridging and a vpn in a distributed architecture router | |
US8713185B2 (en) | Methods of establishing virtual circuits and of providing a virtual private network service through a shared network, and provider edge device for such network | |
US6789121B2 (en) | Method of providing a virtual private network service through a shared network, and provider edge device for such network | |
EP1408656B1 (en) | Method and device for transparent LAN services | |
US7656872B2 (en) | Packet forwarding apparatus and communication network suitable for wide area Ethernet service | |
EP1408655B1 (en) | Method and device for double tagging of data packets | |
US20030152075A1 (en) | Virtual local area network identifier translation in a packet-based network | |
US20050138149A1 (en) | Method and system for increasing available user VLAN space | |
EP1475942A2 (en) | Address Resolution in IP Internetworking Layer 2 point-to-point connections | |
JP2005341591A (en) | Virtual private network, and multi-service provisioning platform and method | |
US7031307B2 (en) | Packet routing apparatus having label switching function | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
Cisco | Transparent Bridging Commands | |
JP2006174508A (en) | Packet transfer control method and method for setting vpn identification information |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |