US8755383B2 - Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges - Google Patents

Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges Download PDF

Info

Publication number
US8755383B2
US8755383B2 US13/149,066 US201113149066A US8755383B2 US 8755383 B2 US8755383 B2 US 8755383B2 US 201113149066 A US201113149066 A US 201113149066A US 8755383 B2 US8755383 B2 US 8755383B2
Authority
US
United States
Prior art keywords
bits
network
data packet
device address
address space
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.)
Active, expires
Application number
US13/149,066
Other languages
English (en)
Other versions
US20120243539A1 (en
Inventor
Srikanth Keesara
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Extreme Networks Inc
Original Assignee
Avaya Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Avaya Inc filed Critical Avaya Inc
Assigned to AVAYA INC. reassignment AVAYA INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KEESARA, SRIKANTH
Priority to US13/149,066 priority Critical patent/US8755383B2/en
Priority to EP11195675.1A priority patent/EP2503743B1/de
Priority to EP16195966.3A priority patent/EP3145135B1/de
Priority to CN201110461263.9A priority patent/CN102694721B/zh
Publication of US20120243539A1 publication Critical patent/US20120243539A1/en
Assigned to THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A. reassignment THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A. SECURITY AGREEMENT Assignors: AVAYA, INC.
Assigned to BANK OF NEW YORK MELLON TRUST COMPANY, N.A., THE reassignment BANK OF NEW YORK MELLON TRUST COMPANY, N.A., THE SECURITY AGREEMENT Assignors: AVAYA, INC.
Publication of US8755383B2 publication Critical patent/US8755383B2/en
Application granted granted Critical
Assigned to CITIBANK, N.A., AS ADMINISTRATIVE AGENT reassignment CITIBANK, N.A., AS ADMINISTRATIVE AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AVAYA INC., AVAYA INTEGRATED CABINET SOLUTIONS INC., OCTEL COMMUNICATIONS CORPORATION, VPNET TECHNOLOGIES, INC.
Assigned to SILICON VALLEY BANK reassignment SILICON VALLEY BANK SECOND AMENDED AND RESTATED PATENT AND TRADEMARK SECURITY AGREEMENT Assignors: EXTREME NETWORKS, INC.
Assigned to EXTREME NETWORKS, INC. reassignment EXTREME NETWORKS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AVAYA COMMUNICATION ISRAEL LTD, AVAYA HOLDINGS LIMITED, AVAYA INC.
Assigned to SILICON VALLEY BANK reassignment SILICON VALLEY BANK THIRD AMENDED AND RESTATED PATENT AND TRADEMARK SECURITY AGREEMENT Assignors: EXTREME NETWORKS, INC.
Assigned to AVAYA INC. reassignment AVAYA INC. BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 029608/0256 Assignors: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.
Assigned to VPNET TECHNOLOGIES, INC., OCTEL COMMUNICATIONS LLC (FORMERLY KNOWN AS OCTEL COMMUNICATIONS CORPORATION), AVAYA INTEGRATED CABINET SOLUTIONS INC., AVAYA INC. reassignment VPNET TECHNOLOGIES, INC. BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001 Assignors: CITIBANK, N.A.
Assigned to AVAYA INC. reassignment AVAYA INC. BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 030083/0639 Assignors: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.
Assigned to BANK OF MONTREAL reassignment BANK OF MONTREAL SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EXTREME NETWORKS, INC.
Assigned to EXTREME NETWORKS, INC. reassignment EXTREME NETWORKS, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: SILICON VALLEY BANK
Assigned to BANK OF MONTREAL reassignment BANK OF MONTREAL AMENDED SECURITY AGREEMENT Assignors: Aerohive Networks, Inc., EXTREME NETWORKS, INC.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/66—Layer 2 routing, e.g. in Ethernet based MAN's

Definitions

  • Computer networks can include various configurations.
  • One such configuration known as a virtual private network (VPN) is a network that operates over a public communication network (such as the Internet) to provide remote offices or individual clients with secure, private access to a specific network, such as a network specific to an organization or company.
  • VPNs function by encapsulating data transfers between two or more networked devices that are not on the same private network. Such encapsulation keeps transferred data private from other devices on one or more intervening local area networks or wide area networks.
  • a VPN can enable a group of client computers to communicate and access specific resources as members of a given broadcast domain even if the various member client computers are not attached to the same network switch.
  • RBridges are separated by a transport network.
  • the transport network could be using a variety of technologies, though Ethernet is technology is the most popular choice for the transport network.
  • forwarded packets carry a TRILL Ethernet header that includes a Media Access Control (MAC) source address (MAC-SA) and a MAC destination address (MAC-DA).
  • MAC-SA Media Access Control
  • MAC-DA MAC destination address
  • a network that uses TRILL can connect customer networks directly through RBridges, or over one or more transport networks, allowing interconnection of multiple RBridges without losing each customer's individually defined Virtual LANs (VLANs).
  • VLANs Virtual LANs
  • TRILL Transparent Interconnect of Lots of Links
  • TRILL networks encapsulate packets (packets that already have at least one encapsulation) before routing such packets across the transport network. Packets are encapsulated at ingress RBridges, partially decapsulated and re-encapsulated at intermediate RBridges, and decapsulated at egress RBridges before continuing to a destination customer network.
  • Ethernet encapsulation of existing packets can simplify and accelerate data transport across the transport network, but this can be at the expense of reduced routing functionality.
  • Such additional features can include supporting Equal-cost multi-path routing (ECMP) without incorrectly ordering user flows, identifying specific User-Network Interfaces (non-transport interface of the ingress RBridge), providing Time to live (TTL) information, identifying flow paths, or any extra information or metadata. Having each node execute such deep packet inspection, however, slows down traffic within the transport network, which can cause delays and lost packets.
  • ECMP Equal-cost multi-path routing
  • TTL Time to live
  • One embodiment includes an address manager that executes a packet switching process.
  • the address manager receives a data packet at a first data switching device, such as an ingress RBridge of a TRILL network or edge node of a transport network.
  • the data packet has an existing header and is received from a customer network.
  • the address manager encapsulates the data packet using a TRILL header.
  • the TRILL header has a data structure that includes at least a transport device address space and a TRILL device address space. Encapsulating the data packet includes setting a first portion of bits, within the transport device address space, such that the first portion of bits indicates a data switching device address that is a node within the TRILL network.
  • Encapsulating the data packet also includes setting a second portion of bits, within the transport device address space, such that the second portion of bits indicates information distinct from the data switching device address that is a node within the TRILL network.
  • the second portion of bits can be used as metadata or extra information that is used apart from indicating a device address (source or destination address).
  • Encapsulating the data packet also includes setting bits within TRILL device address spaces such that the bits indicate an ingress RBridge nickname and an egress RBridge nickname. The first data switching device (ingress RBridge) then forwards the data packet via the TRILL network.
  • the address manager executes a lookup in a forwarding table of the RBridge device based on the transport device address indicated in the first portion of bits.
  • the RBridge then replaces the first portion of bits, that indicates the transport device address of the first data switching device address, with bits that indicate a second data switching device address while maintaining the second portion of bits unchanged.
  • the RBridge modifies only a portion of the bits within the transport device address space, while leaving the remaining portion unchanged or copied exactly to another TRILL header instance used to forward the data packet.
  • the RBridge then forwards the data packet via the TRILL network.
  • Techniques disclosed herein can also support Equal-cost multi-path routing (ECMP) by providing hop-by-hop path selection (next node selection) without increasing packet overhead or requiring deep packet inspection.
  • ECMP Equal-cost multi-path routing
  • the address manager generates a flow identifier by using packet information from the existing header as computation input for generating the flow identifier, such as by hashing on underlying customer information. Encapsulating the data packet includes setting a second portion of bits within the transport device address space, such that the second portion of bits indicates the flow identifier.
  • the data switching device selects a forwarding path to a next-hop node of the transport network by using the flow identifier from the transport device address space as computational input for selecting the forwarding path.
  • the data switching device then forwards the data packet to the next-hop node in the transport network using the selected forwarding path. Subsequent nodes can then use the flow identifier for next-hop selection. Subsequent nodes can also provide Reverse Path Forwarding (RPF) checks and Time to live (TTL) functionality.
  • RPF Reverse Path Forwarding
  • TTL Time to live
  • One such embodiment comprises a computer program product that has a computer-storage medium (e.g., a non-transitory, tangible, computer-readable media, disparately located or commonly located storage media, computer storage media or medium, etc.) including computer program logic encoded thereon that, when performed in a computerized device having a processor and corresponding memory, programs the processor to perform (or causes the processor to perform) the operations disclosed herein.
  • a computer-storage medium e.g., a non-transitory, tangible, computer-readable media, disparately located or commonly located storage media, computer storage media or medium, etc.
  • Such arrangements are typically provided as software, firmware, microcode, code data (e.g., data structures), etc., arranged or encoded on a computer readable storage medium such as an optical medium (e.g., CD-ROM), floppy disk, hard disk, one or more ROM or RAM or PROM chips, an Application Specific Integrated Circuit (ASIC), a field-programmable gate array (FPGA), and so on.
  • a computer readable storage medium such as an optical medium (e.g., CD-ROM), floppy disk, hard disk, one or more ROM or RAM or PROM chips, an Application Specific Integrated Circuit (ASIC), a field-programmable gate array (FPGA), and so on.
  • ASIC Application Specific Integrated Circuit
  • FPGA field-programmable gate array
  • one particular embodiment of the present disclosure is directed to a computer program product that includes one or more non-transitory computer storage media having instructions stored thereon for supporting operations such as: receiving a data packet at a first data switching device, the data packet having an existing header and being received from a customer network, the first data switching device being an ingress RBridge of a TRILL network; encapsulating the data packet using a TRILL header, the TRILL header having a data structure that includes a transport device address space and a TRILL device address space; encapsulating the data packet includes setting a first portion of bits, within the transport device address space, such that the first portion of bits indicates a data switching device address that is a node within the TRILL network; encapsulating the data packet includes setting a second portion of bits, within the transport device address space, such that the second portion of bits indicates information distinct from the data switching device address that is a node within the TRILL network; encapsulating the data packet includes setting bits within TRILL device address spaces such that the bits indicate an ingress
  • another particular embodiment of the present disclosure is directed to a computer program product that includes one or more non-transitory computer storage media having instructions stored thereon for supporting operations such as: receiving a data packet at a first data switching device, the data packet having an existing header and being received from a customer network, the first data switching device being an edge node of a transport network; encapsulating the data packet using a transport network header, the transport network header having a data structure that includes a transport device address space and a virtual local area network (VLAN) indicator space; encapsulating the data packet includes setting a first portion of bits within the transport device address space, such that the first portion of bits indicates a data switching device address that is a node within the transport network; encapsulating the data packet includes setting a second portion of bits within the transport device address space, such that the second portion of bits indicates a flow identifier; selecting a forwarding path to a next-hop node of the transport network by using the flow identifier from the transport device address space as computational input for selecting the forwarding
  • each of the systems, methods, apparatuses, etc. herein can be embodied strictly as a software program, as a hybrid of software and hardware, or as hardware alone such as within a processor, or within an operating system or within a software application, or via a non-software application such a person performing all or part of the operations.
  • Example embodiments as described herein may be implemented in products and/or software applications such as those manufactured by Avaya, Inc. of Lincroft, N.J.
  • FIGS. 1A and 1B are a diagram showing a conceptual representation of a data structure of a TRILL network Ethernet header.
  • FIG. 2 is a network diagram of a TRILL network.
  • FIGS. 5A and 5B are diagrams illustrating example Mac-In-Mac encapsulation headers for use with ECMP and TTL operations.
  • FIGS. 6-8 are flowcharts illustrating an example of a process supporting TRILL header address masking according to embodiments herein.
  • FIG. 12 is a flowchart illustrating an example of a process supporting ECMP using address masking in a transport network according to embodiments herein.
  • FIG. 14 is an example block diagram of an address manager operating in a computer/network environment according to embodiments herein.
  • a network that uses IEEE 802.1ah can route a customer network over a provider's network allowing interconnection of multiple Provider Bridge Networks without losing each customer's individually defined Virtual LANs (VLANs).
  • Another such protocol is that of Shortest Path Bridging or IEEE 802.1aq.
  • a network that uses IEEE 802.1aq can advertise both topology and logical network membership. Packets are encapsulated at an edge node either in Mac-in-Mac 802.1ah or Q-in-Q 802.1ad frames and transported only to other members of the logical network.
  • IEEE 802.1aq supports unicast and multicast, and all routing is on symmetric shortest paths.
  • IEEE 802.1aq includes Shortest Path Bridging MAC (SPBM) functionality.
  • SPBM Shortest Path Bridging MAC
  • a TRILL network is a L2 network that uses Ethernet encapsulation to transfer user L2 traffic between two or more L2 networks that are located at the edge of the TRILL network (transport network).
  • an ingress RBridge encapsulates a data packet received from a customer network with an Ethernet header for use in the TRILL network.
  • FIGS. 1A and 1B illustrate components of such an example encapsulation header 110 .
  • Header 110 - 1 shows several header fields. Note that such encapsulation headers can contain additional fields beyond what is shown in FIG. 1A .
  • Field 111 is a MAC destination address header (MAC-DA).
  • the destination address field contains six bytes (48 bits) of data.
  • Field 112 is a MAC source address header (MAC-SA).
  • a TRILL network 200 includes RBridges 241 .
  • node 241 - 1 is an ingress RBridge
  • node 241 - 2 is an intermediate RBridge
  • node 241 - 3 is an egress RBridge.
  • a data packet is being transmitted through Trill network 200 from left to right.
  • RBridges in the TRILL network can have intervening networks 227 - 1 and 227 - 2 , which can be use Ethernet based L2 bridging networks capable of using local MAC addresses.
  • RBridge 241 - 1 When forwarding, RBridge 241 - 1 add an encapsulation header with the MAC destination address being the MAC address of RBridge 241 - 2 in network 227 - 1 , and a MAC source address of RBridge 241 - 1 in network 227 - 1 .
  • a VLAN tag recognized in network 227 - 1 connecting 241 - 1 and 241 - 2 may be required.
  • the encapsulation header also includes an ingress RBridge nickname of RBridge 241 - 1 and an egress RBridge nickname of RBridge 241 - 3 .
  • Network 227 - 1 then delivers the encapsulated data packet to RBridge 241 - 2 using conventional Ethernet bridging to the MAC-DA of RBridge 241 - 2 .
  • RBridge 241 - 2 then forwards the encapsulated data packet to RBridge 241 - 3 and changes the encapsulation header by replacing the MAC-DA of RBridge 241 - 2 in network 227 - 1 with a MAC address of RBridge 241 - 3 in network 227 - 2 , and by replacing the MAC-SA of RBridge 241 - 1 in network 227 - 2 with the MAC address of RBridge 241 - 2 in network 227 - 2 .
  • Any VLAN tag is then removed or replaced with a VLAN tag recognized in network 227 - 2 as a VLAN connecting RBridge 241 - 2 and RBridge 241 - 3 .
  • Network 227 - 2 then delivers the encapsulated data packet to RBridge 241 - 3 using conventional bridging to the MAC-DA of RBridge 241 - 3 .
  • the intermediate RBridge keeps a portion of the encapsulation header (typically fields 115 , 116 , 117 , 118 , 121 , 122 , 125 , and 126 ), but changes or replaces a portion of the encapsulation header (fields 111 , 112 , and 114 ).
  • an intermediate RBridge decapsulates and re-encapsulates a TRILL header such that a first portion of fields remain the same and a second portion of fields are changed.
  • the MAC-SA and MAC-DA fields can change from one hop to another because the TRILL header includes separate fields for source and destination TRILL devices (fields 125 and 126 ). Although the MAC-SA and MAC-DA are lost at every hop, the TRILL header is still carrying a TRILL device header from an ingress RBridge to an egress RBridge.
  • TRILL functions by broadcasting connectivity among RBridges so that each RBridge knows about all the other RBridges, and the connectivity between them for maintaining forwarding tables.
  • TRILL can also function with transport networks that are not Ethernet based. In other networks, such as Multiprotocol Label Switching (MPLS), different fields will be used instead of MAC-SA/MAC-DA, but the TRILL header portion remains the same.
  • MPLS Multiprotocol Label Switching
  • TRILL can have a separate transport network between any two RBridges. The Ethernet portion of the header then effectively only identifies a next hop RBridge, while the RBridge-DA/RBridge-SA indicates initial and final destinations.
  • the transport addressing is not end-to-end address, but is instead next-hop addressing.
  • the MAC-SA and MAC-DA fields themselves of TRILL headers are structured to carry a masked and a non-masked portion of bits.
  • a masked portion of a the MAC-SA and/or MAC-DA remains the same (or carried across), while the non-masked portion is swapped or changed according to the forwarding RBridge.
  • a portion of the MAC-SA/MAC-DA remains the same, while a portion is changed during forwarding at an intermediate RBridge.
  • TRILL uses 48 bits to get across one link, that is, to get from one hop to another hop. This is an extremely large number. A large number of addresses is unlikely to be deployed in an actual TRILL network. Indeed, in practice, the number of addresses needed for such next hop operation is two or three addresses. Such next-hop addressing can be accomplished by using just three to five bits or so.
  • the system herein uses this discovery by limiting the number of bits in the address space/field that should be considered by the RBridge when doing a next hop forwarding lookup operation.
  • the remaining bits are identified as masked bits, that is, bits designated to be masked or ignored during forwarding table lookups and carried over (kept) during re-encapsulation of the addressing headers. These remaining masked bits in the two address fields (MAC-SA and MAC-DA) can then be considered as free bits that can be used for a variety of application purposes.
  • Such techniques provide extensible functionality with no increase in packet overhead, without requiring a RBridge to support larger (VLAN-ID,MAC) based forwarding records, without compromising CFM to effectively test all forwarding paths that might be used by user data frames, and without burdening the RBridges with excessive implementation complexity.
  • FIG. 3 shows customer networks 225 - 1 and 225 - 2 .
  • customer network 225 - 1 includes User-Network Interfaces (UNIs) 205 - 1 , 205 - 2 , and 205 - 3
  • customer network 225 - 2 includes User-Network Interfaces (UNIs) 205 - 4 , 205 - 5 , and 205 - 6 .
  • the transport network can be provided by a single administrator or by multiple administrators.
  • the transport network and the customer network can also be provided by a single administrator, but are nevertheless functionally treated or identified as separate networks.
  • the transport network has added or defined an encapsulation layer such as TRILL encapsulation.
  • TRILL encapsulation Upon receiving a given frame at the interface between the first access network and the transport network, a TRILL RBridge encapsulates the customer frame within the TRILL encapsulation header of the addressing scheme.
  • data packet 207 (customer packet) is received at ingress RBridge 241 - 1 from UNI 205 - 3 .
  • Ingress RBridge 241 - 1 encapsulates packet 207 with an Ethernet encapsulation header (or similar encapsulation header).
  • the encapsulated packet is now represented as packet 207 - 1 .
  • Ingress RBridge 241 - 1 then forwards packet 207 - 1 along flow path 217 through TRILL network 227 .
  • flow path 217 can represent an arbitrary flow path or a deterministic flow path depending on packet instructions.
  • Packet 207 - 1 next arrives at intermediate RBridge 241 - 2 .
  • Intermediate RBridge 241 - 2 then swaps out a portion of the TRILL header. Specifically, information in the transport device address space. According to embodiment disclosed herein, however, intermediate RBridge 241 - 2 maintains (copies or carries over) bits within the transport device address space that are masked or indicated distinct from transport device addressing.
  • Network 227 (or 227 - 1 and 227 - 2 ) recognizes the top eight bits for addressing, while masking the bottom 40 bits so that it can pass an additional 80 bits of information between edge nodes.
  • This modified TRILL header is now identified as data packet 207 - 2 .
  • the same procedure happens at intermediate RBridge 241 - 7 , with the modified TRILL header now indicated by data packet 207 - 3 .
  • Data packet 207 - 3 is next received at egress RBridge 241 - 3 .
  • Egress RBridge 241 - 3 then decapsulates packet 207 - 3 and forwards the original packet 207 within customer network 225 - 2 .
  • a TRILL creates an addressing scheme within the transport network.
  • Transport networks are different from customer networks because transport networks typically have significantly fewer devices. While customer networks can have tens of millions of addresses, large transport networks often have 1000 to 2000 device addresses or less. Since TRILL is typically not an end-to-end addressing scheme for the transport device address spaces, then the number of address used by any given RBridge can be as little as just a few transport devices. TRILL then uses a different addressing scheme within the TRILL network as compared to the customer networks. Addresses within the transport network are addresses of devices within transport network 227 itself as opposed to end user device addresses.
  • MAC addresses For example an administrator would not need to acquire MAC addresses from IEEE or IETF or otherwise purchase MAC addresses.
  • Using locally administered addresses in combination with a relatively small number of transport devices within a given transport network means that the required number of device addresses is several orders of magnitude smaller than the address space potential.
  • the remaining bits can be considered as free bits available for many different purposes.
  • the system administers the source and destination address spaces in a TRILL header as locally administered.
  • the system reserves a portion of the address space for locally administered transport devices to indicate the actual devices in the transport network (typically switches and routers).
  • This technique frees up the remaining bits, or bits in the remaining portion not reserved for transport device addresses, to be used for other purposes. Such purposes can include non-address purposes.
  • the system provides remaining bits for other uses without increasing a number of forwarding records maintained at each transport device within the transport network. Without masking or otherwise indicating that the freed up bits are not to be used in the forwarding tables, the forwarding tables would dramatically increase because every time a transport device identifies a new address, that address would need to be added to respective forwarding tables.
  • the system can instruct each transport device to use masked forwarding.
  • the system can execute masking using various techniques. For example, for an address space that contains 48 bits, 10 of those bits might be used for transport device addressing, while the remaining bits are used for other purposes.
  • the remaining bits are converted to zeros when executing a given lookup in a forwarding table.
  • the forwarding lookup operation will ignore these remaining bits. This results in fewer variations and combinations of lookup key values, thereby providing or maintaining small forwarding tables.
  • bits can be masked in a unicast MAC.
  • the system uses locally administered unicast MAC addresses by setting Bit 41 on the MAC to “one” to indicate that the MAC address is locally administered and then setting Bit 40 of the MAC is to “zero” to indicate that it is a unicast address. The system then masks a subset of 48-bits of the unicast MAC for the purpose of address recognition/lookups. The value of the masked bit is ignored for the purpose of determining address matches. Bit 41 (locally administered bit) and Bit 40 (multicast bit) are not masked.
  • FIG. 4A shows an example division of the addressing space 400 . Note that portion 402 and portion 404 are approximately equal in size.
  • portion 302 can contain a transport device address and thus remain non-masked, while an equal portion (24 bits) are masked (intended for purposes other than source/destination addressing).
  • This opaque information can be customized for use with any number of applications.
  • the edge nodes or core nodes can use the masked UNI-information for path selections.
  • transport nodes do not use the UNI-ID information (in the MAC address space) for table lookups, but instead use this information for hashing operations.
  • Such a technique can enable ECMP or path functionality within the TRILL network without blowing-up the size of the forwarding tables or requiring a separate protocol.
  • a maximum number of bits can be freed up across the address spaces of the MAC headers, to convert the TRILL network to a single switch network fabric architecture to control egress interfaces.
  • packet 207 entering on UNI 205 - 3 at edge node 241 - 1 needs to eventually be forwarded to UNI 205 - 4 at edge node 241 - 2 .
  • a packet forwarded from edge node 241 - 1 to edge node 241 - 2 might do a deep inspection of the packet to identify the destination UNI.
  • the UNI destination address can be masked within the TRILL header so that no deep packet inspection is necessary at edge node 241 - 2 . This is the principle of doing a masked UNI-ID. This technique can be used both in the forwarding and in the learning process.
  • edge node 241 - 2 can learn packets associated with edge node 241 - 1 and UNI 205 - 3 .
  • the user network interfaces can also be identified locally, thereby minimizing the number of bits needed in the address space to accurately identify user network interfaces attached to each RBridge.
  • Equal-cost multi-path routing (ECMP) or flow IDs have an objective to create a single flow path from one end user to another end user so that certain data flows are not broken.
  • a transport network has multiple potential data paths that can be selected based on load-balancing or other criteria. Certain data transmissions, however, should be sent along a single flow path. When certain flows are broken across multiple paths the packets that are part of the flow can arrive at different times. For example, the receiving device may receive the fifth packet sent before receiving the third packet sent. When this happens, the receiving end user device may drop those packets and request retransmission, which then degrades the performance of the network.
  • Flows and flow IDs have an objective that, if it is possible to indicate to a network what constitutes a flow, then that flow should not be broken across multiple paths, this flow should be executed without requiring deep inspection within a given packet (that is, inspecting header information within the encapsulation header).
  • ECMP can be important because as a given network grows linearly, the potential flow paths can increase exponentially. Because of this, computing paths in advance is computationally not practical or not possible. ECMP enables using all paths in the network while keeping a computational load very small. ECMP is especially beneficial in data centers or networks having lots of links and nodes, or servers that provide a multiplicity of end user sessions.
  • the transport edge device 241 - 1 In one processing stage, the transport edge device 241 - 1 generates a flow ID and inserts this flow ID into an address space of the encapsulation header. In a second processing stage, the transport edge device 241 - 1 executes a hash on the flow ID masked within the address space to select a given flow path. Subsequent transport core devices 244 would then execute the same hash function to select a next hop. With the flow ID being the same within the address header, subsequent nodes within the transport network 227 can consistently compute the same respective hash results for selecting a single flow path, such as flow path 217 . The hash can be executed on the entire address space or simply on the flow ID masked portion within the address space. By inserting a flow ID within the address space of the encapsulation header, packets do not grow in size nor do forwarding tables grow in size.
  • TTL time to live
  • Masked bits within an address space can also be used to provide time to live (TTL) the functionality.
  • Time to live functionality is beneficial if there is a control plane that is not functioning properly or to prevent loops that allow packets to circulate endlessly.
  • TTL fields are located within the encapsulation and within user fields, which are deeper within a packet.
  • transport devices do not look at user fields.
  • Conventional techniques suggest adding an additional field within the encapsulation header to provide time to live data, but this suggestion increases header size and requires sweeping upgrades. Either the address field, or the VLAN-ID field can be used to mask TTL data to provide this functionality without requiring deep packet inspection.
  • FIG. 14 illustrates an example block diagram of an address manager 140 operating in a computer/network environment according to embodiments herein. Functionality associated with address manager 140 will now be discussed via flowcharts and diagrams in FIG. 6 through FIG. 13 . For purposes of the following discussion, the address manager 140 or other appropriate entity performs steps in the flowcharts.
  • the address manager 140 encapsulates the data packet using a TRILL header.
  • the TRILL header has a data structure that includes a transport device address space and a TRILL device address space, and optionally a Virtual Local Area Network (VLAN) indicator space.
  • VLAN Virtual Local Area Network
  • the address manager 140 can use TRILL encapsulation.
  • the TRILL header encapsulates a data packet already having an existing header.
  • encapsulating the data packet includes setting a first portion of bits, within the transport device address space, such that the first portion of bits indicates a data switching device address that is a node within the TRILL network.
  • data is inserted within the transport device address space to indicate a data switching device, such as a router or switch.
  • encapsulating the data packet includes setting bits within TRILL device address spaces such that the bits indicate an ingress RBridge nickname and an egress RBridge nickname.
  • FIGS. 7-8 include a flow chart illustrating additional and/or alternative embodiments and optional functionality of the address manager 140 as disclosed herein.
  • encapsulating the data packet includes setting a first portion of bits, within the transport device address space, such that the first portion of bits indicates a data switching device address that is a node within the TRILL network.
  • setting the second portion of bits that indicates information distinct from the data switching device address includes indicating a User Network Interface (UNI) identity.
  • This UNI identity can indicate an interface that the data packet used to enter the TRILL network.
  • the data switching device can selects a forwarding path by using the UNI identity from the transport device address space as computational input for selecting the forwarding path. For example, each transport node can use the UNI ID as input for a hashing operation.
  • step 624 the address manager indicates a flow identifier using the second portion of bits.
  • encapsulating the data packet includes encapsulating the data packet using an Ethernet header that indicates, within the transport device address space, that the transport device address space uses locally administered Media Access Control addresses. Thus, MAC address do not need to e purchased for use.
  • the encapsulation can also indicate that the data packet is a unicast transmission.
  • the address manager sets a first portion of bits within the VLAN space, such that the first portion of bits within the VLAN space indicates a customer VLAN.
  • the address manager also sets a second portion of bits within the VLAN space, such that the second portion of bits within the VLAN space indicates a time to live (TTL) value of the data packet within the TRILL network. While TTL data can be included within the address space, sometimes it is desirable to keep data within the address space (masked and non-masked data) as unchanging data throughout the transport network.
  • TTL time to live
  • encapsulating the data packet includes setting bits within TRILL device address spaces such that the bits indicate an ingress RBridge nickname and an egress RBridge nickname.
  • TRILL headers segregate ingress/egress RBridge identification from transport node identification.
  • the address manager selects a next-hop forwarding path by using the flow identifier from the transport device address space as computational input for selecting the next-hop forwarding path.
  • the address manager or data switching devices uses the flow identifier for a hashing operation.
  • step 640 the data switching device forwards the data packet via the TRILL network.
  • step 641 the data switching device forwards the data packet to a next-hop node within the TRILL network via the selected next-hop forwarding path.
  • the Ethernet header can include a Media Access Control (MAC) destination address, and a Media Access Control source address.
  • Encapsulating the data packet can include using bits from the MAC destination address and the MAC source address to indicate information distinct from the data switching device addresses. Encapsulating the data packets can also include using bits across both the MAC destination address and the MAC source address to provide additional functionality that requires a greater number of aggregate bits than a single address space can provide.
  • MAC Media Access Control
  • address manager 140 identifies a transport device address from a transport device address space within the TRILL header.
  • the transport device address space has a first portion of bits that indicates a transport device address of a first data switching device.
  • the transport device address space also has a second portion of bits that indicates information distinct from the transport device address of the first data switching device. For example, node 241 - 2 receives data packet 207 - 1 having TRILL encapsulation with a portion of MAC address bits being free or masked bits.
  • address manager 140 identifies a transport device address from a transport device address space within the TRILL header.
  • the transport device address space has a first portion of bits that indicates a transport device address of a first data switching device.
  • the transport device address space also has a second portion of bits that indicates information distinct from the transport device address of the first data switching device.
  • step 930 the data switching device executes a lookup in a forwarding table of the RBridge device based on the transport device address indicated in the first portion of bits.
  • step 950 the data switching device forwards the data packet via the TRILL network.
  • the address manager 140 can also decrement a time to live (TTL) value indicated within a VLAN space of the data packet.
  • the data packet includes a first portion of bits, within the VLAN space of the transport network Ethernet header, which indicates a customer VLAN.
  • the data packet also includes a second portion of bits, within the VLAN space, that indicates the TTL value of the data packet.
  • OAM Operations, Administration, and Management
  • OA&M Operations, Administration, and Management
  • ECMP schemes function more effectively with increasing amounts of granularity in identifying end user flows. In other words, by getting closer to identifying at which node the end user flow cannot be split, the better a corresponding ECMP scheme can be followed.
  • the ingress node of the network pre-computes all available paths in the network from itself to any other node, and assigns a path identifier to each such path.
  • the path identifier is added to the packet header using rules that ensure that all packets within any single user flow use the exact sane path identifier.
  • the forwarding tables on all the nodes of the network include information on which outgoing interfaces to use for each individual path identifier. All intermediate devices between nodes simply use the path identifier when deciding which outgoing interface to use to forward the packet.
  • Another conventional mechanism is hop-by-hop ECMP path selection, typically performed by hashing at every Hop instead of computing all possible end-to-end choices.
  • Each given ingress node pre-computes all possible next-hop choices from itself to any other directly attached node in the network.
  • the number of potential next hops is relatively small compared to a total number of potential end-to-end paths.
  • the number of next hops is limited to a number of existing links in a given box or device. This number is typically in the hundreds or in the thousands, or even just a handful of links.
  • Each ingress node and every other node that processes the packet on its way between two nodes execute a same path selection process. Each node generates a hash index using different fields in the packet that can be used to identify user flows.
  • Hop-by-hop ECMP hashing requires every device in the network to hash on user fields of each packet. This makes it difficult to handle the addition of new protocols. Also, some protocols use encryption to scramble packet payload, which encryption a transport device cannot be expected to decode. Also, OAM packets cannot be used to troubleshoot paths taken by user data traffic in this network. This is because OAM frames typically use a protocol different from user data packets. Generally, the only thing that OAM frames have in common with user data packets is the network layer address information, but source and destination address do not provide sufficient granularity to be able to take advantage of all available paths in the network between given nodes. Thus, practical implementations are possible but they suffer from the disadvantages mentioned above.
  • hop-by-hop ECMP using explicit Flow IDs.
  • the system herein modifies the hop-by hop ECMP scheme defined above by explicitly adding a Flow-ID field is added to packet headers. For example, added immediately after the network layer address.
  • Flow-IDs are a standard way of encoding the possible, user flow information in the packet into a value that can be carried at a well known location in the packet and considered to be part of the network layer information of the packet.
  • the ingress (or first) device in the packet assigns a Flow-ID to the packet based on a computation of the various fields of the packet. This assignment could also be policy based.
  • the ingress node and all subsequent nodes that process the packet make their selection of the next-hop interface based on the value of the Flow-ID. While this is extensible to new protocols and preserves OAM capabilities, such a mechanism increases packet overhead since the Flow-ID is an additional field in the packet, and network devices have to deal with two different packet formats—those with Flow-ID and those without a Flow-ID in the network layer header. This is a significant concern since old protocols remain in use for a seemingly longer than expected, that is, the old protocols do no quickly go away.
  • BMAC address masking uses BMAC address masking to support ECMP functionality. As disclosed above, a portion of an address space is used for a device address, while a second portion (masked or free portion) is used for Flow-IDs. An ingress (edge) node assigns a Flow-ID to every packet it sends into the PBB network. The Flow-ID is then copied into the address space. This can be copied into both the BMAC-SA and BMAC-DA. Once the FLOW-ID is copied into the BMAC address, all PBB network devices that process the packet do a hash of the BMAC-SA and the BMAC-DA to select an outgoing interface from among one of the possible next-hop choices.
  • each node does a hash of the masked Flow-ID field only in the BMAC-SA and BMAC-DA.
  • the address fields contain additional information, such as UNI-IDs, TTL data, or other data, so that there are three or more segments of data in an address field, then each node can do a hash on any combination of the fields for possible next-hop choices.
  • techniques disclosed herein avoid layer violation—that is, inspecting headers and other information within the transport network encapsulation. Executing addressing and hashing on the same layer/header information, ensures effective scaling.
  • RPFC Reverse Path Forwarding Check
  • Conventional SPB standards have adopted RPFC and the mechanism to prevent/mitigate loops in an SPB network.
  • a (BVLAN-ID,BMAC-SA) lookup is performed for every unicast packet received in the SPB network. If the BMAC-SA lookup fails (unknown unicast BMAC-SA), then the packet is discarded.
  • a successful BMAC-SA lookup gives the “expected SPB interface” on which packets with that BMAC-SA are expected to arrive on. If the expected interface is not exactly the same as the actual interface on which the packet actually arrived, then the packet is discarded.
  • ECMP ECMP
  • the control plane IS-IS SPB
  • the unicast RPFC check can be modified when the expected interface is more like a list of interfaces.
  • RPFC for a given BVLAN-ID, BMAC-SA
  • BMAC-SA BMAC-SA
  • RPFC is an effective mechanism of preventing and mitigating loops. Sometimes, however, it may be desirable to have another protection in the data path for loop suppression.
  • a Time To Live (TTL) field can be used for that purpose. While TTL does not prevent a loop from being formed, TTL can stop a loop from continuing perpetually. TTL can be useful for cases where the control plane is non-responsive or has suffered a fault.
  • Techniques can include a combination of RPFC and TTL. RPFC can be used to prevent loops from forming (or quickly mitigating if formed), while TTL prevents loops from persisting in the case of a fatal control plane fault (which would not be prevented by RPFC).
  • a PBB network is a L2-Bridged network that uses Mac-In-Mac encapsulation to transfer user L2 traffic between two or more L2 networks that are located at the edge of the PBB network (provider network).
  • a PBB network includes all networks that use Mac-In-Mac encapsulation technology, including, but not limited to, networks that use the Shortest Path Bridging Technology commonly referred to as SPB or SPBV or SPBM.
  • the PBB network typically includes a Backbone Edge Bridge (BEB) and a Backbone Core Bridge (BCB).
  • BEB Backbone Edge Bridge
  • BCB Backbone Core Bridge
  • BEBs also known as provider network edge nodes
  • BCBs also known as provider core nodes
  • Mac-In-Mac encapsulation a given BEB encapsulates a data packet received from a customer network with an Ethernet header for use in the provider network.
  • FIG. 5A shows a current PBB Header (Mac-In-Mac encapsulation header).
  • Encapsulation header 510 includes BMAC-DA field 511 (Backbone MAC-DA), BMAC-SA field 512 , BTAG Ethertype field 515 , PCP/DEI field 519 , and BVLAN-ID field 518 .
  • Fields 515 , 519 , and 518 are together known as BTAG 554 fields.
  • Header 510 - 1 can be modified for combined RPFC and TTL functionality.
  • BTAG 554 can be swapped with a new tag called the ECMP TAG or ETAG 555 in Header 510 - 2 of FIG. 5B .
  • Field 518 becomes “ECMP Ethertype” 516 (16 bits), while field 528 is segmented with 6 bits reserved (of the 12 available bits) and 6 bits used for TTL data.
  • the size of the TTL and Reserved fields can be changed as long as the two of them together do not take up more than 12 bits.
  • the existing BTAG in the PBB header can be replaced with the ETAG. Since both of them are 4 bytes long, it does not result in any net increase in the packet overhead.
  • BMAC-DA and BMAC-SA fields can used masked address formats in conjunction with the ETAG.
  • the address manager uses BMAC masking to free some bits in the BMAC-SA and/or BMAC-DA address spaces. All or a portion of the free bits are set aside for carrying a Flow-ID.
  • the sender BEB performs a hash of the different packet fields and generates a value large enough for a hash index to use all the bits set aside or designated for use as a Flow-ID in the BMAC-SA and/or BMAC-DA address spaces.
  • the address manager then sets the Flow-ID bits in the Mac-In-Mac header using the hash index generated above.
  • the sender BEB and all other BCBs that process the packet on its way to the receiver BEB execute respective ECMP path selection using the Flow-ID that is carried in the Mac-In-Mac address header(s) as part of the BMAC-SA and/or BMAC-DA address spaces. Accordingly, there is no increase in packet size, CFM/OAM packets can effectively troubleshoot paths take by real data packets by including the Flow-ID of customer packets, and the use of masked BMAC addresses ensures that forwarding table sizes to not have to be increased.
  • FIG. 12 is a flow chart illustrating embodiments disclosed herein.
  • a first data switching device receives a data packet.
  • the data packet has an existing header and is received from a customer network.
  • the first data switching device is an edge node of a transport network, such as a BEB or RBridge or other network switch.
  • the address manager encapsulates the data packet using a transport network header.
  • the transport network header has a data structure that includes a transport device address space and a virtual local area network (VLAN) indicator space. For example, this can include a MAC address space.
  • VLAN virtual local area network
  • the address manager encapsulates the data packet by setting a first portion of bits within the transport device address space (filling the field with data), such that the first portion of bits indicates a data switching device address that is a node within the transport network.
  • step 1230 the data switching device selects a forwarding path to a next-hop node of the transport network by using the flow identifier from the transport device address space as computational input for selecting the forwarding path.
  • the data switching device uses this information from the encapsulation header to select a next hop.
  • step 1240 the data switching device forwards the data packet to the next-hop node in the transport network using the selected forwarding path.
  • generating the flow identifier can include generating a hashing index on customer information identified within the existing header.
  • Encapsulating the data packet can also includes setting a third portion of bits, within the transport device address space, such that the third portion of bits indicates a time to live (TTL) value of the data packet.
  • TTL time to live
  • encapsulating the data packet includes setting a first portion of bits within a VLAN space, such that the first portion of bits within the VLAN space indicates a customer VLAN. Encapsulating the data packet then additionally includes setting a second portion of bits within the VLAN space, such that the second portion of bits within the VLAN space indicates a time to live (TTL) of the data packet.
  • TTL time to live
  • the transport network header can be an Ethernet header that includes a Backbone Media Access Control (MAC) destination address space, and a Backbone Media Access Control source address space. Accordingly, encapsulating the data packet can include using bits from the Backbone MAC destination address space and the Backbone MAC source address space to indicate the flow identifier. Encapsulating the data packet using the Ethernet header can include indicating, within the Backbone MAC space, that the transport device address space uses locally administered Media Access Control addresses.
  • the transport network can be a Provider Backbone Bridge (PBB) network.
  • PBB Provider Backbone Bridge
  • the data switching device receives a data packet.
  • the data switching device is a node within a transport network.
  • the data packet is received from another node within the transport network.
  • the data packet has a customer network header encapsulated by a transport network header.
  • the data switching device in this embodiment can be a core node or intermediate node within the transport network.
  • the address manager identifies a transport device address from a transport device address space within the transport network header.
  • the transport device address space has a first portion of bits that indicates a data switching device address of a second data switching device, and the transport device address space has a second portion of bits that indicates a flow identifier.
  • step 1330 the data switching device executes a lookup, in a forwarding table of the data switching device, based on the data switching device address indicated in the first portion of bits, that is, based on information extracted from the non-masked portion of the address space.
  • the data switching device selects a forwarding path to a next-hop node in the transport network by using the flow identifier from the transport device address space as computational input for selecting the forwarding path, such as via a hashing operation.
  • step 1350 the data switching device forwards the data packet to the next-hop node in the transport network using the selected forwarding path.
  • executing the lookup in the forwarding table of the data switching device includes executing a reverse path forwarding (RPF) check.
  • the RPF check can include discarding the data packet in response to identifying that the data packet was received from an interface that does not match any incoming interface on a list of expected incoming interfaces for the data switching device in the transport network.
  • the expected interface can include multiple potential interfaces.
  • the data switching device can compare the received interface to the list to identify a match. If there is a match then the data switching device continues with forwarding operations. If there is no match then the packet is discarded.
  • the data packet includes a third portion of bits within the transport device address space (or VLAN-ID field).
  • This third portion of bits within the transport device address space indicates a time to live (TTL) value of the data packet.
  • the data switching device the decrements the TTL value indicated within the transport device address space before forwarding.
  • Selecting the forwarding path to a next-hop node can include providing Equal-cost multi-path routing (ECMP) using the using the flow identifier indicated by the a second portion of bits in the transport device address space.
  • ECMP Equal-cost multi-path routing
  • computer system 149 may be any of various types of devices, including, but not limited to, a network switch, a router, a cell phone, a personal computer system, desktop computer, laptop, notebook, or netbook computer, mainframe computer system, handheld computer, workstation, network computer, application server, storage device, a consumer electronics device such as a camera, camcorder, set top box, mobile device, video game console, handheld video game device, or in general any type of computing or electronic device.
  • a network switch such as a network switch, a router, a cell phone, a personal computer system, desktop computer, laptop, notebook, or netbook computer, mainframe computer system, handheld computer, workstation, network computer, application server, storage device, a consumer electronics device such as a camera, camcorder, set top box, mobile device, video game console, handheld video game device, or in general any type of computing or electronic device.
  • Computer system 149 is shown connected to display monitor 130 for displaying a graphical user interface 133 for a user 136 to operate using input devices 135 .
  • Repository 138 can optionally be used for storing data files and content both before and after processing.
  • Input devices 135 can include one or more devices such as a keyboard, computer mouse, microphone, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
US13/149,066 2011-03-21 2011-05-31 Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges Active 2033-01-05 US8755383B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/149,066 US8755383B2 (en) 2011-03-21 2011-05-31 Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges
EP11195675.1A EP2503743B1 (de) 2011-03-21 2011-12-23 Verwendung von maskierten Ethernetadressen zwischen Trill-Leitungsbrücken
EP16195966.3A EP3145135B1 (de) 2011-03-21 2011-12-23 Verwendung von maskierten ethernetadressen zwischen provider backbone bridges (pbb)
CN201110461263.9A CN102694721B (zh) 2011-03-21 2011-12-30 用于网络中的分组交换的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161454944P 2011-03-21 2011-03-21
US13/149,066 US8755383B2 (en) 2011-03-21 2011-05-31 Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges

Publications (2)

Publication Number Publication Date
US20120243539A1 US20120243539A1 (en) 2012-09-27
US8755383B2 true US8755383B2 (en) 2014-06-17

Family

ID=47045184

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/149,066 Active 2033-01-05 US8755383B2 (en) 2011-03-21 2011-05-31 Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges

Country Status (3)

Country Link
US (1) US8755383B2 (de)
EP (2) EP3145135B1 (de)
CN (1) CN102694721B (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130136128A1 (en) * 2011-09-16 2013-05-30 Robert Robinson Encapsulating traffic while preserving packet characteristics
US20150036684A1 (en) * 2013-08-05 2015-02-05 Riverbed Technology, Inc. Method and apparatus for path selection
WO2015169244A1 (en) * 2014-05-09 2015-11-12 Huawei Technologies Co., Ltd. System and method for loop suppression in transit networks
US20150341286A1 (en) * 2012-07-30 2015-11-26 Byung Kyu Choi Provider Bridged Network Communication
US9608858B2 (en) 2014-07-21 2017-03-28 Cisco Technology, Inc. Reliable multipath forwarding for encapsulation protocols

Families Citing this family (162)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8665886B2 (en) 2009-03-26 2014-03-04 Brocade Communications Systems, Inc. Redundant host connection in a routed network
US8369335B2 (en) 2010-03-24 2013-02-05 Brocade Communications Systems, Inc. Method and system for extending routing domain to non-routing end stations
US9461840B2 (en) 2010-06-02 2016-10-04 Brocade Communications Systems, Inc. Port profile management for virtual cluster switching
US9270486B2 (en) 2010-06-07 2016-02-23 Brocade Communications Systems, Inc. Name services for virtual cluster switching
US9716672B2 (en) 2010-05-28 2017-07-25 Brocade Communications Systems, Inc. Distributed configuration management for virtual cluster switching
US9769016B2 (en) 2010-06-07 2017-09-19 Brocade Communications Systems, Inc. Advanced link tracking for virtual cluster switching
US9001824B2 (en) 2010-05-18 2015-04-07 Brocade Communication Systems, Inc. Fabric formation for virtual cluster switching
US9231890B2 (en) 2010-06-08 2016-01-05 Brocade Communications Systems, Inc. Traffic management for virtual cluster switching
US8989186B2 (en) 2010-06-08 2015-03-24 Brocade Communication Systems, Inc. Virtual port grouping for virtual cluster switching
US8867552B2 (en) 2010-05-03 2014-10-21 Brocade Communications Systems, Inc. Virtual cluster switching
US8885488B2 (en) 2010-06-02 2014-11-11 Brocade Communication Systems, Inc. Reachability detection in trill networks
US8446914B2 (en) 2010-06-08 2013-05-21 Brocade Communications Systems, Inc. Method and system for link aggregation across multiple switches
US9246703B2 (en) 2010-06-08 2016-01-26 Brocade Communications Systems, Inc. Remote port mirroring
US9806906B2 (en) 2010-06-08 2017-10-31 Brocade Communications Systems, Inc. Flooding packets on a per-virtual-network basis
US9608833B2 (en) 2010-06-08 2017-03-28 Brocade Communications Systems, Inc. Supporting multiple multicast trees in trill networks
US9628293B2 (en) 2010-06-08 2017-04-18 Brocade Communications Systems, Inc. Network layer multicasting in trill networks
US9807031B2 (en) 2010-07-16 2017-10-31 Brocade Communications Systems, Inc. System and method for network configuration
US20120051346A1 (en) * 2010-08-24 2012-03-01 Quantenna Communications, Inc. 3-address mode bridging
US8711703B2 (en) * 2010-10-29 2014-04-29 Telefonaktiebolaget L M Ericsson (Publ) Load balancing in shortest-path-bridging networks
WO2011113381A2 (zh) 2011-04-26 2011-09-22 华为技术有限公司 业务实例映射方法、装置和系统
US9270572B2 (en) 2011-05-02 2016-02-23 Brocade Communications Systems Inc. Layer-3 support in TRILL networks
US9276953B2 (en) 2011-05-13 2016-03-01 International Business Machines Corporation Method and apparatus to detect and block unauthorized MAC address by virtual machine aware network switches
US8670450B2 (en) 2011-05-13 2014-03-11 International Business Machines Corporation Efficient software-based private VLAN solution for distributed virtual switches
US8837499B2 (en) 2011-05-14 2014-09-16 International Business Machines Corporation Distributed fabric protocol (DFP) switching network architecture
US20120287785A1 (en) 2011-05-14 2012-11-15 International Business Machines Corporation Data traffic handling in a distributed fabric protocol (dfp) switching network architecture
US20120291034A1 (en) 2011-05-14 2012-11-15 International Business Machines Corporation Techniques for executing threads in a computing environment
US9497073B2 (en) 2011-06-17 2016-11-15 International Business Machines Corporation Distributed link aggregation group (LAG) for a layer 2 fabric
US9402271B2 (en) * 2011-06-27 2016-07-26 Brocade Communications Systems, Inc. Converged wireless local area network
US8879549B2 (en) 2011-06-28 2014-11-04 Brocade Communications Systems, Inc. Clearing forwarding entries dynamically and ensuring consistency of tables across ethernet fabric switch
US8948056B2 (en) 2011-06-28 2015-02-03 Brocade Communication Systems, Inc. Spanning-tree based loop detection for an ethernet fabric switch
US9407533B2 (en) 2011-06-28 2016-08-02 Brocade Communications Systems, Inc. Multicast in a trill network
US9401861B2 (en) 2011-06-28 2016-07-26 Brocade Communications Systems, Inc. Scalable MAC address distribution in an Ethernet fabric switch
US9007958B2 (en) 2011-06-29 2015-04-14 Brocade Communication Systems, Inc. External loop detection for an ethernet fabric switch
US8885641B2 (en) 2011-06-30 2014-11-11 Brocade Communication Systems, Inc. Efficient trill forwarding
US8873558B2 (en) * 2011-08-03 2014-10-28 Cisco Technology, Inc. Reverse path forwarding lookup with link bundles
US9736085B2 (en) * 2011-08-29 2017-08-15 Brocade Communications Systems, Inc. End-to end lossless Ethernet in Ethernet fabric
US8767529B2 (en) 2011-09-12 2014-07-01 International Business Machines Corporation High availability distributed fabric protocol (DFP) switching network architecture
US20130064066A1 (en) 2011-09-12 2013-03-14 International Business Machines Corporation Updating a switch software image in a distributed fabric protocol (dfp) switching network
CN102368727B (zh) * 2011-09-14 2015-01-21 杭州华三通信技术有限公司 跨ip网络的trill网络通信方法、系统和设备
US8750129B2 (en) 2011-10-06 2014-06-10 International Business Machines Corporation Credit-based network congestion management
US9065745B2 (en) 2011-10-06 2015-06-23 International Business Machines Corporation Network traffic distribution
US8804572B2 (en) * 2011-10-25 2014-08-12 International Business Machines Corporation Distributed switch systems in a trill network
US9699117B2 (en) 2011-11-08 2017-07-04 Brocade Communications Systems, Inc. Integrated fibre channel support in an ethernet fabric switch
US9450870B2 (en) 2011-11-10 2016-09-20 Brocade Communications Systems, Inc. System and method for flow management in software-defined networks
WO2013082819A1 (zh) * 2011-12-09 2013-06-13 华为技术有限公司 一种二层网络环路处理的方法、装置及网络设备
US8995272B2 (en) 2012-01-26 2015-03-31 Brocade Communication Systems, Inc. Link aggregation in software-defined networks
US8953616B2 (en) * 2012-01-30 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) Shortest path bridging in a multi-area network
US9742693B2 (en) 2012-02-27 2017-08-22 Brocade Communications Systems, Inc. Dynamic service insertion in a fabric switch
US9154416B2 (en) 2012-03-22 2015-10-06 Brocade Communications Systems, Inc. Overlay tunnel in a fabric switch
CN102594711B (zh) * 2012-03-28 2014-11-26 杭州华三通信技术有限公司 一种在边缘设备上的报文转发方法和边缘设备
US9270589B2 (en) * 2012-04-04 2016-02-23 Marvell Israel (M.I.S.L) Ltd. Transparent RBridge
US9374301B2 (en) 2012-05-18 2016-06-21 Brocade Communications Systems, Inc. Network feedback in software-defined networks
US10277464B2 (en) 2012-05-22 2019-04-30 Arris Enterprises Llc Client auto-configuration in a multi-switch link aggregation
EP2853066B1 (de) 2012-05-23 2017-02-22 Brocade Communications Systems, Inc. Layer-3-überlagerungs-gateways
US9602430B2 (en) 2012-08-21 2017-03-21 Brocade Communications Systems, Inc. Global VLANs for fabric switches
US9049233B2 (en) 2012-10-05 2015-06-02 Cisco Technology, Inc. MPLS segment-routing
CN103780486B (zh) * 2012-10-26 2017-03-08 杭州华三通信技术有限公司 一种trill网络中的镜像报文传输方法和设备
CN103812775B (zh) * 2012-11-13 2017-04-12 华为技术有限公司 报文转发方法、装置及系统
US9401872B2 (en) 2012-11-16 2016-07-26 Brocade Communications Systems, Inc. Virtual link aggregations across multiple fabric switches
US9413691B2 (en) 2013-01-11 2016-08-09 Brocade Communications Systems, Inc. MAC address synchronization in a fabric switch
US9548926B2 (en) 2013-01-11 2017-01-17 Brocade Communications Systems, Inc. Multicast traffic load balancing over virtual link aggregation
US9350680B2 (en) 2013-01-11 2016-05-24 Brocade Communications Systems, Inc. Protection switching over a virtual link aggregation
US9565113B2 (en) 2013-01-15 2017-02-07 Brocade Communications Systems, Inc. Adaptive link aggregation and virtual link aggregation
CN104145456A (zh) * 2013-01-16 2014-11-12 华为技术有限公司 一种trill oam报文实现方法，rb和trill网络
CN103944826B (zh) * 2013-01-22 2017-03-15 杭州华三通信技术有限公司 Spbm网络中的表项聚合方法及设备
US9565099B2 (en) 2013-03-01 2017-02-07 Brocade Communications Systems, Inc. Spanning tree in fabric switches
US9049127B2 (en) * 2013-03-11 2015-06-02 Cisco Technology, Inc. Methods and devices for providing service clustering in a trill network
CN104052669B (zh) * 2013-03-12 2018-12-07 凯为公司 用于处理交替配置的最长前缀匹配表的装置
US9331942B2 (en) * 2013-03-12 2016-05-03 Xpliant, Inc. Apparatus and method for processing alternately configured longest prefix match tables
US9401818B2 (en) 2013-03-15 2016-07-26 Brocade Communications Systems, Inc. Scalable gateways for a fabric switch
US9537718B2 (en) 2013-03-15 2017-01-03 Cisco Technology, Inc. Segment routing over label distribution protocol
US9667441B2 (en) * 2013-03-18 2017-05-30 Mellanox Technologies Ltd. Uniting FDB lookups for encapsulated packets
CN103166858B (zh) * 2013-03-26 2016-06-08 杭州华三通信技术有限公司 一种报文传输方法和设备
US9565028B2 (en) 2013-06-10 2017-02-07 Brocade Communications Systems, Inc. Ingress switch multicast distribution in a fabric switch
US9699001B2 (en) 2013-06-10 2017-07-04 Brocade Communications Systems, Inc. Scalable and segregated network virtualization
US9692677B2 (en) * 2013-06-12 2017-06-27 Avaya Inc. Implementing multicast link trace connectivity fault management in an Ethernet network
CN104348717B (zh) * 2013-08-02 2018-05-11 新华三技术有限公司 报文转发方法和装置
US9806949B2 (en) 2013-09-06 2017-10-31 Brocade Communications Systems, Inc. Transparent interconnection of Ethernet fabric switches
EP3047604B1 (de) 2013-09-17 2021-03-24 Cisco Technology, Inc. Bit-indizierte explizite replikation
US10003494B2 (en) 2013-09-17 2018-06-19 Cisco Technology, Inc. Per-prefix LFA FRR with bit indexed explicit replication
US9438432B2 (en) 2013-09-17 2016-09-06 Cisco Technology, Inc. Bit indexed explicit replication packet encapsulation
US9544230B2 (en) * 2013-09-17 2017-01-10 Cisco Technology, Inc. Migration support for bit indexed explicit replication
US10218524B2 (en) 2013-09-17 2019-02-26 Cisco Technology, Inc. Bit indexed explicit replication for layer 2 networking
US9806897B2 (en) 2013-09-17 2017-10-31 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
US11451474B2 (en) 2013-09-17 2022-09-20 Cisco Technology, Inc. Equal cost multi-path with bit indexed explicit replication
US9571897B2 (en) 2013-09-17 2017-02-14 Cisco Technology, Inc. Bit indexed explicit replication for professional media networks
US9912612B2 (en) 2013-10-28 2018-03-06 Brocade Communications Systems LLC Extended ethernet fabric switches
US9515918B2 (en) 2013-11-18 2016-12-06 International Business Machines Corporation Computing forwarding tables for link failures
CN104660508B (zh) * 2013-11-25 2018-03-16 华为技术有限公司 一种报文转发方法及装置
US9967199B2 (en) 2013-12-09 2018-05-08 Nicira, Inc. Inspecting operations of a machine to detect elephant flows
US9548924B2 (en) * 2013-12-09 2017-01-17 Nicira, Inc. Detecting an elephant flow based on the size of a packet
CN104753790B (zh) * 2013-12-26 2018-05-04 华为技术有限公司 一种基于trill网络的报文传输方法及设备
CN103763224B (zh) * 2014-01-23 2017-04-12 华为技术有限公司 一种数据处理方法及装置
CN103763192B (zh) * 2014-01-29 2017-04-12 杭州华三通信技术有限公司 报文转发方法和装置
US9548873B2 (en) 2014-02-10 2017-01-17 Brocade Communications Systems, Inc. Virtual extensible LAN tunnel keepalives
US9762488B2 (en) 2014-03-06 2017-09-12 Cisco Technology, Inc. Segment routing extension headers
US10581758B2 (en) 2014-03-19 2020-03-03 Avago Technologies International Sales Pte. Limited Distributed hot standby links for vLAG
US10476698B2 (en) 2014-03-20 2019-11-12 Avago Technologies International Sales Pte. Limited Redundent virtual link aggregation group
US10567271B2 (en) * 2014-04-18 2020-02-18 Nokia Canada Inc. Topology-aware packet forwarding in a communication network
US10063473B2 (en) 2014-04-30 2018-08-28 Brocade Communications Systems LLC Method and system for facilitating switch virtualization in a network of interconnected switches
US9800471B2 (en) 2014-05-13 2017-10-24 Brocade Communications Systems, Inc. Network extension groups of global VLANs in a fabric switch
US9807001B2 (en) 2014-07-17 2017-10-31 Cisco Technology, Inc. Segment routing using a remote forwarding adjacency identifier
US10616108B2 (en) 2014-07-29 2020-04-07 Avago Technologies International Sales Pte. Limited Scalable MAC address virtualization
US9544219B2 (en) 2014-07-31 2017-01-10 Brocade Communications Systems, Inc. Global VLAN services
US9807007B2 (en) 2014-08-11 2017-10-31 Brocade Communications Systems, Inc. Progressive MAC address learning
US20160087887A1 (en) * 2014-09-22 2016-03-24 Hei Tao Fung Routing fabric
US9524173B2 (en) 2014-10-09 2016-12-20 Brocade Communications Systems, Inc. Fast reboot for a switch
US9699029B2 (en) 2014-10-10 2017-07-04 Brocade Communications Systems, Inc. Distributed configuration management in a switch group
US9553829B2 (en) 2014-11-13 2017-01-24 Cavium, Inc. Apparatus and method for fast search table update in a network switch
US9485179B2 (en) 2014-11-13 2016-11-01 Cavium, Inc. Apparatus and method for scalable and flexible table search in a network switch
CN105591940B (zh) * 2014-11-17 2020-03-31 中兴通讯股份有限公司 一种trill网络分发树选择方法和trill网络节点
US9626255B2 (en) 2014-12-31 2017-04-18 Brocade Communications Systems, Inc. Online restoration of a switch snapshot
US9628407B2 (en) 2014-12-31 2017-04-18 Brocade Communications Systems, Inc. Multiple software versions in a switch group
US9942097B2 (en) 2015-01-05 2018-04-10 Brocade Communications Systems LLC Power management in a network of interconnected switches
US10003552B2 (en) 2015-01-05 2018-06-19 Brocade Communications Systems, Llc. Distributed bidirectional forwarding detection protocol (D-BFD) for cluster of interconnected switches
DE102015200947B3 (de) * 2015-01-21 2016-04-07 Bayerische Motoren Werke Aktiengesellschaft Systemskalierung bei Ethernet-Kommunikation im Fahrzeug
US9906378B2 (en) 2015-01-27 2018-02-27 Cisco Technology, Inc. Capability aware routing
US10341221B2 (en) 2015-02-26 2019-07-02 Cisco Technology, Inc. Traffic engineering for bit indexed explicit replication
US9807005B2 (en) 2015-03-17 2017-10-31 Brocade Communications Systems, Inc. Multi-fabric manager
US10038592B2 (en) 2015-03-17 2018-07-31 Brocade Communications Systems LLC Identifier assignment to a new switch in a switch group
US10579406B2 (en) 2015-04-08 2020-03-03 Avago Technologies International Sales Pte. Limited Dynamic orchestration of overlay tunnels
EP3107269A1 (de) * 2015-06-17 2016-12-21 Advanced Digital Broadcast S.A. System und verfahren zur mac-adressierung
US10439929B2 (en) 2015-07-31 2019-10-08 Avago Technologies International Sales Pte. Limited Graceful recovery of a multicast-enabled switch
US10171303B2 (en) 2015-09-16 2019-01-01 Avago Technologies International Sales Pte. Limited IP-based interconnection of switches with a logical chassis
CN105591913B (zh) * 2015-11-04 2018-10-12 新华三技术有限公司 Trill网络中的报文转发方法和装置
US9912614B2 (en) 2015-12-07 2018-03-06 Brocade Communications Systems LLC Interconnection of switches based on hierarchical overlay tunneling
US10523796B2 (en) * 2015-12-22 2019-12-31 Intel Corporation Techniques for embedding fabric address information into locally-administered Ethernet media access control addresses (MACs) and a multi-node fabric system implementing the same
US10263881B2 (en) 2016-05-26 2019-04-16 Cisco Technology, Inc. Enforcing strict shortest path forwarding using strict segment identifiers
CN107819693B (zh) * 2016-09-12 2019-05-07 北京百度网讯科技有限公司 用于数据流系统的数据流处理方法及装置
US11032197B2 (en) 2016-09-15 2021-06-08 Cisco Technology, Inc. Reroute detection in segment routing data plane
US10630743B2 (en) 2016-09-23 2020-04-21 Cisco Technology, Inc. Unicast media replication fabric using bit indexed explicit replication
US10237090B2 (en) 2016-10-28 2019-03-19 Avago Technologies International Sales Pte. Limited Rule-based network identifier mapping
US10637675B2 (en) 2016-11-09 2020-04-28 Cisco Technology, Inc. Area-specific broadcasting using bit indexed explicit replication
US10341225B2 (en) * 2016-12-30 2019-07-02 Hughes Network Systems, Llc Bonding of satellite terminals
US10623308B2 (en) * 2017-02-17 2020-04-14 Dell Products L.P. Flow routing system
US10447496B2 (en) 2017-03-30 2019-10-15 Cisco Technology, Inc. Multicast traffic steering using tree identity in bit indexed explicit replication (BIER)
US10164794B2 (en) 2017-04-28 2018-12-25 Cisco Technology, Inc. Bridging of non-capable subnetworks in bit indexed explicit replication
US11418460B2 (en) * 2017-05-15 2022-08-16 Consensii Llc Flow-zone switching
US20190014092A1 (en) * 2017-07-08 2019-01-10 Dan Malek Systems and methods for security in switched networks
CN107801183A (zh) * 2017-09-22 2018-03-13 河南西岛仪表研发有限公司 一种基于节点地址的无线链路组网方法
US11032257B1 (en) 2017-12-08 2021-06-08 Rankin Labs, Llc Method for covertly delivering a packet of data over a network
CN108337183B (zh) * 2017-12-19 2021-10-26 南京大学 一种数据中心网络流负载均衡的方法
US11861025B1 (en) 2018-01-08 2024-01-02 Rankin Labs, Llc System and method for receiving and processing a signal within a TCP/IP protocol stack
CN111837368B (zh) 2018-02-23 2022-01-14 华为技术有限公司 使用内部网关协议通告和编程优选路径路由
CN112055954B (zh) 2018-04-26 2022-08-26 华为技术有限公司 网络中优选路径路由的资源预留和维护
WO2019210769A1 (en) * 2018-05-03 2019-11-07 Huawei Technologies Co., Ltd. Explicit routing with network function encoding
US20210266254A1 (en) * 2018-06-22 2021-08-26 Idac Holdings, Inc. Device to device forwarding
US10728220B2 (en) 2018-08-10 2020-07-28 John Rankin System and method for covertly transmitting a payload of data
US11689543B2 (en) 2018-08-10 2023-06-27 Rankin Labs, Llc System and method for detecting transmission of a covert payload of data
US11652732B2 (en) 2018-08-21 2023-05-16 Rankin Labs, Llc System and method for scattering network traffic across a number of disparate hosts
US11989320B2 (en) 2018-12-19 2024-05-21 Rankin Labs, Llc Hidden electronic file system within non-hidden electronic file system
WO2020160564A1 (en) * 2019-03-19 2020-08-06 Futurewei Technologies, Inc. Preferred path routing in ethernet networks
DE102019114309A1 (de) 2019-05-28 2020-12-03 Beckhoff Automation Gmbh Verfahren zum Routen von Telegrammen in einem Automatisierungsnetzwerk, Datenstruktur, Automatisierungsnetzwerk und Netzwerkverteiler
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
US11140074B2 (en) 2019-09-24 2021-10-05 Cisco Technology, Inc. Communicating packets across multi-domain networks using compact forwarding instructions
US20210111990A1 (en) * 2019-10-14 2021-04-15 Cisco Technology, Inc. Systems and methods for providing multiple disjointed paths to core network at first-mile access
CN111641558B (zh) * 2019-10-24 2021-11-30 北京大学 一种基于位置感知的网络中间设备
US11516048B2 (en) 2019-12-18 2022-11-29 Rankin Labs, Llc Distribution of data over a network with interconnected rings
WO2021142049A1 (en) * 2020-01-07 2021-07-15 John Rankin Presenting data to a user without a host server
US11962518B2 (en) 2020-06-02 2024-04-16 VMware LLC Hardware acceleration techniques using flow selection
US20220393967A1 (en) * 2021-06-07 2022-12-08 Vmware, Inc. Load balancing of vpn traffic over multiple uplinks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040264458A1 (en) * 2003-06-25 2004-12-30 Alcatel Architecture for bridged ethernet residential access networks
US20070047583A1 (en) * 2005-08-29 2007-03-01 Siemens Aktiengesellschaft Method for using a short address in a packet header
US20080181243A1 (en) * 2006-12-15 2008-07-31 Brocade Communications Systems, Inc. Ethernet forwarding in high performance fabrics
US20100316056A1 (en) * 2009-06-12 2010-12-16 Nortel Networks Limited Techniques for routing data between network areas

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8509248B2 (en) * 2008-12-29 2013-08-13 Juniper Networks, Inc. Routing frames in a computer network using bridge identifiers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040264458A1 (en) * 2003-06-25 2004-12-30 Alcatel Architecture for bridged ethernet residential access networks
US20070047583A1 (en) * 2005-08-29 2007-03-01 Siemens Aktiengesellschaft Method for using a short address in a packet header
US20080181243A1 (en) * 2006-12-15 2008-07-31 Brocade Communications Systems, Inc. Ethernet forwarding in high performance fabrics
US20100316056A1 (en) * 2009-06-12 2010-12-16 Nortel Networks Limited Techniques for routing data between network areas

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130136128A1 (en) * 2011-09-16 2013-05-30 Robert Robinson Encapsulating traffic while preserving packet characteristics
US9769116B2 (en) * 2011-09-16 2017-09-19 Wilmerding Communications Llc Encapsulating traffic while preserving packet characteristics
US20150341286A1 (en) * 2012-07-30 2015-11-26 Byung Kyu Choi Provider Bridged Network Communication
US9716671B2 (en) * 2012-07-30 2017-07-25 Hewlett Packard Enterprise Development Lp Provider bridged network communication
US9531624B2 (en) * 2013-08-05 2016-12-27 Riverbed Technology, Inc. Method and apparatus for path selection
US20170085468A1 (en) * 2013-08-05 2017-03-23 Riverbed Technology, Inc. Method and apparatus for path selection
US20150036684A1 (en) * 2013-08-05 2015-02-05 Riverbed Technology, Inc. Method and apparatus for path selection
US10313229B2 (en) * 2013-08-05 2019-06-04 Riverbed Technology, Inc. Method and apparatus for path selection
US20190245780A1 (en) * 2013-08-05 2019-08-08 Riverbed Technology, Inc. Method and apparatus for path selection
US11032188B2 (en) * 2013-08-05 2021-06-08 Riverbed Technology, Inc. Method and apparatus for path selection
WO2015169244A1 (en) * 2014-05-09 2015-11-12 Huawei Technologies Co., Ltd. System and method for loop suppression in transit networks
US9350648B2 (en) 2014-05-09 2016-05-24 Huawei Technologies Co., Ltd. System and method for loop suppression in transit networks
US9900246B2 (en) 2014-05-09 2018-02-20 Huawei Technologies Co., Ltd. System and method for loop suppression in transit networks
US9608858B2 (en) 2014-07-21 2017-03-28 Cisco Technology, Inc. Reliable multipath forwarding for encapsulation protocols

Also Published As

Publication number Publication date
EP2503743B1 (de) 2016-12-07
US20120243539A1 (en) 2012-09-27
EP2503743A2 (de) 2012-09-26
EP3145135B1 (de) 2021-06-02
CN102694721B (zh) 2019-06-18
CN102694721A (zh) 2012-09-26
EP2503743A3 (de) 2012-11-14
EP3145135A1 (de) 2017-03-22

Similar Documents

Publication Publication Date Title
US8755383B2 (en) Usage of masked ethernet addresses between transparent interconnect of lots of links (TRILL) routing bridges
US8787377B2 (en) Usage of masked BMAC addresses in a provider backbone bridged (PBB) network
US11240065B2 (en) NSH encapsulation for traffic steering
RU2735725C1 (ru) Способ и устройство обработки и отправки пакетов, узел pe и узел
CN109218178B (zh) 一种报文处理方法及网络设备
US9843504B2 (en) Extending OpenFlow to support packet encapsulation for transport over software-defined networks
US8537816B2 (en) Multicast VPN support for IP-VPN lite
US8675522B2 (en) Conveying the VLAN/L2 VSN/bridging-domain of the incoming interface (IIF) when transporting multicast traffic over a shortest path bridged (SPB) network
WO2019105462A1 (zh) 报文的发送、处理方法及装置，pe节点，节点
US9654303B2 (en) Method and apparatus for emulating network devices
US8351352B1 (en) Methods and apparatus for RBridge hop-by-hop compression and frame aggregation
US8830998B2 (en) Separation of edge and routing/control information for multicast over shortest path bridging
EP3834365B1 (de) Versionierung des multicast-verteilungsbaums zur minimierung von multicast-gruppenverkehrsunterbrechungen
US20150092775A1 (en) Using context labels to scale mac tables on computer network edge devices
US20120014261A1 (en) Monitoring A Flow Set To Detect Faults
US8705403B2 (en) Load balancing multicast traffic
WO2022062506A1 (zh) 一种数据处理方法、装置、存储介质及电子装置
US11362954B2 (en) Tunneling inter-domain stateless internet protocol multicast packets
US10333828B2 (en) Bidirectional multicasting over virtual port channel
Sajassi et al. A network virtualization overlay solution using ethernet VPN (eVPN)
WO2024016869A1 (zh) 一种组播配置方法及装置
Ajila et al. Using modified floyd-warshall algorithm to implement spb ieee 802.1 aq protocol simulator on ns-3
Shahrokhkhani An Analysis on Network Virtualization Protocols and Technologies
Bitar et al. RFC 8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)

Legal Events

Date Code Title Description
AS Assignment

Owner name: AVAYA INC., NEW JERSEY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KEESARA, SRIKANTH;REEL/FRAME:026362/0302

Effective date: 20110531

AS Assignment

Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., PENNSYLVANIA

Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:029608/0256

Effective date: 20121221

Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., P

Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:029608/0256

Effective date: 20121221

AS Assignment

Owner name: BANK OF NEW YORK MELLON TRUST COMPANY, N.A., THE, PENNSYLVANIA

Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:030083/0639

Effective date: 20130307

Owner name: BANK OF NEW YORK MELLON TRUST COMPANY, N.A., THE,

Free format text: SECURITY AGREEMENT;ASSIGNOR:AVAYA, INC.;REEL/FRAME:030083/0639

Effective date: 20130307

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: CITIBANK, N.A., AS ADMINISTRATIVE AGENT, NEW YORK

Free format text: SECURITY INTEREST;ASSIGNORS:AVAYA INC.;AVAYA INTEGRATED CABINET SOLUTIONS INC.;OCTEL COMMUNICATIONS CORPORATION;AND OTHERS;REEL/FRAME:041576/0001

Effective date: 20170124

AS Assignment

Owner name: SILICON VALLEY BANK, CALIFORNIA

Free format text: SECOND AMENDED AND RESTATED PATENT AND TRADEMARK SECURITY AGREEMENT;ASSIGNOR:EXTREME NETWORKS, INC.;REEL/FRAME:043200/0614

