US20080253379A1 - Label switching system - Google Patents
Label switching system Download PDFInfo
- Publication number
- US20080253379A1 US20080253379A1 US11/875,202 US87520207A US2008253379A1 US 20080253379 A1 US20080253379 A1 US 20080253379A1 US 87520207 A US87520207 A US 87520207A US 2008253379 A1 US2008253379 A1 US 2008253379A1
- Authority
- US
- United States
- Prior art keywords
- port
- port group
- lsr
- label
- mpls
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- 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/10—Routing in connection-oriented networks, e.g. X.25 or ATM
-
- 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
- H04L45/507—Label distribution
-
- 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/60—Router architectures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
Definitions
- the present invention relates generally to a label switching system, and more particularly to an explicit routing method and a packet router in this label switching system.
- the label switching is a key technology for actualizing an Intranet/Internet backbone oriented high-speed transfer, traffic load sharing and band control on a full scale.
- the label switching also functions to match a routing process at an IP level (Layer 3) with a switching process on a lower layer (Layer 2) where ATM, a frame relay, Ethernet etc are conducted, and perform packet forwarding (transmission, exchange and transfer) on Layer 2 according to [labels] attached to IP packets.
- MPLS Multi Protocol Label Switching
- MPLS-WG Internet Engineering Task Force
- ITU International Telecommunication Union
- IP/ATM IP over ATM
- the label switching has such a characteristic that the data can be transferred at a high speed, a scalability can be obtained, and a traffic can be easily controlled.
- An ATM-LSR ATM Label Switching Router
- VPI Virtual Path Identifier
- VCI Virtual Channel Identifier
- VC Virtual Channel
- traffic engineering conceived as one of most important applications of MPLS aims at utilizing an efficient and reliable network and at the same time optimizing an activity ratio of network resources. What is requested for attaining this is a (Constraint Base Routing) function of specifying a variety of routes without being limited to the IP routing with respect to MPLS.
- the traffic engineering be capable of gasping an activity state of the network resources with a variety of hyper structures. Accordingly, the variety of granularity are likewise required of the (CR) function of specifying the many routes provided by MPLS.
- FIGS. 1 , 2 and 3 each show an example of architecture of the LSR as the MPLS edge device on ATM-Switch base, wherein the label switching architecture is mapped intact.
- the example of architecture shown in FIG. 1 includes a method of incorporating the IP/MPLS forwarding function into a CPU. According to this method, however, the CPU analyzes the packets, searches a routing table and edits a packet header, and therefore high-speed forwarding can not be actualized.
- IP/MPLS forwarding function hardware
- the CPU controls the IP/MPLS forwarding function on the basis of data about results of executing a label distribution protocol and a routing protocol
- the IP/MPLS forwarding function resultantly short-cuts the CPU, and the high-speed forwarding is thus actualized.
- IP/MPLS forwarding function hardware
- each adapter an external interface: a package containing one or a plurality of ports, which corresponds to a port group
- the CPU controls the IP/MPLS forwarding function on the basis of the data about the results of executing the label distribution protocol and the routing protocol, the IP/MPLS forwarding function resultantly short-cuts the CPU, and the high-speed forwarding is thus actualized.
- This method needs an addition of functions to the adapter (the problems in terms of mounting is smaller than a change in the common unit), and, as in the example of architecture shown in FIG. 2 , there exists the problem in terms of the mounting space and the mounting cost. Further, both of the adapter at an ingress for the packets and the adapter at an egress for the packets terminate the IP/MPLS, which is redundant control.
- FIG. 4 An example of architecture shown in FIG. 4 may be considered as an eclectic design of architecture between FIG. 2 and FIG. 3 .
- This is a method, wherein the IP/MPLS forwarding function (hardware) is mounted in an egress for the packets, i.e., in the adapter provided toward a non-MPLS network, the CPU controls the IP/MPLS forwarding function on the basis of the data about the results of executing the label distribution protocol and the routing protocol, the IP/MPLS forwarding function resultantly short-cuts the CPU, and the high-speed forwarding is thus actualized.
- the IP/MPLS forwarding function hardware
- the label distribution protocol of MPLS will be described.
- the label distribution protocol is roughly categorized into the following two types as routing methods.
- Hop by hop routing A route is determined (routing) hop by hop based on a routing table.
- Constraint Base Routing This is explicit routing by an ingress node on the basis of routing data and other various items of data, and is also routing in which a variety of system resources such as QoS etc are specified.
- RSVP Extensions Extensions to RSVP for LSP Tunnels
- OSPF Open Shortest Path First
- IGP interior gateway protocol
- a forwarder which terminates MPLS and IP, actualizes MPLS forwarding for the MPLS network and actualizes IP forwarding for the IP network (non-MPLS network).
- FIG. 5 shows an example of sequence of the hop by hop routing.
- an ingress LSR an Edge-LSR in an MPLS domain
- LSP Label Switched Path
- FEC Forwarding Equivalence Class
- a relay node (an ATM-LSR in an MPLS domain) receiving Label Request message determines NEXT HOP by searching the routing table with the FEC in the received message serving as key data, and transmits Label Request message to this NEXT HOP.
- An egress LSR an Edge-LSR in an MPLS domain receiving Label Request message recognizes that the egress LSR is the egress by searching the routing table with FEC in the received message serving as key data, then determines a label used for the LSP, subsequently sets the LSP and also sets the label in Label Mapping message, and transmits it to an upstream LSR.
- the relay LSR receiving Label Mapping message sets an LSP to a downstream LSR, determines a label with respect to the upstream LSR which is used for this LSP, then sets the LSP and also sets this label in Label Mapping message, and transmits it to the upstream LSR.
- the ingress LSR receiving Label Mapping message sets an LSP to the downstream LSR.
- the setting of the LSP from the ingress LSR down to the egress LSR is thus completed.
- FIG. 6 shows an example of sequence of explicit routing based on CR-LDP.
- the ingress LSR detecting the trigger for setting the LSP determines a plurality of LSRs through which the LSP set by a local policy and so forth based on topology data etc passes, then explicitly sets the LSRs in Label Request message (the FEC set at this time is generally “CRLSP” additionally defined by CR-LSP, and it is indicated that the FEC corresponding to this LSP dynamically changes).
- the ingress LSR similarly determines NEXT HOP by the local policy etc, transmits Label Request message to this NEXT HOP.
- the relay LSR receiving Label Request message determines NEXT HOP on the basis of the explicit route in the received message, and the egress LSR receiving Label Request message recognizes from the explicit route in the received message that the same LSR itself is an egress.
- FIG. 7 shows an example of sequence of explicit routing based on RSVP Extensions. The followings are large differences of this example from FIG. 6 .
- LDP explicitly sets a session on TCP, while RSVP Extensions tacitly set the session.
- Label Request message and Label Mapping message are replaced respectively with Path message and Reserve message.
- the MPLS architecture can not be mapped well to the system architecture shown in FIG. 4 for reasons which follow.
- the egress node terminates MPLS, then determines an output port in accordance with IP routing (forwarding), and forwards the packets.
- an IP forwarding engine is mounted in the adapter, and hence it is required that not the egress node but the adapter of the egress node terminates IP/MPLS.
- the label distribution protocols of both of hop by hop routing and Explicit Routing are incapable of indicating an intra-system specified adapter or port, and it is therefore unfeasible to set the LSP in which the specified adapter of the egress node is a terminal.
- FEC is specified in Label Request message, and, according to a present version of LDP, only one FEC element is allowed as FEC in the message. Therefore, the egress node is capable of specifying the egress node from this FEC.
- a minimum unit of a hyper structure for specifying the explicit route of present MPLS is a node. It might be herein considered that the hyper structure capable of specifying a given port and a given group of the node in addition to the specifying on the node basis.
- MPLS Label Switching
- Constraint Base Routing a granularity of function
- the present invention aims at providing a design of how the MPLS architecture is mapped to the packet router (LSR) taking an architecture shown in FIG. 4 , and of how this packet router is mapped to the MPLS architecture in terms of a mounting space and a mounting cost. To describe it in greater details, the present invention aims at designing how an egress adapter terminates MPLS in the packet router if this packet router is an egress of MPLS.
- LSR packet router
- a first explicit routing method in a label switching system comprises a step of logically dividing a label switching router(LSR) into a plurality of LSRs each having a label switching function, and a step of specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node.
- LSR label switching router
- a second explicit routing method in a label switching system comprises a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group, and a step of managing the topology data flooded from other system and, when setting a label switched path on the basis of an explicit route specified, explicitly specifying a port or a port group of an egress node, and a port or a port group of a relay node on the basis of the received topology data.
- a third explicit routing method in a label switching system comprises a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group.
- a fourth explicit routing method in a label switching system comprises a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group by use of Opaque LSA of OSPF protocol.
- a fifth explicit routing method in a label switching system comprises a step of explicitly specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node, and a port or a port group of a relay node.
- a sixth explicit routing method in a label switching system may further comprise a step of specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP, and a step of specifying a port or a port group of the relay node by setting an IP address corresponding to the port or the port group of the relay node in intermediate ER-HOP-TLV in ER-TLVs in Label Request Message of the CR-LDP.
- a seventh explicit routing method in a label switching system may further comprise a step of specifying the port or the port group of the egress node and the port or the port group of the relay node by adding an intra-system port number or an intra-system port group number in ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP.
- An eighth explicit routing method in a label switching system may further comprise a step of explicating a port through which data should pass per system and specifying a port or a port group of the egress node by use of resource class TLV with ER-TLV in Label Request Message of CR-LDP being used as ER-HOP-TLV.
- a ninth explicit routing method in a label switching system may further comprise a step of specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final Subject-object in Explicit Route Objects in a path message of RSVP protocol extended for setting a label switched path in MPLS protocol, and a step of specifying a port or port group of the relay node by setting an IS address corresponding to the port or the port group of the relay node in intermediate Subject-object in Explicit Route Objects in the path message of the RSVP protocol.
- a tenth explicit routing method in a label switching system may further comprise a step of specifying a port or a port group of the egress node and a port or a port group of the relay node by adding an intra-system port number or an intra-system port group number in Subject-object in Explicit Route Objects in the path message of RSVP protocol extended for setting the label switched path in MPLS protocol.
- An eleventh explicit routing method in a label switching system comprises a step of specifying an MPLS explicit route by adding, to an IP-over-MPLS (IP/MPLS)forwarding function of one specified egress-and-ingress port group, a communication function with the IP/MPLS forwarding function of an intra-system other port group, and a forwarding function to the intra-system other port group.
- IP/MPLS IP-over-MPLS
- a first packet router in a label switching system comprises a logical router configuring module for logically dividing a label switching router (LSR) into a plurality of LSRs each having a label switching function, and a module for specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node.
- LSR label switching router
- a second packet router in a label switching system comprises a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group, and a module for managing the topology data flooded from other system and, when setting a label switched path on the basis of an explicit route specified, explicitly specifying a port or a port group of an egress node, and a port or a port group of a relay node on the basis of the received topology data.
- a third packet router in a label switching system comprises a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group.
- a fourth packet router in a label switching system comprises a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group by use of Opaque LSA of OSPF protocol.
- a fifth packet router in a label switching system comprises a module for explicitly specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node, and a port or a port group of a relay node.
- a sixth packet router in a label switching system may further comprise a module for specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP, and a module for specifying a port or a port group of the relay node by setting an IP address corresponding to the port or the port group of the relay node in intermediate ER-HOP-TLV in ER-TLVs in Label Request Message of the CR-LDP.
- a seventh packet router in a label switching system may further comprise a module for specifying the port or the port group of the egress node and the port or the port group of the relay node by adding an intra-system port number or an intra-system port group number in ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP.
- An eighth packet router in a label switching system may further comprise a module for explicating a port through which data should pass per system and specifying a port or a port group of the egress node by use of resource class TLV with ER-TLV in Label Request Message of CR-LDP being used as ER-HOP-TLV.
- a ninth packet router in a label switching system may further comprise a module for specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final Subject-object in Explicit Route Objects in a path message of RSVP protocol extended for setting a label switched path in MPLS protocol, and a module for specifying a port or port group of the relay node by setting an IP address corresponding to the port or the port group of the relay node in intermediate Subject-object in Explicit Route Objects in the path message of the RSVP protocol.
- a tenth packet router in a label switching system may further comprise a module for specifying a port or a port group of the egress node and a port or a port group of the relay node by adding an intra-system port number or an intra-system port group number in Subject-object in Explicit Route Objects in the path message of RSVP protocol extended for setting the label switched path in MPLS protocol.
- An eleventh packet router in a label switching system comprises a module for specifying an MPLS explicit route by adding, to an IP/MPLS forwarding function of one specified egress-and-ingress port group, a communication function with the IP-over-MPLS (IP/MPLS) forwarding function of an intra-system other port group, and a forwarding function to the intra-system other port group.
- IP/MPLS IP-over-MPLS
- FIG. 1 is a block diagram showing an example of architecture of a conventional LSR
- FIG. 2 is a block diagram showing an example of architecture of the conventional LSR
- FIG. 3 is a block diagram showing an example of architecture of the conventional LSR
- FIG. 4 is a block diagram showing an example of architecture of the conventional LSR
- FIG. 5 is an explanatory view showing a conventional label distribution sequence
- FIG. 6 is an explanatory view showing the conventional label distribution sequence
- FIG. 7 is an explanatory view showing the conventional label distribution sequence
- FIG. 8 is a block diagram showing an architecture of an LSR in a first embodiment of the present invention.
- FIG. 9 is a block diagram showing a detailed architecture of an LSR in the first embodiment.
- FIG. 10 is an explanatory flowchart showing an operation of the LSR in the first embodiment
- FIG. 11 is a block diagram showing an architecture of the LSR in a second embodiment of the present invention.
- FIG. 12 is a block diagram showing a detailed architecture of the LSR in the second embodiment
- FIG. 13 is an explanatory chart showing an example of definition of Opaque LSA of OSPF
- FIG. 14 is an explanatory chart showing an example of definitions of Label Request Message of CR-LDP, ER-TLV, ER-HOP-TLV and resource class TLV;
- FIG. 15 is an explanatory chart showing an example of definitions of Label Request Message of CR-LDP, ER-TLV, ER-HOP-TLV and resource class TLV;
- FIG. 16 is an explanatory chart showing an example of additional definition of ER-HOP-TLV
- FIG. 17 is an explanatory chart showing an example of definitions of Path Message of RSVP Extension, and Explicit-Route Object and IPv4 Subobject;
- FIG. 18 is an explanatory chart showing an example of additional definition of Subobject of Explicit-Route Object
- FIG. 19 is an explanatory flowchart showing an operation of the LSR in the second embodiment
- FIG. 20 is an explanatory flowchart showing the operation of the LSR in the second embodiment
- FIG. 21 is an explanatory flowchart showing the operation of the LSR in the second embodiment
- FIG. 22 is a block diagram showing an architecture of the LSR in a third embodiment of the present invention.
- FIG. 23 is a block diagram showing a detailed architecture of a forwarder in the LSR in the third embodiment.
- FIG. 24 is a block diagram showing a detailed architecture of a forwarder (X) in the LSR in the third embodiment.
- FIG. 25 is a block diagram showing a detailed architecture of the forwarder(X) in the LSR in the third embodiment.
- FIGS. 8 , 9 and 10 A label switching router (LSR) classified as a packet router in a first embodiment of the present invention, will be explained referring to FIGS. 8 , 9 and 10 in combination.
- FIGS. 8 and 9 show an architecture of the LSR.
- FIG. 10 shows a processing flowchart.
- a label switching router (LSR) 10 in the first embodiment adopts an architecture of logically mounting a plurality of LSRs in a system.
- the independent LSR is logically defined corresponding to each adapter (corresponding to a port group) within the LSR 10 , and each adapter within the system is recognized as an independent LSR by other LSRs.
- an architecture of the LSR 10 is that adapters 1 and 2 are connected to an MPLS network (ATM), and adapters 3 and 4 are connected to a non-MPLS network (Ethernet).
- ATM MPLS network
- Ethernet non-MPLS network
- LSR 1 , LSR 2 , LSR 3 and LSR 4 are defined as logical LSRs, and the respective LSRs are connected in full-mesh, corresponding to the adapters 1 , 2 , 3 and 4 .
- LSR 1 , LSR 2 are not connected to the non-MPLS network, and it may therefore be sufficient that the LSR 1 and LSR 2 each incorporate a function as a relay node.
- the LSR 1 and LSR 2 have neither a necessity of terminating the LSP nor a necessity of incorporating an IP/MPLS forwarding function, accordingly.
- LSRs are thereby capable of recognizing the LSR 10 as the independent LSR 1 , LSR 2 , LSR 3 , LSR 4 , and, when setting the LSP for transferring packets which are to be forwarded to a network connected to the LSR 3 .
- the LSP can be set with the LSR 3 serving as an egress node. Namely, the LSP can be terminated by the adapter 3 .
- the logical LSRs 1 , 2 , 3 and 4 are defined corresponding to the adapters, and further a component for managing each of the logical LSRs is defined.
- the respective logical LSRs 1 , 2 , 3 and 4 are capable of independently operating with respect to an outside system.
- a logical LSR management module 11 manages and integrates the logical LSRs 1 , 2 , 3 and 4 , whereby a function as one single LSR can be attained.
- Traffic engineering is classified as one of most useful applications of the MPLS, and aims at optimizing an activity ratio of network resources and optimizing a forwarding performance of the traffic.
- a traffic engineering processing module 12 based on a database managed by a topology data management module 13 , calculates an optimal set route of the LSP, detects triggers for adding, changing and deleting the route, and determines a flow of allocating to the set LSP.
- the traffic engineering processing module 12 indicates a label switching processing module 14 to set, add, change and delete the LSP, and allocate and change the flow to the LSP. Moreover, the traffic engineering processing module 12 receives a result of processing and a report on the LSP set in response to a request made by other LSR from the label switching processing module 14 , and reflects this result in the database of the topology data management module 13 . A part of the whole of the flow allocating process to the LSP may be executed by an MPLS forwarder on the adapter.
- the label switching processing module 14 requests the logical LSRs 1 , 2 , 3 and 4 to set, add, change and delete the LSP via the logical LSR management module 11 . Further, the label switching processing module 14 receives other LSR's requests for setting, adding, changing and deleting the LSP from the LSR management module 11 via the logical LSRs 1 , 2 , 3 and 4 , and requests the logical LSRs 1 , 2 , 3 and 4 to execute these processes via the logical LSR management module 11 .
- an MPLS forwarding table is updated by communications with an MPLS forwarding table management module 17 , and a part of copies of the MPLS forwarding table to the logical LSRs 1 , 2 , 3 and 4 via the logical LSR management module 11 .
- the logical LSR management module 11 controls the communications with the logical LSRs 1 , 2 , 3 and 4 , and executes mutual translations between a logical architecture and a physical architecture with respect to the communications between the label switching processing module 14 and the logical LSRs 1 , 2 , 3 and 4 .
- the logical LSR management module 1 maps a physical-architecture-based request given from the label switching processing module 14 to the logical architecture, and notifies the logical LSRs 1 , 2 , 3 , 4 of this mapping.
- the logical LSR management module 11 maps logical-architecture-based requests given from the logical LSRs 1 , 2 , 3 , 4 to the physical architecture, and notifies the label switching processing module 14 of this mapping.
- the label management module 15 manages the respective databases thereof, and provide functions of searching and updating these databases.
- the switch driver 16 controls an ATM switch Fabric (core switch), and sets and deletes the LSP.
- An adapter #n driver 19 provides the logical LSRs 1 , 2 , 3 and 4 with an adapter control function.
- the label switching processing modules 20 in the logical LSRs 3 and 4 manage the whole of the logical LSRs 1 , 2 , 3 , 4 , and execute a virtual label switching process in response to indications given from the logical LSRs 1 , 2 , 3 and 4 . That is, the label switching processing module 14 and the logical LSR management module 11 carry out operations of managing the intra-system LSPs, allocating the labels, performing switch control, and updating the IP routing table and the MPLS forwarding table, and controls a protocol process with outside LSRs.
- IP routing protocol processing modules 21 in the logical LSRs 3 and 4 execute the processes of protocols such as OSPF, RIP2, BGP4 etc.
- a topology data flooding processing module 22 executes a protocol process relative to a flood of the topology data for the traffic engineering independently of the topology process pertaining to the IP routing. Mounting thereof may, however, also be what is integrated as a protocol into which the routing protocol of the IP routing protocol processing module 21 is extended.
- the label distribution protocol processing modules 23 in the logical LSRs 3 and 4 execute a label distribution protocol such as LDP, CR-LDP, RSVP Extension etc.
- a forwarder control module 24 controls a forwarder mounted into the adapter. That is, the forwarder control module 24 initializes and updates an IP forwarding table and an MPLS forwarding table that are possessed by the forwarder.
- the label switching processing modules 20 , the IP routing protocol processing modules 21 , the topology data flooding processing modules 22 , the label distribution protocol processing modules 23 and the forwarder control modules 24 in the logical LSRs 1 and 2 are the same functions as those modules in the logical LSRs 3 and 4 . Note that the logical LSRs 1 and 2 do not terminate the MPLS/IP, and hence the forwarder control modules 24 have no necessity of being operated.
- FIGS. 11 , 12 , 13 through 18 , 19 , 20 and 21 show an architecture of the label switch router (LSR).
- FIGS. 13 through 18 show examples of a variety of definitions of the protocols for the traffic engineering.
- FIGS. 19 , 20 and 21 are flowcharts showing the processes.
- a label switching router (LSR) 30 in the second embodiment takes such an architecture that the intra-system adapters can be specified.
- the LSR 30 has a database stored with various items of topology data of the network.
- the LSR 30 incorporates a function of flooding the topology data on the basis of the database, and a function of updating the database on the basis of the flooded topology data.
- the LSR 30 has a label distributing function (LSO setting function) by which an explicit route is specified based on the database.
- the LSR 30 incorporates a function (1) of rearranging ports and an aggregation of the ports into groups and thus managing the ports, a function (2) of flooding the port and/or a group number of the port to an address of a connection destination network, a function (3) of structuring the flooding data including the above item (2) into a database, a function (4) of determining, based on the database in the item (3), an explicit route inclusive of the port or the port group in addition to nodes through which the packets pass, and a function (5) of distributing the labels by giving the explicit route determined in the item (3).
- the topology data sub-itemized down to the port groups or the ports of the relay node and the egress node can be managed at an ingress node, and it is feasible to set not only a port group of the egress node or an LSP with the specified port but also a port group or a port of the relay node through which the packets pass.
- an LSR 30 management functions corresponding to the respective ports and the port group (corresponding to the adapters) of other system and the self-system, are added to the components indicated by hatching.
- a port management is carried out in the way of allocating ports 1 , 2 to a port group 1 , ports 3 , 4 to a port group 2 , ports 5 , 6 to a port group 3 , and ports 7 , 8 to a port group 4 .
- what is added to the LSR 30 is a function of flooding a port or/and a group number of the port to an address of a connection destination network.
- the function of flooding the topology data is supported by the routing protocol such as OSPF etc.
- OSPF routing protocol
- FIG. 13 This example is illustrated in FIG. 13 .
- This type of LSA is newly defined and then flooded, whereby each system receives LSA from other system and, as a result, the topology data for the traffic engineering can be obtained.
- a link and an interface in FIG. 13 correspond to the ports.
- Sub-TVLV defined in FIG. 13 .
- sub-TVLV type 7
- name port group number.
- a port group number is allocated to a resource class TLV.
- the port group number is defined, whereby the port group number can be flooded. This function is incorporated into a topology data flooding processing module 31 .
- a function of converting the flooding data into a database is added to the LSR 30 .
- the port group numbers flooded by the topology data flooding processing module 31 are also converted into a database. This function is incorporated into the topology data management module 32 and the traffic engineering processing module 33 .
- a function of determining the explicit route inclusive of the port or the port group is added. Based on the databases of the topology data management module 32 and of the traffic engineering processing module 33 , the explicit route of the LSP from the ingress node to the output port of the egress node, is determined by a local policy or a managerial selection. This function is incorporated into the traffic engineering processing module 33 .
- the following function of distributing the labels by explicating the port or the port group, is added.
- ER HOP TLV in Label Request Message of CR-LDP shown in FIGS. 14 and 15 specifies a node (system) through which essentially the LSP passes. This is extensively defined, and final ER HOP TLV in ER TLVs shall indicate an output port group of the egress node.
- the ingress node based on the determination of the explicit route, specifies an IP address (corresponding to any one of ports in the port group) corresponding to the output port group of the egress node in final ER HOP TLV in ER TLVs in the Label Request Message.
- the egress node specifies an output port in accordance with the IP address indicated in final ER HOP TLV in ER TLVs in Label Request Message, and may further specify a port group to which that port belongs.
- IPv4 Subobject in EXPLICIT-ROUTE object in Path Message of RSVP Extension shown in FIG. 17 specifies a node (system) through which essentially the LSP passes. This is extensively defined, and final IPv4 Subobject in EXPLICIT ROUTE object shall indicate an output port group of an egress node. This is RSVP Extension version in the item (1).
- the port and the port group (a link and a link group) are additionally defined in ER HOP type of ER HOP TLV, and further a port and port group (link and link group) ELV is additionally defined.
- the ingress node based on the determination of the explicit route, specifies an output port group number or/and port number of the egress node in final ER HOP TLV in ER TLVs in Label Request Message by use of the port an port group (link and link group) TLV.
- the egress node may specify a port and a port group passing through the relay node in intermediate ER HOP TLV by use of the port and port group (link and link group) TLV.
- the port and the port group (the link and the link group) are additionally defined in Subobject type of EXPLICIT_ROUTE object, and further port and port group (link and link group) Subobject is additionally defined. This is RSVP Extension version in the item (3).
- a resource class is additionally defined in ER Hop type of ER HOP TLV. Further, resource class TLV shown in FIG. 15 is used as ER HOP TLV.
- the ingress node uses resource class TLV in final ER HOP TLV in ER TLVs in Label Request Message, and specifies an output port group number of the egress node.
- the egress node may specify an output port group number from the output port group number indicated by final ER HOP TLV in ER TLVs in Label Request Message.
- resource class TLV is used in intermediate ER HOP TLV, whereby a port group passing through a relay node can be specified.
- the topology data sub-itemized down to the port groups or the ports of the relay node and the egress node can be managed at the ingress node, and it is feasible to set an LSP with the specified port group or port of the egress node, and to specify the port group or port of the relay node through which the packets pass.
- the label switching router (LSR) classified as the packet router in a third embodiment of the present invention will be explained referring to FIGS. 22 , 23 , 24 , and 25 in combination.
- a label switching router (LSR) 40 in the third embodiment takes such an architecture that an egress adapter within the system is capable of executing internal shuttling.
- the LSR 40 has, in the system architecture illustrated in FIG. 2 , an addition of the following functions to one specified egress adapter. That is, these functions are a function (1) of setting a connection with other egress adapter via an ATM switch, a function (2) conducting IP forwarding to other adapters in addition to the intra-adapter ports (which uses the connection given in the item (1), and a function (3) of adding routing data to other adapters to a routing table that is referred in the item (2).
- the setting of the explicit LSP can be actualized neither by changing a basic framework (in terms of mounting) of the system architecture shown in FIG. 2 nor by the ingress node specifying (managing) the adapters of the egress node.
- FIG. 23 shows an example of architecture of an IP/MPLS forwarder in the LSR 40 illustrated in FIG. 22 .
- a driver/receiver 51 transmits and receives the data to and from an external interface (ATM/Ether).
- ATM/Ether external interface
- the received data is stored in a buffer 52
- the driver/receiver 51 transfers the control, wherein an address and a size of the received data are set as output data.
- the driver/receiver 51 transmits the data stored in the buffer 52 , wherein the address and the size thereof are set as input data.
- the buffer 52 is stored with the received data and also edited data (transmitted data).
- the IP routing table 53 is a copy of a part of the IP routing table possessed by the LSR 40 body, and contains ports 1 ⁇ n as output destination ports.
- An MPLS forwarding table (Label Information Base) 54 is a copy of a part of the MPLS forwarding table possessed by the LSR 40 body, and contains VCs 1 ⁇ n as output destination ports.
- a table updating processing module 55 executes a process of updating the IP routing table 53 and the MPLS forwarding table 54 in response to an indication given from an LSR body control unit.
- a cellulating module (packet deassembling module) 56 cellulates the packets which have already been edited, and indicates the driver 58 to transmit the cells by specifying a VC.
- a decellulating module (packet assembling module) 57 decellulates the received cells from the receiver 58 , and assembles them into packets on the buffer 52 .
- a packet editing module 59 executes a process of editing an IP header and an MPLS header of the packet.
- An IP forwarding processing module 60 determines a packet transmitting destination with reference to the IP routing table 53 , and indicates the packet editing module 61 to edit the IP header.
- An MPLS forwarding processing module 62 determines a packet transmitting destination with reference to the MPLS forwarding table 54 , and indicates the packet editing module 61 to edit an MPLS header.
- FIG. 24 shows a first example of architecture of the IP/MPLS forwarder (X) in the LSR 40 illustrated in FIG. 22 .
- An IP/MPLS forwarder (X) 70 actualizes the setting of the explicit LSP neither by changing the basic framework (in terms of mounting) of the system architecture shown in FIG. 2 nor by the ingress node specifying (managing) the adapters of the egress node.
- An IP routing table 71 is a copy of a part of the IP routing table possessed by the LSR body, and contains ports 1 ⁇ n as output destination ports and VCs 1 ⁇ n.
- a packet editing module 72 executes a process of editing the IP header and the MPLS header.
- An IP forwarding processing module 73 determines a packet transmitting destination with reference to the IP routing table 71 , and indicates the packet editing module 72 to edit the IP header. On this occasion, the IP forwarding processing module 72 explicates whether the transmitting destination is the port nor the VC n.
- the conflict control module 74 controls a conflict between shuttle packets inputted from the port n and from the VC n, and executes scheduling of the input packets to the cellulating module 56 .
- FIG. 25 shows a second example of architecture of the IP/MPLS forwarder (X) in the LSR 40 illustrated in FIG. 22 .
- Functions of this IP/MPLS forwarder (X) 80 which are to be added to the architecture of the IP/MPLS forwarder 50 shown in FIG. 23 , will be explained.
- Drivers/receivers 81 , 82 transmit and receive the data to and from the outside interface (ATM/Ether).
- the received data are stored in a buffer 83 .
- the drivers/receivers 81 , 82 transfer the control, wherein addresses and sizes of the received data are set as output data.
- the drivers/receivers 81 , 82 transmit the data stored in the buffer 83 , wherein the addresses and the sizes thereof are set as input data.
- the drivers/receivers 81 , 82 are operated only for data shuttling, and do not therefore receive the data from outside.
Abstract
A packet router in a label switching system includes a logical router configuring module for logically dividing a label switching router (LSR) into a plurality of LSRs each having a label switching function, and a module for specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node. With this construction, a label switching architecture in an ATM network for actualizing MPLS (label switching) can be mapped to an ATM-Switch base system architecture, and a granularity of function (Constraint Base Routing) of specifying a variety of routes provided by MPLS can be attained.
Description
- The present invention relates generally to a label switching system, and more particularly to an explicit routing method and a packet router in this label switching system.
- The label switching is a key technology for actualizing an Intranet/Internet backbone oriented high-speed transfer, traffic load sharing and band control on a full scale. The label switching also functions to match a routing process at an IP level (Layer 3) with a switching process on a lower layer (Layer 2) where ATM, a frame relay, Ethernet etc are conducted, and perform packet forwarding (transmission, exchange and transfer) on
Layer 2 according to [labels] attached to IP packets. - Standardization of this label switching are now being promoted as MPLS (Multi Protocol Label Switching) by MPLS-WG of IETF (Internet Engineering Task Force). Further, ITU (International Telecommunication Union) also examines the use of MPLS in IP over ATM (IP/ATM) in the public network.
- Generally, the label switching has such a characteristic that the data can be transferred at a high speed, a scalability can be obtained, and a traffic can be easily controlled. An ATM-LSR (ATM Label Switching Router) for actualizing the label switching in the ATM network uses VPI (Virtual Path Identifier) for identifying VP (Virtual Path) and VCI (Virtual Channel Identifier) for identifying VC (Virtual Channel) as labels, and IP packets are mapped (interworking) to ATM layer (Layer 2).
- Taking into consideration a situation wherein a great number of ATM networks have already been developed in the field and a multiplicity of ATM systems have been put on the market, for developing the label switching in a real network, it is of much importance to contrive how the existing ATM-Switch architecture is mapped to the label switching. It is also desired that the label switching exhibiting a high compatibility with the existing ATM-Switch architecture, be actualized.
- On the other hand, traffic engineering (load sharing) conceived as one of most important applications of MPLS aims at utilizing an efficient and reliable network and at the same time optimizing an activity ratio of network resources. What is requested for attaining this is a (Constraint Base Routing) function of specifying a variety of routes without being limited to the IP routing with respect to MPLS.
- Moreover, it is desired for actualizing optimization of the traffic engineering that the traffic engineering be capable of gasping an activity state of the network resources with a variety of hyper structures. Accordingly, the variety of granularity are likewise required of the (CR) function of specifying the many routes provided by MPLS.
- It is herein considered to design an architecture for actualizing an LSR (Label Switching Router) as an edge device of MPLS on ATM-Switch base. What is herein focused on is a method of mounting an IP/MPLS forwarding function.
-
FIGS. 1 , 2 and 3 each show an example of architecture of the LSR as the MPLS edge device on ATM-Switch base, wherein the label switching architecture is mapped intact. - The example of architecture shown in
FIG. 1 includes a method of incorporating the IP/MPLS forwarding function into a CPU. According to this method, however, the CPU analyzes the packets, searches a routing table and edits a packet header, and therefore high-speed forwarding can not be actualized. - What is given in the example of architecture shown in
FIG. 2 is such a method that the IP/MPLS forwarding function (hardware) is mounted at a pre-stage of the CPU, the CPU controls the IP/MPLS forwarding function on the basis of data about results of executing a label distribution protocol and a routing protocol, the IP/MPLS forwarding function resultantly short-cuts the CPU, and the high-speed forwarding is thus actualized. - According to this method, when actualized based on the ATM switch, a common unit needs a new piece of hardware, and there is a problem in terms of a mounting space and a mounting cost as well.
- What is given in the example of architecture shown in
FIG. 3 is such a method that the IP/MPLS forwarding function (hardware) is mounted in each adapter (an external interface: a package containing one or a plurality of ports, which corresponds to a port group), the CPU controls the IP/MPLS forwarding function on the basis of the data about the results of executing the label distribution protocol and the routing protocol, the IP/MPLS forwarding function resultantly short-cuts the CPU, and the high-speed forwarding is thus actualized. - This method needs an addition of functions to the adapter (the problems in terms of mounting is smaller than a change in the common unit), and, as in the example of architecture shown in
FIG. 2 , there exists the problem in terms of the mounting space and the mounting cost. Further, both of the adapter at an ingress for the packets and the adapter at an egress for the packets terminate the IP/MPLS, which is redundant control. - An example of architecture shown in
FIG. 4 may be considered as an eclectic design of architecture betweenFIG. 2 andFIG. 3 . This is a method, wherein the IP/MPLS forwarding function (hardware) is mounted in an egress for the packets, i.e., in the adapter provided toward a non-MPLS network, the CPU controls the IP/MPLS forwarding function on the basis of the data about the results of executing the label distribution protocol and the routing protocol, the IP/MPLS forwarding function resultantly short-cuts the CPU, and the high-speed forwarding is thus actualized. - This method needs an addition of functions to the adapter (the problems in terms of mounting is smaller than the change in the common unit), and, as in the examples of architecture shown in
FIGS. 2 and 3 , there exists the problem in terms of the mounting space and the mounting cost. On the system, however, IP/MPLS is terminated by only the adapter at the egress for the packets, and hence the redundant control is not required, which is more advantageous than the example of architecture shown inFIG. 3 . - Herein, the label distribution protocol of MPLS will be described. The label distribution protocol is roughly categorized into the following two types as routing methods.
- (1) Hop by hop routing: A route is determined (routing) hop by hop based on a routing table.
- (2) Constraint Base Routing: This is explicit routing by an ingress node on the basis of routing data and other various items of data, and is also routing in which a variety of system resources such as QoS etc are specified.
- Further, the following three protocols are the typical label distribution protocols.
- (1) LDP (Label Distribution Protocol: Note that this herein indicates a specific protocol.)
- This is a protocol for best-effort communications by hop by hop routing.
- (2) CR-LDP (Constraint-Based LSP Setup using LDP)
- This is the label distribution protocol capable of performing the explicit routing and QoS communications etc, and is an extension version of LDP.
- (3) RSVP Extensions (Extensions to RSVP for LSP Tunnels)
- This is the label distribution protocol capable of performing the explicit routing and QoS communications etc, and is an extension version of RSVP.
- It is to be noted that OSPF (Open Shortest Path First) is a routing protocol in
FIGS. 1 through 4 , and is one type of interior gateway protocol (IGP). Further, a forwarder, which terminates MPLS and IP, actualizes MPLS forwarding for the MPLS network and actualizes IP forwarding for the IP network (non-MPLS network). -
FIG. 5 shows an example of sequence of the hop by hop routing. As shown inFIG. 5 , according to the hop by hop routing, an ingress LSR (an Edge-LSR in an MPLS domain) that detects a trigger for setting an LSP (Label Switched Path) sets, in Label Request message, an FEC (Forwarding Equivalence Class: This indicates an aggregation of packets passing though the LSP, and, at the present, an address prefix having a length of 0˜32 bits and a full host address are defined as FEC elements, and the FEC is an aggregation of the FEC elements.) corresponding to the LSP to be set. The ingress LSR then determines NEXT HOP by searching the routing table with the FEC serving as key data, and transmits Label Request message to this NEXT HOP. - A relay node (an ATM-LSR in an MPLS domain) receiving Label Request message determines NEXT HOP by searching the routing table with the FEC in the received message serving as key data, and transmits Label Request message to this NEXT HOP.
- An egress LSR (an Edge-LSR in an MPLS domain) receiving Label Request message recognizes that the egress LSR is the egress by searching the routing table with FEC in the received message serving as key data, then determines a label used for the LSP, subsequently sets the LSP and also sets the label in Label Mapping message, and transmits it to an upstream LSR.
- The relay LSR receiving Label Mapping message sets an LSP to a downstream LSR, determines a label with respect to the upstream LSR which is used for this LSP, then sets the LSP and also sets this label in Label Mapping message, and transmits it to the upstream LSR.
- The ingress LSR receiving Label Mapping message sets an LSP to the downstream LSR. The setting of the LSP from the ingress LSR down to the egress LSR is thus completed.
-
FIG. 6 shows an example of sequence of explicit routing based on CR-LDP. The followings are larger differences of this example fromFIG. 5 . The ingress LSR detecting the trigger for setting the LSP (Label Switched Path) determines a plurality of LSRs through which the LSP set by a local policy and so forth based on topology data etc passes, then explicitly sets the LSRs in Label Request message (the FEC set at this time is generally “CRLSP” additionally defined by CR-LSP, and it is indicated that the FEC corresponding to this LSP dynamically changes). The ingress LSR similarly determines NEXT HOP by the local policy etc, transmits Label Request message to this NEXT HOP. The relay LSR receiving Label Request message determines NEXT HOP on the basis of the explicit route in the received message, and the egress LSR receiving Label Request message recognizes from the explicit route in the received message that the same LSR itself is an egress. -
FIG. 7 shows an example of sequence of explicit routing based on RSVP Extensions. The followings are large differences of this example fromFIG. 6 . LDP explicitly sets a session on TCP, while RSVP Extensions tacitly set the session. Label Request message and Label Mapping message are replaced respectively with Path message and Reserve message. - In the LSR adopting the system architecture shown in
FIG. 4 , if considering the LSP based on the label distribution protocol, the MPLS architecture can not be mapped well to the system architecture shown inFIG. 4 for reasons which follow. - (1) According to a concept of MPLS that is being now developed in IETF, the egress node terminates MPLS, then determines an output port in accordance with IP routing (forwarding), and forwards the packets.
- (2) According to Explicit Routing (based on both of CR-LDP and RSVP Extensions) of MPLS that is nor being developed in IETF, a node or an aggregation of nodes through which the packets pass, is or are specified.
- (3) In the system architecture shown in
FIG. 4 , an IP forwarding engine is mounted in the adapter, and hence it is required that not the egress node but the adapter of the egress node terminates IP/MPLS. - To be specific, the label distribution protocols of both of hop by hop routing and Explicit Routing are incapable of indicating an intra-system specified adapter or port, and it is therefore unfeasible to set the LSP in which the specified adapter of the egress node is a terminal.
- In the case of hop by hop routing based on LDP, FEC is specified in Label Request message, and, according to a present version of LDP, only one FEC element is allowed as FEC in the message. Therefore, the egress node is capable of specifying the egress node from this FEC.
- Further, as described above, a minimum unit of a hyper structure for specifying the explicit route of present MPLS, is a node. It might be herein considered that the hyper structure capable of specifying a given port and a given group of the node in addition to the specifying on the node basis.
- Accordingly, it is a primary object of the present invention to provide an explicit routing method and a packet router that are capable of mapping a label switching architecture in an ATM network which actualizes MPLS (Label Switching) to an ATM-Switch base system architecture, and attaining a granularity of function (Constraint Base Routing) of specifying a variety of routes provided by MPLS.
- Namely, the present invention aims at providing a design of how the MPLS architecture is mapped to the packet router (LSR) taking an architecture shown in
FIG. 4 , and of how this packet router is mapped to the MPLS architecture in terms of a mounting space and a mounting cost. To describe it in greater details, the present invention aims at designing how an egress adapter terminates MPLS in the packet router if this packet router is an egress of MPLS. - It is another object of the present invention to support a granularity capable of specifying a given port and a given port group in addition to the specifying on a node basis when specifying an explicit route of MPLS.
- To accomplish the above objects, a first explicit routing method in a label switching system according to the present invention, comprises a step of logically dividing a label switching router(LSR) into a plurality of LSRs each having a label switching function, and a step of specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node.
- A second explicit routing method in a label switching system according to the present invention comprises a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group, and a step of managing the topology data flooded from other system and, when setting a label switched path on the basis of an explicit route specified, explicitly specifying a port or a port group of an egress node, and a port or a port group of a relay node on the basis of the received topology data.
- A third explicit routing method in a label switching system according to the present invention comprises a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group.
- A fourth explicit routing method in a label switching system according to the present invention comprises a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group by use of Opaque LSA of OSPF protocol.
- A fifth explicit routing method in a label switching system according to the present invention comprises a step of explicitly specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node, and a port or a port group of a relay node.
- A sixth explicit routing method in a label switching system according to the present invention may further comprise a step of specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP, and a step of specifying a port or a port group of the relay node by setting an IP address corresponding to the port or the port group of the relay node in intermediate ER-HOP-TLV in ER-TLVs in Label Request Message of the CR-LDP.
- A seventh explicit routing method in a label switching system according to the present invention may further comprise a step of specifying the port or the port group of the egress node and the port or the port group of the relay node by adding an intra-system port number or an intra-system port group number in ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP.
- An eighth explicit routing method in a label switching system according to the present invention may further comprise a step of explicating a port through which data should pass per system and specifying a port or a port group of the egress node by use of resource class TLV with ER-TLV in Label Request Message of CR-LDP being used as ER-HOP-TLV.
- A ninth explicit routing method in a label switching system according to the present invention may further comprise a step of specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final Subject-object in Explicit Route Objects in a path message of RSVP protocol extended for setting a label switched path in MPLS protocol, and a step of specifying a port or port group of the relay node by setting an IS address corresponding to the port or the port group of the relay node in intermediate Subject-object in Explicit Route Objects in the path message of the RSVP protocol.
- A tenth explicit routing method in a label switching system according to the present invention may further comprise a step of specifying a port or a port group of the egress node and a port or a port group of the relay node by adding an intra-system port number or an intra-system port group number in Subject-object in Explicit Route Objects in the path message of RSVP protocol extended for setting the label switched path in MPLS protocol.
- An eleventh explicit routing method in a label switching system according to the present invention comprises a step of specifying an MPLS explicit route by adding, to an IP-over-MPLS (IP/MPLS)forwarding function of one specified egress-and-ingress port group, a communication function with the IP/MPLS forwarding function of an intra-system other port group, and a forwarding function to the intra-system other port group.
- A first packet router in a label switching system according to the present invention comprises a logical router configuring module for logically dividing a label switching router (LSR) into a plurality of LSRs each having a label switching function, and a module for specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node.
- A second packet router in a label switching system according to the present invention comprises a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group, and a module for managing the topology data flooded from other system and, when setting a label switched path on the basis of an explicit route specified, explicitly specifying a port or a port group of an egress node, and a port or a port group of a relay node on the basis of the received topology data.
- A third packet router in a label switching system according to the present invention comprises a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group.
- A fourth packet router in a label switching system according to the present invention comprises a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group by use of Opaque LSA of OSPF protocol.
- A fifth packet router in a label switching system according to the present invention comprises a module for explicitly specifying, when setting a label switched path on the basis of an explicit route specified, a port or a port group of an egress node, and a port or a port group of a relay node.
- A sixth packet router in a label switching system according to the present invention may further comprise a module for specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP, and a module for specifying a port or a port group of the relay node by setting an IP address corresponding to the port or the port group of the relay node in intermediate ER-HOP-TLV in ER-TLVs in Label Request Message of the CR-LDP.
- A seventh packet router in a label switching system according to the present invention may further comprise a module for specifying the port or the port group of the egress node and the port or the port group of the relay node by adding an intra-system port number or an intra-system port group number in ER-HOP-TLV in ER-TLVs in Label Request Message of CR-LDP.
- An eighth packet router in a label switching system according to the present invention may further comprise a module for explicating a port through which data should pass per system and specifying a port or a port group of the egress node by use of resource class TLV with ER-TLV in Label Request Message of CR-LDP being used as ER-HOP-TLV.
- A ninth packet router in a label switching system according to the present invention may further comprise a module for specifying a port or a port group of the egress node by setting an IP address corresponding to the port or the port group of the egress node in final Subject-object in Explicit Route Objects in a path message of RSVP protocol extended for setting a label switched path in MPLS protocol, and a module for specifying a port or port group of the relay node by setting an IP address corresponding to the port or the port group of the relay node in intermediate Subject-object in Explicit Route Objects in the path message of the RSVP protocol.
- A tenth packet router in a label switching system according to the present invention may further comprise a module for specifying a port or a port group of the egress node and a port or a port group of the relay node by adding an intra-system port number or an intra-system port group number in Subject-object in Explicit Route Objects in the path message of RSVP protocol extended for setting the label switched path in MPLS protocol.
- An eleventh packet router in a label switching system according to the present invention comprises a module for specifying an MPLS explicit route by adding, to an IP/MPLS forwarding function of one specified egress-and-ingress port group, a communication function with the IP-over-MPLS (IP/MPLS) forwarding function of an intra-system other port group, and a forwarding function to the intra-system other port group.
- According to the present invention, it is feasible to actualize MPLS on the packet router taking the architecture of mounting an IP/MPLS forwarder in an adapter at an egress for packets in terms of a mounting space and a mounting cost. As a result, MPLS utilizing the existing system architecture can be easily mounted.
- Further, according to the present invention, when setting an explicit LSP, it is possible to attain routing elaborate enough to specify the ports or the port groups of the relay node and of the egress node. As a result, there is yielded a effect of expanding a range of utilizing an application making use of MPLS such as traffic engineering etc.
- These objects and advantages of the present invention will become more apparent and more readily appreciated from the following detailed description of the presently preferred exemplary embodiments, taken in conjunction with the accompanying drawings of which:
-
FIG. 1 is a block diagram showing an example of architecture of a conventional LSR; -
FIG. 2 is a block diagram showing an example of architecture of the conventional LSR; -
FIG. 3 is a block diagram showing an example of architecture of the conventional LSR; -
FIG. 4 is a block diagram showing an example of architecture of the conventional LSR; -
FIG. 5 is an explanatory view showing a conventional label distribution sequence; -
FIG. 6 is an explanatory view showing the conventional label distribution sequence; -
FIG. 7 is an explanatory view showing the conventional label distribution sequence; -
FIG. 8 is a block diagram showing an architecture of an LSR in a first embodiment of the present invention; -
FIG. 9 is a block diagram showing a detailed architecture of an LSR in the first embodiment; -
FIG. 10 is an explanatory flowchart showing an operation of the LSR in the first embodiment; -
FIG. 11 is a block diagram showing an architecture of the LSR in a second embodiment of the present invention; -
FIG. 12 is a block diagram showing a detailed architecture of the LSR in the second embodiment; -
FIG. 13 is an explanatory chart showing an example of definition of Opaque LSA of OSPF; -
FIG. 14 is an explanatory chart showing an example of definitions of Label Request Message of CR-LDP, ER-TLV, ER-HOP-TLV and resource class TLV; -
FIG. 15 is an explanatory chart showing an example of definitions of Label Request Message of CR-LDP, ER-TLV, ER-HOP-TLV and resource class TLV; -
FIG. 16 is an explanatory chart showing an example of additional definition of ER-HOP-TLV; -
FIG. 17 is an explanatory chart showing an example of definitions of Path Message of RSVP Extension, and Explicit-Route Object and IPv4 Subobject; -
FIG. 18 is an explanatory chart showing an example of additional definition of Subobject of Explicit-Route Object; -
FIG. 19 is an explanatory flowchart showing an operation of the LSR in the second embodiment; -
FIG. 20 is an explanatory flowchart showing the operation of the LSR in the second embodiment; -
FIG. 21 is an explanatory flowchart showing the operation of the LSR in the second embodiment; -
FIG. 22 is a block diagram showing an architecture of the LSR in a third embodiment of the present invention; -
FIG. 23 is a block diagram showing a detailed architecture of a forwarder in the LSR in the third embodiment; -
FIG. 24 is a block diagram showing a detailed architecture of a forwarder (X) in the LSR in the third embodiment; and -
FIG. 25 is a block diagram showing a detailed architecture of the forwarder(X) in the LSR in the third embodiment. - Embodiments of the present invention will hereinafter be described with reference to the accompanying drawings.
- A label switching router (LSR) classified as a packet router in a first embodiment of the present invention, will be explained referring to
FIGS. 8 , 9 and 10 in combination.FIGS. 8 and 9 show an architecture of the LSR.FIG. 10 shows a processing flowchart. - A label switching router (LSR) 10 in the first embodiment adopts an architecture of logically mounting a plurality of LSRs in a system. The independent LSR is logically defined corresponding to each adapter (corresponding to a port group) within the
LSR 10, and each adapter within the system is recognized as an independent LSR by other LSRs. - As shown in
FIG. 8 , an architecture of theLSR 10 is thatadapters adapters LSR 10,LSR 1,LSR 2,LSR 3 andLSR 4 are defined as logical LSRs, and the respective LSRs are connected in full-mesh, corresponding to theadapters - Based on this architecture, communications (based on a routing protocol, and a label distribution protocol) with other LSRs are performed. At this time, the
LSR 1,LSR 2 are not connected to the non-MPLS network, and it may therefore be sufficient that theLSR 1 andLSR 2 each incorporate a function as a relay node. TheLSR 1 andLSR 2 have neither a necessity of terminating the LSP nor a necessity of incorporating an IP/MPLS forwarding function, accordingly. - Other LSRs are thereby capable of recognizing the
LSR 10 as theindependent LSR 1,LSR 2,LSR 3,LSR 4, and, when setting the LSP for transferring packets which are to be forwarded to a network connected to theLSR 3. The LSP can be set with theLSR 3 serving as an egress node. Namely, the LSP can be terminated by theadapter 3. - To describe it in greater details, as shown in
FIG. 9 , thelogical LSRs - With these definitions, the respective
logical LSRs LSR management module 11 manages and integrates thelogical LSRs - Traffic engineering is classified as one of most useful applications of the MPLS, and aims at optimizing an activity ratio of network resources and optimizing a forwarding performance of the traffic. A traffic
engineering processing module 12, based on a database managed by a topologydata management module 13, calculates an optimal set route of the LSP, detects triggers for adding, changing and deleting the route, and determines a flow of allocating to the set LSP. - Further, the traffic
engineering processing module 12, based on the results given above, indicates a labelswitching processing module 14 to set, add, change and delete the LSP, and allocate and change the flow to the LSP. Moreover, the trafficengineering processing module 12 receives a result of processing and a report on the LSP set in response to a request made by other LSR from the labelswitching processing module 14, and reflects this result in the database of the topologydata management module 13. A part of the whole of the flow allocating process to the LSP may be executed by an MPLS forwarder on the adapter. - The label
switching processing module 14, in accordance with an indication given from the trafficengineering processing module 12, requests thelogical LSRs LSR management module 11. Further, the labelswitching processing module 14 receives other LSR's requests for setting, adding, changing and deleting the LSP from theLSR management module 11 via thelogical LSRs logical LSRs LSR management module 11. - When executing those processes, labels are caught and released by communications with a
label management module 15, and at the same time aswitch driver 16 is requested to execute switching from an input label to an output label. Furthermore, an MPLS forwarding table is updated by communications with an MPLS forwardingtable management module 17, and a part of copies of the MPLS forwarding table to thelogical LSRs LSR management module 11. - The logical
LSR management module 11 controls the communications with thelogical LSRs switching processing module 14 and thelogical LSRs LSR management module 1 maps a physical-architecture-based request given from the labelswitching processing module 14 to the logical architecture, and notifies thelogical LSRs LSR management module 11 maps logical-architecture-based requests given from thelogical LSRs switching processing module 14 of this mapping. - The
label management module 15, the topologydata management module 13, the IP routingtable management module 18 and the MPLS forwarding table management table 17, manage the respective databases thereof, and provide functions of searching and updating these databases. - The
switch driver 16 controls an ATM switch Fabric (core switch), and sets and deletes the LSP. An adapter#n driver 19 provides thelogical LSRs - The label
switching processing modules 20 in thelogical LSRs logical LSRs logical LSRs switching processing module 14 and the logicalLSR management module 11 carry out operations of managing the intra-system LSPs, allocating the labels, performing switch control, and updating the IP routing table and the MPLS forwarding table, and controls a protocol process with outside LSRs. - IP routing
protocol processing modules 21 in thelogical LSRs flooding processing module 22 executes a protocol process relative to a flood of the topology data for the traffic engineering independently of the topology process pertaining to the IP routing. Mounting thereof may, however, also be what is integrated as a protocol into which the routing protocol of the IP routingprotocol processing module 21 is extended. - The label distribution
protocol processing modules 23 in thelogical LSRs forwarder control module 24 controls a forwarder mounted into the adapter. That is, theforwarder control module 24 initializes and updates an IP forwarding table and an MPLS forwarding table that are possessed by the forwarder. - Further, the label
switching processing modules 20, the IP routingprotocol processing modules 21, the topology dataflooding processing modules 22, the label distributionprotocol processing modules 23 and theforwarder control modules 24 in thelogical LSRs logical LSRs logical LSRs forwarder control modules 24 have no necessity of being operated. - With the above architecture (a software architecture may also be taken) adopted, as a result, an explicit route with a specified egress adapter of the egress node can be set.
- The label switch router (LSR) serving as a packet router in a second embodiment of the present invention will be described with reference to
FIGS. 11 , 12, 13 through 18, 19, 20 and 21 in combination.FIGS. 11 and 12 show an architecture of the label switch router (LSR).FIGS. 13 through 18 show examples of a variety of definitions of the protocols for the traffic engineering.FIGS. 19 , 20 and 21 are flowcharts showing the processes. - A label switching router (LSR) 30 in the second embodiment takes such an architecture that the intra-system adapters can be specified.
- As shown in
FIG. 11 , theLSR 30 has a database stored with various items of topology data of the network. TheLSR 30 incorporates a function of flooding the topology data on the basis of the database, and a function of updating the database on the basis of the flooded topology data. Further, theLSR 30 has a label distributing function (LSO setting function) by which an explicit route is specified based on the database. - Further, the
LSR 30 incorporates a function (1) of rearranging ports and an aggregation of the ports into groups and thus managing the ports, a function (2) of flooding the port and/or a group number of the port to an address of a connection destination network, a function (3) of structuring the flooding data including the above item (2) into a database, a function (4) of determining, based on the database in the item (3), an explicit route inclusive of the port or the port group in addition to nodes through which the packets pass, and a function (5) of distributing the labels by giving the explicit route determined in the item (3). - The topology data sub-itemized down to the port groups or the ports of the relay node and the egress node can be managed at an ingress node, and it is feasible to set not only a port group of the egress node or an LSP with the specified port but also a port group or a port of the relay node through which the packets pass.
- To explain it in full depth, as shown in
FIG. 12 , in anLSR 30, management functions corresponding to the respective ports and the port group (corresponding to the adapters) of other system and the self-system, are added to the components indicated by hatching. In thisLSR 30, a port management is carried out in the way of allocatingports port group 1,ports port group 2,ports port group 3, andports port group 4. - Moreover, what is added to the
LSR 30 is a function of flooding a port or/and a group number of the port to an address of a connection destination network. At the present, the function of flooding the topology data is supported by the routing protocol such as OSPF etc. There is further made a proposal of adding a function to OSPF and flooding the topology data for the traffic engineering (independently of the topology data for the IP routing) (which involves the use of Opaque LSA (Link State Advertisement) of OSPF). - This example is illustrated in
FIG. 13 . This type of LSA is newly defined and then flooded, whereby each system receives LSA from other system and, as a result, the topology data for the traffic engineering can be obtained. A link and an interface inFIG. 13 correspond to the ports. - Basically, this is used, however, this concept is further extended, and the port group is added to Sub-TVLV defined in
FIG. 13 . To give an example of the definition, sub-TVLV type: 7, length (octets): 1, value (octet): 4, name: port group number. Further, a port group number is allocated to a resource class TLV. Thus, the port group number is defined, whereby the port group number can be flooded. This function is incorporated into a topology dataflooding processing module 31. - A function of converting the flooding data into a database is added to the
LSR 30. In addition to the topology data for the traffic engineering, which are flooded with opaque LSA of OSPF shown inFIG. 13 , the port group numbers flooded by the topology dataflooding processing module 31 are also converted into a database. This function is incorporated into the topologydata management module 32 and the trafficengineering processing module 33. - In the
LSR 30, a function of determining the explicit route inclusive of the port or the port group is added. Based on the databases of the topologydata management module 32 and of the trafficengineering processing module 33, the explicit route of the LSP from the ingress node to the output port of the egress node, is determined by a local policy or a managerial selection. This function is incorporated into the trafficengineering processing module 33. - Further, in the
LSR 30, the following function of distributing the labels by explicating the port or the port group, is added. - (1) ER HOP TLV in Label Request Message of CR-LDP shown in
FIGS. 14 and 15 specifies a node (system) through which essentially the LSP passes. This is extensively defined, and final ER HOP TLV in ER TLVs shall indicate an output port group of the egress node. - The ingress node, based on the determination of the explicit route, specifies an IP address (corresponding to any one of ports in the port group) corresponding to the output port group of the egress node in final ER HOP TLV in ER TLVs in the Label Request Message.
- The egress node specifies an output port in accordance with the IP address indicated in final ER HOP TLV in ER TLVs in Label Request Message, and may further specify a port group to which that port belongs.
- (2) IPv4 Subobject in EXPLICIT-ROUTE object in Path Message of RSVP Extension shown in
FIG. 17 , specifies a node (system) through which essentially the LSP passes. This is extensively defined, and final IPv4 Subobject in EXPLICIT ROUTE object shall indicate an output port group of an egress node. This is RSVP Extension version in the item (1). - (3) As shown in
FIG. 16 , the port and the port group (a link and a link group) are additionally defined in ER HOP type of ER HOP TLV, and further a port and port group (link and link group) ELV is additionally defined. - The ingress node, based on the determination of the explicit route, specifies an output port group number or/and port number of the egress node in final ER HOP TLV in ER TLVs in Label Request Message by use of the port an port group (link and link group) TLV.
- Further, as the necessity arises, the egress node may specify a port and a port group passing through the relay node in intermediate ER HOP TLV by use of the port and port group (link and link group) TLV.
- (4) As shown in
FIG. 18 , the port and the port group (the link and the link group) are additionally defined in Subobject type of EXPLICIT_ROUTE object, and further port and port group (link and link group) Subobject is additionally defined. This is RSVP Extension version in the item (3). - (5) As shown in
FIG. 16 , a resource class is additionally defined in ER Hop type of ER HOP TLV. Further, resource class TLV shown inFIG. 15 is used as ER HOP TLV. - The ingress node, based on the determination of the explicit route, uses resource class TLV in final ER HOP TLV in ER TLVs in Label Request Message, and specifies an output port group number of the egress node.
- The egress node may specify an output port group number from the output port group number indicated by final ER HOP TLV in ER TLVs in Label Request Message.
- Further, as the necessity arises, resource class TLV is used in intermediate ER HOP TLV, whereby a port group passing through a relay node can be specified.
- The topology data sub-itemized down to the port groups or the ports of the relay node and the egress node can be managed at the ingress node, and it is feasible to set an LSP with the specified port group or port of the egress node, and to specify the port group or port of the relay node through which the packets pass.
- Note that the same components of the
LSR 30 shown inFIG. 12 as those of theLSR 10 shown inFIG. 9 are marked with the same reference numerals. - The label switching router (LSR) classified as the packet router in a third embodiment of the present invention, will be explained referring to
FIGS. 22 , 23, 24, and 25 in combination. - A label switching router (LSR) 40 in the third embodiment takes such an architecture that an egress adapter within the system is capable of executing internal shuttling. As shown in
FIG. 22 , theLSR 40 has, in the system architecture illustrated inFIG. 2 , an addition of the following functions to one specified egress adapter. That is, these functions are a function (1) of setting a connection with other egress adapter via an ATM switch, a function (2) conducting IP forwarding to other adapters in addition to the intra-adapter ports (which uses the connection given in the item (1), and a function (3) of adding routing data to other adapters to a routing table that is referred in the item (2). - With these functions added, the setting of the explicit LSP can be actualized neither by changing a basic framework (in terms of mounting) of the system architecture shown in
FIG. 2 nor by the ingress node specifying (managing) the adapters of the egress node. -
FIG. 23 shows an example of architecture of an IP/MPLS forwarder in theLSR 40 illustrated inFIG. 22 . In an IP/MPLS forwarder 50, a driver/receiver 51 transmits and receives the data to and from an external interface (ATM/Ether). The received data is stored in abuffer 52, the driver/receiver 51 transfers the control, wherein an address and a size of the received data are set as output data. When in a data transmitting process, the driver/receiver 51 transmits the data stored in thebuffer 52, wherein the address and the size thereof are set as input data. - The
buffer 52 is stored with the received data and also edited data (transmitted data). The IP routing table 53 is a copy of a part of the IP routing table possessed by theLSR 40 body, and containsports 1˜n as output destination ports. An MPLS forwarding table (Label Information Base) 54 is a copy of a part of the MPLS forwarding table possessed by theLSR 40 body, and containsVCs 1˜n as output destination ports. - A table updating
processing module 55 executes a process of updating the IP routing table 53 and the MPLS forwarding table 54 in response to an indication given from an LSR body control unit. A cellulating module (packet deassembling module) 56 cellulates the packets which have already been edited, and indicates thedriver 58 to transmit the cells by specifying a VC. A decellulating module (packet assembling module) 57 decellulates the received cells from thereceiver 58, and assembles them into packets on thebuffer 52. - A
packet editing module 59 executes a process of editing an IP header and an MPLS header of the packet. An IPforwarding processing module 60 determines a packet transmitting destination with reference to the IP routing table 53, and indicates thepacket editing module 61 to edit the IP header. An MPLSforwarding processing module 62 determines a packet transmitting destination with reference to the MPLS forwarding table 54, and indicates thepacket editing module 61 to edit an MPLS header. -
FIG. 24 shows a first example of architecture of the IP/MPLS forwarder (X) in theLSR 40 illustrated inFIG. 22 . An IP/MPLS forwarder (X) 70 actualizes the setting of the explicit LSP neither by changing the basic framework (in terms of mounting) of the system architecture shown inFIG. 2 nor by the ingress node specifying (managing) the adapters of the egress node. - Functions of this IP/MPLS forwarder (X) 70, which are to be added to the architecture of the IP/
MPLS forwarder 50 shown inFIG. 23 , will be explained. An IP routing table 71 is a copy of a part of the IP routing table possessed by the LSR body, and containsports 1˜n as output destination ports andVCs 1˜n. Apacket editing module 72 executes a process of editing the IP header and the MPLS header. Responding to indications given from the IPforwarding processing module 73, there are, however, a case where thepacket editing module 72 indicates thedriver 51 to transmit the edited packets to the port n, and a case where thepacket editing module 72 indicates aconflict control module 74 to transmit the edited packets to she virtual channel (VC) n. - An IP
forwarding processing module 73 determines a packet transmitting destination with reference to the IP routing table 71, and indicates thepacket editing module 72 to edit the IP header. On this occasion, the IPforwarding processing module 72 explicates whether the transmitting destination is the port nor the VC n. Theconflict control module 74 controls a conflict between shuttle packets inputted from the port n and from the VC n, and executes scheduling of the input packets to thecellulating module 56. -
FIG. 25 shows a second example of architecture of the IP/MPLS forwarder (X) in theLSR 40 illustrated inFIG. 22 . Functions of this IP/MPLS forwarder (X) 80, which are to be added to the architecture of the IP/MPLS forwarder 50 shown inFIG. 23 , will be explained. - Drivers/
receivers buffer 83. The drivers/receivers receivers buffer 83, wherein the addresses and the sizes thereof are set as input data. In this architecture, however, the drivers/receivers - Although only a few embodiments of the present invention have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the preferred embodiments without departing from the novel teachings and advantages of the present invention. Accordingly, all such modifications are intended to be included within the scope of the present invention as defined by the following claims.
Claims (9)
1. (canceled)
2. An explicit routing method in a label switching system, comprising:
a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group; and
a step of managing the topology data flooded from other system and, when setting a label switched path on the basis of an explicit route specified, explicitly specifying a port or a port group of an egress node, and a port or a port group of a relay node on the basis of the received topology data.
3. An explicit routing method in a label switching system, comprising:
a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group.
4. An explicit routing method in a label switching system, comprising:
a step of flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group by use of Opaque LSA of OSPF protocol.
5-12. (canceled)
13. A packet router in a label switching system, comprising:
a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group; and
a module for managing the topology data flooded from other system and, when setting a label switched path on the basis of an explicit route specified, explicitly specifying a port or a port group of an egress node, and a port or a port group of a relay node on the basis of the received topology data.
14. A packet router in a label switching system, comprising:
a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group.
15. A packet router in a label switching system, comprising:
a module for flooding, as topology data, a set of an intra-system port and an IP address allocated to the port, or a set of a port group among a plurality of groups into which the ports are divided, and an IP address allocated to the port group by use of Opaque LSA of OSPF protocol.
16-22. (canceled)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/875,202 US20080253379A1 (en) | 2000-01-11 | 2007-10-19 | Label switching system |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000006160A JP3817400B2 (en) | 2000-01-11 | 2000-01-11 | Explicit route designation method and packet relay apparatus in label switching system |
JP2000-006160 | 2000-01-11 | ||
US09/696,674 US7336648B1 (en) | 2000-01-11 | 2000-10-25 | Label switching system |
US11/875,202 US20080253379A1 (en) | 2000-01-11 | 2007-10-19 | Label switching system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/696,674 Division US7336648B1 (en) | 2000-01-11 | 2000-10-25 | Label switching system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080253379A1 true US20080253379A1 (en) | 2008-10-16 |
Family
ID=18534734
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/696,674 Expired - Fee Related US7336648B1 (en) | 2000-01-11 | 2000-10-25 | Label switching system |
US11/875,202 Abandoned US20080253379A1 (en) | 2000-01-11 | 2007-10-19 | Label switching system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/696,674 Expired - Fee Related US7336648B1 (en) | 2000-01-11 | 2000-10-25 | Label switching system |
Country Status (2)
Country | Link |
---|---|
US (2) | US7336648B1 (en) |
JP (1) | JP3817400B2 (en) |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040143593A1 (en) * | 2002-12-19 | 2004-07-22 | International Business Machines Corporation | System and method for re-sequencing data packets on a per-flow basis |
US20070104194A1 (en) * | 2005-11-04 | 2007-05-10 | Ijsbrand Wijnands | In-band multicast signaling using LDP |
US20070217428A1 (en) * | 2006-03-16 | 2007-09-20 | Ijsbrand Wijnands | Automation fallback to P2P LSPs for mLDP built multipoint-trees |
US20090135841A1 (en) * | 2004-11-05 | 2009-05-28 | Cisco Technology, Inc. | System and method for retrieving computed paths from a path computation element using encrypted objects |
US20090150547A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for scaling applications on a blade chassis |
US20090150538A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for monitoring virtual wires |
US20090150521A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for creating a virtual network path |
US20090150527A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for reconfiguring a virtual network path |
US20090150883A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for controlling network traffic in a blade chassis |
US20090150529A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for enforcing resource constraints for virtual machines across migration |
US20090222567A1 (en) * | 2008-02-29 | 2009-09-03 | Sun Microsystems, Inc. | Method and system for media-based data transfer |
US20090219936A1 (en) * | 2008-02-29 | 2009-09-03 | Sun Microsystems, Inc. | Method and system for offloading network processing |
US20090238189A1 (en) * | 2008-03-24 | 2009-09-24 | Sun Microsystems, Inc. | Method and system for classifying network traffic |
US20090328073A1 (en) * | 2008-06-30 | 2009-12-31 | Sun Microsystems, Inc. | Method and system for low-overhead data transfer |
US20090327392A1 (en) * | 2008-06-30 | 2009-12-31 | Sun Microsystems, Inc. | Method and system for creating a virtual router in a blade chassis to maintain connectivity |
US20100040070A1 (en) * | 2008-08-14 | 2010-02-18 | Chang-Jin Suh | Node device and method for deciding shortest path using spanning tree |
US7903554B1 (en) * | 2008-04-04 | 2011-03-08 | Force 10 Networks, Inc. | Leaking component link traffic engineering information |
US20130028094A1 (en) * | 2011-07-25 | 2013-01-31 | Zhonghua Gao | Fiber chanel device |
US8634415B2 (en) | 2011-02-16 | 2014-01-21 | Oracle International Corporation | Method and system for routing network traffic for a blade server |
US9489327B2 (en) | 2013-11-05 | 2016-11-08 | Oracle International Corporation | System and method for supporting an efficient packet processing model in a network environment |
US9800498B2 (en) | 2009-06-24 | 2017-10-24 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for managing label of access network |
US9858241B2 (en) | 2013-11-05 | 2018-01-02 | Oracle International Corporation | System and method for supporting optimized buffer utilization for packet processing in a networking device |
US9906442B2 (en) * | 2015-04-17 | 2018-02-27 | Dell Products Lp | Systems and methods for increasing the multiprotocol label switching stack |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7664877B1 (en) * | 2001-03-19 | 2010-02-16 | Juniper Networks, Inc. | Methods and apparatus for using both LDP and RSVP in a communications systems |
US8868715B2 (en) * | 2001-10-15 | 2014-10-21 | Volli Polymer Gmbh Llc | Report generation and visualization systems and methods and their use in testing frameworks for determining suitability of a network for target applications |
US8543681B2 (en) * | 2001-10-15 | 2013-09-24 | Volli Polymer Gmbh Llc | Network topology discovery systems and methods |
EP1592181B1 (en) * | 2003-02-03 | 2015-01-21 | Nippon Telegraph And Telephone Corporation | Optical network, optical edge router, program thereof, cut through method, and edge router |
CN100372337C (en) * | 2004-05-31 | 2008-02-27 | 华为技术有限公司 | Route selection method for implementing cross-domain constraint-based routing |
US7606235B1 (en) * | 2004-06-03 | 2009-10-20 | Juniper Networks, Inc. | Constraint-based label switched path selection within a computer network |
JP2008502234A (en) * | 2004-06-07 | 2008-01-24 | ▲ホア▼▲ウェイ▼技術有限公司 | How to achieve route forwarding in a network |
US7558289B1 (en) * | 2004-06-17 | 2009-07-07 | Marvell International Ltd. | Method and apparatus for providing quality of service (QOS) in a wireless local area network |
US20060018255A1 (en) * | 2004-07-26 | 2006-01-26 | Avaya Technology Corp. | Defining a static path through a communications network to provide wiretap law compliance |
US7567512B1 (en) | 2004-08-27 | 2009-07-28 | Juniper Networks, Inc. | Traffic engineering using extended bandwidth accounting information |
US7558199B1 (en) | 2004-10-26 | 2009-07-07 | Juniper Networks, Inc. | RSVP-passive interfaces for traffic engineering peering links in MPLS networks |
US8576855B2 (en) * | 2006-05-17 | 2013-11-05 | Alcatel Lucent | System and method of interface association for interface operational status event monitoring |
US7907526B2 (en) * | 2006-05-26 | 2011-03-15 | Telefonaktiebolaget L M Ericsson (Publ) | Traffic-triggered setup of label switched paths |
WO2008011354A2 (en) * | 2006-07-18 | 2008-01-24 | Gordon Bolt | Controlled incremental multi-protocol label switching (mpls) traffic engineering |
CN101494552B (en) | 2008-01-23 | 2011-05-18 | 华为技术有限公司 | Method, system and apparatus for establishing business connection |
JP4957660B2 (en) * | 2008-06-20 | 2012-06-20 | 富士通株式会社 | Communication device in label switching network |
US8374502B2 (en) * | 2009-02-27 | 2013-02-12 | Futurewei Technologies, Inc. | Open shortest path first extensions in support of wavelength switched optical networks |
US20110058558A1 (en) * | 2009-09-08 | 2011-03-10 | Electronics And Telecommunications Research Institute | Network control device and network control method |
US8675494B2 (en) * | 2009-12-04 | 2014-03-18 | Brocade Communications Systems, Inc. | Conflict identification in label switched services |
US8787400B1 (en) | 2012-04-25 | 2014-07-22 | Juniper Networks, Inc. | Weighted equal-cost multipath |
US9071541B2 (en) | 2012-04-25 | 2015-06-30 | Juniper Networks, Inc. | Path weighted equal-cost multipath |
US9577925B1 (en) | 2013-07-11 | 2017-02-21 | Juniper Networks, Inc. | Automated path re-optimization |
US9344357B2 (en) * | 2014-01-24 | 2016-05-17 | Cisco Technology, Inc. | Label-switched path aggregation |
US11323365B2 (en) * | 2018-05-17 | 2022-05-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Tearing down a label switched path through a communications network |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5455825A (en) * | 1994-04-28 | 1995-10-03 | Mitsubishi Electric Research Laboratories | Tag-based scheduling system for digital communication switch |
US5699347A (en) * | 1995-11-17 | 1997-12-16 | Bay Networks, Inc. | Method and apparatus for routing packets in networks having connection-oriented subnetworks |
US5854899A (en) * | 1996-05-09 | 1998-12-29 | Bay Networks, Inc. | Method and apparatus for managing virtual circuits and routing packets in a network/subnetwork environment |
US6408001B1 (en) * | 1998-10-21 | 2002-06-18 | Lucent Technologies Inc. | Method for determining label assignments for a router |
US6530032B1 (en) * | 1999-09-23 | 2003-03-04 | Nortel Networks Limited | Network fault recovery method and apparatus |
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 |
US6628649B1 (en) * | 1999-10-29 | 2003-09-30 | Cisco Technology, Inc. | Apparatus and methods providing redundant routing in a switched network device |
US6674744B1 (en) * | 1998-09-22 | 2004-01-06 | Lucent Technologies Inc. | Point-to-point data transport over the internet utilizing label switching without IP headers |
US6680943B1 (en) * | 1999-10-01 | 2004-01-20 | Nortel Networks Limited | Establishing bi-directional communication sessions across a communications network |
US6721269B2 (en) * | 1999-05-25 | 2004-04-13 | Lucent Technologies, Inc. | Apparatus and method for internet protocol flow ring protection switching |
US6735190B1 (en) * | 1998-10-21 | 2004-05-11 | Lucent Technologies Inc. | Packet transport method device utilizing header removal fields |
US6850524B1 (en) * | 2000-07-31 | 2005-02-01 | Gregory Donald Troxel | Systems and methods for predictive routing |
-
2000
- 2000-01-11 JP JP2000006160A patent/JP3817400B2/en not_active Expired - Fee Related
- 2000-10-25 US US09/696,674 patent/US7336648B1/en not_active Expired - Fee Related
-
2007
- 2007-10-19 US US11/875,202 patent/US20080253379A1/en not_active Abandoned
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5455825A (en) * | 1994-04-28 | 1995-10-03 | Mitsubishi Electric Research Laboratories | Tag-based scheduling system for digital communication switch |
US5699347A (en) * | 1995-11-17 | 1997-12-16 | Bay Networks, Inc. | Method and apparatus for routing packets in networks having connection-oriented subnetworks |
US5854899A (en) * | 1996-05-09 | 1998-12-29 | Bay Networks, Inc. | Method and apparatus for managing virtual circuits and routing packets in a network/subnetwork environment |
US6674744B1 (en) * | 1998-09-22 | 2004-01-06 | Lucent Technologies Inc. | Point-to-point data transport over the internet utilizing label switching without IP headers |
US6408001B1 (en) * | 1998-10-21 | 2002-06-18 | Lucent Technologies Inc. | Method for determining label assignments for a router |
US6735190B1 (en) * | 1998-10-21 | 2004-05-11 | Lucent Technologies Inc. | Packet transport method device utilizing header removal fields |
US6721269B2 (en) * | 1999-05-25 | 2004-04-13 | Lucent Technologies, Inc. | Apparatus and method for internet protocol flow ring protection switching |
US6530032B1 (en) * | 1999-09-23 | 2003-03-04 | Nortel Networks Limited | Network fault recovery method and apparatus |
US6680943B1 (en) * | 1999-10-01 | 2004-01-20 | Nortel Networks Limited | Establishing bi-directional communication sessions across a communications network |
US6628649B1 (en) * | 1999-10-29 | 2003-09-30 | Cisco Technology, Inc. | Apparatus and methods providing redundant routing in a switched network device |
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 |
US6850524B1 (en) * | 2000-07-31 | 2005-02-01 | Gregory Donald Troxel | Systems and methods for predictive routing |
Cited By (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8995445B2 (en) * | 2002-12-19 | 2015-03-31 | International Business Machines Corporation | System and method for re-sequencing data packets on a per-flow basis |
US20040143593A1 (en) * | 2002-12-19 | 2004-07-22 | International Business Machines Corporation | System and method for re-sequencing data packets on a per-flow basis |
US20090135841A1 (en) * | 2004-11-05 | 2009-05-28 | Cisco Technology, Inc. | System and method for retrieving computed paths from a path computation element using encrypted objects |
US7995593B2 (en) * | 2004-11-05 | 2011-08-09 | Cisco Technology, Inc. | System and method for retrieving computed paths from a path computation element using encrypted objects |
US7852841B2 (en) * | 2005-11-04 | 2010-12-14 | Cisco Technology, Inc. | In-band multicast signaling using LDP |
US20070104194A1 (en) * | 2005-11-04 | 2007-05-10 | Ijsbrand Wijnands | In-band multicast signaling using LDP |
US8948170B2 (en) | 2005-11-04 | 2015-02-03 | Cisco Technology, Inc. | Automation fallback to P2P LSPs for MLDP built multipoint-trees |
US20070217428A1 (en) * | 2006-03-16 | 2007-09-20 | Ijsbrand Wijnands | Automation fallback to P2P LSPs for mLDP built multipoint-trees |
US8107473B2 (en) | 2006-03-16 | 2012-01-31 | Cisco Technology, Inc. | Automation fallback to P2P LSPs for mLDP built multipoint-trees |
US8370530B2 (en) | 2007-12-10 | 2013-02-05 | Oracle America, Inc. | Method and system for controlling network traffic in a blade chassis |
US20090150527A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for reconfiguring a virtual network path |
US8086739B2 (en) | 2007-12-10 | 2011-12-27 | Oracle America, Inc. | Method and system for monitoring virtual wires |
US20090150883A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for controlling network traffic in a blade chassis |
US20090150547A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for scaling applications on a blade chassis |
US20090150538A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for monitoring virtual wires |
US20090150521A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for creating a virtual network path |
US20090150529A1 (en) * | 2007-12-10 | 2009-06-11 | Sun Microsystems, Inc. | Method and system for enforcing resource constraints for virtual machines across migration |
US7984123B2 (en) | 2007-12-10 | 2011-07-19 | Oracle America, Inc. | Method and system for reconfiguring a virtual network path |
US8095661B2 (en) * | 2007-12-10 | 2012-01-10 | Oracle America, Inc. | Method and system for scaling applications on a blade chassis |
US7962587B2 (en) | 2007-12-10 | 2011-06-14 | Oracle America, Inc. | Method and system for enforcing resource constraints for virtual machines across migration |
US7945647B2 (en) | 2007-12-10 | 2011-05-17 | Oracle America, Inc. | Method and system for creating a virtual network path |
US7965714B2 (en) | 2008-02-29 | 2011-06-21 | Oracle America, Inc. | Method and system for offloading network processing |
US7970951B2 (en) | 2008-02-29 | 2011-06-28 | Oracle America, Inc. | Method and system for media-based data transfer |
US20090222567A1 (en) * | 2008-02-29 | 2009-09-03 | Sun Microsystems, Inc. | Method and system for media-based data transfer |
US20090219936A1 (en) * | 2008-02-29 | 2009-09-03 | Sun Microsystems, Inc. | Method and system for offloading network processing |
US7944923B2 (en) | 2008-03-24 | 2011-05-17 | Oracle America, Inc. | Method and system for classifying network traffic |
US20090238189A1 (en) * | 2008-03-24 | 2009-09-24 | Sun Microsystems, Inc. | Method and system for classifying network traffic |
US7903554B1 (en) * | 2008-04-04 | 2011-03-08 | Force 10 Networks, Inc. | Leaking component link traffic engineering information |
US20090327392A1 (en) * | 2008-06-30 | 2009-12-31 | Sun Microsystems, Inc. | Method and system for creating a virtual router in a blade chassis to maintain connectivity |
US7941539B2 (en) | 2008-06-30 | 2011-05-10 | Oracle America, Inc. | Method and system for creating a virtual router in a blade chassis to maintain connectivity |
US20090328073A1 (en) * | 2008-06-30 | 2009-12-31 | Sun Microsystems, Inc. | Method and system for low-overhead data transfer |
US8739179B2 (en) | 2008-06-30 | 2014-05-27 | Oracle America Inc. | Method and system for low-overhead data transfer |
US20100040070A1 (en) * | 2008-08-14 | 2010-02-18 | Chang-Jin Suh | Node device and method for deciding shortest path using spanning tree |
US9800498B2 (en) | 2009-06-24 | 2017-10-24 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for managing label of access network |
US11258705B2 (en) | 2009-06-24 | 2022-02-22 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for managing label of access network |
US8634415B2 (en) | 2011-02-16 | 2014-01-21 | Oracle International Corporation | Method and system for routing network traffic for a blade server |
US9544232B2 (en) | 2011-02-16 | 2017-01-10 | Oracle International Corporation | System and method for supporting virtualized switch classification tables |
US20130028094A1 (en) * | 2011-07-25 | 2013-01-31 | Zhonghua Gao | Fiber chanel device |
US9489327B2 (en) | 2013-11-05 | 2016-11-08 | Oracle International Corporation | System and method for supporting an efficient packet processing model in a network environment |
US9858241B2 (en) | 2013-11-05 | 2018-01-02 | Oracle International Corporation | System and method for supporting optimized buffer utilization for packet processing in a networking device |
US9906442B2 (en) * | 2015-04-17 | 2018-02-27 | Dell Products Lp | Systems and methods for increasing the multiprotocol label switching stack |
Also Published As
Publication number | Publication date |
---|---|
JP2001197116A (en) | 2001-07-19 |
JP3817400B2 (en) | 2006-09-06 |
US7336648B1 (en) | 2008-02-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7336648B1 (en) | Label switching system | |
US6683874B1 (en) | Router device and label switched path control method using upstream initiated aggregation | |
Armitage | MPLS: the magic behind the myths [multiprotocol label switching] | |
JP4597456B2 (en) | No. Method for integrating 7 common line signaling network and multi-protocol label switching network | |
US6501756B1 (en) | Method of managing hop-count in label switching network and node apparatus | |
JP3762749B2 (en) | Restoration protection method and apparatus | |
JP4833292B2 (en) | Ethernet GMPLS control | |
US7483387B2 (en) | Hierarchical label distribution for inter-area summarization of edge-device addresses | |
US8014293B1 (en) | Scalable route resolution | |
US5953312A (en) | Method and apparatus for determining alternate routes in a network using a connection-oriented protocol | |
JP3790658B2 (en) | Routing information mapping apparatus, method and recording medium in network | |
US7873053B2 (en) | Method and apparatus for reserving network resources for pseudo point-to-point connections | |
JP3688408B2 (en) | Packet transfer control method and node device | |
Kalmykov et al. | Segment routing as a basis for software defined network | |
WO2003058868A2 (en) | Dynamic route selection for label switched paths in communication networks | |
EP1331834B1 (en) | Virtual Path reservation device for multi protocol label switching MPLS networks | |
Cisco | MPLS Tag-Switching | |
CN110650088B (en) | Resource reservation technology for point-to-multipoint tunnel on ring network | |
US20050169264A1 (en) | Multi-protocol label switching (MPLS) edge router | |
KR100411249B1 (en) | The Label Assignment Method using the BGP table information in MPLS Network | |
Metz | At the core of IP networks: link-state routing protocols | |
CN1984499A (en) | Method for automatically exchanging optical network node access | |
Chen et al. | Using policy-based MPLS management architecture to improve QoS on IP network | |
Sánchez-López et al. | A solution for integrating MPLS over ATM | |
WO2014149960A1 (en) | System, method and apparatus for lsp setup using inter-domain abr indication |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |