US20090196289A1 - Fast-path implementation for an uplink double tagging engine - Google Patents
Fast-path implementation for an uplink double tagging engine Download PDFInfo
- Publication number
- US20090196289A1 US20090196289A1 US12/427,553 US42755309A US2009196289A1 US 20090196289 A1 US20090196289 A1 US 20090196289A1 US 42755309 A US42755309 A US 42755309A US 2009196289 A1 US2009196289 A1 US 2009196289A1
- Authority
- US
- United States
- Prior art keywords
- packet
- port
- multicast
- vlan
- tag
- 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
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
- H04L12/4645—Details on frame tagging
- H04L12/4666—Operational details on the addition or the stripping of a tag in a frame, e.g. at a provider edge node
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
- H04L47/2433—Allocation of priorities to traffic types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2458—Modification of priorities while in transit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/35—Switches specially adapted for specific applications
- H04L49/354—Switches specially adapted for specific applications for supporting virtual local area networks [VLAN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
Definitions
- the present invention relates to a method of and an apparatus for processing a packet based on a double tagging engine within a Virtual Private LAN Service (VPLS), a Transparent LAN Service (TLS), a Virtual Private Switched Network Service (VPSNS), or any Layer 2 Virtual Private Network (VPN).
- VPLS Virtual Private LAN Service
- TLS Transparent LAN Service
- VPNNS Virtual Private Switched Network Service
- the present invention can be applied to any packet-based service provider communication network environment, such as token ring, ATM, Ethernet, Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet.
- the present invention relates to a method of and an apparatus for fast-path implementation for TLS using double tagging engine that can be implemented on a semiconductor substrate such as a silicon chip, or can be implemented on software, or a combination of hardware and software.
- One example of the present invention can include a method for processing a packet in a communications network.
- the method can include the steps of: receiving a packet in an ingress port at a network component, identifying a destination address and a network identifier from the packet, obtaining an outgoing port bit map based on the destination address and the network identifier of the packet, and forwarding the packet to a destination module and out of an egress port within the network component based on the outgoing port bit map.
- the present invention can relate to a method for processing a packet in a communications network.
- the method can include the steps of receiving a packet in an ingress port at a network component, identifying a network identifier from the packet, accessing a packet tag corresponding to the packet, obtaining an outgoing port bit map based on the network identifier, and obtaining a membership port bit map based on the packet tag.
- the method can have the steps of generating an egress port bit map based on the outgoing port bit map and the membership port bit map, and forwarding the packet to a destination module and an egress port within the network component based on the egress port bit map.
- the present invention can be a method for processing a packet in a communications network.
- the method can include the steps of receiving a packet in an ingress port at a network component, identifying a source module and a source port corresponding to the packet, obtaining a packet tag from the packet tag table based on the source module and the source port, assigning a packet tag priority based on a class of service of the packet, and obtaining an ether-type from a register.
- the steps can include appending the packet received within the buffer with the packet tag, the packet tag priority and the ether-type, and forwarding the packet appended with the packet tag, the packet tag priority and the ether-type to an egress port within the network component.
- Another example of the present invention can be a method for processing a packet in a communications network.
- the method can have the steps of receiving a packet in an ingress port at a network component, removing a packet tag from the packet, obtaining a multicast index and a multicast type from indexing the packet tag to a look-up table, and appending the packet with the multicast index and the multicast type.
- the method can have the steps of modifying an operational code of the packet to multicast when the multicast type is a first predetermined type, modifying the operation code of the packet to an IP multicast when the multicast type is a second predetermined type, assigning a first class of service for the packet with a packet tag priority, and forwarding the packet to a first egress port.
- the network component can have a buffer configured to receive a packet in an ingress port at a network component, a first identification unit configured to identify a destination address and a network identifier from the packet received at the buffer, a look-up table configured to be indexed by the destination address and the network identifier identified by the identification unit to obtain an outgoing port bit map, and a forwarding unit configured to forward the packet to a destination module and out of an egress port within the network component based on the outgoing port bit map.
- the present invention can relate to a network component for processing a packet.
- the network component can have a first buffer configured to receive a packet in an ingress port at a network component, a first identification unit configured to identify a network identifier from the packet received at the buffer, an accessing unit configured to access a packet tag corresponding to the packet received at the buffer, an outgoing port look-up table configured to be indexed by the network identifier identified by the identification unit to obtain an outgoing port bit map, a membership look-up table configured to be indexed by the packet tag accessed by the accessing unit to obtain a membership port bit map, a second buffer configured to store an egress port bit map based on the outgoing port bit map from the outgoing look-up table and the membership port bit map from the membership look-up table, and a forwarding unit configured to forward the packet to a destination module and an egress port within the network component based on the egress port bit map stored at the second buffer.
- the present invention can be directed to a network component for processing a packet.
- the network component can have a buffer configured to receive a packet in an ingress port at a network component, an identifying unit configured to identify a source module and a source port corresponding to the packet received at the buffer, a packet tag look-up table configured to be indexed by the source module and the source port identified by the identifying unit to obtain a packet tag, and an assigning unit configured to assign a packet tag priority based on a class of service of the packet received at the buffer.
- the present example can have a register configured to store an ether-type, an appending unit configured to append the packet received at the buffer with the packet tag, the packet tag priority and the ether-type, and a forwarding unit configured to forward the packet appended with the packet tag, the packet tag priority and the ether-type by the appending unit, to an egress port within the network component.
- the present invention can be related to a network component for processing a packet.
- the network component can include a buffer configured to receive a packet in an ingress port at a network component, a removing unit configured to remove a packet tag from the packet received at the buffer, a packet tag look-up table configured to be indexed by the packet tag removed from the removing unit to obtain a multicast index and a multicast type, and an appending unit configured to append the packet with the multicast index and the multicast type.
- the present invention can have a modifying unit configured to modify an operational code of the packet to be multicast when the multicast type appended by the appending unit is a first predetermined type, a modifying unit configured to modify the operation code of the packet to be IP multicast when the multicast type is a second predetermined type, an assigning unit configured to assign a packet tag priority based on a first class of service of the packet received at the buffer, and a first forwarding unit configured to forward the packet to a first egress port.
- the system can have a receiving means for receiving a packet in an ingress port at a network component, a first identifying means for identifying a destination address and a network identifier from the packet, an obtaining means for obtaining an outgoing port bit map based on the destination address and the network identifier of the packet, and a forwarding means for forwarding the packet to a destination module and out of an egress port within the network component based on the outgoing port bit map.
- the present invention can relate to a system for processing a packet in a network component.
- the system can include a receiving means for receiving a packet in an ingress port at a network component, a first identifying means for identifying a network identifier from the packet, an accessing means for accessing a packet tag corresponding to the packet, a first obtaining means for obtaining an outgoing port bit map based on the network identifier, a second obtaining means for obtaining a membership port bit map based on the packet tag, a generating means for generating an egress port bit map based on the outgoing port bit map and the membership port bit map, and a forwarding means for forwarding the packet to a destination module and an egress port within the network component based on the egress port bit map.
- the present invention can include a system for processing a packet in a network component.
- the system can have a receiving means for receiving a packet in an ingress port at a network component, an identifying means for identifying a source module and a source port corresponding to the packet, a first obtaining means for obtaining a packet tag from the packet tag table based on the source module and the source port, and an assigning means for assigning a packet tag priority based on a class of service of the packet.
- the system can have a second obtaining means for obtaining an ether-type from a register, an appending means for appending the packet received within the buffer with the packet tag, the packet tag priority and the ether-type, and a forwarding means for forwarding the packet appended with the packet tag, the packet tag priority and the ether-type to an egress port within the network component.
- the present invention can include a system for processing a packet in a network component.
- the said system can have a first receiving means for receiving a packet in an ingress port at a network component, a removing means for removing a packet tag from the packet, a first obtaining means for obtaining a multicast index and a multicast type from indexing the packet tag to a look-up table, and an appending means for appending the packet with the multicast index and the multicast type.
- the system can have a first modifying means for modifying an operational code of the packet to multicast when the multicast type is a first predetermined type, a second modifying means for modifying the operation code of the packet to an IP multicast when the multicast type is a second predetermined type, an assigning means for assigning a first class of service for the packet with a packet tag priority, and a first forwarding means for forwarding the packet to a first egress port.
- FIG. 1 illustrates one example of a Transparent LAN Service Network System in accordance with the present invention
- FIG. 2 illustrates another example of a Transparent LAN Service Network System in accordance with the present invention
- FIG. 3 illustrates one example of a Provider Edge Device in accordance with the present invention
- FIG. 4 illustrates another example of a Provider Edge Device in accordance with the present invention
- FIG. 5( a ) illustrates one example of a packet inserted with a customer VLAN ID tag in accordance with the present invention
- FIG. 5( b ) illustrates one example of a packet inserted with a customer VLAN ID tag, an SP VLAN tag, and additional information in accordance with the present invention
- FIG. 6 illustrates one example of a method of processing a packet based on double tagging engine within a TLS network system
- FIG. 7 illustrates another example of a method of processing a packet based on double tagging engine within a TLS network system
- FIG. 8 illustrates yet another example of a method of processing a packet based on double tagging engine within a TLS network system
- FIG. 9 illustrates one additional example of a method of processing a packet based on double tagging engine within a TLS network system.
- FIG. 10 illustrates another example of a method of processing a packet based on double tagging engine within a TLS network system.
- FIG. 1 illustrates one example of a fast-path Transparent LAN Service (hereinafter “TLS”) network system 10 that can implement double tagging.
- TLS network system 10 of this example can be configured to deliver Ethernet or other service to multiple customers geographically dispersed across a network, such as a Wide Area Network (WAN) or Metro Area Network (MAN), as if the multiple customers were connected through a Local Area Network (LAN).
- WAN Wide Area Network
- MAN Metro Area Network
- LAN Local Area Network
- the TLS network system 10 as shown in FIG. 1 illustrates a Service Provider Network (SPN) 20 .
- the SPN 20 can be a packet switched network, such as the Internet.
- FIG. 1 shows a plurality of Provider Edge (PE) devices PE 1 , PE 2 , PE 3 . . . PE n connected to the SPN 20 .
- PE Provider Edge
- FIG. 1 illustrates TLS network system 10 having two VPLS customers, VPLS CUST A and VPLS CUST B. It is noted that although FIG. 1 shows a TLS network system 10 having two VPLS customers, the present invention can be configured to handle a plurality of VPLS customers CUST n within the TLS network system 10 .
- Each VPLS CUST A and B can be connected to a PE device.
- each VPLS customer can have its own plurality of independent Virtual Local Area Networks (VLAN), VLAN 1 , VLAN 2 . . . VLAN n.
- FIG. 1 shows VLAN 1 , VLAN 2 . . . VLAN n of VPLS CUST A being “bridged” transparently over SPN 10 , wherein a Service Provider VLAN, SP VLAN 30 , can be configured to specifically carry all of VPLS CUST A's communication traffic.
- FIG. 1 shows VLAN 1 , VLAN 2 . . . VLAN n of VPLS CUST B being “bridged” transparently over SPN 10 , wherein SP VLAN 40 can be configured to carry all of VPLS CUST B's communication traffic.
- FIG. 2 illustrates another example of a TLS network system 15 that can include a SPN 25 and PE devices PE 1 and PE 2 .
- Each PE device can be configured to have a plurality of ports, such as at least one uplink port, upt 1 and one or more customer facing port(s), pt 0 , pt 1 . . . pt n.
- Each port within each of the PE devices can be configured to be a receiving port, or an ingress port, as well as a transmitting port, or an egress port, for receiving and transmitting a packet, respectively.
- the TLS network system 10 , 15 of the present example can manage data and/or information in the form of a packet, it is noted that in other examples of the present invention, the TLS network system 10 , 15 can be configured to also manage data and/or information in other formats, such as a data frame, or a data cell. Therefore, any reference to a packet herein can also refer to at least a frame, a cell, or a data packet, a data frame or a data cell.
- each port within the PE devices can be organized into groups of port(s) for one or more customer(s), wherein each organized group of port(s) can represent a VPLS domain for the TLS network system 15 .
- a specific customer can be provided with one or more port(s) from the PE device.
- each port from within the organized group of port(s) assigned to the specific customer can be designated to connect with each and every VLAN of that particular customer, or selected VLANs.
- one or more customer(s) can share the same organized group of port(s) from the PE device if each customer share the same set of unique VLAN IDs.
- FIG. 2 shows PE devices PE 1 and PE 2 connected to a SPN 25 via an uplink port upt 1 , wherein PE 1 and PE 2 can be two geographically dispersed sites.
- PE 1 and PE 2 each has a plurality of ports pt 0 , pt. 1 , pt 2 , pt 3 . . . pt n therein.
- Port pt 0 of PE 1 is designated for VPLS CUST A only.
- Port pt 1 of the same PE device however is designed for two customers, them being VPLS CUST B and C.
- ports pt 3 , pt 4 , pt 5 , pt 6 , pt 7 and pt 8 are organized as a group of ports for VPLS CUST D.
- port pt 4 is designated for VPLS CUST A and port pt 5 is designated to both VPLS CUST B and C.
- ports pt n ⁇ 3, pt n ⁇ 2, pt n ⁇ 1 and pt n are organized as a group of ports for VPLS CUST D.
- FIG. 3 illustrates one example of a hardware configuration of a PE device.
- the hardware configuration of FIG. 3 can be in an integrated, modular and single chip solution, and therefore can be embodied on a semiconductor substrate, such as silicon.
- the hardware configuration of FIG. 3 can be embodied in a plurality of discrete components on a circuit board.
- FIG. 3 shows a PE device that can include a double tagging engine module 300 , a network module A 305 , a switch fabric module 310 , a network module B 315 , and a network module C 320 .
- the double tagging engine module 300 can have an uplink port uplink pt 325 that can be a network port for connecting to the Ethernet, such as the Internet.
- the double tagging engine module 300 can include a switch fabric port SF port a 330 for connecting to the switch fabric module 310 .
- the PE device of FIG. 3 also shows a network module A 305 , network module B 315 , and network module C 320 .
- Each of the network modules A, B and C can be a network switching chip made commercially available through Broadcom® Corporation. Additionally, each of the network modules A, B and C can have one or more customer facing ports, and one switch fabric port.
- the customer facing ports can connect the PE device to the customers or subscribers of the SPN.
- the SF ports a, b and c can connect each module to the switch fabric module 310 .
- the customer facing ports and the SF ports a, b and c can be an ingress port as well as an egress port.
- the switch fabric module 310 can also be a network switching chip made commercially available through Broadcom® Corporation.
- FIG. 4 illustrates one example of a hardware configuration of a PE device 400 .
- the hardware configuration of FIG. 4 can be in an integrated, modular and single chip solution, and therefore can be embodied on a semiconductor substrate, such as silicon.
- the hardware configuration of FIG. 4 can be embodied in a plurality of discrete components on a circuit board.
- the PE device 400 can be configured to include at least one uplink port uplink pt 401 , and a plurality of customer facing ports or subscriber ports, pt 0 , pt 1 , . . . pt n.
- each port within the PE device can be configured to be a receiving port, or an ingress port, as well as a transmitting port, or an egress port, for receiving and transmitting a packet, respectively.
- FIG. 5( a ) illustrates one example of a packet 500 that can be received in or transmitted out of any one of the customer facing ports or subscriber ports pt 0 , pt 1 , . . . pt n.
- the packet 500 can be configured to include, at least a destination address field DA, a source address field SA, a customer VLAN identification tag VLAN ID, a type or length field T/L, and a payload P.
- the destination address field can be a bit value that can be used by the receiving Media Access Controller (MAC), in order to determine if the incoming packet is addressed to the particular port.
- MAC Media Access Controller
- the source address field can be a bit value and can be supplied by the transmitting MAC, which can insert its own unique address into the source address field as the frame is transmitted, indicating it was the original station.
- the receiving MAC is not required to take action based on the source address field.
- the customer VLAN ID tag is a first packet tag inserted within the packet. The VLAN ID tag can identify a particular VLAN for a unique customer.
- the customer VLAN ID tag can identify the packet as originating from one of the customer's VLANs.
- the T/L field can provide the type or the length of the packet.
- the payload P can contain the actual frame data that is being transferred.
- FIG. 5( b ) illustrates one example of a packet 510 that can be received in or transmitted out of the uplink pt 401 .
- the packet 510 can be configured to include, at least a destination address field DA, a source address field SA, an SP VLAN tag, a customer VLAN identification tag VLAN ID, an Ether-type, a SP VLAN tag priority, an op-code and a payload P.
- Packet 510 can include an SP VLAN ID tag, which can be a second tag in the packet 510 .
- the SP VLAN ID tag can specify or identify a customer within the TLS network system 10 . In other words, if a TLS network system 10 includes a plurality of customers, such as VPLS CUST A, VPLS CUST B, VPLS CUST C, and VPLS CUST D, the SP VLAN ID tag can identify the packet as originating from and belonging to a particular VPLS customer.
- packet 510 can include at least a first tag, that being a customer VLAN ID tag, and a second tag, that being a SP VLAN ID tag.
- the SP VLAN ID tag can identify the packet as belonging to a particular VPLS customer, and the VLAN ID tag can identify the particular VLAN belonging to that VPLS customer. Accordingly, a packet having a first and second tag can always be identified as belonging to a unique VPLS customer, even if a plurality of the VPLS customers have overlapping or common VLAN IDs.
- FIG. 4 can include a storage unit 402 , such as a register.
- the storage unit 402 can be configured to store a one-bit DT engine bit 403 .
- the DT engine bit 403 can either be set or not set by preprogramming.
- the DT engine bit 403 can have either the value of “1” which sets the DT engine bit 403 , or the value of “0” which un-set the DT engine bit 403 .
- the PE device 400 can be operating under tagging engine mode. For instance, a bit value of “1” can indicate that the PE device 400 is operating under double tagging engine mode, and whereby a bit value of “0” can indicate that the PE device 400 is not operating under double tagging engine mode.
- the PE device 400 of FIG. 4 can be configured to include a plurality of look-up tables, such as an SP VLAN ID tag look-up table 404 , a VPLS look-up table 408 , a VLAN look-up table 416 , an L2 multicast look-up table 420 , and an L2 address look-up table 424 .
- a plurality of look-up tables such as an SP VLAN ID tag look-up table 404 , a VPLS look-up table 408 , a VLAN look-up table 416 , an L2 multicast look-up table 420 , and an L2 address look-up table 424 .
- the SP VLAN ID tag look-up table 404 can include one or more SP VLAN ID tag(s) 406 therein and can be indexed by a source module and a source port from a packet.
- the SP VLAN ID tag(s) 406 within the table 404 can be obtained when a packet received at the PE device 400 is to be forwarded to the uplink port 401 , wherein the packet is to be double tagged.
- the VPLS look-up table 408 can have one or more entries therein.
- the VLPS look-up table 408 can be indexed by a SP VLAN ID tag so that one or more entries therein may be accessed or identified.
- Each mask entry can be configured to have a VPLS port bit map 410 or a membership port bit map therein.
- the VPLS port bit map 410 can be a bit string having a bit length that can be equal, for example, to a number of ports with the PE device 400 .
- Each bit position of the VPLS port bit map 410 can correspond to a particular port within the PE device 400 .
- the VPLS port bit map 410 can be configured to identify a group of one or more port(s) that correspond or belong to a particular VPLS membership for a PE device.
- the VPLS port bit map 410 can identify a group of one or more port(s) to which an unique customer's VLAN(s) can be mapped.
- each bit position of the VPLS port bit map 410 can be set with a value or condition of either “1” or “0”.
- the port corresponding to the bit position can be included as part of the group of port(s) associated with the VPLS membership.
- the port corresponding to the bit position can be excluded from the group of port(s) associated with the VPLS membership.
- each entry within the VPLS look-up table 408 can include a Layer 2 multicast index 412 and a VPLS type 414 .
- the Layer 2 multicast index 412 and the VPLS type 414 can correspond to a VPLS port bit map 410 .
- FIG. 4 also shows a VLAN ID look up table 416 within the PE device 400 .
- the VLAN ID look-up table 416 can include one or more preprogrammed mask entries therein. Each mask entry can be configured to be an outgoing port bit map 418 .
- the outgoing bit map 418 can be a bit string having any bit length. Each bit position of the outgoing bit map 418 can correspond to a particular port of a particular module within the PE device 400 for a particular VLAN ID. In essence, the outgoing bit map 418 can be configured to identify one or more outgoing port(s) with respect to a particular VLAN ID. Accordingly, each bit position of the outgoing bit map 418 can be set with a value or condition of either “1” or “0”.
- the port of a specified module corresponding to the bit position can be identified or specified as an outgoing port associated with a particular customer VLAN ID.
- the port of a specified module corresponding to the bit position can be identified or specified as not being included as an outgoing port of a particular customer VLAN ID.
- the VLAN ID look-up table 416 can be indexed by the VLAN ID tag from the packet 500 of FIG. 5( a ) as an example. Upon receiving the packet in an ingress port, the VLAN ID can be identified and indexed into the VLAN ID look-up table 416 , wherein one VLAN ID mask entry having an outgoing port bit map 418 can be identified.
- FIG. 4 also shows an L2 Multicast look-up table 420 within the PE device 400 .
- the L2 Multicast look-up table 420 can include one or more preprogrammed mask entries therein, and the size of the L2 Multicast lookup table 420 can equal to the number of multicast groups supported by the PE device 400 .
- each mask entry within the L2 Multicast look-up table 420 can be accessed or identified by using the customer VLAN ID and the multicast DA within the packet received. Each entry can contain a list of ports which map to a L2 multicast group.
- Each mask entry within the L2 Multicast look-up table 420 can be configured to be an outgoing port bit map 422 which can be a list of ports which maps to an L2 Multicast group.
- the L2 Multicast look-up table 420 can be used to flood multicast packets to only those ports which have memberships of the L2 multicast group. In other words, rather than flooding a packet to the entire group of ports belonging to a particular VLAN ID, each outgoing port bit map 422 within the L2 Multicast table can be used to flood a packet to only the ports having membership of the L2 multicast group.
- the outgoing port bit map 422 within the L2 Multicast look-up table 420 can be a bit string having any bit length.
- Each bit position of the outgoing port bit map 422 can correspond to a particular port within the PE device 400 having an L2 multicast membership.
- the outgoing port bit map 422 can be configured to identify one or more outgoing port(s) with respect to a particular L2 multicast group. Accordingly, each bit position of the outgoing port bit map 422 can be set with a value or condition of either “1” or “0”.
- the port corresponding to the bit position can be identified or specified as an outgoing port associated with a particular L2 multicast membership with respect to the packet received.
- the port corresponding to the bit position can be identified or specified as not being included as an outgoing port of a particular L2 multicast group with respect to the packet received.
- FIG. 4 shows an L2 Address look-up table 424 within the PE device 400 .
- the L2 Address look-up table 424 can include one or more preprogrammed mask entries therein.
- each mask entry within the L2 Address look-up table 424 can be accessed or identified by indexing the customer VLAN ID and the DA within the packet received.
- Each mask entry within the L2 Address look-up table 424 can be configured to be an outgoing port bit map 426 .
- the outgoing port bit map 426 within the L2 Address look-up table 424 can be a bit string having any bit length.
- Each bit position of the outgoing port bit map 426 can correspond to a port within the PE device 400 .
- the outgoing port bit map 426 can be configured to identify one or more outgoing port(s) with respect to a packet received. Similar to above, each bit position of the outgoing bit map 426 can be set with a value or condition of either “1” or “0”.
- the port corresponding to the bit position can be identified or specified as an outgoing port with respect to the packet received.
- the port corresponding to the bit position can be identified or specified as not being an outgoing port with respect to the packet received.
- the PE device of FIG. 3 can also include a CPU 428 .
- the CPU 428 can be configured to implement a plurality of tasks and operations.
- the PE device 400 of FIG. 4 can include an Ether-type configuration register 430 .
- the Ether-type configuration register 430 can be configured to store an Ether-type value and can be accessed and inserted into a packet transmitted from an uplink port.
- the PE device 400 can have one or more class of service select register(s) 434 for storing a class of service type.
- the class of service select register(s) 434 can correspond to a customer port.
- FIGS. 6-10 illustrate one or more examples of a method of processing and double tagging a packet based on a double tagging engine thereof in accordance with the present invention.
- the method of the present example can be implemented in hardware, or software, or a combination of both hardware and software.
- FIG. 6 shows one example of a method of processing a packet received on an Ethernet access port of a module based on a double tagging engine.
- a known Layer 2 unicast or a known Layer 2 multicast packet can be received at a customer subscriber port at step 600 .
- a known unicast packet can be a packet that is relayed or transmitted to only one known destination port.
- a known multicast packet can be a packet that is relayed or transmitted to multiple known destination ports.
- an unknown unicast/multicast/broadcast packet can be a destination-lookup-failure packet.
- a received packet can be an unknown unicast/multicast/broadcast packet due to a failure in the destination address (DA) lookup for the packet received. Therefore, if the destination address lookup is not successful, then the destination port or ports with respect to the packet received is unknown.
- DA destination address
- a known unicast or a known multicast packet can be received at one of the customer facing ports of a PE device. Once the packet is received, a destination address and a customer VLAN ID can be identified from the packet at step 605 .
- an outgoing port bit map can be obtained from a look-up table at step 610 . If the packet received is a known unicast packet, then the outgoing port bit map can be obtained from an L2 Address look-up table. However, if the packet received is a known multicast packet, then the outgoing port bit map can be obtained from an L2 Multicast look-up table.
- a fast filtering processor can assign a class of service (CoS) to the module header of the packet based on a service level agreement (SLA) at step 615 . Thereafter, the packet can be forwarded to one or more destination module(s) and one or more egress port(s) based on the outgoing port bit map at step 620 .
- CoS class of service
- SLA service level agreement
- FIG. 7 shows one example of a method of processing a packet received on an Ethernet access port of a DT engine module based on a double tagging engine.
- a known Layer 2 unicast, known Layer 2 multicast, or an unknown Layer 2 unicast, multicast or broadcast packet can be received at an Ethernet access port of a DT engine module at step 700 .
- a source module and a source port corresponding to the packet is identified at step 705 .
- the source module and the source port indicate the source where the packet originated therefrom.
- the source module and the source port can be indexed to a SP VLAN tag look-up table to obtain a SP VLAN tag, which corresponds to the source module and the source port at step 710 .
- a SP VLAN tag priority can be assigned to the packet based on the CoS of the packet at step 715 .
- an Ether-type value can be obtained from an Ether-type configuration register at step 720 .
- the packet received can be appended with the above information at step 725 .
- the packet received at the Ethernet access port of a DT engine module can be appended with a SP VLAN tag, a SP VLAN tag priority and a Ether-type value therein.
- the packet can be forwarded out of the uplink port of the DT engine module to a SPN at step 730 .
- FIG. 8 shows one example of a method of processing a packet received on an Ethernet access port of a module based on a double tagging engine.
- An unknown Layer 2 unicast, multicast and broadcast packet can be received at subscriber port or a customer facing port of one or more network switching module such as Draco, or Tucana at step 800 .
- a customer VLAN ID can be identified from the packet at step 805 .
- a SP VLAN ID tag can be identified from the packet at step 810 .
- the VLAN ID can be indexed to a VLAN ID look-up table and the SP VLAN ID tag can similarly be indexed to a SP VLAN ID look-up table.
- an outgoing port bit map can be obtained from indexing the VLAN ID to the VLAN ID look-up table at step 815
- a VPLS port bit map or a membership port bit map can also be obtained from indexing the SP VLAN ID tag to the SP VLAN ID look-up table.
- a logical AND operation can be performed on the two port bit maps to generate an egress port bit map at step 825 .
- a CoS can be assigned to the packet based on a SLA at step 830 , and the packet can be forwarded to one or more destination module(s) and an egress port based on the egress port bit map at step 835 .
- FIG. 9 shows one example of a method of processing a packet received on an uplink port or HiGig ingress port of a DT engine module based on a double tagging engine.
- a Layer 2 known unicast or a layer 2 known multicast packet can be received at the uplink port of a DT engine module at step 900 .
- a destination address and a customer VLAN ID can be identified from the packet at step 905 .
- an outgoing port bit map can be obtained from a look-up table at step 910 . If the packet received is a known unicast packet, then the outgoing port bit map can be obtained from an L2 Address look-up table. However, if the packet received is a known multicast packet, then the outgoing port bit map can be obtained from an L2 Multicast look-up table.
- a SP VLAN ID tag can be identified and removed from the packet at step 915 . Thereafter, the packet can be forwarded to one or more destination module(s) and one or more egress port(s) based on the outgoing port bit map at step 920 .
- the packet can be assigned a SP VLAN tag priority to the CoS at step 925 , and the CoS SEL register can be modified on the subscriber egress port(s) to match the CoS of the packet at step 930 .
- FIG. 10 shows one example of a method of processing a packet received on an uplink port or high Gigabit ingress port of a DT engine module based on a double tagging engine.
- a Layer 2 unknown unicast, broadcast, and multicast packet can be received at an ingress uplink port of a DT engine module at step 1000 .
- a SP VLAN ID tag can be identified and removed from the packet at step 1005 .
- the identified SP VLAN ID tag can be indexed to a Layer 2 multicast look-up table and obtain a L2 multicast index and a L2 multicast type from the look-up table at step 1010 .
- the packet can be appended with the L2 multicast index and the L2 multicast type at step 1015 .
- the operation code (op-code) within the module header of the packet can be modified to “multicast” when the multicast type appended within the packet matches a first predetermined type value at step 1020 .
- the operation code (op-code) within the module header of the packet can be modified to “IP multicast” when the multicast type appended within the packet matches a second predetermined type value also at step 1020 .
- a SP VLAN ID priority can be assigned to the packet's CoS at step 1025 . Thereafter, the packet can be forwarded to a high Gigabit ingress port of a network switching module within a PE device at step 1030 .
- the packet can be received at the high Gigabit port of a module with a PE device at step 1035 .
- an outgoing port bit map can be obtained from indexing the L2 multicast look-up table at step 1040 .
- the CoS SEL register can be modified on the subscriber egress port(s) to match the CoS of the packet at step 1045 , and thereafter the packet can be forwarded out of one or more subscriber customer facing port(s) based on the outgoing port bit map at step 1050 .
- the above-disclosed system configurations of the present invention can be embodied within a Virtual Private LAN Service (VPLS), a Transparent LAN Service (TLS), a Virtual Private Switched Network Service (VPSNS), or any Layer 2 Virtual Private Network (VPN).
- VPLS Virtual Private LAN Service
- TLS Transparent LAN Service
- VPNNS Virtual Private Switched Network Service
- the above-disclosed hardware configuration can be embodied in a semiconductor substrate, such as silicon.
- the methods of the invention can be implemented in hardware, or software, or a combination of both hardware and software.
- a person of skill in the art with respect to network system design and/or semiconductor design and manufacturing would be able to implement the various network systems, elements and methods of the present invention onto a single system or onto a single semiconductor substrate, respectively, based upon the architectural description discussed above.
Abstract
Description
- This application claims is a continuation application of U.S. patent application Ser. No. 10/378,937, filed Mar. 5, 2003, titled “FAST-PATH IMPLEMENTATION FOR AN UPLINK DOUBLE TAGGING ENGINE,” the disclosure of which is incorporated herein by reference in its entirety.
- The present invention relates to a method of and an apparatus for processing a packet based on a double tagging engine within a Virtual Private LAN Service (VPLS), a Transparent LAN Service (TLS), a Virtual Private Switched Network Service (VPSNS), or any
Layer 2 Virtual Private Network (VPN). In essence, the present invention can be applied to any packet-based service provider communication network environment, such as token ring, ATM, Ethernet, Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet. In particular, the present invention relates to a method of and an apparatus for fast-path implementation for TLS using double tagging engine that can be implemented on a semiconductor substrate such as a silicon chip, or can be implemented on software, or a combination of hardware and software. - As the popularity and usage of networked computers grows, an increasing amount of end-users are being interconnected via wide area networks and the Internet. In particular, business entities, such as corporations, having multiple site-offices located in different parts of the world, are increasingly relying on the Internet to communicate with each other. For instance, a corporate entity having multiple site-offices located at geographically dispersed sites may look to a fast and efficient way of using the Internet to interconnect a group of private site-offices belonging to the private corporate entity together. Accordingly, there is a need to provide a fast, inexpensive and reliable system that can offer a virtual private customer-based network wherein inter-office network connections are achieved using the fast growing Internet infrastructure, especially the Internet Service Provider (ISP).
- One example of the present invention can include a method for processing a packet in a communications network. The method can include the steps of: receiving a packet in an ingress port at a network component, identifying a destination address and a network identifier from the packet, obtaining an outgoing port bit map based on the destination address and the network identifier of the packet, and forwarding the packet to a destination module and out of an egress port within the network component based on the outgoing port bit map.
- In another example, the present invention can relate to a method for processing a packet in a communications network. The method can include the steps of receiving a packet in an ingress port at a network component, identifying a network identifier from the packet, accessing a packet tag corresponding to the packet, obtaining an outgoing port bit map based on the network identifier, and obtaining a membership port bit map based on the packet tag. In addition, the method can have the steps of generating an egress port bit map based on the outgoing port bit map and the membership port bit map, and forwarding the packet to a destination module and an egress port within the network component based on the egress port bit map.
- In yet another example, the present invention can be a method for processing a packet in a communications network. The method can include the steps of receiving a packet in an ingress port at a network component, identifying a source module and a source port corresponding to the packet, obtaining a packet tag from the packet tag table based on the source module and the source port, assigning a packet tag priority based on a class of service of the packet, and obtaining an ether-type from a register. Furthermore, the steps can include appending the packet received within the buffer with the packet tag, the packet tag priority and the ether-type, and forwarding the packet appended with the packet tag, the packet tag priority and the ether-type to an egress port within the network component.
- Another example of the present invention can be a method for processing a packet in a communications network. The method can have the steps of receiving a packet in an ingress port at a network component, removing a packet tag from the packet, obtaining a multicast index and a multicast type from indexing the packet tag to a look-up table, and appending the packet with the multicast index and the multicast type. Also, the method can have the steps of modifying an operational code of the packet to multicast when the multicast type is a first predetermined type, modifying the operation code of the packet to an IP multicast when the multicast type is a second predetermined type, assigning a first class of service for the packet with a packet tag priority, and forwarding the packet to a first egress port.
- Another example of the present invention can be a network component for processing a packet. The network component can have a buffer configured to receive a packet in an ingress port at a network component, a first identification unit configured to identify a destination address and a network identifier from the packet received at the buffer, a look-up table configured to be indexed by the destination address and the network identifier identified by the identification unit to obtain an outgoing port bit map, and a forwarding unit configured to forward the packet to a destination module and out of an egress port within the network component based on the outgoing port bit map.
- In another example, the present invention can relate to a network component for processing a packet. The network component can have a first buffer configured to receive a packet in an ingress port at a network component, a first identification unit configured to identify a network identifier from the packet received at the buffer, an accessing unit configured to access a packet tag corresponding to the packet received at the buffer, an outgoing port look-up table configured to be indexed by the network identifier identified by the identification unit to obtain an outgoing port bit map, a membership look-up table configured to be indexed by the packet tag accessed by the accessing unit to obtain a membership port bit map, a second buffer configured to store an egress port bit map based on the outgoing port bit map from the outgoing look-up table and the membership port bit map from the membership look-up table, and a forwarding unit configured to forward the packet to a destination module and an egress port within the network component based on the egress port bit map stored at the second buffer.
- In yet another example, the present invention can be directed to a network component for processing a packet. The network component can have a buffer configured to receive a packet in an ingress port at a network component, an identifying unit configured to identify a source module and a source port corresponding to the packet received at the buffer, a packet tag look-up table configured to be indexed by the source module and the source port identified by the identifying unit to obtain a packet tag, and an assigning unit configured to assign a packet tag priority based on a class of service of the packet received at the buffer. In addition, the present example can have a register configured to store an ether-type, an appending unit configured to append the packet received at the buffer with the packet tag, the packet tag priority and the ether-type, and a forwarding unit configured to forward the packet appended with the packet tag, the packet tag priority and the ether-type by the appending unit, to an egress port within the network component.
- In another example, the present invention can be related to a network component for processing a packet. The network component can include a buffer configured to receive a packet in an ingress port at a network component, a removing unit configured to remove a packet tag from the packet received at the buffer, a packet tag look-up table configured to be indexed by the packet tag removed from the removing unit to obtain a multicast index and a multicast type, and an appending unit configured to append the packet with the multicast index and the multicast type. Moreover, the present invention can have a modifying unit configured to modify an operational code of the packet to be multicast when the multicast type appended by the appending unit is a first predetermined type, a modifying unit configured to modify the operation code of the packet to be IP multicast when the multicast type is a second predetermined type, an assigning unit configured to assign a packet tag priority based on a first class of service of the packet received at the buffer, and a first forwarding unit configured to forward the packet to a first egress port.
- Another example of the present invention can be directed to a system of processing a packet in a network component. The system can have a receiving means for receiving a packet in an ingress port at a network component, a first identifying means for identifying a destination address and a network identifier from the packet, an obtaining means for obtaining an outgoing port bit map based on the destination address and the network identifier of the packet, and a forwarding means for forwarding the packet to a destination module and out of an egress port within the network component based on the outgoing port bit map.
- In yet another example, the present invention can relate to a system for processing a packet in a network component. The system can include a receiving means for receiving a packet in an ingress port at a network component, a first identifying means for identifying a network identifier from the packet, an accessing means for accessing a packet tag corresponding to the packet, a first obtaining means for obtaining an outgoing port bit map based on the network identifier, a second obtaining means for obtaining a membership port bit map based on the packet tag, a generating means for generating an egress port bit map based on the outgoing port bit map and the membership port bit map, and a forwarding means for forwarding the packet to a destination module and an egress port within the network component based on the egress port bit map.
- In another example, the present invention can include a system for processing a packet in a network component. The system can have a receiving means for receiving a packet in an ingress port at a network component, an identifying means for identifying a source module and a source port corresponding to the packet, a first obtaining means for obtaining a packet tag from the packet tag table based on the source module and the source port, and an assigning means for assigning a packet tag priority based on a class of service of the packet. Furthermore, the system can have a second obtaining means for obtaining an ether-type from a register, an appending means for appending the packet received within the buffer with the packet tag, the packet tag priority and the ether-type, and a forwarding means for forwarding the packet appended with the packet tag, the packet tag priority and the ether-type to an egress port within the network component.
- In another example, the present invention can include a system for processing a packet in a network component. The said system can have a first receiving means for receiving a packet in an ingress port at a network component, a removing means for removing a packet tag from the packet, a first obtaining means for obtaining a multicast index and a multicast type from indexing the packet tag to a look-up table, and an appending means for appending the packet with the multicast index and the multicast type. In addition, the system can have a first modifying means for modifying an operational code of the packet to multicast when the multicast type is a first predetermined type, a second modifying means for modifying the operation code of the packet to an IP multicast when the multicast type is a second predetermined type, an assigning means for assigning a first class of service for the packet with a packet tag priority, and a first forwarding means for forwarding the packet to a first egress port.
- For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:
-
FIG. 1 illustrates one example of a Transparent LAN Service Network System in accordance with the present invention; -
FIG. 2 illustrates another example of a Transparent LAN Service Network System in accordance with the present invention; -
FIG. 3 illustrates one example of a Provider Edge Device in accordance with the present invention; -
FIG. 4 illustrates another example of a Provider Edge Device in accordance with the present invention; -
FIG. 5( a) illustrates one example of a packet inserted with a customer VLAN ID tag in accordance with the present invention; -
FIG. 5( b) illustrates one example of a packet inserted with a customer VLAN ID tag, an SP VLAN tag, and additional information in accordance with the present invention; -
FIG. 6 illustrates one example of a method of processing a packet based on double tagging engine within a TLS network system; -
FIG. 7 illustrates another example of a method of processing a packet based on double tagging engine within a TLS network system; -
FIG. 8 illustrates yet another example of a method of processing a packet based on double tagging engine within a TLS network system; -
FIG. 9 illustrates one additional example of a method of processing a packet based on double tagging engine within a TLS network system; and -
FIG. 10 illustrates another example of a method of processing a packet based on double tagging engine within a TLS network system. -
FIG. 1 illustrates one example of a fast-path Transparent LAN Service (hereinafter “TLS”)network system 10 that can implement double tagging. TheTLS network system 10 of this example can be configured to deliver Ethernet or other service to multiple customers geographically dispersed across a network, such as a Wide Area Network (WAN) or Metro Area Network (MAN), as if the multiple customers were connected through a Local Area Network (LAN). - The
TLS network system 10 as shown inFIG. 1 illustrates a Service Provider Network (SPN) 20. The SPN 20 can be a packet switched network, such as the Internet. Also,FIG. 1 shows a plurality of Provider Edge (PE)devices PE 1,PE 2,PE 3 . . . PE n connected to the SPN 20. - In addition,
FIG. 1 illustratesTLS network system 10 having two VPLS customers, VPLS CUST A and VPLS CUST B. It is noted that althoughFIG. 1 shows aTLS network system 10 having two VPLS customers, the present invention can be configured to handle a plurality of VPLS customers CUST n within theTLS network system 10. - Each VPLS CUST A and B can be connected to a PE device. In addition, each VPLS customer can have its own plurality of independent Virtual Local Area Networks (VLAN),
VLAN 1,VLAN 2 . . . VLAN n. Accordingly,FIG. 1 showsVLAN 1,VLAN 2 . . . VLAN n of VPLS CUST A being “bridged” transparently overSPN 10, wherein a Service Provider VLAN,SP VLAN 30, can be configured to specifically carry all of VPLS CUST A's communication traffic. Similarly,FIG. 1 showsVLAN 1,VLAN 2 . . . VLAN n of VPLS CUST B being “bridged” transparently overSPN 10, whereinSP VLAN 40 can be configured to carry all of VPLS CUST B's communication traffic. -
FIG. 2 illustrates another example of aTLS network system 15 that can include aSPN 25 andPE devices PE 1 andPE 2. Each PE device can be configured to have a plurality of ports, such as at least one uplink port, upt 1 and one or more customer facing port(s),pt 0,pt 1 . . . pt n. Each port within each of the PE devices can be configured to be a receiving port, or an ingress port, as well as a transmitting port, or an egress port, for receiving and transmitting a packet, respectively. Although theTLS network system TLS network system - Further shown in
FIG. 2 , each port within the PE devices can be organized into groups of port(s) for one or more customer(s), wherein each organized group of port(s) can represent a VPLS domain for theTLS network system 15. According toFIG. 2 , a specific customer can be provided with one or more port(s) from the PE device. As such, each port from within the organized group of port(s) assigned to the specific customer can be designated to connect with each and every VLAN of that particular customer, or selected VLANs. It is noted that one or more customer(s) can share the same organized group of port(s) from the PE device if each customer share the same set of unique VLAN IDs. - For instance,
FIG. 2 showsPE devices PE 1 andPE 2 connected to aSPN 25 via an uplink port upt1, whereinPE 1 andPE 2 can be two geographically dispersed sites.PE 1 andPE 2, each has a plurality ofports pt 0, pt. 1,pt 2,pt 3 . . . pt n therein.Port pt 0 ofPE 1 is designated for VPLS CUST A only.Port pt 1 of the same PE device however is designed for two customers, them being VPLS CUST B and C. Furthermore,ports pt 3,pt 4,pt 5,pt 6,pt 7 andpt 8, are organized as a group of ports for VPLS CUST D. As forPE 2,port pt 4 is designated for VPLS CUST A andport pt 5 is designated to both VPLS CUST B and C. Also, ports pt n−3, pt n−2, pt n−1 and pt n, are organized as a group of ports for VPLS CUST D. -
FIG. 3 illustrates one example of a hardware configuration of a PE device. The hardware configuration ofFIG. 3 can be in an integrated, modular and single chip solution, and therefore can be embodied on a semiconductor substrate, such as silicon. Alternatively, the hardware configuration ofFIG. 3 can be embodied in a plurality of discrete components on a circuit board. -
FIG. 3 shows a PE device that can include a doubletagging engine module 300, anetwork module A 305, aswitch fabric module 310, anetwork module B 315, and anetwork module C 320. The doubletagging engine module 300 can have an uplinkport uplink pt 325 that can be a network port for connecting to the Ethernet, such as the Internet. In addition, the doubletagging engine module 300 can include a switch fabric port SF port a 330 for connecting to theswitch fabric module 310. - The PE device of
FIG. 3 also shows anetwork module A 305,network module B 315, andnetwork module C 320. Each of the network modules A, B and C can be a network switching chip made commercially available through Broadcom® Corporation. Additionally, each of the network modules A, B and C can have one or more customer facing ports, and one switch fabric port. The customer facing ports can connect the PE device to the customers or subscribers of the SPN. The SF ports a, b and c can connect each module to theswitch fabric module 310. The customer facing ports and the SF ports a, b and c can be an ingress port as well as an egress port. - The
switch fabric module 310 can also be a network switching chip made commercially available through Broadcom® Corporation. -
FIG. 4 illustrates one example of a hardware configuration of aPE device 400. The hardware configuration ofFIG. 4 can be in an integrated, modular and single chip solution, and therefore can be embodied on a semiconductor substrate, such as silicon. Alternatively, the hardware configuration ofFIG. 4 can be embodied in a plurality of discrete components on a circuit board. - The
PE device 400 can be configured to include at least one uplinkport uplink pt 401, and a plurality of customer facing ports or subscriber ports,pt 0,pt 1, . . . pt n. As mentioned above, each port within the PE device can be configured to be a receiving port, or an ingress port, as well as a transmitting port, or an egress port, for receiving and transmitting a packet, respectively. -
FIG. 5( a) illustrates one example of apacket 500 that can be received in or transmitted out of any one of the customer facing ports orsubscriber ports pt 0,pt 1, . . . pt n. Thepacket 500 can be configured to include, at least a destination address field DA, a source address field SA, a customer VLAN identification tag VLAN ID, a type or length field T/L, and a payload P. - The destination address field can be a bit value that can be used by the receiving Media Access Controller (MAC), in order to determine if the incoming packet is addressed to the particular port. There can typically be three types of destination addresses i) unicast/individual or physical DA, ii) multicast or logical DA and iii) broadcast DA. The source address field can be a bit value and can be supplied by the transmitting MAC, which can insert its own unique address into the source address field as the frame is transmitted, indicating it was the original station. The receiving MAC is not required to take action based on the source address field. Furthermore, the customer VLAN ID tag is a first packet tag inserted within the packet. The VLAN ID tag can identify a particular VLAN for a unique customer. In other words, if a customer has a plurality of VLANs, such as
VLAN 1, VLAN . . . VLANn, the customer VLAN ID tag can identify the packet as originating from one of the customer's VLANs. The T/L field can provide the type or the length of the packet. The payload P can contain the actual frame data that is being transferred. -
FIG. 5( b) illustrates one example of apacket 510 that can be received in or transmitted out of theuplink pt 401. Thepacket 510 can be configured to include, at least a destination address field DA, a source address field SA, an SP VLAN tag, a customer VLAN identification tag VLAN ID, an Ether-type, a SP VLAN tag priority, an op-code and a payload P. -
Packet 510 can include an SP VLAN ID tag, which can be a second tag in thepacket 510. The SP VLAN ID tag can specify or identify a customer within theTLS network system 10. In other words, if aTLS network system 10 includes a plurality of customers, such as VPLS CUST A, VPLS CUST B, VPLS CUST C, and VPLS CUST D, the SP VLAN ID tag can identify the packet as originating from and belonging to a particular VPLS customer. - Therefore,
packet 510 can include at least a first tag, that being a customer VLAN ID tag, and a second tag, that being a SP VLAN ID tag. The SP VLAN ID tag can identify the packet as belonging to a particular VPLS customer, and the VLAN ID tag can identify the particular VLAN belonging to that VPLS customer. Accordingly, a packet having a first and second tag can always be identified as belonging to a unique VPLS customer, even if a plurality of the VPLS customers have overlapping or common VLAN IDs. -
FIG. 4 can include astorage unit 402, such as a register. Thestorage unit 402 can be configured to store a one-bitDT engine bit 403. TheDT engine bit 403 can either be set or not set by preprogramming. For example, theDT engine bit 403 can have either the value of “1” which sets theDT engine bit 403, or the value of “0” which un-set theDT engine bit 403. When theDT engine bit 403 is set, then thePE device 400 can be operating under tagging engine mode. For instance, a bit value of “1” can indicate that thePE device 400 is operating under double tagging engine mode, and whereby a bit value of “0” can indicate that thePE device 400 is not operating under double tagging engine mode. - Furthermore, the
PE device 400 ofFIG. 4 can be configured to include a plurality of look-up tables, such as an SP VLAN ID tag look-up table 404, a VPLS look-up table 408, a VLAN look-up table 416, an L2 multicast look-up table 420, and an L2 address look-up table 424. - The SP VLAN ID tag look-up table 404 can include one or more SP VLAN ID tag(s) 406 therein and can be indexed by a source module and a source port from a packet. The SP VLAN ID tag(s) 406 within the table 404 can be obtained when a packet received at the
PE device 400 is to be forwarded to theuplink port 401, wherein the packet is to be double tagged. - The VPLS look-up table 408 can have one or more entries therein. The VLPS look-up table 408 can be indexed by a SP VLAN ID tag so that one or more entries therein may be accessed or identified. Each mask entry can be configured to have a VPLS
port bit map 410 or a membership port bit map therein. The VPLSport bit map 410 can be a bit string having a bit length that can be equal, for example, to a number of ports with thePE device 400. Each bit position of the VPLSport bit map 410 can correspond to a particular port within thePE device 400. In essence, the VPLSport bit map 410 can be configured to identify a group of one or more port(s) that correspond or belong to a particular VPLS membership for a PE device. In other words, the VPLSport bit map 410 can identify a group of one or more port(s) to which an unique customer's VLAN(s) can be mapped. Accordingly, each bit position of the VPLSport bit map 410 can be set with a value or condition of either “1” or “0”. By setting a bit position within the VPLSport bit map 410 with a value or condition of “1”, the port corresponding to the bit position can be included as part of the group of port(s) associated with the VPLS membership. In the alternative, by setting a bit position within the VPLSport bit map 410 with a value or condition of “0”, the port corresponding to the bit position can be excluded from the group of port(s) associated with the VPLS membership. - In addition, each entry within the VPLS look-up table 408 can include a
Layer 2multicast index 412 and aVPLS type 414. TheLayer 2multicast index 412 and theVPLS type 414 can correspond to a VPLSport bit map 410. -
FIG. 4 also shows a VLAN ID look up table 416 within thePE device 400. The VLAN ID look-up table 416 can include one or more preprogrammed mask entries therein. Each mask entry can be configured to be an outgoingport bit map 418. Theoutgoing bit map 418 can be a bit string having any bit length. Each bit position of theoutgoing bit map 418 can correspond to a particular port of a particular module within thePE device 400 for a particular VLAN ID. In essence, theoutgoing bit map 418 can be configured to identify one or more outgoing port(s) with respect to a particular VLAN ID. Accordingly, each bit position of theoutgoing bit map 418 can be set with a value or condition of either “1” or “0”. By setting a bit position within theoutgoing bit map 418 with a value or condition of “1”, the port of a specified module corresponding to the bit position can be identified or specified as an outgoing port associated with a particular customer VLAN ID. In the alternative, by setting a bit position within theoutgoing bit map 418 with a value or condition of “0”, the port of a specified module corresponding to the bit position can be identified or specified as not being included as an outgoing port of a particular customer VLAN ID. - The VLAN ID look-up table 416 can be indexed by the VLAN ID tag from the
packet 500 ofFIG. 5( a) as an example. Upon receiving the packet in an ingress port, the VLAN ID can be identified and indexed into the VLAN ID look-up table 416, wherein one VLAN ID mask entry having an outgoingport bit map 418 can be identified. -
FIG. 4 also shows an L2 Multicast look-up table 420 within thePE device 400. The L2 Multicast look-up table 420 can include one or more preprogrammed mask entries therein, and the size of the L2 Multicast lookup table 420 can equal to the number of multicast groups supported by thePE device 400. In addition, each mask entry within the L2 Multicast look-up table 420 can be accessed or identified by using the customer VLAN ID and the multicast DA within the packet received. Each entry can contain a list of ports which map to a L2 multicast group. - Each mask entry within the L2 Multicast look-up table 420 can be configured to be an outgoing
port bit map 422 which can be a list of ports which maps to an L2 Multicast group. The L2 Multicast look-up table 420 can be used to flood multicast packets to only those ports which have memberships of the L2 multicast group. In other words, rather than flooding a packet to the entire group of ports belonging to a particular VLAN ID, each outgoingport bit map 422 within the L2 Multicast table can be used to flood a packet to only the ports having membership of the L2 multicast group. - The outgoing
port bit map 422 within the L2 Multicast look-up table 420 can be a bit string having any bit length. Each bit position of the outgoingport bit map 422 can correspond to a particular port within thePE device 400 having an L2 multicast membership. In essence, the outgoingport bit map 422 can be configured to identify one or more outgoing port(s) with respect to a particular L2 multicast group. Accordingly, each bit position of the outgoingport bit map 422 can be set with a value or condition of either “1” or “0”. By setting a bit position within the outgoingport bit map 422 with a value or condition of “1”, the port corresponding to the bit position can be identified or specified as an outgoing port associated with a particular L2 multicast membership with respect to the packet received. In the alternative, by setting a bit position within the outgoingport bit map 422 with a value or condition of “0”, the port corresponding to the bit position can be identified or specified as not being included as an outgoing port of a particular L2 multicast group with respect to the packet received. - Furthermore,
FIG. 4 shows an L2 Address look-up table 424 within thePE device 400. The L2 Address look-up table 424 can include one or more preprogrammed mask entries therein. In addition, each mask entry within the L2 Address look-up table 424 can be accessed or identified by indexing the customer VLAN ID and the DA within the packet received. - Each mask entry within the L2 Address look-up table 424 can be configured to be an outgoing
port bit map 426. The outgoingport bit map 426 within the L2 Address look-up table 424 can be a bit string having any bit length. Each bit position of the outgoingport bit map 426 can correspond to a port within thePE device 400. In essence, the outgoingport bit map 426 can be configured to identify one or more outgoing port(s) with respect to a packet received. Similar to above, each bit position of theoutgoing bit map 426 can be set with a value or condition of either “1” or “0”. By setting a bit position within theoutgoing bit map 426 with a value or condition of “1”, the port corresponding to the bit position can be identified or specified as an outgoing port with respect to the packet received. In the alternative, by setting a bit position within theoutgoing bit map 426 with a value or condition of “0”, the port corresponding to the bit position can be identified or specified as not being an outgoing port with respect to the packet received. - The PE device of
FIG. 3 can also include aCPU 428. TheCPU 428 can be configured to implement a plurality of tasks and operations. - In addition, the
PE device 400 ofFIG. 4 can include an Ether-type configuration register 430. The Ether-type configuration register 430 can be configured to store an Ether-type value and can be accessed and inserted into a packet transmitted from an uplink port. Also, thePE device 400 can have one or more class of service select register(s) 434 for storing a class of service type. The class of service select register(s) 434 can correspond to a customer port. -
FIGS. 6-10 illustrate one or more examples of a method of processing and double tagging a packet based on a double tagging engine thereof in accordance with the present invention. The method of the present example can be implemented in hardware, or software, or a combination of both hardware and software. -
FIG. 6 shows one example of a method of processing a packet received on an Ethernet access port of a module based on a double tagging engine. A knownLayer 2 unicast or a knownLayer 2 multicast packet can be received at a customer subscriber port atstep 600. A known unicast packet can be a packet that is relayed or transmitted to only one known destination port. In contrast, a known multicast packet can be a packet that is relayed or transmitted to multiple known destination ports. Moreover, an unknown unicast/multicast/broadcast packet can be a destination-lookup-failure packet. In other words, a received packet can be an unknown unicast/multicast/broadcast packet due to a failure in the destination address (DA) lookup for the packet received. Therefore, if the destination address lookup is not successful, then the destination port or ports with respect to the packet received is unknown. - Therefore, a known unicast or a known multicast packet can be received at one of the customer facing ports of a PE device. Once the packet is received, a destination address and a customer VLAN ID can be identified from the packet at
step 605. - After identifying the destination address and the customer VLAN ID from the packet, an outgoing port bit map can be obtained from a look-up table at
step 610. If the packet received is a known unicast packet, then the outgoing port bit map can be obtained from an L2 Address look-up table. However, if the packet received is a known multicast packet, then the outgoing port bit map can be obtained from an L2 Multicast look-up table. - Once the outgoing port bit map is obtained, a fast filtering processor can assign a class of service (CoS) to the module header of the packet based on a service level agreement (SLA) at
step 615. Thereafter, the packet can be forwarded to one or more destination module(s) and one or more egress port(s) based on the outgoing port bit map atstep 620. -
FIG. 7 shows one example of a method of processing a packet received on an Ethernet access port of a DT engine module based on a double tagging engine. A knownLayer 2 unicast, knownLayer 2 multicast, or anunknown Layer 2 unicast, multicast or broadcast packet can be received at an Ethernet access port of a DT engine module atstep 700. Once the packet is received at the Ethernet access port of the DT engine module, a source module and a source port corresponding to the packet is identified atstep 705. In other words, the source module and the source port indicate the source where the packet originated therefrom. - Thereafter, the source module and the source port can be indexed to a SP VLAN tag look-up table to obtain a SP VLAN tag, which corresponds to the source module and the source port at
step 710. Once the SP VLAN tag is obtained from the SP VLAN tag look-up table, a SP VLAN tag priority can be assigned to the packet based on the CoS of the packet atstep 715. Additionally, an Ether-type value can be obtained from an Ether-type configuration register atstep 720. - After obtaining the SP VLAN tag, and an Ether-type value, and assigning a SP VLAN tag priority, the packet received can be appended with the above information at
step 725. In other words, the packet received at the Ethernet access port of a DT engine module can be appended with a SP VLAN tag, a SP VLAN tag priority and a Ether-type value therein. Once the packet is appended with such information, the packet can be forwarded out of the uplink port of the DT engine module to a SPN atstep 730. -
FIG. 8 shows one example of a method of processing a packet received on an Ethernet access port of a module based on a double tagging engine. Anunknown Layer 2 unicast, multicast and broadcast packet can be received at subscriber port or a customer facing port of one or more network switching module such as Draco, or Tucana atstep 800. Once the packet is received, a customer VLAN ID can be identified from the packet atstep 805. In addition, a SP VLAN ID tag, can be identified from the packet atstep 810. - After the VLAN ID and the SP VLAN ID tag have been identified from the packet, the VLAN ID can be indexed to a VLAN ID look-up table and the SP VLAN ID tag can similarly be indexed to a SP VLAN ID look-up table. Thus, an outgoing port bit map can be obtained from indexing the VLAN ID to the VLAN ID look-up table at
step 815, and a VPLS port bit map or a membership port bit map can also be obtained from indexing the SP VLAN ID tag to the SP VLAN ID look-up table. - Once the outgoing port bit map and the VPLS port bit map are obtained, a logical AND operation can be performed on the two port bit maps to generate an egress port bit map at
step 825. Thereafter, a CoS can be assigned to the packet based on a SLA atstep 830, and the packet can be forwarded to one or more destination module(s) and an egress port based on the egress port bit map atstep 835. -
FIG. 9 shows one example of a method of processing a packet received on an uplink port or HiGig ingress port of a DT engine module based on a double tagging engine. ALayer 2 known unicast or alayer 2 known multicast packet can be received at the uplink port of a DT engine module atstep 900. Once the packet is received, a destination address and a customer VLAN ID can be identified from the packet atstep 905. - After identifying the destination address and the customer VLAN ID from the packet, an outgoing port bit map can be obtained from a look-up table at
step 910. If the packet received is a known unicast packet, then the outgoing port bit map can be obtained from an L2 Address look-up table. However, if the packet received is a known multicast packet, then the outgoing port bit map can be obtained from an L2 Multicast look-up table. - Once the outgoing port bit map is obtained, a SP VLAN ID tag can be identified and removed from the packet at
step 915. Thereafter, the packet can be forwarded to one or more destination module(s) and one or more egress port(s) based on the outgoing port bit map atstep 920. The packet can be assigned a SP VLAN tag priority to the CoS atstep 925, and the CoS SEL register can be modified on the subscriber egress port(s) to match the CoS of the packet atstep 930. -
FIG. 10 shows one example of a method of processing a packet received on an uplink port or high Gigabit ingress port of a DT engine module based on a double tagging engine. ALayer 2 unknown unicast, broadcast, and multicast packet can be received at an ingress uplink port of a DT engine module atstep 1000. Upon receiving the packet, a SP VLAN ID tag can be identified and removed from the packet atstep 1005. - The identified SP VLAN ID tag can be indexed to a
Layer 2 multicast look-up table and obtain a L2 multicast index and a L2 multicast type from the look-up table atstep 1010. The packet can be appended with the L2 multicast index and the L2 multicast type atstep 1015. Once the packet is appended with the multicast index and the multicast type, the operation code (op-code) within the module header of the packet can be modified to “multicast” when the multicast type appended within the packet matches a first predetermined type value atstep 1020. Additionally, the operation code (op-code) within the module header of the packet can be modified to “IP multicast” when the multicast type appended within the packet matches a second predetermined type value also atstep 1020. - Once the packet is appended with the multicast index and type, and the op-code within the module header of the packet is modified, a SP VLAN ID priority can be assigned to the packet's CoS at
step 1025. Thereafter, the packet can be forwarded to a high Gigabit ingress port of a network switching module within a PE device atstep 1030. - The packet can be received at the high Gigabit port of a module with a PE device at
step 1035. Once the packet is received, an outgoing port bit map can be obtained from indexing the L2 multicast look-up table atstep 1040. After the outgoing port bit map is obtained, the CoS SEL register can be modified on the subscriber egress port(s) to match the CoS of the packet atstep 1045, and thereafter the packet can be forwarded out of one or more subscriber customer facing port(s) based on the outgoing port bit map atstep 1050. - The above-disclosed system configurations of the present invention can be embodied within a Virtual Private LAN Service (VPLS), a Transparent LAN Service (TLS), a Virtual Private Switched Network Service (VPSNS), or any
Layer 2 Virtual Private Network (VPN). In addition, the above-disclosed hardware configuration can be embodied in a semiconductor substrate, such as silicon. Furthermore, the methods of the invention can be implemented in hardware, or software, or a combination of both hardware and software. In addition, a person of skill in the art with respect to network system design and/or semiconductor design and manufacturing would be able to implement the various network systems, elements and methods of the present invention onto a single system or onto a single semiconductor substrate, respectively, based upon the architectural description discussed above. - One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.
Claims (1)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/427,553 US20090196289A1 (en) | 2002-10-07 | 2009-04-21 | Fast-path implementation for an uplink double tagging engine |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US41626902P | 2002-10-07 | 2002-10-07 | |
US10/378,937 US7539185B2 (en) | 2002-10-07 | 2003-03-05 | Fast-path implementation for an uplink double tagging engine |
US12/427,553 US20090196289A1 (en) | 2002-10-07 | 2009-04-21 | Fast-path implementation for an uplink double tagging engine |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/378,937 Continuation US7539185B2 (en) | 2002-10-07 | 2003-03-05 | Fast-path implementation for an uplink double tagging engine |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090196289A1 true US20090196289A1 (en) | 2009-08-06 |
Family
ID=32033373
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/378,937 Expired - Fee Related US7539185B2 (en) | 2002-10-07 | 2003-03-05 | Fast-path implementation for an uplink double tagging engine |
US12/427,553 Abandoned US20090196289A1 (en) | 2002-10-07 | 2009-04-21 | Fast-path implementation for an uplink double tagging engine |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/378,937 Expired - Fee Related US7539185B2 (en) | 2002-10-07 | 2003-03-05 | Fast-path implementation for an uplink double tagging engine |
Country Status (3)
Country | Link |
---|---|
US (2) | US7539185B2 (en) |
EP (1) | EP1408655B1 (en) |
DE (1) | DE60332591D1 (en) |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080250492A1 (en) * | 2007-04-06 | 2008-10-09 | Ludovic Hazard | Structure and implementation of universal virtual private networks |
WO2012127490A1 (en) * | 2011-03-24 | 2012-09-27 | Tejas Networks Limited | Interworkinq network element |
US20130107887A1 (en) * | 2011-10-26 | 2013-05-02 | Mark A. Pearson | Maintaining virtual network context across multiple infrastructures |
US20130201984A1 (en) * | 2012-02-03 | 2013-08-08 | Gigamon Llc | Systems and methods for packet filtering and switching |
US10122614B2 (en) | 2015-02-26 | 2018-11-06 | Cisco Technology, Inc. | Failure protection for traffic-engineered bit indexed explicit replication |
US10218524B2 (en) | 2013-09-17 | 2019-02-26 | Cisco Technology, Inc. | Bit indexed explicit replication for layer 2 networking |
US10218610B2 (en) | 2012-10-05 | 2019-02-26 | Cisco Technology, Inc. | MPLS segment routing |
US10225090B2 (en) | 2013-09-17 | 2019-03-05 | Cisco Technology, Inc. | Bit indexed explicit replication using multiprotocol label switching |
US10263881B2 (en) | 2016-05-26 | 2019-04-16 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
US10270664B2 (en) | 2013-03-15 | 2019-04-23 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
US10382334B2 (en) | 2014-03-06 | 2019-08-13 | Cisco Technology, Inc. | Segment routing extension headers |
US10404482B2 (en) | 2013-09-17 | 2019-09-03 | Cisco Technology, Inc. | Bit indexed explicit replication forwarding optimization |
US10432425B2 (en) | 2017-03-30 | 2019-10-01 | Cisco Technology, Inc. | Internet protocol based encapsulation for bit indexed explicit replication (BIER) |
US10461946B2 (en) | 2013-09-17 | 2019-10-29 | Cisco Technology, Inc. | Overlay signaling for bit indexed explicit replication |
US10536324B2 (en) | 2013-09-17 | 2020-01-14 | Cisco Technology, Inc. | Per-prefix LFA FRR with bit indexed explicit replication |
US10574479B2 (en) | 2017-04-28 | 2020-02-25 | Cisco Technology, Inc. | Bridging of non-capable subnetworks in bit indexed explicit replication |
US10601707B2 (en) | 2014-07-17 | 2020-03-24 | Cisco Technology, Inc. | Segment routing using a remote forwarding adjacency identifier |
US10630743B2 (en) | 2016-09-23 | 2020-04-21 | Cisco Technology, Inc. | Unicast media replication fabric using bit indexed explicit replication |
US10637675B2 (en) | 2016-11-09 | 2020-04-28 | Cisco Technology, Inc. | Area-specific broadcasting using bit indexed explicit replication |
US10637686B2 (en) | 2015-01-27 | 2020-04-28 | Cisco Technology, Inc. | Capability aware routing |
US10749776B2 (en) * | 2017-10-10 | 2020-08-18 | Bull Sas | Method for generating requests for the segmentation of the monitoring of an interconnection network and associated hardware |
US11032197B2 (en) | 2016-09-15 | 2021-06-08 | Cisco Technology, Inc. | Reroute detection in segment routing data plane |
US11451474B2 (en) | 2013-09-17 | 2022-09-20 | Cisco Technology, Inc. | Equal cost multi-path with bit indexed explicit replication |
US11722404B2 (en) | 2019-09-24 | 2023-08-08 | Cisco Technology, Inc. | Communicating packets across multi-domain networks using compact forwarding instructions |
Families Citing this family (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3521904B2 (en) * | 2002-08-22 | 2004-04-26 | 日本電気株式会社 | Frame transfer method and node in Ethernet (R) |
US8225389B2 (en) * | 2003-04-11 | 2012-07-17 | Broadcom Corporation | Method and system to provide physical port security in a digital communication system |
US7738467B2 (en) * | 2003-07-15 | 2010-06-15 | Hewlett-Packard Development Company, L.P. | Output port based double Q tagging |
US7580409B1 (en) * | 2003-09-08 | 2009-08-25 | Extreme Networks, Inc. | System for and method of communicating control information between entities interconnected by backplane connections |
US7751416B2 (en) * | 2003-09-18 | 2010-07-06 | Cisco Technology, Inc. | Virtual network device |
US7839843B2 (en) * | 2003-09-18 | 2010-11-23 | Cisco Technology, Inc. | Distributed forwarding in virtual network devices |
US8526427B1 (en) | 2003-10-21 | 2013-09-03 | Cisco Technology, Inc. | Port-based loadsharing for a satellite switch |
US7733869B2 (en) * | 2003-12-10 | 2010-06-08 | Alcatel-Lucent | Providing VPLS-like service over native ATM networks |
US8990430B2 (en) * | 2004-02-19 | 2015-03-24 | Cisco Technology, Inc. | Interface bundles in virtual network devices |
US8208370B1 (en) | 2004-03-31 | 2012-06-26 | Cisco Technology, Inc. | Method and system for fast link failover |
US7889733B2 (en) * | 2004-04-28 | 2011-02-15 | Cisco Technology, Inc. | Intelligent adjunct network device |
US7710957B2 (en) | 2004-05-19 | 2010-05-04 | Cisco Technology, Inc. | System and method for implementing multiple spanning trees per network |
US7706364B2 (en) | 2004-05-19 | 2010-04-27 | Cisco Technology, Inc. | Virtual network device clusters |
US7436836B2 (en) * | 2004-06-30 | 2008-10-14 | Cisco Technology, Inc. | Method and apparatus for detecting support for a protocol defining supplemental headers |
US7808983B2 (en) | 2004-07-08 | 2010-10-05 | Cisco Technology, Inc. | Network device architecture for centralized packet processing |
US7672314B2 (en) * | 2004-07-09 | 2010-03-02 | Cisco Technology, Inc. | Scaling VLANs in a data network |
US8730976B2 (en) * | 2004-08-17 | 2014-05-20 | Cisco Technology, Inc. | System and method for preventing erroneous link aggregation due to component relocation |
CN100438493C (en) * | 2004-09-10 | 2008-11-26 | 华为技术有限公司 | Improvement of user access capacity of wide band access apparatus |
EP1667380B1 (en) * | 2004-12-03 | 2013-02-27 | Alcatel Lucent | Method for transmitting information from a source via a first network unit and a network and a second network unit to a destination |
CN100382531C (en) * | 2005-10-28 | 2008-04-16 | 杭州华三通信技术有限公司 | Switching in method for virtual special network and realizing apparatus |
US8018964B2 (en) * | 2005-12-16 | 2011-09-13 | Cisco Technology, Inc. | Multicast operations using prioritized state information |
US8902908B2 (en) * | 2006-05-02 | 2014-12-02 | Cisco Technology, Inc. | Support of a large number of VLANs in a bridged network |
US8379676B1 (en) | 2006-06-01 | 2013-02-19 | World Wide Packets, Inc. | Injecting in-band control messages without impacting a data rate |
US7760723B1 (en) * | 2006-06-01 | 2010-07-20 | World Wide Packets, Inc. | Relaying a data stream from a data device to a network tunnel |
US7653056B1 (en) * | 2006-06-02 | 2010-01-26 | World Wide Packets, Inc. | Virtual switching using a provisional identifier to conceal a user identifier |
US8018938B1 (en) | 2006-06-02 | 2011-09-13 | World Wide Packets, Inc. | Translating between a switching format and a transport format |
US8379644B1 (en) | 2006-06-30 | 2013-02-19 | Marvell International Ltd. | System and method of processing management frames |
US7830883B1 (en) | 2006-12-19 | 2010-11-09 | World Wide Packets, Inc. | Modifying duplicate packets to have different transport formats |
IL190433A (en) * | 2007-03-26 | 2012-07-31 | Marvell Israel Misl Ltd | System and method of modifying data packet tags |
WO2009018483A1 (en) * | 2007-07-31 | 2009-02-05 | Viasat, Inc. | Input output access controller |
US8125991B1 (en) * | 2007-07-31 | 2012-02-28 | Hewlett-Packard Development Company, L.P. | Network switch using managed addresses for fast route lookup |
JP2009094832A (en) * | 2007-10-10 | 2009-04-30 | Nec Access Technica Ltd | Multicast data distribution apparatus, distribution method therefor, and distribution control program thereof |
US20090285207A1 (en) * | 2008-05-15 | 2009-11-19 | Cohen Yochai | System and method for routing packets using tags |
US7916761B2 (en) * | 2008-11-03 | 2011-03-29 | The Boeing Company | Methods and apparatus for adding latency and jitter to selected network packets |
US8411689B2 (en) | 2009-09-23 | 2013-04-02 | Aerovironment, Inc. | Fault-tolerant, frame-based communication system |
EP2480982B1 (en) * | 2009-09-23 | 2014-12-17 | Aerovironment, Inc. | Fault-tolerant, frame-based communication system |
US8885475B2 (en) * | 2010-09-10 | 2014-11-11 | Fujitsu Limited | Method and system for virtualized forwarding |
US9571337B1 (en) * | 2010-12-22 | 2017-02-14 | Juniper Networks, Inc. | Deriving control plane connectivity during provisioning of a distributed control plane of a switch |
US8798077B2 (en) * | 2010-12-29 | 2014-08-05 | Juniper Networks, Inc. | Methods and apparatus for standard protocol validation mechanisms deployed over a switch fabric system |
CN104009926B (en) * | 2013-02-26 | 2017-04-12 | 杭州华三通信技术有限公司 | Multicast method in EVI network and edge device ED |
US9860081B2 (en) | 2013-06-18 | 2018-01-02 | Extreme Networks, Inc. | General user network interface (UNI) multi-homing techniques for shortest path bridging (SPB) networks |
US10708189B1 (en) | 2016-12-09 | 2020-07-07 | Barefoot Networks, Inc. | Priority-based flow control |
US10735331B1 (en) * | 2016-12-09 | 2020-08-04 | Barefoot Networks, Inc. | Buffer space availability for different packet classes |
US10412018B1 (en) | 2017-03-21 | 2019-09-10 | Barefoot Networks, Inc. | Hierarchical queue scheduler |
CN112583510A (en) * | 2019-09-30 | 2021-03-30 | 华为技术有限公司 | Message forwarding method, device and system |
CN112787928A (en) * | 2019-11-07 | 2021-05-11 | 中兴通讯股份有限公司 | Multi-service forwarding method, switch, electronic device and readable medium |
JP2021197562A (en) * | 2020-06-09 | 2021-12-27 | 富士通株式会社 | Communication apparatus and communication method |
US11665087B2 (en) | 2021-09-15 | 2023-05-30 | International Business Machines Corporation | Transparent service-aware multi-path networking with a feature of multiplexing |
Family Cites Families (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5394402A (en) * | 1993-06-17 | 1995-02-28 | Ascom Timeplex Trading Ag | Hub for segmented virtual local area network with shared media access |
US5617421A (en) * | 1994-06-17 | 1997-04-01 | Cisco Systems, Inc. | Extended domain computer network using standard links |
US6035105A (en) * | 1996-01-02 | 2000-03-07 | Cisco Technology, Inc. | Multiple VLAN architecture system |
US6085238A (en) * | 1996-04-23 | 2000-07-04 | Matsushita Electric Works, Ltd. | Virtual LAN system |
US6052751A (en) * | 1997-02-14 | 2000-04-18 | Advanced Micro Devices, I Nc. | Method and apparatus for changing the number of access slots into a memory |
US6041057A (en) * | 1997-03-24 | 2000-03-21 | Xylan Corporation | Self-configuring ATM network |
US5938736A (en) * | 1997-06-30 | 1999-08-17 | Sun Microsystems, Inc. | Search engine architecture for a high performance multi-layer switch element |
US5991297A (en) * | 1997-08-28 | 1999-11-23 | Ascend Communications | Independently sizable memory pages for a plurality of connection ID types in a network switch |
US6115379A (en) * | 1997-09-11 | 2000-09-05 | 3Com Corporation | Unicast, multicast, and broadcast method and apparatus |
US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
US6728249B2 (en) * | 1998-06-27 | 2004-04-27 | Intel Corporation | System and method for performing cut-through forwarding in an ATM network supporting LAN emulation |
US6181699B1 (en) * | 1998-07-01 | 2001-01-30 | National Semiconductor Corporation | Apparatus and method of assigning VLAN tags |
GB9824594D0 (en) * | 1998-11-11 | 1999-01-06 | 3Com Technologies Ltd | Modifying tag fields in ethernet data packets |
US6788681B1 (en) * | 1999-03-16 | 2004-09-07 | Nortel Networks Limited | Virtual private networks and methods for their operation |
US6937574B1 (en) * | 1999-03-16 | 2005-08-30 | Nortel Networks Limited | Virtual private networks and methods for their operation |
US6553028B1 (en) * | 1999-04-30 | 2003-04-22 | Cisco Technology, Inc. | Method and apparatus for multicast switching using a centralized switching engine |
US6778547B1 (en) * | 1999-05-21 | 2004-08-17 | Advanced Micro Devices, Inc. | Method and apparatus for improving throughput of a rules checker logic |
US6633565B1 (en) * | 1999-06-29 | 2003-10-14 | 3Com Corporation | Apparatus for and method of flow switching in a data communications network |
US6862280B1 (en) * | 2000-03-02 | 2005-03-01 | Alcatel | Priority remapping for data communication switch |
US6901452B1 (en) * | 2000-03-02 | 2005-05-31 | Alcatel | Selectable prioritization for data communication switch |
US6693909B1 (en) * | 2000-05-05 | 2004-02-17 | Fujitsu Network Communications, Inc. | Method and system for transporting traffic in a packet-switched network |
US6965572B1 (en) * | 2000-06-07 | 2005-11-15 | At&T Corp. | Loopback capability for bi-directional multi-protocol label switching traffic engineered trucks |
JP4126856B2 (en) * | 2000-07-07 | 2008-07-30 | 沖電気工業株式会社 | TAG-VLAN ID automatic identification method |
US20020062415A1 (en) * | 2000-09-29 | 2002-05-23 | Zarlink Semiconductor N.V. Inc. | Slotted memory access method |
JP4183379B2 (en) * | 2000-11-27 | 2008-11-19 | 富士通株式会社 | Network and edge router |
US6618388B2 (en) * | 2001-01-05 | 2003-09-09 | Extreme Networks | Method and system for VMAN protocol |
US7136355B2 (en) * | 2001-01-16 | 2006-11-14 | Admtek Incorporated | Transmission components for processing VLAN tag and priority packets supported by using single chip's buffer structure |
US7242665B2 (en) * | 2001-01-25 | 2007-07-10 | Ericsson Ab | Network device virtual interface |
US7092389B2 (en) * | 2001-01-30 | 2006-08-15 | At&T Corp. | Technique for ethernet access to packet-based services |
US20020176450A1 (en) * | 2001-01-31 | 2002-11-28 | Sycamore Networks, Inc. | System and methods for selectively transmitting ethernet traffic over SONET/SDH optical network |
JP4192446B2 (en) * | 2001-06-29 | 2008-12-10 | 株式会社日立製作所 | Communication service transaction method and communication system |
US20030152075A1 (en) * | 2002-02-14 | 2003-08-14 | Hawthorne Austin J. | Virtual local area network identifier translation in a packet-based network |
US7095738B1 (en) * | 2002-05-07 | 2006-08-22 | Cisco Technology, Inc. | System and method for deriving IPv6 scope identifiers and for mapping the identifiers into IPv6 addresses |
US7180899B2 (en) * | 2002-10-29 | 2007-02-20 | Cisco Technology, Inc. | Multi-tiered Virtual Local area Network (VLAN) domain mapping mechanism |
-
2003
- 2003-03-05 US US10/378,937 patent/US7539185B2/en not_active Expired - Fee Related
- 2003-10-07 EP EP03022682A patent/EP1408655B1/en not_active Expired - Lifetime
- 2003-10-07 DE DE60332591T patent/DE60332591D1/en not_active Expired - Lifetime
-
2009
- 2009-04-21 US US12/427,553 patent/US20090196289A1/en not_active Abandoned
Cited By (59)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8705549B2 (en) * | 2007-04-06 | 2014-04-22 | International Business Machines Corporation | Structure and implementation of universal virtual private networks |
US20080250492A1 (en) * | 2007-04-06 | 2008-10-09 | Ludovic Hazard | Structure and implementation of universal virtual private networks |
WO2012127490A1 (en) * | 2011-03-24 | 2012-09-27 | Tejas Networks Limited | Interworkinq network element |
US20130107887A1 (en) * | 2011-10-26 | 2013-05-02 | Mark A. Pearson | Maintaining virtual network context across multiple infrastructures |
US20130201984A1 (en) * | 2012-02-03 | 2013-08-08 | Gigamon Llc | Systems and methods for packet filtering and switching |
US8891527B2 (en) * | 2012-02-03 | 2014-11-18 | Gigamon Inc. | Systems and methods for packet filtering and switching |
US10218610B2 (en) | 2012-10-05 | 2019-02-26 | Cisco Technology, Inc. | MPLS segment routing |
US10469370B2 (en) | 2012-10-05 | 2019-11-05 | Cisco Technology, Inc. | Segment routing techniques |
US11784889B2 (en) | 2013-03-15 | 2023-10-10 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
US10764146B2 (en) | 2013-03-15 | 2020-09-01 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
US11424987B2 (en) | 2013-03-15 | 2022-08-23 | Cisco Technology, Inc. | Segment routing: PCE driven dynamic setup of forwarding adjacencies and explicit path |
US11689427B2 (en) | 2013-03-15 | 2023-06-27 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
US10270664B2 (en) | 2013-03-15 | 2019-04-23 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
US11290340B2 (en) | 2013-03-15 | 2022-03-29 | Cisco Technology, Inc. | Segment routing over label distribution protocol |
US10469325B2 (en) | 2013-03-15 | 2019-11-05 | Cisco Technology, Inc. | Segment routing: PCE driven dynamic setup of forwarding adjacencies and explicit path |
US11451474B2 (en) | 2013-09-17 | 2022-09-20 | Cisco Technology, Inc. | Equal cost multi-path with bit indexed explicit replication |
US10659242B2 (en) | 2013-09-17 | 2020-05-19 | Cisco Technology, Inc. | Bit indexed explicit replication using multiprotocol label switching |
US10404482B2 (en) | 2013-09-17 | 2019-09-03 | Cisco Technology, Inc. | Bit indexed explicit replication forwarding optimization |
US10461946B2 (en) | 2013-09-17 | 2019-10-29 | Cisco Technology, Inc. | Overlay signaling for bit indexed explicit replication |
US10218524B2 (en) | 2013-09-17 | 2019-02-26 | Cisco Technology, Inc. | Bit indexed explicit replication for layer 2 networking |
US11601296B2 (en) | 2013-09-17 | 2023-03-07 | Cisco Technology, Inc. | Bit indexed explicit replication for layer 2 networking |
US10498547B2 (en) | 2013-09-17 | 2019-12-03 | Cisco Technology, Inc. | Bit indexed explicit replication |
US10536324B2 (en) | 2013-09-17 | 2020-01-14 | Cisco Technology, Inc. | Per-prefix LFA FRR with bit indexed explicit replication |
US11044112B2 (en) | 2013-09-17 | 2021-06-22 | Cisco Technology, Inc. | Bit indexed explicit forwarding optimization |
US11153108B2 (en) | 2013-09-17 | 2021-10-19 | Cisco Technology, Inc. | Bit indexed explicit replication using multiprotocol label switching |
US10708075B2 (en) | 2013-09-17 | 2020-07-07 | Cisco Technology, Inc. | Bit indexed explicit replication using internet protocol version 6 |
US11646906B2 (en) | 2013-09-17 | 2023-05-09 | Cisco Technology, Inc. | Bit indexed explicit forwarding optimization |
US10225090B2 (en) | 2013-09-17 | 2019-03-05 | Cisco Technology, Inc. | Bit indexed explicit replication using multiprotocol label switching |
US10764076B2 (en) | 2013-09-17 | 2020-09-01 | Cisco Technology, Inc. | Bit indexed explicit replication for layer 2 networking |
US11206148B2 (en) | 2013-09-17 | 2021-12-21 | Cisco Technology, Inc. | Bit indexed explicit replication |
US11336574B2 (en) | 2014-03-06 | 2022-05-17 | Cisco Technology, Inc. | Segment routing extension headers |
US11374863B2 (en) | 2014-03-06 | 2022-06-28 | Cisco Technology, Inc. | Segment routing extension headers |
US10382334B2 (en) | 2014-03-06 | 2019-08-13 | Cisco Technology, Inc. | Segment routing extension headers |
US10601707B2 (en) | 2014-07-17 | 2020-03-24 | Cisco Technology, Inc. | Segment routing using a remote forwarding adjacency identifier |
US10637686B2 (en) | 2015-01-27 | 2020-04-28 | Cisco Technology, Inc. | Capability aware routing |
US10693765B2 (en) | 2015-02-26 | 2020-06-23 | Cisco Technology, Inc. | Failure protection for traffic-engineered bit indexed explicit replication |
US10341222B2 (en) * | 2015-02-26 | 2019-07-02 | Cisco Technology, Inc. | Traffic engineering for bit indexed explicit replication |
US10958566B2 (en) * | 2015-02-26 | 2021-03-23 | Cisco Technology, Inc. | Traffic engineering for bit indexed explicit replication |
US10122614B2 (en) | 2015-02-26 | 2018-11-06 | Cisco Technology, Inc. | Failure protection for traffic-engineered bit indexed explicit replication |
US10341221B2 (en) * | 2015-02-26 | 2019-07-02 | Cisco Technology, Inc. | Traffic engineering for bit indexed explicit replication |
US10742537B2 (en) | 2016-05-26 | 2020-08-11 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
US10263881B2 (en) | 2016-05-26 | 2019-04-16 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
US11671346B2 (en) | 2016-05-26 | 2023-06-06 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
US11323356B2 (en) | 2016-05-26 | 2022-05-03 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
US11489756B2 (en) | 2016-05-26 | 2022-11-01 | Cisco Technology, Inc. | Enforcing strict shortest path forwarding using strict segment identifiers |
US11032197B2 (en) | 2016-09-15 | 2021-06-08 | Cisco Technology, Inc. | Reroute detection in segment routing data plane |
US11297117B2 (en) | 2016-09-23 | 2022-04-05 | Cisco Technology, Inc. | Unicast media replication fabric using bit indexed explicit replication |
US10630743B2 (en) | 2016-09-23 | 2020-04-21 | Cisco Technology, Inc. | Unicast media replication fabric using bit indexed explicit replication |
US10637675B2 (en) | 2016-11-09 | 2020-04-28 | Cisco Technology, Inc. | Area-specific broadcasting using bit indexed explicit replication |
US11438186B2 (en) | 2016-11-09 | 2022-09-06 | Cisco Technology, Inc. | Area-specific broadcasting using bit indexed explicit replication |
US10447496B2 (en) | 2017-03-30 | 2019-10-15 | Cisco Technology, Inc. | Multicast traffic steering using tree identity in bit indexed explicit replication (BIER) |
US10432425B2 (en) | 2017-03-30 | 2019-10-01 | Cisco Technology, Inc. | Internet protocol based encapsulation for bit indexed explicit replication (BIER) |
US10985942B2 (en) | 2017-03-30 | 2021-04-20 | Cisco Technology, Inc. | Multicast traffic steering using tree identity in bit indexed explicit replication (BIER) |
US10574479B2 (en) | 2017-04-28 | 2020-02-25 | Cisco Technology, Inc. | Bridging of non-capable subnetworks in bit indexed explicit replication |
US11303470B2 (en) | 2017-04-28 | 2022-04-12 | Cisco Technology, Inc. | Bridging of non-capable subnetworks in bit indexed explicit replication |
US11258687B2 (en) | 2017-10-10 | 2022-02-22 | Bull Sas | Method for generating requests for the segmentation of the monitoring of an interconnection network and associated hardware |
US10749776B2 (en) * | 2017-10-10 | 2020-08-18 | Bull Sas | Method for generating requests for the segmentation of the monitoring of an interconnection network and associated hardware |
US11722404B2 (en) | 2019-09-24 | 2023-08-08 | Cisco Technology, Inc. | Communicating packets across multi-domain networks using compact forwarding instructions |
US11855884B2 (en) | 2019-09-24 | 2023-12-26 | Cisco Technology, Inc. | Communicating packets across multi-domain networks using compact forwarding instructions |
Also Published As
Publication number | Publication date |
---|---|
US20040066781A1 (en) | 2004-04-08 |
DE60332591D1 (en) | 2010-07-01 |
US7539185B2 (en) | 2009-05-26 |
EP1408655B1 (en) | 2010-05-19 |
EP1408655A3 (en) | 2006-04-12 |
EP1408655A2 (en) | 2004-04-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7539185B2 (en) | Fast-path implementation for an uplink double tagging engine | |
US7636319B2 (en) | Fastpath implementation for a double tagging loopback engine | |
US7515592B2 (en) | Fast-path implementation for transparent LAN services using double tagging | |
US7773508B2 (en) | Protecting the filtering database in virtual bridges | |
US7660303B2 (en) | Point-to-multipoint functionality in a bridged network | |
US7095738B1 (en) | System and method for deriving IPv6 scope identifiers and for mapping the identifiers into IPv6 addresses | |
US6430621B1 (en) | System using different tag protocol identifiers to distinguish between multiple virtual local area networks | |
US7593400B2 (en) | MAC address learning in a distributed bridge | |
US6147995A (en) | Method for establishing restricted broadcast groups in a switched network | |
US7548541B2 (en) | Managing VLAN traffic in a multiport network node using customer-specific identifiers | |
EP1471684B1 (en) | Method and apparatus for determining shared broadcast domains of network switches, ports and interfaces | |
US20030152075A1 (en) | Virtual local area network identifier translation in a packet-based network | |
US20030174706A1 (en) | Fastpath implementation for transparent local area network (LAN) services over multiprotocol label switching (MPLS) | |
KR20040107379A (en) | Apparatus and method for implementing vlan bridging and a vpn in a distributed architecture router | |
US8873431B1 (en) | Communications system and method for maintaining topology in a VLAN environment | |
US20050138206A1 (en) | Network unit for forwarding an ethernet packet | |
Cisco | Configuring Ethernet Switching | |
Cisco | Configuring Transparent Bridging | |
IL195263A (en) | Mac address learning in a distributed bridge |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001 Effective date: 20160201 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001 Effective date: 20160201 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:041706/0001 Effective date: 20170120 Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:041706/0001 Effective date: 20170120 |
|
AS | Assignment |
Owner name: BROADCOM CORPORATION, CALIFORNIA Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041712/0001 Effective date: 20170119 |