CA2570745C - Technique for transferring data over a packet switched network - Google Patents
Technique for transferring data over a packet switched network Download PDFInfo
- Publication number
- CA2570745C CA2570745C CA2570745A CA2570745A CA2570745C CA 2570745 C CA2570745 C CA 2570745C CA 2570745 A CA2570745 A CA 2570745A CA 2570745 A CA2570745 A CA 2570745A CA 2570745 C CA2570745 C CA 2570745C
- Authority
- CA
- Canada
- Prior art keywords
- egress
- transport
- ingress
- network
- packet
- 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.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- 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
Abstract
A technique transfers data over a packet-switched network (PSN), comprising a plurality of intermediate nodes, in a manner that does not require that the intermediate nodes support a network layer infrastructure. A network controller coupled to the intermediate nodes acquires topology information associated with the PSN~s topology. This information may include pseudo-wire definitions, ingress and egress interface information, ingress and egress labels, and so on. The network controller generates a transport database from the topology information and distributes the transport database to the intermediate nodes. An intermediate node acquires the transport database information and configures a packet-processing engine (PPE), contained within the intermediate node, to process packets acquired by the intermediate node.
Description
2 TECBENIQUE FOR TRANSFERRING DATA OVER A PACKET
SWITCHED NETWORK
BACKGROUND OF THE INVENTION
Field of the Invention The present invention relates to data networks and specifically to transferring data over packet switched networks.
Background Information A computer network is a geographically distributed collection of interconnected communication links and segments for transporting data between nodes, such as corn-puter systems. Many types of network segments are available, with types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect personal computers and workstations over dedicated, private communications links lo-cated in the same general physical location, such as a building or a campus.
WANs, on the other hand, typically connect large numbers of geographically dispersed nodes over is long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or pack-ets of data according to predefined protocols, such as the Asynchronous Transfer Mode (ATM) protocol, Frame Relay (FR) protocol and the Transmission Control Proto-col/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules de-fining how the nodes interact with each other.
To interconnect dispersed computer networks, many organizations rely on the infrastructure and facilities of Service Providers (SPs). SPs typically own one or more transport networks that are configured to provide high-speed connections capable of handling traffic for many customers/subscribers. A transport network, as used herein, is a data network used to transport data within a SP's network. In a typical configura-tion, a customer/subscriber couples its dispersed networks to an edge router configured to enable access to the SP's network. The SP's network may comprise various switches configured to switch traffic between the various edge routers. The routers typically operate at layer-3 (L3) of a communications protocol stack, which is the net-s work layer of the Open Systems Interconnect (OSI) reference model. The switches typically operate at layer-2 (L2) of the communications protocol stack, which is the data-link layer of the OSI reference model.
SPs often provide multiple services to their customers/subscribers, such as FR
services and ATM services. Here, an SP may employ parallel or "overlay"
networks ro wherein each network is configured to provide a specific service. For example, a SP
that provides a FR service and an ATM service may employ two separate networks where each network provides a separate service. Providing separate networks for sepa-rate services, however, is often costly and difficult to manage; thus, many SPs employ a "converged network" to provide various services. A converged network is a network is that converges various different services onto a single network, such as an optical net-work. Converged networks are often called "transport networks" in that they usually act only to transport various services' data from one point in the SP's network to an-other point in the network.
One way to implement a converged network is to employ a technique called 20 "pseudo wire emulation edge-to-edge" (PWE3). PWE3 is described in S.
Bryant et al., "PWE3 Architecture," draft-ie#:pwe3-arch-06.bct available from the Internet Engineer-ing Task Force (IETF), http://wwwietf.org. PWE3 is a technique that emulates the es-sential attributes of a service, such as ATM or FR, over a packet-switched network (PSN), such as a Synchronous Optical NETwork/Synchronous Digital Hierarchy 25 (SONET/SDH) network, which acts as a transport network. PWE3 utilizes pseudo wires (PWs), which are mechanisms that emulate the essential attributes of a particular service.
In a typical PWE3 arrangement, a customer's data is encapsulated at the ingress point (e.g., an "ingress" edge router") in the SP's network. The encapsulated data is 30 transported over the SP's transport network via a predefined path, such as an IP path or a Multiprotocol Label Switching (MPLS) path, to an egress point in the SP's network
SWITCHED NETWORK
BACKGROUND OF THE INVENTION
Field of the Invention The present invention relates to data networks and specifically to transferring data over packet switched networks.
Background Information A computer network is a geographically distributed collection of interconnected communication links and segments for transporting data between nodes, such as corn-puter systems. Many types of network segments are available, with types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect personal computers and workstations over dedicated, private communications links lo-cated in the same general physical location, such as a building or a campus.
WANs, on the other hand, typically connect large numbers of geographically dispersed nodes over is long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or pack-ets of data according to predefined protocols, such as the Asynchronous Transfer Mode (ATM) protocol, Frame Relay (FR) protocol and the Transmission Control Proto-col/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules de-fining how the nodes interact with each other.
To interconnect dispersed computer networks, many organizations rely on the infrastructure and facilities of Service Providers (SPs). SPs typically own one or more transport networks that are configured to provide high-speed connections capable of handling traffic for many customers/subscribers. A transport network, as used herein, is a data network used to transport data within a SP's network. In a typical configura-tion, a customer/subscriber couples its dispersed networks to an edge router configured to enable access to the SP's network. The SP's network may comprise various switches configured to switch traffic between the various edge routers. The routers typically operate at layer-3 (L3) of a communications protocol stack, which is the net-s work layer of the Open Systems Interconnect (OSI) reference model. The switches typically operate at layer-2 (L2) of the communications protocol stack, which is the data-link layer of the OSI reference model.
SPs often provide multiple services to their customers/subscribers, such as FR
services and ATM services. Here, an SP may employ parallel or "overlay"
networks ro wherein each network is configured to provide a specific service. For example, a SP
that provides a FR service and an ATM service may employ two separate networks where each network provides a separate service. Providing separate networks for sepa-rate services, however, is often costly and difficult to manage; thus, many SPs employ a "converged network" to provide various services. A converged network is a network is that converges various different services onto a single network, such as an optical net-work. Converged networks are often called "transport networks" in that they usually act only to transport various services' data from one point in the SP's network to an-other point in the network.
One way to implement a converged network is to employ a technique called 20 "pseudo wire emulation edge-to-edge" (PWE3). PWE3 is described in S.
Bryant et al., "PWE3 Architecture," draft-ie#:pwe3-arch-06.bct available from the Internet Engineer-ing Task Force (IETF), http://wwwietf.org. PWE3 is a technique that emulates the es-sential attributes of a service, such as ATM or FR, over a packet-switched network (PSN), such as a Synchronous Optical NETwork/Synchronous Digital Hierarchy 25 (SONET/SDH) network, which acts as a transport network. PWE3 utilizes pseudo wires (PWs), which are mechanisms that emulate the essential attributes of a particular service.
In a typical PWE3 arrangement, a customer's data is encapsulated at the ingress point (e.g., an "ingress" edge router") in the SP's network. The encapsulated data is 30 transported over the SP's transport network via a predefined path, such as an IP path or a Multiprotocol Label Switching (MPLS) path, to an egress point in the SP's network
- 3 -(e.g., an "egress" edge router). The data is decapsulated at the egress point and deliv-ered to the customer's remote network coupled to the egress point.
One problem associated with PWE3 implementations is that they often require both data-link layer and network layer support. For example, a network that employs s the MPLS protocol to transfer data across PWs in a PWE3 network typically requires establishing a L3 infrastructure that may include defining sub-networks and implement-ing various routing and distribution protocols, such as the Open Shortest Path First (OSFF) routing protocol and the Label Distribution Protocol (LDP). Setting up a L3 infrastructure is often arduous and may require specialty knowledge of the protocols io utilized in the infrastructure. SPs typically utilize L2 transport networks that often do not require a L3 infrastructure in order to operate. That is, these networks often trans-port data through the network using L2 switching techniques. To provide PW
support as defined by PWE3, a SP would have to develop a L3 infrastructure within its net-work. Providing such an infrastructure may be costly.
The present invention overcomes shortcomings associated with prior techniques by providing a technique for supporting pseudo wires, contained in a data network comprising a plurality of intermediate nodes, in a manner that does not require a layer-3 (L3) infrastructure.
20 Briefly, a controller coupled to the intermediate nodes acquires topology infor-mation associated with the data network's topology. The topology information may include pseudo wire definitions, ingress and egress interface information, ingress and egress labels, and so on. The controller uses the topology information to generate a transport database containing information that defines, inter alia, paths associated with 25 e.g., pseudo wires in the network. The data base information is distributed to the in-termediate nodes, which utilize the information to process data packets acquired by the nodes including switching data along paths defined by the pseudo wires.
In the illustrated embodiment, a service provider's (SP) data network comprises a transport controller coupled to a plurality of intermediate nodes. The intermediate 30 nodes comprise a packet-switched transport network used to transport data provided by
One problem associated with PWE3 implementations is that they often require both data-link layer and network layer support. For example, a network that employs s the MPLS protocol to transfer data across PWs in a PWE3 network typically requires establishing a L3 infrastructure that may include defining sub-networks and implement-ing various routing and distribution protocols, such as the Open Shortest Path First (OSFF) routing protocol and the Label Distribution Protocol (LDP). Setting up a L3 infrastructure is often arduous and may require specialty knowledge of the protocols io utilized in the infrastructure. SPs typically utilize L2 transport networks that often do not require a L3 infrastructure in order to operate. That is, these networks often trans-port data through the network using L2 switching techniques. To provide PW
support as defined by PWE3, a SP would have to develop a L3 infrastructure within its net-work. Providing such an infrastructure may be costly.
The present invention overcomes shortcomings associated with prior techniques by providing a technique for supporting pseudo wires, contained in a data network comprising a plurality of intermediate nodes, in a manner that does not require a layer-3 (L3) infrastructure.
20 Briefly, a controller coupled to the intermediate nodes acquires topology infor-mation associated with the data network's topology. The topology information may include pseudo wire definitions, ingress and egress interface information, ingress and egress labels, and so on. The controller uses the topology information to generate a transport database containing information that defines, inter alia, paths associated with 25 e.g., pseudo wires in the network. The data base information is distributed to the in-termediate nodes, which utilize the information to process data packets acquired by the nodes including switching data along paths defined by the pseudo wires.
In the illustrated embodiment, a service provider's (SP) data network comprises a transport controller coupled to a plurality of intermediate nodes. The intermediate 30 nodes comprise a packet-switched transport network used to transport data provided by
- 4 -customers/subscribers to the SP's network. The transport controller acquires topology information of the transport network including information associated with pseudo wires in the network and uses this information to generate a transport database contain-ing information related to the pseudo wires. Information contained in the transport da-tabase is distributed to the intermediate nodes, which use the information to configure a packet-processing engine (PPE) contained in each intermediate node to switch data along paths defined by the pseudo wires.
A data packet acquired from the transport network by the intermediate node is transferred to the PPE, which passes the packet through various processing stages and to eventually to an egress interface for transfer onto the transport network. Specifically, the packet enters the PPE and is transferred to a classifying stage, which associates the packet with an ingress key. The packet and the ingress key are then transferred to a rate control stage, which polices the packet based on various information rate parameters.
Next, the packet and the ingress key are transferred to a data cross connect stage which is "switches" the packet to an egress interface by identifying and associating an egress key with the packet. The egress key and the packet are then transferred to an egress encapsulation stage where the packet is encapsulated with, e.g., label information, if any. Finally, the packet is transferred to a traffic management stage, which schedules the packet for transfer to the egress interface logic for transfer onto the data network.
20 In sum, the inventive technique incorporates a transport controller to distribute a transport database containing information associated with transporting data through the network to intermediate nodes in the network, via pseudo wires. The intermediate nodes incorporate a PPE, which switches the packets based on information contained in the transport database. Advantageously, the inventive technique obviates the need to 25 establish a L3 infrastructure in order to support pseudo wires in a network.
A data packet acquired from the transport network by the intermediate node is transferred to the PPE, which passes the packet through various processing stages and to eventually to an egress interface for transfer onto the transport network. Specifically, the packet enters the PPE and is transferred to a classifying stage, which associates the packet with an ingress key. The packet and the ingress key are then transferred to a rate control stage, which polices the packet based on various information rate parameters.
Next, the packet and the ingress key are transferred to a data cross connect stage which is "switches" the packet to an egress interface by identifying and associating an egress key with the packet. The egress key and the packet are then transferred to an egress encapsulation stage where the packet is encapsulated with, e.g., label information, if any. Finally, the packet is transferred to a traffic management stage, which schedules the packet for transfer to the egress interface logic for transfer onto the data network.
20 In sum, the inventive technique incorporates a transport controller to distribute a transport database containing information associated with transporting data through the network to intermediate nodes in the network, via pseudo wires. The intermediate nodes incorporate a PPE, which switches the packets based on information contained in the transport database. Advantageously, the inventive technique obviates the need to 25 establish a L3 infrastructure in order to support pseudo wires in a network.
- 5 -BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numbers indicate identical or functionally similar elements:
Fig. 1 is a schematic block diagram of a data net-work that may be advanta-geously used with the present invention;
Fig. 2 is a high-level partial schematic block diagram of a transport network controller that may be advantageously used with the present invention;
Fig. 3 is a partial schematic block diagram of a transport database that may be Fig. 4 is a partial schematic block diagram of an intermediate node that may be advantageously used with the present invention;
Fig. 5 is a partial schematic block diagram of a line card that may be advanta-geously used with the present invention;
Fig. 6 is a partial schematic block diagram of a packet-processing engine that may be advantageously used with the present invention;
Fig. 7 is a schematic block diagram of a data cross connect database that may be advantageously used with the present invention;
Fig. 8 is a schematic block diagram of an egress encapsulation database that Fig. 9 is a schematic block diagram of a transport label that may be advanta-geously used with the present invention;
Fig. 10 is a schematic block diagram of a generic framing procedure (GFP) Syn-chronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) packet in Fig. 11 is a flow diagram of a sequence of steps that may be advantageously used to configure an intermediate node in accordance with the inventive technique; and Fig. 12 is a flow diagram of a sequence of steps that may be advantageously used to process a data packet in accordance with the inventive technique.
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numbers indicate identical or functionally similar elements:
Fig. 1 is a schematic block diagram of a data net-work that may be advanta-geously used with the present invention;
Fig. 2 is a high-level partial schematic block diagram of a transport network controller that may be advantageously used with the present invention;
Fig. 3 is a partial schematic block diagram of a transport database that may be Fig. 4 is a partial schematic block diagram of an intermediate node that may be advantageously used with the present invention;
Fig. 5 is a partial schematic block diagram of a line card that may be advanta-geously used with the present invention;
Fig. 6 is a partial schematic block diagram of a packet-processing engine that may be advantageously used with the present invention;
Fig. 7 is a schematic block diagram of a data cross connect database that may be advantageously used with the present invention;
Fig. 8 is a schematic block diagram of an egress encapsulation database that Fig. 9 is a schematic block diagram of a transport label that may be advanta-geously used with the present invention;
Fig. 10 is a schematic block diagram of a generic framing procedure (GFP) Syn-chronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) packet in Fig. 11 is a flow diagram of a sequence of steps that may be advantageously used to configure an intermediate node in accordance with the inventive technique; and Fig. 12 is a flow diagram of a sequence of steps that may be advantageously used to process a data packet in accordance with the inventive technique.
- 6 -DETAILED DESCRIPTION OF AN ILLUSTRATIVE
EMBODIMENT
Fig. 1 is a schematic block diagram of a data network 100 that may be advanta-geously used with the present invention. Network 100 comprises a plurality of end nodes 110 coupled to customer edge (CE) nodes 120 via local area network (LAN) connections 170. The CE nodes 120 are coupled to a service provider (SP) network 110 via data links 180, which illustratively are Ethernet links. The SP
network 110 includes a transport network illustratively implemented as a packet-switch network (PSN) comprising a plurality of intermediate nodes 400 coupled via optical links 160.
io Network 110 also includes a "local" network comprising a transport controller 200 coupled to the intermediate nodes 400 via local network links 190. The local network enables the transport controller 200 to communicate with the intermediate nodes 400.
These intemetworked nodes in network 100 communicate by exchanging data packets according to a predefined set of protocols, such as the Transmission Control Proto-col/Internet Protocol (TCP/IP) and the Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) protocol. A protocol, as used herein, is a set of for-mal rules describing how to transfer data between two entities (e.g., intermediate nodes 400) in a data network.
The transport controller 200, inter alia, maintains network topology information that describes the data network's topology. Illustratively, the transport control acquires the topology information from a user 105 via, e.g., a network management system (NMS) operating on the transport controller 200. The topology information may in-clude definitions of pseudo wires defined in the network 100. The transport controller 200 uses this information to generate a transport database (described below) that is transferred to the various intermediate nodes 400. It should be noted that other means may be used acquire the network's topology information, such as downloading the in-formation to the transport controller 200. It should be further noted that the transport controller 200 may be configured as a transport circuit management system that is con-figured to manage various transport circuits in, e.g., the SP's network 110.
Fig. 2 is a schematic block diagram of a transport controller 200 that may be advantageously used with the present invention. Controller 200 comprises a processor
EMBODIMENT
Fig. 1 is a schematic block diagram of a data network 100 that may be advanta-geously used with the present invention. Network 100 comprises a plurality of end nodes 110 coupled to customer edge (CE) nodes 120 via local area network (LAN) connections 170. The CE nodes 120 are coupled to a service provider (SP) network 110 via data links 180, which illustratively are Ethernet links. The SP
network 110 includes a transport network illustratively implemented as a packet-switch network (PSN) comprising a plurality of intermediate nodes 400 coupled via optical links 160.
io Network 110 also includes a "local" network comprising a transport controller 200 coupled to the intermediate nodes 400 via local network links 190. The local network enables the transport controller 200 to communicate with the intermediate nodes 400.
These intemetworked nodes in network 100 communicate by exchanging data packets according to a predefined set of protocols, such as the Transmission Control Proto-col/Internet Protocol (TCP/IP) and the Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) protocol. A protocol, as used herein, is a set of for-mal rules describing how to transfer data between two entities (e.g., intermediate nodes 400) in a data network.
The transport controller 200, inter alia, maintains network topology information that describes the data network's topology. Illustratively, the transport control acquires the topology information from a user 105 via, e.g., a network management system (NMS) operating on the transport controller 200. The topology information may in-clude definitions of pseudo wires defined in the network 100. The transport controller 200 uses this information to generate a transport database (described below) that is transferred to the various intermediate nodes 400. It should be noted that other means may be used acquire the network's topology information, such as downloading the in-formation to the transport controller 200. It should be further noted that the transport controller 200 may be configured as a transport circuit management system that is con-figured to manage various transport circuits in, e.g., the SP's network 110.
Fig. 2 is a schematic block diagram of a transport controller 200 that may be advantageously used with the present invention. Controller 200 comprises a processor
-7-220 coupled to various input/output (I/0) devices 230 and a network interface card (NIC) 240, via I/O bus 270, and to memory 250. The I/O devices 230 may include a display unit, such as a monitor, a keyboard, a mouse, and various storage devices, such as disk units. The NIC 240 contains logic that enables transport controller 200 to inter-s face with the network 100 and communicate with the various intermediate nodes 400 via, e.g., links 190. An example of a system that may be used to implement the trans-port controller 200 is a personal computer (PC), such as a PC that is compatible with an International Business Machines (IBM) PC.
It should be noted that in the illustrated embodiment, links 190 comprise a pre-to ferred "out-of-band" network that enables communication between the transport con-troller 200 and the intermediate nodes 400. However, the inventive technique may be used in networks that employ "in-band" communication techniques to transfer data be-tween the transport controller 200 and the intermediate nodes 400.
Memory 250 is a computer readable medium containing operating system 254, ts one or more software processes (PROCs) 256, network topology data structure 252 and transport database 300. Operating system 254 contains computer executable instruc-tions executed by processor 220 to functionally organize the transport controller 200 by, inter cilia, invoking operations in support of software processes 256 executing on the transport controller 200. These processes 256 may include software functions that zo implement various protocols supported by the transport controller 200, as well as proc-esses that implement aspects of the inventive technique. It should be noted that other computer readable mediums, such as disk storage devices and flash memory devices, may be used to store computer executable instructions that implement aspects of the present invention.
25 The network topology data structure 252 holds information that illustratively describes the topology of the SP's network 110. This topology information may in-clude descriptions of pseudo wires contained in the network 110 and defined, e.g., by a user logged into the transport controller 200. The transport controller 200 uses the to-pology information to generate transport database 300 containing, inter alio, pseudo 30 wire path information that is used by the intermediate nodes 400 to illustratively trans-fer data through the SP's network 110.
Fig. 3 is partial schematic block diagram of a transport database 300 that may be advantageously used with the present invention. Database 300 is illustratively a table comprising one or more entries 310. Each entry 3190 represents a mapping of an ingress interface/label combination with an egress interface/label combination and comprises an ingress label field 320, The ingress label field 320 holds a value that represents a label associated with an input As used herein, a sub-interface refers to a portion of an interface. For example, 1 100 megabits-per-second(Mbps) Ethernet interface may be apportioned into ten sub-interfaces of 10 A pseudo wire path may be defined by one or more entries 310 in the transport database 300. Entries 310 associated with pseudo wire paths at a particular node 400 are distributed to that node 400. The node 400 uses this information to configure one or more packet-processing
It should be noted that in the illustrated embodiment, links 190 comprise a pre-to ferred "out-of-band" network that enables communication between the transport con-troller 200 and the intermediate nodes 400. However, the inventive technique may be used in networks that employ "in-band" communication techniques to transfer data be-tween the transport controller 200 and the intermediate nodes 400.
Memory 250 is a computer readable medium containing operating system 254, ts one or more software processes (PROCs) 256, network topology data structure 252 and transport database 300. Operating system 254 contains computer executable instruc-tions executed by processor 220 to functionally organize the transport controller 200 by, inter cilia, invoking operations in support of software processes 256 executing on the transport controller 200. These processes 256 may include software functions that zo implement various protocols supported by the transport controller 200, as well as proc-esses that implement aspects of the inventive technique. It should be noted that other computer readable mediums, such as disk storage devices and flash memory devices, may be used to store computer executable instructions that implement aspects of the present invention.
25 The network topology data structure 252 holds information that illustratively describes the topology of the SP's network 110. This topology information may in-clude descriptions of pseudo wires contained in the network 110 and defined, e.g., by a user logged into the transport controller 200. The transport controller 200 uses the to-pology information to generate transport database 300 containing, inter alio, pseudo 30 wire path information that is used by the intermediate nodes 400 to illustratively trans-fer data through the SP's network 110.
Fig. 3 is partial schematic block diagram of a transport database 300 that may be advantageously used with the present invention. Database 300 is illustratively a table comprising one or more entries 310. Each entry 3190 represents a mapping of an ingress interface/label combination with an egress interface/label combination and comprises an ingress label field 320, The ingress label field 320 holds a value that represents a label associated with an input As used herein, a sub-interface refers to a portion of an interface. For example, 1 100 megabits-per-second(Mbps) Ethernet interface may be apportioned into ten sub-interfaces of 10 A pseudo wire path may be defined by one or more entries 310 in the transport database 300. Entries 310 associated with pseudo wire paths at a particular node 400 are distributed to that node 400. The node 400 uses this information to configure one or more packet-processing
8
- 9 -taining one or more line cards 500, a network interface card (NIC) 450 and a supervisor engine 460 interconnected by a backplane 440. The backplane 440 comprises a point-to-point interconnect bus that interconnects the various cards and allows data and sig-nals to be transferred from one card to another. The supervisor engine 460 contains a processor 462 and memory 464 configured, inter alba, to enable the intermediate node 400 to process transport database information 300 acquired from the transport control-ler 200 and distribute the transport database information 300 to the various PPEs con-tained in node 400 in accordance with the inventive technique. The NIC 450 contains logic that enables the intermediate node 400 to transfer data between the intermediate to node 400 and the transport controller 200 via a link 190 to the transport controller 200.
The line cards 500 couple the intermediate node 400 with the network 100 and are, inter cilia, configured to transfer and acquire data to and from the network via egress interfaces 417 and ingress interfaces 415, respectively, using various protocols, such as the SONET/SDH protocol, in accordance with the inventive technique.
Fig. 5 is a partial schematic block diagram of a line card 500 that may be advantageously used with the present invention. Line card 500 comprises ingress interface logic 520 and egress interface logic 530 coupled to a PPE 600, which is further coupled to backplane interface logic 560. The backplane interface logic 560 contains interface circuitry that interfaces the line card 500 to the backplane 440 and enables the line card 500 to trans-fer and acquire data to and from other cards coupled to the backplane 440. The ingress interface logic 520 and egress interface logic 530 interface the line card to the network 100 via the ingress 415 and egress 417 interfaces, respectively, and enable the line card 500 to transfer and acquire data to and from the network 100. To that end, logic 520 and 530 comprise conventional interface circuitry that may incorporate the signal, elec-trical and mechanical characteristics, and interchange circuits, needed to interface line card 500 with the network's physical media and protocols running over that media.
The PPE 600 contains logic that processes data (packets) acquired by the in-gress interface logic 520. Fig. 6 is a schematic block diagram of a PPE 600 that may be advantageously used with the present invention. Packets are processed by various stages contained in the PPE including a classifying stage, rate control stage, data cross connect stage, egress encapsulation stage and traffic management stage implemented as
The line cards 500 couple the intermediate node 400 with the network 100 and are, inter cilia, configured to transfer and acquire data to and from the network via egress interfaces 417 and ingress interfaces 415, respectively, using various protocols, such as the SONET/SDH protocol, in accordance with the inventive technique.
Fig. 5 is a partial schematic block diagram of a line card 500 that may be advantageously used with the present invention. Line card 500 comprises ingress interface logic 520 and egress interface logic 530 coupled to a PPE 600, which is further coupled to backplane interface logic 560. The backplane interface logic 560 contains interface circuitry that interfaces the line card 500 to the backplane 440 and enables the line card 500 to trans-fer and acquire data to and from other cards coupled to the backplane 440. The ingress interface logic 520 and egress interface logic 530 interface the line card to the network 100 via the ingress 415 and egress 417 interfaces, respectively, and enable the line card 500 to transfer and acquire data to and from the network 100. To that end, logic 520 and 530 comprise conventional interface circuitry that may incorporate the signal, elec-trical and mechanical characteristics, and interchange circuits, needed to interface line card 500 with the network's physical media and protocols running over that media.
The PPE 600 contains logic that processes data (packets) acquired by the in-gress interface logic 520. Fig. 6 is a schematic block diagram of a PPE 600 that may be advantageously used with the present invention. Packets are processed by various stages contained in the PPE including a classifying stage, rate control stage, data cross connect stage, egress encapsulation stage and traffic management stage implemented as
- 10-, classifier 620, rate controller 630, data cross connect 650, egress encapsulator 660 and traffic manager 670, respectively.
The classifier 620 contains circuitry configured to classify traffic acquired by the ingress interface logic 520 as belonging to asub-interface by, e.g., examining head-s ers in packets received on the interface. Specifically, classifier 620 examines a packet's contents and determines a virtual port identifier (ID) associated with the packet. The virtual port ID identifies the sub-interface associated with the packet. The classifier 620 derives an ingress key from the virtual port ID and associates the ingress key with the packet. The packet and its ingress key are then transferred to the rate con-ic) troller 630.
The rate controller 630 contains circuitry configured to police a packet acquired by a particular sub-interface associated with the packet. Illustratively, the policing ac-tion is controlled by various parameters associated with the rate controller including a committed information rate (CIR), a CIR burst size, a peak information rate (PIR) and a is PIR burst size. Packets that adhere to a rate controller's parameters are transferred to the data cross connect logic 650 for further processing.
The data cross connect 650 contRins circuitry that "switches" a packet from an ingress interface 415 to an egress interface 417. The data cross connect 650 contains a cross connect database (XC DB) 700 configured to hold information that establishes a 20 relationship between an ingress interface and an egress interface. The information con- , tained,in XC DB 700 is derived from transport database information 300 acquired from the transport controller 200 (Fig. 2). As noted above, this information includes labels that define, e.g., paths associated with pseudo wires. Specifically, XC DB 700 holds information that associates an ingress interface's ingress key with an egress interface's 25 egress key. The egress and ingress key values are derived from egress and ingress in-terface information, respectively, contained in the transport database information ac-quired by the node 400.
Fig. 7 is a schematic block diagram of XC DB 700 illustrated as a table contain-ing one or more entries 710 wherein each entry 710 contains an ingress key field 720 30 and an egress key field 740. The ingress key field 720 holds an ingress key value that is derived from the ingress interface information contained in the transport database
The classifier 620 contains circuitry configured to classify traffic acquired by the ingress interface logic 520 as belonging to asub-interface by, e.g., examining head-s ers in packets received on the interface. Specifically, classifier 620 examines a packet's contents and determines a virtual port identifier (ID) associated with the packet. The virtual port ID identifies the sub-interface associated with the packet. The classifier 620 derives an ingress key from the virtual port ID and associates the ingress key with the packet. The packet and its ingress key are then transferred to the rate con-ic) troller 630.
The rate controller 630 contains circuitry configured to police a packet acquired by a particular sub-interface associated with the packet. Illustratively, the policing ac-tion is controlled by various parameters associated with the rate controller including a committed information rate (CIR), a CIR burst size, a peak information rate (PIR) and a is PIR burst size. Packets that adhere to a rate controller's parameters are transferred to the data cross connect logic 650 for further processing.
The data cross connect 650 contRins circuitry that "switches" a packet from an ingress interface 415 to an egress interface 417. The data cross connect 650 contains a cross connect database (XC DB) 700 configured to hold information that establishes a 20 relationship between an ingress interface and an egress interface. The information con- , tained,in XC DB 700 is derived from transport database information 300 acquired from the transport controller 200 (Fig. 2). As noted above, this information includes labels that define, e.g., paths associated with pseudo wires. Specifically, XC DB 700 holds information that associates an ingress interface's ingress key with an egress interface's 25 egress key. The egress and ingress key values are derived from egress and ingress in-terface information, respectively, contained in the transport database information ac-quired by the node 400.
Fig. 7 is a schematic block diagram of XC DB 700 illustrated as a table contain-ing one or more entries 710 wherein each entry 710 contains an ingress key field 720 30 and an egress key field 740. The ingress key field 720 holds an ingress key value that is derived from the ingress interface information contained in the transport database
-11 -information distributed to the node 400. Likewise, the egress key field 740 holds an egress key value that is derived from the egress interface information contained in the transport database information distributed to the node 400.
Referring also to Fig. 6., the data cross connect 650 switches packets by deter-s mining if an ingress key associated with the packet matches an ingress key 720 con-tained in a XC DB entry 710. If so, the packet is "switched" to the egress interface 417 associated with the matching entry's egress key 740 by associating the packet with the egress key 740. The packet and egress key 740 are then transferred to the egress en-capsulator 660.
The egress encapsulator 660 contains circuitry configured to encapsulate (if necessary) the packet before it is transferred onto the network. This encapsulation may include, e.g., inserting a Multiprotocol Label Switching (MPLS) header, an IEEE
802.1Q header or a transport label header (discussed below) into the packet.
Egress encapsulation logic 660 contains an encapsulation database (ENCAP DB) 800 that is is used to determine the form of encapsulation (if any) that is performed on the packet.
Fig. 8 is a schematic block diagram of ENCAP DB 800 configured as a table compris-ing one or more entries 810. Entry 810 contains an egress key field 820 that holds a value that represents an egress key and a header field 840 that holds information that specifies header information (if any) that is inserted into the packet.
Specifically, the egress key 740 associated with the packet is compared with egress keys 820 contained in the ENCAP DB 800 to determine if an entry 810 contains an egress key 820 that matches the packet's egress key 740. If so, the packet is encap-sulated in accordance with the header information specified in the header field 840.
Otherwise, if the packet's egress key 740 does not match any of the egress keys 820 contained in the ENCAP DB, no encapsulation is performed.
After the encapsulation (if any) is complete, the packet is transferred to the traf-fic manager 670 which schedules the packet for transfer onto the network.
Specifically, the packet is enqueued onto an output queue (not shown) associated with the packet's egress key 740. The packet is then scheduled for transfer onto a particular egress inter-face 417 associated with the output queue.
Referring also to Fig. 6., the data cross connect 650 switches packets by deter-s mining if an ingress key associated with the packet matches an ingress key 720 con-tained in a XC DB entry 710. If so, the packet is "switched" to the egress interface 417 associated with the matching entry's egress key 740 by associating the packet with the egress key 740. The packet and egress key 740 are then transferred to the egress en-capsulator 660.
The egress encapsulator 660 contains circuitry configured to encapsulate (if necessary) the packet before it is transferred onto the network. This encapsulation may include, e.g., inserting a Multiprotocol Label Switching (MPLS) header, an IEEE
802.1Q header or a transport label header (discussed below) into the packet.
Egress encapsulation logic 660 contains an encapsulation database (ENCAP DB) 800 that is is used to determine the form of encapsulation (if any) that is performed on the packet.
Fig. 8 is a schematic block diagram of ENCAP DB 800 configured as a table compris-ing one or more entries 810. Entry 810 contains an egress key field 820 that holds a value that represents an egress key and a header field 840 that holds information that specifies header information (if any) that is inserted into the packet.
Specifically, the egress key 740 associated with the packet is compared with egress keys 820 contained in the ENCAP DB 800 to determine if an entry 810 contains an egress key 820 that matches the packet's egress key 740. If so, the packet is encap-sulated in accordance with the header information specified in the header field 840.
Otherwise, if the packet's egress key 740 does not match any of the egress keys 820 contained in the ENCAP DB, no encapsulation is performed.
After the encapsulation (if any) is complete, the packet is transferred to the traf-fic manager 670 which schedules the packet for transfer onto the network.
Specifically, the packet is enqueued onto an output queue (not shown) associated with the packet's egress key 740. The packet is then scheduled for transfer onto a particular egress inter-face 417 associated with the output queue.
- 12 -It should be noted that the functions performed by various stages in the PPE
may be implemented, either in whole or in part, using computer executable instructions that are stored on a computer readable medium, such as a random-access memory or a disk. Further, one skilled in the art would know that electromagnetic signals may be s generated to carry computer executable instructions that implement aspects of the pre-sent invention over, e.g., a wireless data link or a data network such as the Internet.
As noted above, a packet may be encapsulated with a transport label header.
= Fig. 9 illustrates a transport label header 900 that may be advantageously used with the present invention. Header 900 comprises a label field 920, a priority field 930, a stack (S) field 940, a discard eligible (DE) field 950, a frame check (FC) field 960 and a time-to-live (TTL) field 970. The label field 920 is illustratively a 20-bit field that con-tains a value that represents a label that used for switching the packet through the net-work 100. The priority field 930 is illustratively a 3-bit field that contains a value that establishes a priority associated with the packet. The S field 940 is illustratively a one-is bit field that contains a value that if set indicates that the label field 920 contains the last label in a stack of labels contained in the packet. The DE field 950 is illustratively a one-bit field that contains a value that if set to a one indicates the packet is eligible for discard. The FC field 960 is illustratively a one-bit field that contains a value that if set indicates the payload of the packet contains a frame check sequence (FCS). The TTL
field 970 is illustratively a 6-bit field that contains a value that represents a time-to-live value associated with the packet.
In accordance with the inventive technique, packets are encapsulated by placing a transport label header 900 in a frame containing the packet. Fig. 10 illustrates a ge-neric framing procedure (GFP) SONET/SDH frame 1000 encapsulated in accordance with the present invention. Frame 1000 contains a protocol data unit (PDU) length in-dicator (PL) field 1020, a core header error control (cHEC) field 1030, a payload type identifier (PTI) field 1040, a payload FCS identifier (PFI) field 1042, an extension header identifier (E)a) field 1044, a user payload identifier (UPI) field 1046, a type header error control (tHEC) field 1050, a transport label stack field 1060, a payload field 1070 and an optional payload FCS field 1080.
may be implemented, either in whole or in part, using computer executable instructions that are stored on a computer readable medium, such as a random-access memory or a disk. Further, one skilled in the art would know that electromagnetic signals may be s generated to carry computer executable instructions that implement aspects of the pre-sent invention over, e.g., a wireless data link or a data network such as the Internet.
As noted above, a packet may be encapsulated with a transport label header.
= Fig. 9 illustrates a transport label header 900 that may be advantageously used with the present invention. Header 900 comprises a label field 920, a priority field 930, a stack (S) field 940, a discard eligible (DE) field 950, a frame check (FC) field 960 and a time-to-live (TTL) field 970. The label field 920 is illustratively a 20-bit field that con-tains a value that represents a label that used for switching the packet through the net-work 100. The priority field 930 is illustratively a 3-bit field that contains a value that establishes a priority associated with the packet. The S field 940 is illustratively a one-is bit field that contains a value that if set indicates that the label field 920 contains the last label in a stack of labels contained in the packet. The DE field 950 is illustratively a one-bit field that contains a value that if set to a one indicates the packet is eligible for discard. The FC field 960 is illustratively a one-bit field that contains a value that if set indicates the payload of the packet contains a frame check sequence (FCS). The TTL
field 970 is illustratively a 6-bit field that contains a value that represents a time-to-live value associated with the packet.
In accordance with the inventive technique, packets are encapsulated by placing a transport label header 900 in a frame containing the packet. Fig. 10 illustrates a ge-neric framing procedure (GFP) SONET/SDH frame 1000 encapsulated in accordance with the present invention. Frame 1000 contains a protocol data unit (PDU) length in-dicator (PL) field 1020, a core header error control (cHEC) field 1030, a payload type identifier (PTI) field 1040, a payload FCS identifier (PFI) field 1042, an extension header identifier (E)a) field 1044, a user payload identifier (UPI) field 1046, a type header error control (tHEC) field 1050, a transport label stack field 1060, a payload field 1070 and an optional payload FCS field 1080.
-13 -=
A OFF' frame 1000 may be classified as containing a core header and a payload area wherein the core header comprises the PLI field 1020 and the cHEC field and the payload area comprises the remaining fields of the GFP frame. The PLI
field 1020 contains a value that indicates a number of bytes in the payload area of the GFP
frame. The cliEC field 1030 contains a value that represents a cyclic redundancy check (CRC) of the core header. The P11 field 1040 contains an identifier that identi-fies the content and format of the GFP payload. The PFI field contains an indicator that indicates whether the payload field 1070 is followed by a payload FCS field 1080. The EXI field 1044 contains an identifier that identifies an extension header. The UPI field io 1046 contains an identifier that identifies the payload 1070. The tHEC
field 1050 con-tains a CRC value that protects the integrity of the contents of the P17 1040, PFI 1042, MCI 1044, UPI 1046 and tHEC 1050 fields. The transport label stack field 1060 con-tains a "stack" of one or more labels which may include e.g., MF'LS labels and/or a transport label 900. The payload field 1070 contains user data information and the FCS
is field 1080 contains a CRC value that protects the contents of the payload field 1070.
The transport controller 200 acquires network topology information, generates the transport database 300 from this information, and distributes the transport database information to the various intermediate nodes 400 in the network. The intermediate nodes 400 use the transport database information to configure the PPE 600.
Fig. 11 is a 20 flow diagram of a sequence of steps that may be used to generate and distribute the transport database information, and use the transport database information to configure the PPE 600 in accordance with the inventive technique.
The sequence begins at Step 1105 and proceeds to Step 1110 where the trans-port controller 200 acquires network topology information that describes aspects of the 2.5 network 100 and places the information in the network topology data structure 252.
The topology information may include identifiers that identify nodes contained in the network, e.g., nodes 400, point-to-point connections between various nodes in the net-work, interfaces associated with these point-to-point connections, labels associated with the interfaces, one or more definitions of pseudo wires contained in the network, and so 30 on. Illustratively, a user using a network management application running on the trans-port controller 200 specifies the topology information. Alternatively, all or portions of
A OFF' frame 1000 may be classified as containing a core header and a payload area wherein the core header comprises the PLI field 1020 and the cHEC field and the payload area comprises the remaining fields of the GFP frame. The PLI
field 1020 contains a value that indicates a number of bytes in the payload area of the GFP
frame. The cliEC field 1030 contains a value that represents a cyclic redundancy check (CRC) of the core header. The P11 field 1040 contains an identifier that identi-fies the content and format of the GFP payload. The PFI field contains an indicator that indicates whether the payload field 1070 is followed by a payload FCS field 1080. The EXI field 1044 contains an identifier that identifies an extension header. The UPI field io 1046 contains an identifier that identifies the payload 1070. The tHEC
field 1050 con-tains a CRC value that protects the integrity of the contents of the P17 1040, PFI 1042, MCI 1044, UPI 1046 and tHEC 1050 fields. The transport label stack field 1060 con-tains a "stack" of one or more labels which may include e.g., MF'LS labels and/or a transport label 900. The payload field 1070 contains user data information and the FCS
is field 1080 contains a CRC value that protects the contents of the payload field 1070.
The transport controller 200 acquires network topology information, generates the transport database 300 from this information, and distributes the transport database information to the various intermediate nodes 400 in the network. The intermediate nodes 400 use the transport database information to configure the PPE 600.
Fig. 11 is a 20 flow diagram of a sequence of steps that may be used to generate and distribute the transport database information, and use the transport database information to configure the PPE 600 in accordance with the inventive technique.
The sequence begins at Step 1105 and proceeds to Step 1110 where the trans-port controller 200 acquires network topology information that describes aspects of the 2.5 network 100 and places the information in the network topology data structure 252.
The topology information may include identifiers that identify nodes contained in the network, e.g., nodes 400, point-to-point connections between various nodes in the net-work, interfaces associated with these point-to-point connections, labels associated with the interfaces, one or more definitions of pseudo wires contained in the network, and so 30 on. Illustratively, a user using a network management application running on the trans-port controller 200 specifies the topology information. Alternatively, all or portions of
-14 -this information may be acquired from another system in communication with the transport controller 200, or a protocol running on the transport controller 200 that is capable of gathering all or some of this information, from e.g., the nodes 400.
At Step 1130, the transport controller 200 generates transport database 300 from s the network topology information 252. Specifically, transport controller examines the network topology information 252 and determines label and interface information for paths, such as pseudo wires, defined in the topological information. The transport con-troller 200 then generates entries in the transport database 300 that define these paths, including identifiers that identify interfaces and labels associated with the paths.
At Step 1140, the transport controller 200 distributes the transport database in-formation 300 to the intermediate nodes 400, illustratively, via the local network links 190.
At Step 1150 and 1160, an intermediate node 400 acquires the transport data-base information and configures the PPE 600 using the information.
Specifically, the ts intermediate node 400 generates ingress keys and egress keys from the ingress interface and egress interface information, respectively, and uses the generated key information to configure the classifier logic 620, data cross connect 650 and egress encapsulator 660 for use by these components, in a manner as described above. Node 400 also uses the relationship established by the ingress and egress interfaces in the transport data-base information to generate relationships between the ingress and the egress keys that are used by the PPE's various components. In addition, the ingress label and egress label information may be used by the egress encapsulation logic to determine labels 900 placed in a frame's label stack, such as transport label stack 1060. At Step 1195 the sequence ends.
Illustratively, an intermediate node 400 that acquires a packet transfers the packet to the PPE 600 for further processing. Fig. 12 is a sequence of steps that may be used to process a packet at an intermediate node 400 in accordance with the inventive technique. The sequence begins at Step 1205 and proceeds to Step 1210 where an in-termediate node 400 acquires a packet from another intermediate node 400 via a data 3o link 190 or from a customer edge node 120 via a data link 180. At Step 1230, the clas-sifier logic 620 examines the packet and associates an ingress key with the packet based
At Step 1130, the transport controller 200 generates transport database 300 from s the network topology information 252. Specifically, transport controller examines the network topology information 252 and determines label and interface information for paths, such as pseudo wires, defined in the topological information. The transport con-troller 200 then generates entries in the transport database 300 that define these paths, including identifiers that identify interfaces and labels associated with the paths.
At Step 1140, the transport controller 200 distributes the transport database in-formation 300 to the intermediate nodes 400, illustratively, via the local network links 190.
At Step 1150 and 1160, an intermediate node 400 acquires the transport data-base information and configures the PPE 600 using the information.
Specifically, the ts intermediate node 400 generates ingress keys and egress keys from the ingress interface and egress interface information, respectively, and uses the generated key information to configure the classifier logic 620, data cross connect 650 and egress encapsulator 660 for use by these components, in a manner as described above. Node 400 also uses the relationship established by the ingress and egress interfaces in the transport data-base information to generate relationships between the ingress and the egress keys that are used by the PPE's various components. In addition, the ingress label and egress label information may be used by the egress encapsulation logic to determine labels 900 placed in a frame's label stack, such as transport label stack 1060. At Step 1195 the sequence ends.
Illustratively, an intermediate node 400 that acquires a packet transfers the packet to the PPE 600 for further processing. Fig. 12 is a sequence of steps that may be used to process a packet at an intermediate node 400 in accordance with the inventive technique. The sequence begins at Step 1205 and proceeds to Step 1210 where an in-termediate node 400 acquires a packet from another intermediate node 400 via a data 3o link 190 or from a customer edge node 120 via a data link 180. At Step 1230, the clas-sifier logic 620 examines the packet and associates an ingress key with the packet based
-15-_ on information contained in the packet. The classifier 620 then transfers the packet and ingress key to the rate controller 630 (Step 1240).
At Step 1250, the rate controller polices the Packet based on various rate control information as described above. The policed packet is then transferred from the rate s controller to the data cross connect 650 which determines if the ingress key associated with packet matches an ingress key 720 contained in an entry 710 in the XC DB
(Step 1260). If not, the sequence proceeds to Step 1265 where the packet is dropped.
The sequence then ends at Step 1295.
At Step 1260, if a matching entry 710 is found, the packet is associated with the io egress key 740 contained in the matching entry 710. Next, at Step 1270, the packet and egress key are transferred to the egress encapsulator 660 where the egress key is com-pared with entries 810 in the encapsulation database 800 to determine if an entry 810 in the database contnins an egress key 820 that matches the egress key associated with the packet If not, the sequence proceeds to Step 1280. Otherwise, the sequence proceeds is to Step 1275 where the packet is encapsulated in accordance with the header informa-tion 840 contained in the matching entry 810. At Step 1280 the traffic manager schedules the packet for transfer onto the network. The packet eventually leaves the traffic manager 670 and transferred to the egress interface logic 530 for transfer onto the network (Step 1280). The sequence ends at Step 1295.
20 The foregoing description has been directed to specific embodiments of this in-vention. It will be apparent that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages.
There-fore, it is an object of the appended claims to cover all such variations and modifica-tions as come within the true spirit and scope of the invention.
25 What is claimed is:
At Step 1250, the rate controller polices the Packet based on various rate control information as described above. The policed packet is then transferred from the rate s controller to the data cross connect 650 which determines if the ingress key associated with packet matches an ingress key 720 contained in an entry 710 in the XC DB
(Step 1260). If not, the sequence proceeds to Step 1265 where the packet is dropped.
The sequence then ends at Step 1295.
At Step 1260, if a matching entry 710 is found, the packet is associated with the io egress key 740 contained in the matching entry 710. Next, at Step 1270, the packet and egress key are transferred to the egress encapsulator 660 where the egress key is com-pared with entries 810 in the encapsulation database 800 to determine if an entry 810 in the database contnins an egress key 820 that matches the egress key associated with the packet If not, the sequence proceeds to Step 1280. Otherwise, the sequence proceeds is to Step 1275 where the packet is encapsulated in accordance with the header informa-tion 840 contained in the matching entry 810. At Step 1280 the traffic manager schedules the packet for transfer onto the network. The packet eventually leaves the traffic manager 670 and transferred to the egress interface logic 530 for transfer onto the network (Step 1280). The sequence ends at Step 1295.
20 The foregoing description has been directed to specific embodiments of this in-vention. It will be apparent that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages.
There-fore, it is an object of the appended claims to cover all such variations and modifica-tions as come within the true spirit and scope of the invention.
25 What is claimed is:
Claims (14)
1. In a data network comprising one or more intermediate nodes and a transport controller, a method for configuring data transmission in the data network comprising the steps of:
acquiring, at the transport controller, network topology information that describes the network's topology;
generating, at the transport controller, a transport database from the network topology information wherein the transport database contains pseudo wire path information that defines paths through intermediate nodes by mapping an ingress label and an ingress interface to an egress label and an egress interface for one or more pseudo wires contained in the data network; and distributing pseudo wire path information contained in the transport database from the transport controller to one or more packet processing engines (PPEs) contained in the one or more intermediate nodes to configure the PPEs to direct data packets acquired by the one or more intermediate nodes on an ingress interface indicated in the distributed pseudo wire path information to an egress interface indicated in the distributed pseudo wire path information .
acquiring, at the transport controller, network topology information that describes the network's topology;
generating, at the transport controller, a transport database from the network topology information wherein the transport database contains pseudo wire path information that defines paths through intermediate nodes by mapping an ingress label and an ingress interface to an egress label and an egress interface for one or more pseudo wires contained in the data network; and distributing pseudo wire path information contained in the transport database from the transport controller to one or more packet processing engines (PPEs) contained in the one or more intermediate nodes to configure the PPEs to direct data packets acquired by the one or more intermediate nodes on an ingress interface indicated in the distributed pseudo wire path information to an egress interface indicated in the distributed pseudo wire path information .
2. A method as defined in claim 1 wherein the transport controller is configured as a transport circuit management system configured to manage transport circuits in the data network.
3. A method as defined in claim 1 wherein the transport database contains one or more entries wherein each entry includes a mapping of an ingress label and an ingress interface to an egress label and an egress interface.
4. A method as defined in claim I comprising the steps of:
acquiring information contained in the transport database; and configuring one or more packet-processing engines (PPEs) contained at an intermediate node with the acquired transport database information.
acquiring information contained in the transport database; and configuring one or more packet-processing engines (PPEs) contained at an intermediate node with the acquired transport database information.
5. A method as defined in claim 1 comprising the steps of:
generating one or more ingress keys from the ingress interface indicated in the pseudo wire path information ; and generating one or more egress keys from the egress interface indicated in the pseudo wire path information.
generating one or more ingress keys from the ingress interface indicated in the pseudo wire path information ; and generating one or more egress keys from the egress interface indicated in the pseudo wire path information.
6. A method as defined in claim 5 wherein each PPE contains a classifying stage, a data cross connect stage, and an egress encapsulation stage.
7. A method as defined in claim 6 comprising the step of:
configuring the classifying stage, data cross connect stage and egress encapsulation stage using the generated one or more ingress keys and one or more egress keys.
configuring the classifying stage, data cross connect stage and egress encapsulation stage using the generated one or more ingress keys and one or more egress keys.
8. A method as defined in claim 1 comprising the steps of:
acquiring a data packet at an intermediate node; and associating the acquired data packet with an ingress key.
acquiring a data packet at an intermediate node; and associating the acquired data packet with an ingress key.
9. A method as defined in claim 8 wherein the intermediate node contains a cross connect database comprising one or more entries wherein each entry contains an ingress key and an egress key.
10. A method as defined in claim 9 comprising the steps of:
comparing the packet's ingress key with an ingress key contained in the cross connect database to determine if they match; and if so, associating the packet with an egress key contained in the matching entry.
comparing the packet's ingress key with an ingress key contained in the cross connect database to determine if they match; and if so, associating the packet with an egress key contained in the matching entry.
11. A method as defined in claim 10 wherein the intermediate node contains an encapsulation database comprising one or more entries wherein each entry contains an egress key and an encapsulation header.
12. A method as defined in claim 11 comprising the steps of:
comparing the packet's egress key with an egress key contained in the encapsulation database to determine if they match; and if so, encapsulating the packet in accordance with the encapsulation header contained in the matching entry.
comparing the packet's egress key with an egress key contained in the encapsulation database to determine if they match; and if so, encapsulating the packet in accordance with the encapsulation header contained in the matching entry.
13. A system coupled to a data network comprising:
means for acquiring network topology information that describes the data network's topology;
means for generating a transport database from the network topology information wherein the transport database contains pseudo wire path information that defines paths through intermediate nodes by mapping an ingress label and an ingress interface to an egress label and an egress interface for one or more pseudo wires contained in the data network; and means for distributing pseudo wire path information contained in the transport database to packet processing engines (PPEs) contained in the one or more intermediate nodes contained in the data network to configure the PPEs to direct data packets acquired by the one or more intermediate nodes on an ingress interface indicated in the distributed pseudo wire path information over to an egress interface indicated in the distributed pseudo wire path information.
means for acquiring network topology information that describes the data network's topology;
means for generating a transport database from the network topology information wherein the transport database contains pseudo wire path information that defines paths through intermediate nodes by mapping an ingress label and an ingress interface to an egress label and an egress interface for one or more pseudo wires contained in the data network; and means for distributing pseudo wire path information contained in the transport database to packet processing engines (PPEs) contained in the one or more intermediate nodes contained in the data network to configure the PPEs to direct data packets acquired by the one or more intermediate nodes on an ingress interface indicated in the distributed pseudo wire path information over to an egress interface indicated in the distributed pseudo wire path information.
14. A computer readable medium having stored thereon computer executable instructions which, when executed by a processor, cause the processor to:
acquire network topology information that describes the network's topology;
generate a transport database from the network topology information wherein the transport database contains path information that defines paths through intermediate nodes by mapping an ingress label and an ingress interface to an egress label and an egress interface for one or more pseudo wires contained in the data network; and distribute at least some of the path information contained in the transport database to packet processing engines (PPEs) contained in the one or more intermediate nodes in the data network to configure the PPEs to direct data packets acquired by the one or more intermediate nodes on an ingress interface indicated in the distributed pseudo wire path information to an egress interface indicated in the distributed pseudo wire path information.
acquire network topology information that describes the network's topology;
generate a transport database from the network topology information wherein the transport database contains path information that defines paths through intermediate nodes by mapping an ingress label and an ingress interface to an egress label and an egress interface for one or more pseudo wires contained in the data network; and distribute at least some of the path information contained in the transport database to packet processing engines (PPEs) contained in the one or more intermediate nodes in the data network to configure the PPEs to direct data packets acquired by the one or more intermediate nodes on an ingress interface indicated in the distributed pseudo wire path information to an egress interface indicated in the distributed pseudo wire path information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2842069A CA2842069A1 (en) | 2004-06-24 | 2005-06-09 | Technique for transferring data over a packet switched network |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/876,127 | 2004-06-24 | ||
| US10/876,127 US8149731B2 (en) | 2004-06-24 | 2004-06-24 | Technique for transferring data over a packet switched network |
| PCT/US2005/020155 WO2006011952A2 (en) | 2004-06-24 | 2005-06-09 | Technique for transferring data over a packet switched network |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2842069A Division CA2842069A1 (en) | 2004-06-24 | 2005-06-09 | Technique for transferring data over a packet switched network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2570745A1 CA2570745A1 (en) | 2006-02-02 |
| CA2570745C true CA2570745C (en) | 2014-04-22 |
Family
ID=35599334
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2570745A Expired - Fee Related CA2570745C (en) | 2004-06-24 | 2005-06-09 | Technique for transferring data over a packet switched network |
| CA2842069A Abandoned CA2842069A1 (en) | 2004-06-24 | 2005-06-09 | Technique for transferring data over a packet switched network |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2842069A Abandoned CA2842069A1 (en) | 2004-06-24 | 2005-06-09 | Technique for transferring data over a packet switched network |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8149731B2 (en) |
| EP (1) | EP1766876B1 (en) |
| CA (2) | CA2570745C (en) |
| WO (1) | WO2006011952A2 (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8149731B2 (en) | 2004-06-24 | 2012-04-03 | Cisco Technology, Inc. | Technique for transferring data over a packet switched network |
| CN100496045C (en) * | 2004-08-04 | 2009-06-03 | 华为技术有限公司 | Method and system for supporting data framing protocol on multi-service transmission node equipment |
| US7756125B2 (en) * | 2005-08-05 | 2010-07-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for routing pseudo-wire encapsulated packets |
| WO2007101140A2 (en) * | 2006-02-24 | 2007-09-07 | Nortel Networks Ltd. | Multi-protocol support over ethernet packet-switched networks |
| US20070286204A1 (en) * | 2006-06-12 | 2007-12-13 | Hamid Ould-Brahim | Supporting Multi-Protocol Label Switching (MPLS) Applications Over Ethernet Switch Paths |
| US8345552B2 (en) | 2007-02-27 | 2013-01-01 | Alcatel Lucent | Virtual connection route selection apparatus and techniques |
| US7986667B2 (en) | 2007-10-19 | 2011-07-26 | Ericsson Ab | Forwarding data path optimization in a distributed environment for achieving micro-mobility |
| US8731401B2 (en) | 2010-12-14 | 2014-05-20 | University Of Houston | Dense wavelength division multiplexing multi-mode switching systems and methods for concurrent and dynamic reconfiguration with different switching modes |
| WO2012100842A1 (en) * | 2011-01-27 | 2012-08-02 | Telefonaktiebolaget L M Ericsson (Publ) | Method and device for creating and for receiving a data packet with discard eligible information |
| US9143429B2 (en) | 2012-02-28 | 2015-09-22 | Google Inc. | Identifying an egress point to a network location |
| US8837476B2 (en) | 2012-09-07 | 2014-09-16 | International Business Machines Corporation | Overlay network capable of supporting storage area network (SAN) traffic |
| US11418629B2 (en) * | 2014-05-19 | 2022-08-16 | Bay Microsystems, Inc. | Methods and systems for accessing remote digital data over a wide area network (WAN) |
| EP3270547A1 (en) * | 2016-07-14 | 2018-01-17 | Deutsche Telekom AG | Field bus apparatus for communicating with a remote automation device |
| CN108075968A (en) * | 2016-11-10 | 2018-05-25 | 中国移动通信集团广东有限公司 | A kind of network system and pseudo-line service processing method |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6678826B1 (en) * | 1998-09-09 | 2004-01-13 | Communications Devices, Inc. | Management system for distributed out-of-band security databases |
| US6856627B2 (en) * | 1999-01-15 | 2005-02-15 | Cisco Technology, Inc. | Method for routing information over a network |
| US6654369B1 (en) * | 1999-05-28 | 2003-11-25 | Intel Corporation | Method for directing the route of a cell transmitting a network |
| US6725264B1 (en) | 2000-02-17 | 2004-04-20 | Cisco Technology, Inc. | Apparatus and method for redirection of network management messages in a cluster of network devices |
| US7426179B1 (en) * | 2000-03-17 | 2008-09-16 | Lucent Technologies Inc. | Method and apparatus for signaling path restoration information in a mesh network |
| US7136374B1 (en) * | 2001-03-19 | 2006-11-14 | Juniper Networks, Inc. | Transport networks supporting virtual private networks, and configuring such networks |
| US7450505B2 (en) | 2001-06-01 | 2008-11-11 | Fujitsu Limited | System and method for topology constrained routing policy provisioning |
| US7181141B1 (en) * | 2001-11-02 | 2007-02-20 | Ciena Corporation | Method and system for collecting network topology in an optical communications network |
| US20040126313A1 (en) * | 2002-06-24 | 2004-07-01 | Haase Richard A. | Methods and processes of hydrogen peroxide production |
| DE10238291A1 (en) * | 2002-08-21 | 2004-03-04 | Siemens Ag | Efficient intra-domain routing in packet networks |
| US7596629B2 (en) * | 2002-11-21 | 2009-09-29 | Cisco Technology, Inc. | System and method for interconnecting heterogeneous layer 2 VPN applications |
| US6985488B2 (en) * | 2003-01-15 | 2006-01-10 | Ciena Corporation | Method and apparatus for transporting packet data over an optical network |
| US7417950B2 (en) | 2003-02-03 | 2008-08-26 | Ciena Corporation | Method and apparatus for performing data flow ingress/egress admission control in a provider network |
| US7336617B1 (en) * | 2003-08-01 | 2008-02-26 | Verizon Laboratories Inc. | Bit-field-encoded resource record for determining a transmission path in a communications network |
| US20050147104A1 (en) * | 2003-12-29 | 2005-07-07 | Hamid Ould-Brahim | Apparatus and method for multihop MPLS/IP/ATM/frame relay/ethernet pseudo-wire |
| US7606235B1 (en) * | 2004-06-03 | 2009-10-20 | Juniper Networks, Inc. | Constraint-based label switched path selection within a computer network |
| US8149731B2 (en) | 2004-06-24 | 2012-04-03 | Cisco Technology, Inc. | Technique for transferring data over a packet switched network |
-
2004
- 2004-06-24 US US10/876,127 patent/US8149731B2/en active Active
-
2005
- 2005-06-09 EP EP05757519.3A patent/EP1766876B1/en active Active
- 2005-06-09 WO PCT/US2005/020155 patent/WO2006011952A2/en active Application Filing
- 2005-06-09 CA CA2570745A patent/CA2570745C/en not_active Expired - Fee Related
- 2005-06-09 CA CA2842069A patent/CA2842069A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006011952A2 (en) | 2006-02-02 |
| EP1766876A2 (en) | 2007-03-28 |
| WO2006011952A8 (en) | 2007-11-15 |
| CA2842069A1 (en) | 2006-02-02 |
| US20060013226A1 (en) | 2006-01-19 |
| CA2570745A1 (en) | 2006-02-02 |
| EP1766876A4 (en) | 2009-05-13 |
| US8149731B2 (en) | 2012-04-03 |
| EP1766876B1 (en) | 2017-03-15 |
| WO2006011952A3 (en) | 2007-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2570745C (en) | Technique for transferring data over a packet switched network | |
| EP1585261B1 (en) | Apparatus and method for processing labeled flows in a communications access network | |
| EP1585264B1 (en) | Method for indicating classification of a communications flow | |
| US7782841B2 (en) | Method and system for transporting data using pseudowire circuits over a bridged network | |
| US7417950B2 (en) | Method and apparatus for performing data flow ingress/egress admission control in a provider network | |
| KR100612318B1 (en) | Apparatus and method for implementing vlan bridging and a vpn in a distributed architecture router | |
| EP1720024B1 (en) | A method for realizing the pseudo wire emulation edge-to-edge protocol | |
| US7486674B2 (en) | Data mirroring in a service | |
| EP1585259B1 (en) | System and method for providing a multiple-protocol crossconnect | |
| EP1585260B1 (en) | Apparatus and method for terminating service emulation instances | |
| CN100382517C (en) | Network QoS test method and system | |
| US8014316B2 (en) | System, method and computer-readable storage medium for calculating addressing and bandwidth requirements of a network | |
| WO2007135666A2 (en) | Mac address learning in a distributed bridge | |
| JP2001237876A (en) | Buildup method for ip virtual private network and the ip virtual private network | |
| US9143406B2 (en) | Apparatus, method and computer-readable storage medium for calculating throughput requirements of a network | |
| CN110166320B (en) | MPLS-TP OAM implementation method and system based on OpenFlow switch | |
| Li | Design, implementation and performance evaluation of MPLS layer 2 Martini VPN | |
| Ögren | Selecting/realization of Virtual Private Networks with Multiprotocol Label Switching or Virtual Local Area Networks | |
| Xiao et al. | RFC 3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) | |
| Pate | Network Working Group X. Xiao, Ed. Request for Comments: 3916 Riverstone Networks Category: Informational D. McPherson, Ed. Arbor Networks | |
| KR20120072301A (en) | Apparatus and method for packet transport service based on mpls-tp network | |
| IL195263A (en) | Mac address learning in a distributed bridge |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20180611 |