Effective date: 20170714

AS Assignment

Owner name: EXTREME NETWORKS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AVAYA INC.;AVAYA COMMUNICATION ISRAEL LTD;AVAYA HOLDINGS LIMITED;REEL/FRAME:043569/0047

Effective date: 20170714

AS Assignment

Owner name: SILICON VALLEY BANK, CALIFORNIA

Free format text: THIRD AMENDED AND RESTATED PATENT AND TRADEMARK SECURITY AGREEMENT;ASSIGNOR:EXTREME NETWORKS, INC.;REEL/FRAME:044639/0300

Effective date: 20171027

AS Assignment

Owner name: AVAYA INTEGRATED CABINET SOLUTIONS INC., CALIFORNIA

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531

Effective date: 20171128

Owner name: OCTEL COMMUNICATIONS LLC (FORMERLY KNOWN AS OCTEL COMMUNICATIONS CORPORATION), CALIFORNIA

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531

Effective date: 20171128

Owner name: AVAYA INC., CALIFORNIA

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 029608/0256;ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.;REEL/FRAME:044891/0801

Effective date: 20171128

Owner name: OCTEL COMMUNICATIONS LLC (FORMERLY KNOWN AS OCTEL

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531

Effective date: 20171128

Owner name: AVAYA INTEGRATED CABINET SOLUTIONS INC., CALIFORNI

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531

Effective date: 20171128

Owner name: VPNET TECHNOLOGIES, INC., CALIFORNIA

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531

Effective date: 20171128

Owner name: AVAYA INC., CALIFORNIA

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 041576/0001;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:044893/0531

Effective date: 20171128

Owner name: AVAYA INC., CALIFORNIA

Free format text: BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL/FRAME 030083/0639;ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.;REEL/FRAME:045012/0666

Effective date: 20171128

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

AS Assignment

Owner name: BANK OF MONTREAL, NEW YORK

Free format text: SECURITY INTEREST;ASSIGNOR:EXTREME NETWORKS, INC.;REEL/FRAME:046050/0546

Effective date: 20180501

Owner name: EXTREME NETWORKS, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:046051/0775

Effective date: 20180501

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: BANK OF MONTREAL, NEW YORK

Free format text: AMENDED SECURITY AGREEMENT;ASSIGNORS:EXTREME NETWORKS, INC.;AEROHIVE NETWORKS, INC.;REEL/FRAME:064782/0971

Effective date: 20230818