DE112020002490T5 - Verfahren und system zur gewährleistung der fairness beim netzaustritt zwischen anwendungen - Google Patents

Verfahren und system zur gewährleistung der fairness beim netzaustritt zwischen anwendungen Download PDF

Info

Publication number
DE112020002490T5
DE112020002490T5 DE112020002490.3T DE112020002490T DE112020002490T5 DE 112020002490 T5 DE112020002490 T5 DE 112020002490T5 DE 112020002490 T DE112020002490 T DE 112020002490T DE 112020002490 T5 DE112020002490 T5 DE 112020002490T5
Authority
DE
Germany
Prior art keywords
flow
packet
bandwidth
shaping
queue
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.)
Pending
Application number
DE112020002490.3T
Other languages
English (en)
Inventor
David Charles Hewson
Timothy J. Johnson
Abdulla M. Bataineh
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.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
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 Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE112020002490T5 publication Critical patent/DE112020002490T5/de
Pending legal-status Critical Current

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/28—Routing or path finding of packets in data switching networks using route fault recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0862—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1036—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1045—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache
    • G06F12/1063—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache the data cache being concurrently virtually addressed
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/1642—Handling requests for interconnection or transfer for access to memory bus based on arbitration with request queuing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668—Details of memory controller
    • G06F13/1673—Details of memory controller using buffers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668—Details of memory controller
    • G06F13/1689—Synchronisation and timing concerns
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/385—Information transfer, e.g. on bus using universal interface adapter for adaptation of a particular data processing system to different peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4063—Device-to-bus coupling
    • G06F13/4068—Electrical coupling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4204—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
    • G06F13/4221—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4265—Bus transfer protocol, e.g. handshake; Synchronisation on a point to point bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306—Intercommunication techniques
    • G06F15/17331—Distributed shared memory [DSM], e.g. remote direct memory access [RDMA]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/021—Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/028—Dynamic adaptation of the update intervals, e.g. event-triggered updates
    • 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/12—Shortest path evaluation
    • H04L45/122—Shortest path evaluation by minimising distances, e.g. by selecting a route with minimum of number of hops
    • 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/12—Shortest path evaluation
    • H04L45/123—Evaluation of link metrics
    • 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/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth
    • 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/16—Multipoint routing
    • 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/20—Hop count for routing purposes, e.g. TTL
    • 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/22—Alternate routing
    • 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/24—Multipath
    • 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/38—Flow based routing
    • 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/42—Centralised routing
    • 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/46—Cluster building
    • 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/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • 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/70—Routing based on monitoring results
    • 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/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • 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/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing
    • 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/11—Identifying congestion
    • 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/12—Avoiding congestion; Recovering from congestion
    • 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/12—Avoiding congestion; Recovering from congestion
    • H04L47/122—Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities
    • 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/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • 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/18—End to end
    • 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/20—Traffic policing
    • 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/22—Traffic shaping
    • 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
    • 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/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • 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/2466—Traffic characterised by specific attributes, e.g. priority or QoS using signalling traffic
    • 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/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • 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/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • 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/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • 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/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • 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/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • 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/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H04L47/323—Discarding or blocking control packets, e.g. ACK packets
    • 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/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • 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/39—Credit based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/621—Individual queue per connection or flow, e.g. per VC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/622—Queue service order
    • H04L47/6235—Variable service order
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/6255—Queue scheduling characterised by scheduling criteria for service slots or service orders queue load conditions, e.g. longest queue first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/626—Queue scheduling characterised by scheduling criteria for service slots or service orders channel conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/6275—Queue scheduling characterised by scheduling criteria for service slots or service orders based on priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/629—Ensuring fair share of resources, e.g. weighted fair queuing [WFQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/10—Packet switching elements characterised by the switching fabric construction
    • H04L49/101—Packet switching elements characterised by the switching fabric construction using crossbar or matrix
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/15—Interconnection of switching modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3009—Header conversion, routing tables or routing tags
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3018—Input queuing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3027—Output queuing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9005—Buffering arrangements using dynamic buffer space allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9021—Plurality of buffers per packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9036—Common buffer combined with individual queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/50—Control mechanisms for virtual memory, cache or TLB
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0026—PCI express
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/38—Universal adapter
    • G06F2213/3808—Network interface controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Transfer Systems (AREA)
  • Small-Scale Networks (AREA)
  • Advance Control (AREA)

Abstract

Es werden Verfahren und Systeme bereitgestellt, um die Fairness zwischen Anwendungen am Netzwerkausgang zu erleichtern. An einem Ausgangs-Port eines Netzwerks kann ein Arbitrator fairness-basiertes Traffic Shaping für Daten bereitstellen, die mit Anwendungen verbunden sind. Das gewünschte Fairness-basierte Traffic Shaping kann auf Basis von Bandbreite, Verkehrsklassen oder anderen Parametern erfolgen. Folglich kann die Bandbreite der Ausgangsverbindung fair unter den Anwendungen aufgeteilt werden.

Description

  • HINTERGRUND
  • Feld
  • Dies bezieht sich allgemein auf den technischen Bereich der Vernetzung. Genauer gesagt bezieht sich diese Offenlegung auf Methoden und Systeme zur Erleichterung der Fairness beim Netzwerkeintritt zwischen Anwendungen.
  • Verwandte Kunst
  • Da netzwerkfähige Geräte und Anwendungen immer allgegenwärtiger werden, erfordern verschiedene Arten von Datenverkehr sowie die ständig steigende Netzwerklast immer mehr Leistung von der zugrunde liegenden Netzwerkarchitektur. So können beispielsweise Anwendungen wie High-Performance Computing (HPC), Medien-Streaming und Internet of Things (IOT) verschiedene Arten von Datenverkehr mit unterschiedlichen Merkmalen erzeugen. Infolgedessen stehen Netzwerkarchitekten zusätzlich zu den herkömmlichen Netzwerkleistungskennzahlen wie Bandbreite und Verzögerung weiterhin vor Herausforderungen wie Skalierbarkeit, Vielseitigkeit und Effizienz.
  • ZUSAMMENFASSUNG
  • Es werden Verfahren und Systeme bereitgestellt, um die Fairness zwischen Anwendungen am Netzwerkausgang zu erleichtern. An einem Ausgangs-Port eines Netzwerks kann ein Arbitrator fairness-basiertes Traffic Shaping für Daten bereitstellen, die mit Anwendungen verbunden sind. Das gewünschte Faimess-basierte Traffic Shaping kann auf der Grundlage von Bandbreite, Verkehr Klassen oder andere Parameter. Folglich kann die Bandbreite des Egress-Links unter den Anwendungen gerecht aufgeteilt werden.
  • KURZBESCHREIBUNG DER ZAHLEN
    • zeigt ein beispielhaftes Netz, das Fließkanäle erleichtert.
    • zeigt einen beispielhaften Schalter, der die Fließkanäle erleichtert.
    • zeigt ein Beispiel dafür, wie Schalter entlang eines Datenpfads Informationen über den Flusszustand aufrechterhalten können.
    • zeigt einen beispielhaften Fabric-Header für ein Datenpaket.
    • zeigt ein beispielhaftes Format eines Bestätigungspakets (ACK).
    • zeigt die Beziehung zwischen verschiedenen Variablen, die zur Ableitung und Aufrechterhaltung von Zustandsinformationen eines Flusses verwendet werden.
    • zeigt ein Beispiel dafür, wie Fließkanaltabellen verwendet werden können, um einen Fluss zu liefern.
    • zeigt ein Beispiel für eine Kantenflusskanaltabelle (EFCT).
    • zeigt ein Beispiel für eine Eingangsflusskanaltabelle (IFCT).
    • zeigt ein Beispiel für eine Ausgangsflusskanaltabelle (OFCT).
    • zeigt eine beispielhafte Schalterarchitektur.
    • zeigt eine beispielhafte Matrix von Kreuzschienen-Schaltfeldern.
    • zeigt einen beispielhaften Kreuzschienenschalter mit virtueller Ausgangswarteschlange und Kreuzschienen-Warteschlange.
    • zeigt beispielhafte Alterswarteschlangen für die Speicherung von Anfragen.
    • zeigt eine beispielhafte Konfiguration von Token-Buckets für die Arbitrierung zwischen den Shaping-Warteschlangen.
    • zeigt ein Flussdiagramm eines beispielhaften Schlichtungsprozesses, der die Fairness beim Austritt erleichtert.
    • zeigt einen beispielhaften Mechanismus für die Arbitrierung zwischen Anfragen zur Paketweiterleitung.
    • zeigt ein Beispiel, bei dem eine unfaire Aufteilung der Verbindungsbandbreite in einem Netz auftreten kann.
    • zeigt ein Beispiel für eine Überlastung des Endpunkts.
    • zeigt ein Flussdiagramm eines beispielhaften Verfahrens zur Erzeugung einer expliziten Endpunkt-Stau-Benachrichtigung ACK.
    • zeigt einen beispielhaften Logikblock für das Staumanagement am Endpunkt.
    • zeigt ein Flussdiagramm eines beispielhaften Prozesses zur Erzeugung eines ACK als Reaktion auf ein Paket, das aus der Warteschlange eines Ausgangspuffers entfernt wurde.
    • zeigt ein Flussdiagramm eines beispielhaften Feinkomflusssteuerungsverfahrens (FGFC).
    • zeigt ein Beispiel für einen FGFC-fähigen Netzschnittstellen-Controller.
    • zeigt ein Beispiel für eine Überlastung der Netzverbindung.
    • zeigt ein Flussdiagramm eines Beispiels für die Anwendung einer kreditbasierten Flusskontrolle auf einer überlasteten Fabric-Verbindung.
    • zeigt ein beispielhaftes Kantenschaltsystem, das Fließkanäle erleichtert.
    • zeigt ein beispielhaftes Zwischenschaltsystem, das Fließkanäle erleichtert.
  • In den Abbildungen beziehen sich gleiche Ziffern auf die gleichen Elemente der Abbildung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Verschiedene Modifikationen der offengelegten Ausführungsformen sind für den Fachmann ohne weiteres ersichtlich, und die hierin definierten allgemeinen Grundsätze können auf andere Ausführungsformen und Anwendungen angewandt werden, ohne vom Geist und Umfang der vorliegenden Offenbarung abzuweichen. Daher ist die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt.
  • Übersicht
  • Die vorliegende Offenlegung beschreibt Systeme und Verfahren, die die Fairness bei Netzwerkausgängen erleichtern können. Insbesondere kann ein Switch die Weiterleitung empfangener Pakete auf der Grundlage ihrer Verkehrsklasse planen und bei der Planung der Paketübertragung eine faire Arbitrierung durchführen. Shaping-Warteschlangen können verwendet werden, um die gewünschte Bandbreitenzuweisung zwischen verschiedenen Verkehrsklassen und virtuellen Kanälen zu erreichen.
  • In dieser Offenlegung können Paketströme auch als „Paketflüsse“ oder einfach als „Flüsse“ bezeichnet werden. Der Datenpfad, den ein Datenstrom durchläuft, kann zusammen mit seinen Konfigurationsinformationen, die von Vermittlungsstellen verwaltet werden, als „Datenstromkanal“ bezeichnet werden. „Darüber hinaus werden die Begriffe „Puffer“ und „Warteschlange“ in dieser Offenlegung austauschbar verwendet.
  • zeigt ein beispielhaftes Netzwerk, das Flusskanäle ermöglicht. In diesem Beispiel kann ein Netzwerk 100 von Switches, das auch als „Switch-Fabric“ bezeichnet werden kann, Switches 102, 104, 106, 108 und 110 umfassen. Jeder Switch kann eine eindeutige Adresse oder ID innerhalb der Switch-Fabric 100 haben. Verschiedene Arten von Geräten und Netzwerken können mit einer Switch-Fabric verbunden werden. Beispielsweise kann ein Speicherarray 112 über den Switch 110 mit der Switch-Fabric 100 verbunden werden; ein InfiniBand (IB) basiertes HPC-Netzwerk 114 kann über den Switch 108 mit der Switch-Fabric 100 verbunden werden; eine Reihe von Endhosts, wie z. B. Host 116, kann über den Switch 104 mit der Switch-Fabric 100 verbunden werden; und ein IP/Ethernet-Netzwerk 118 kann über den Switch 102 mit der Switch-Fabric 100 verbunden werden. Im Allgemeinen kann ein Switch Edge-Ports und Fabric-Ports haben. Ein Edge-Port kann mit einem Gerät verbunden werden, das sich außerhalb der Fabric befindet. Ein Fabric-Port kann über eine Fabric-Verbindung mit einem anderen Switch innerhalb der Fabric verbunden werden.
  • Normalerweise kann der Verkehr über einen Eingangsport eines Edge-Switches in die Switch-Fabric 100 eingespeist werden und die Switch-Fabric 100 über einen Ausgangsport eines anderen (oder desselben) Edge-Switches verlassen. Ein Ingress-Edge-Switch kann injizierte Datenpakete in Flows gruppieren, die durch Flow-IDs identifiziert werden können. Das Konzept eines Datenflusses ist nicht auf ein bestimmtes Protokoll oder eine bestimmte Schicht (wie Schicht-2 oder Schicht-3 im OSI-Referenzmodell) beschränkt. Ein Datenfluss kann z. B. dem Datenverkehr mit einer bestimmten Quell-Ethernet-Adresse, dem Datenverkehr zwischen einer Quell-IP-Adresse und einer Ziel-IP-Adresse, dem Datenverkehr, der einem TCP- oder UDP-Port/IP-5-Tupel entspricht (Quell- und Ziel-IP-Adresse, Quell- und Ziel-TCP- oder -UDP-Portnummer und IP-Protokollnummer), oder dem Datenverkehr, der von einem auf einem Endhost laufenden Prozess oder Thread erzeugt wird, zugeordnet werden. Mit anderen Worten: Ein Fluss kann so konfiguriert werden, dass er Daten zwischen beliebigen physischen oder logischen Einheiten zuordnet. Die Konfiguration dieser Zuordnung kann per Fernzugriff oder lokal am Ingress Edge Switch vorgenommen werden.
  • Beim Empfang von injizierten Datenpaketen kann der Ingress Edge Switch dem Datenfluss eine Fluss-ID zuweisen. Diese Flow-ID kann in einem speziellen Header enthalten sein, den der Ingress Edge Switch zur Verkapselung der injizierten Pakete verwenden kann. Darüber hinaus kann der Ingress-Edge-Switch auch die ursprünglichen Header-Felder eines injizierten Pakets untersuchen, um die entsprechende Adresse des Egress-Edge-Switch zu ermitteln, und diese Adresse als Zieladresse in den Einkapselungs-Header aufnehmen. Beachten Sie, dass die Flow-ID ein lokal signifikanter Wert sein kann, der für eine Verbindung spezifisch ist, und dass dieser Wert nur für einen bestimmten Eingangsport auf einem Switch eindeutig sein kann. Wenn das Paket an den Next-Hop-Switch weitergeleitet wird, tritt das Paket in eine andere Verbindung ein, und die Flow-ID kann entsprechend aktualisiert werden. Da die Pakete eines Flusses mehrere Verbindungen und Switches durchlaufen, können die diesem Fluss entsprechenden Flow-IDs eine eindeutige Kette bilden. Das heißt, dass an jedem Switch, bevor ein Paket den Switch verlässt, die Flow-ID des Pakets auf eine Flow-ID aktualisiert werden kann, die von der ausgehenden Verbindung verwendet wird. Diese Eins-zu-Eins-Zuordnung zwischen den Fluss-IDs kann am Ingress-Edge-Switch beginnen und am Egress-Edge-Switch enden. Da die Fluss-IDs nur innerhalb einer eingehenden Verbindung eindeutig sein müssen, kann ein Switch eine große Anzahl von Flüssen aufnehmen. Wenn eine Fluss-ID beispielsweise 11 Bits lang ist, kann ein Eingangsanschluss bis zu 2048 Flüsse unterstützen. Darüber hinaus kann das Match-Muster (ein oder mehrere Header-Felder eines Pakets), das zur Zuordnung zu einem Datenfluss verwendet wird, eine größere Anzahl von Bits enthalten. Ein 32-Bit langes Abgleichmuster, das mehrere Felder in einem Paketkopf enthalten kann, kann beispielsweise 2^32 verschiedene Kopffeldmuster abbilden. Wenn eine Fabric über N Ingress-Edge-Ports verfügt, kann eine Gesamtzahl von N*2^32 identifizierbaren Flows unterstützt werden.
  • Ein Switch kann jedem Datenfluss eine eigene, dedizierte Eingangswarteschlange zuweisen. Diese Konfiguration ermöglicht es dem Switch, den Grad der Überlastung einzelner Datenströme zu überwachen und zu verwalten und eine Blockierung der Warteschlange zu verhindern, die auftreten könnte, wenn ein gemeinsamer Puffer für mehrere Datenströme verwendet wird. Wenn ein Paket an den Ziel-Egress-Switch geliefert wird, kann der Egress-Switch eine Bestätigung (ACK) in Upstream-Richtung über denselben Datenpfad an den Ingress-Edge-Switch zurücksenden. Da dieses ACK-Paket denselben Datenpfad durchläuft, können die Switches entlang des Pfades die Zustandsinformationen erhalten, die mit der Zustellung des entsprechenden Datenflusses verbunden sind, indem sie die Menge der ausstehenden, unbestätigten Daten überwachen. Diese Zustandsinformationen können dann verwendet werden, um ein flussspezifisches Verkehrsmanagement durchzuführen, um den Zustand des gesamten Netzes und eine faire Behandlung der Flüsse zu gewährleisten. Wie weiter unten näher erläutert, kann die Switch Fabric durch diese Warteschlangenbildung pro Datenfluss in Kombination mit flussspezifischen Zustellungsbestätigungen eine effektive, schnelle und genaue Staukontrolle implementieren. Im Gegenzug kann die Switch Fabric den Datenverkehr mit einer deutlich verbesserten Netzwerkauslastung bereitstellen, ohne dass es zu Überlastungen kommt.
  • Flows können dynamisch oder „on the fly“ je nach Bedarf eingerichtet und freigegeben werden. Insbesondere kann ein Fluss von einem Edge-Switch eingerichtet werden (z. B. wird die Zuordnung von Fluss-ID zu Paketkopf hergestellt), wenn ein Datenpaket am Switch ankommt und diesem Paket zuvor keine Fluss-ID zugewiesen wurde. Während dieses Paket das Netz durchläuft, können Flow-IDs an jedem Switch, den das Paket durchläuft, zugewiesen werden, und es kann eine Kette von Flow-IDs vom Eingang bis zum Ausgang gebildet werden. Nachfolgende Pakete, die zum selben Fluss gehören, können auf dem Datenpfad dieselben Fluss-IDs verwenden. Wenn Pakete an den Ziel-Egress-Switch zugestellt und ACK-Pakete von den Switches entlang des Datenpfads empfangen werden, kann jeder Switch seine Statusinformationen in Bezug auf die Menge der ausstehenden, nicht bestätigten Daten für diesen Fluss aktualisieren. Wenn die Eingangswarteschlange eines Switches für diesen Datenfluss leer ist und es keine weiteren unbestätigten Daten gibt, kann der Switch die Fluss-ID freigeben (d. h. diesen Flusskanal freigeben) und die Fluss-ID für andere Flüsse wiederverwenden. Durch diesen datengesteuerten dynamischen Mechanismus für die Einrichtung und den Abbau von Datenflüssen wird eine zentrale Verwaltung der Datenflüsse überflüssig, und das Netz kann schnell auf Änderungen der Verkehrsmuster reagieren.
  • Beachten Sie, dass sich die hier beschriebene Netzwerkarchitektur von Softwaredefinierten Netzwerken (SDN) unterscheidet, die in der Regel das OpenFlow-Protokoll verwenden. In SDN werden Switches von einem zentralen Netzwerk-Controller konfiguriert, und Pakete werden auf der Grundlage eines oder mehrerer Felder in den Headern der Schicht 2 (Datenverbindungsschicht, z. B. Ethernet), Schicht 3 (Netzwerkschicht, z. B. IP) oder Schicht 4 (Transportschicht, z. B. TCP oder UDP) weitergeleitet. Im SDN wird eine solche Header-FeldSuche an jedem Switch im Netzwerk durchgeführt, und es gibt keine schnelle, auf der Flow-ID basierende Weiterleitung, wie sie in den hier beschriebenen Netzwerken erfolgt. Da die OpenFlow-Header-Feldsuche mit ternärem inhaltsadressierbarem Speicher (TCAM) durchgeführt wird, können die Kosten für solche Suchen hoch sein. Da die Konfiguration der Header-Feld-Zuordnung von der zentralen Steuereinheit vorgenommen wird, ist der Auf- und Abbau jeder Zuordnungsbeziehung relativ langsam und kann eine beträchtliche Menge an Steuerverkehr erfordern. Infolgedessen kann die Reaktion eines SDN-Netzwerks auf verschiedene Netzwerksituationen, wie z. B. eine Überlastung, langsam sein. Im Gegensatz dazu können in dem hier beschriebenen Netzwerk die Flows dynamisch auf der Grundlage der Verkehrsnachfrage auf- und abgebaut werden, und die Pakete können mit einer Flow-ID fester Länge weitergeleitet werden. Mit anderen Worten: Flusskanäle können datengesteuert und dezentral verwaltet (d. h. eingerichtet, überwacht und abgebaut) werden, ohne dass ein zentraler Controller eingreifen muss. Darüber hinaus kann die auf der Fluss-ID basierende Weiterleitung die Menge des verwendeten TCAM-Speicherplatzes reduzieren, so dass eine viel größere Anzahl von Flüssen untergebracht werden kann.
  • Nehmen wir an, dass die Speichermatrix 112 Daten über TCP/IP an den Host 116 senden soll (siehe das Beispiel in ). Während des Betriebs kann die Speichermatrix 112 das erste Paket mit der IP-Adresse des Hosts 116 als Zieladresse und einem vorbestimmten TCP-Port, der im TCP-Header angegeben ist, senden. Wenn dieses Paket die Vermittlungsstelle 110 erreicht, kann der Paketprozessor am Eingangsport der Vermittlungsstelle 110 ein TCP/IP-5-Tupel dieses Pakets identifizieren. Der Paketprozessor der Vermittlungsstelle 110 kann auch feststellen, dass dieses 5-Tupel derzeit keiner Fluss-ID zugeordnet ist, und kann diesem 5-Tupel eine neue Fluss-ID zuweisen. Darüber hinaus kann die Vermittlungsstelle 110 den Ausgangs-Switch, d. h. den Switch 104, für dieses Paket anhand der IP-Adresse des Ziels (d. h. des Hosts 116) bestimmen (vorausgesetzt, die Vermittlungsstelle 110 weiß, dass der Host 116 mit dem Switch 104 verbunden ist). Anschließend kann der Switch 110 das empfangene Paket mit einem Fabric-Header einkapseln, der die neu zugewiesene Flow-ID und die Fabric-Adresse des Switches 104 angibt. Switch 110 kann dann die Weiterleitung des eingekapselten Pakets an Switch 104 auf der Grundlage einer Fabric-Weiterleitungstabelle planen, die von allen Switches in Fabric 100 unter Verwendung eines Routing-Algorithmus wie Link State oder Distance Vector berechnet werden kann.
  • Beachten Sie, dass die oben beschriebenen Vorgänge im Wesentlichen mit Leitungsgeschwindigkeit und mit geringer Pufferung und Verzögerung durchgeführt werden können, wenn das erste Paket empfangen wird. Nachdem das erste Paket verarbeitet und für die Übertragung eingeplant wurde, können nachfolgende Pakete desselben Datenflusses von der Vermittlungsstelle 110 noch schneller verarbeitet werden, da dieselbe Datenfluss-ID verwendet wird. Darüber hinaus können die Flusskanäle so gestaltet werden, dass die Zuweisung, der Abgleich und die Freigabe von Flusskanälen im Wesentlichen die gleichen Kosten verursachen. So können beispielsweise eine bedingte Zuweisung eines Flusskanals auf der Grundlage einer Nachschlageübereinstimmung und eine separate, unabhängige Freigabe eines anderen Flusskanals fast in jedem Taktzyklus gleichzeitig durchgeführt werden. Das bedeutet, dass die Erzeugung und Kontrolle der Flusskanäle fast keinen zusätzlichen Overhead zur regulären Weiterleitung von Paketen verursachen. Der Staukontrollmechanismus hingegen kann die Leistung einiger Anwendungen um mehr als drei Größenordnungen verbessern.
  • An jeder Vermittlungsstelle entlang des Datenpfads (einschließlich der Vermittlungsstellen 110, 106 und 104) kann ein dedizierter Eingangspuffer für diesen Datenfluss bereitgestellt werden, und die Menge der übertragenen, aber nicht quittierten Daten kann verfolgt werden. Wenn das erste Paket den Switch 104 erreicht, kann der Switch 104 feststellen, dass die Fabric-Zieladresse im Fabric-Header des Pakets mit seiner eigenen Adresse übereinstimmt. Daraufhin kann der Switch 104 das Paket aus dem Fabric-Header entkapseln und das entkapselte Paket an den Host 116 weiterleiten. Außerdem kann der Switch 104 ein ACK-Paket erzeugen und dieses ACK-Paket an den Switch 110 zurücksenden. Da dieses ACK-Paket denselben Datenpfad durchläuft, können die Switches 106 und 110 jeweils ihre eigenen Statusinformationen für die unbestätigten Daten für diesen Fluss aktualisieren.
  • Im Allgemeinen kann eine Überlastung des Netzes dazu führen, dass sich die Netzpuffer füllen. Wenn ein Netzpuffer voll ist, sollte der Verkehr, der den Puffer passieren will, idealerweise verlangsamt oder gestoppt werden. Andernfalls könnte der Puffer überlaufen, und die Pakete könnten verworfen werden. In herkömmlichen Netzen erfolgt die Staukontrolle in der Regel von Ende zu Ende am Rand. Es wird davon ausgegangen, dass der Kern des Netzes nur als „dumme Röhre“ fungiert, deren Hauptzweck die Weiterleitung des Datenverkehrs ist. Ein solches Netzdesign leidet oft unter langsamen Reaktionen auf Überlastungen, da Überlastungsinformationen oft nicht schnell an die Edge-Geräte gesendet werden können und die daraus resultierenden Maßnahmen, die von den Edge-Geräten ergriffen werden, nicht immer effektiv zur Beseitigung der Überlastung sind. Diese langsame Reaktion schränkt wiederum die Auslastung des Netzes ein, denn um das Netz staufrei zu halten, muss der Netzbetreiber häufig die Gesamtmenge des in das Netz eingespeisten Verkehrs begrenzen. Außerdem ist eine Endezu-Ende-Überlastungskontrolle in der Regel nur dann wirksam, wenn das Netz nicht bereits überlastet ist. Sobald das Netz stark überlastet ist, würde eine Ende-zu-Ende-Überlastungssteuerung nicht mehr funktionieren, da die Überlastungsmeldungen selbst überlastet sein können (es sei denn, für das Senden von Überlastungssteuerungsmeldungen wird ein separates Netz der Steuerungsebene verwendet, das sich vom Netz der Datenebene unterscheidet).
  • Im Gegensatz dazu können die Flusskanäle verhindern, dass eine solche Überlastung innerhalb der Switch-Fabric entsteht. Der Flow-Channel-Mechanismus kann erkennen, wenn ein Fluss einen gewissen Grad an Überlastung erfährt, und als Reaktion darauf neue Pakete desselben Flusses verlangsamen oder daran hindern, in die Fabric zu gelangen. Im Gegenzug können diese neuen Pakete in einer Flow-Channel-Warteschlange am Edge-Port zwischengespeichert werden und werden erst dann in die Fabric gelassen, wenn Pakete für denselben Flow die Fabric am Edge-Zielport verlassen. Durch diesen Prozess kann der Gesamtpufferbedarf dieses Flusses innerhalb der Fabric auf eine Menge begrenzt werden, die nicht dazu führt, dass die Fabric-Puffer zu voll werden.
  • Mit Flow Channels verfügen die Switches über relativ genaue Statusinformationen über die Menge der ausstehenden Daten, die sich innerhalb der Fabric im Transit befinden. Diese Zustandsinformationen können für alle Flows an einem Ingress-Edge-Port zusammengefasst werden. Das bedeutet, dass die gesamte Datenmenge, die von einem Ingress-Edge-Port eingespeist wird, bekannt sein kann. Folglich kann der Flow-Channel-Mechanismus eine Grenze für die Gesamtdatenmenge in der Fabric festlegen. Wenn alle Edge-Ports diese Begrenzung anwenden, kann die Gesamtmenge der Paketdaten in der gesamten Fabric gut kontrolliert werden, was wiederum verhindern kann, dass die gesamte Fabric gesättigt wird. Die Flusskanäle können auch den Fortschritt eines einzelnen überlasteten Flusses innerhalb der Fabric verlangsamen, ohne andere Flüsse zu verlangsamen. Mit dieser Funktion können Pakete von einem Stau-Hotspot ferngehalten werden, während gleichzeitig verhindert wird, dass die Puffer voll werden, und freier Pufferplatz für nicht zusammenhängenden Verkehr gewährleistet wird.
  • Betrieb des Strömungskanals
  • Im Allgemeinen können Flusskanäle einen Pfad für jede Kommunikationssitzung über die Switch-Fabric definieren. Der Pfad und die Datenmenge, die zu jedem Fluss gehören, können in einer Reihe von dynamisch verbundenen Flusstabellen beschrieben werden, die mit jeder Verbindung der Switch-Fabric verbunden sind. An jedem Eingangsport, Edge und Fabric kann eine Reihe von Flow-Channel-Warteschlangen definiert werden. Es kann eine Warteschlange für jeden Flusskanal geben. Wenn Pakete ankommen, können sie entweder einem Flusskanal an einem Edge-Port zugewiesen werden oder sie wurden einem Flusskanal durch den Egress-Fabric-Port des Link-Partners an einem Fabric-Eingangs-Port zugewiesen. Die Flow-Channel-Informationen können verwendet werden, um die Pakete in die entsprechende Flow-Channel-Warteschlange zu leiten.
  • zeigt einen beispielhaften Schalter, der Fließkanäle erleichtert. In diesem Beispiel kann der Schalter einen Kreuzschienenschalter 202 umfassen. Der Kreuzschienenschalter 202 kann eine Reihe von Eingangsanschlüssen, wie z. B. Eingangsanschluss 204, und eine Reihe von Ausgangsanschlüssen, wie z. B. Ausgang 208, haben. Der Kreuzschienenschalter 202 kann Pakete von einem Eingangsanschluss zu einem Ausgangsanschluss weiterleiten. Jeder Eingangsanschluss kann mit einer Reihe von Eingangswarteschlangen verbunden sein, die jeweils einem anderen ankommenden Datenstrom zugewiesen sind, der an diesem Eingangsanschluss ankommt. Beispielsweise können Daten, die an einem bestimmten Port des Switches ankommen, zunächst auf der Grundlage ihrer einzelnen Ströme getrennt und in strömungsspezifischen Eingangswarteschlangen, wie der Eingangswarteschlange 206, gespeichert werden. Die in den Eingangswarteschlangen gespeicherten Pakete können auf der Grundlage von Planungsalgorithmen zur Staukontrolle (die in späteren Abschnitten ausführlicher beschrieben werden) aus der Warteschlange genommen und an den Crossbar Switch 202 gesendet werden. Auf der Ausgangsseite kann ein Paket, sobald es den Crossbar-Switch 202 passiert hat, vorübergehend in einer Ausgangsübertragungswarteschlange gespeichert werden, z. B. in der Ausgangsübertragungswarteschlange 210, die von allen Strömen gemeinsam genutzt werden kann, die über denselben Ausgangsanschluss abgehen. Bevor ein Paket aus der Warteschlange für die Ausgangsübertragung entfernt und auf der abgehenden Verbindung übertragen wird, kann der Paketkopf mit der Fluss-ID für die abgehende Verbindung aktualisiert werden. Beachten Sie, dass diese Hop-by-Hop-Flow-ID-Zuordnung vorgenommen werden kann, wenn das erste Paket im Fluss das Netzwerk durchläuft. Wenn das Paket den Next-Hop-Switch erreicht, kann das Paket erneut in einer flussspezifischen Eingangswarteschlange gespeichert werden, und der gleiche Prozess kann wiederholt werden. Beachten Sie, dass eine Flow-ID verwendet wird, um zwischen Flüssen zu unterscheiden, die über dieselbe Fabric-Verbindung laufen, und dass sie in der Regel von der Senderseite dieser Verbindung zugewiesen werden kann, d. h. vom Ausgangsport des Switches, der auf dieser Verbindung sendet.
  • Durch die Bereitstellung flussspezifischer Eingangswarteschlangen kann der Switch jedem Fluss erlauben, sich unabhängig von allen anderen Flüssen zu bewegen. Der Switch kann das Head-of-Queue-Blocking-Problem vermeiden, das bei gemeinsamen Eingangspuffern häufig auftritt. Die flussspezifische Eingabewarteschlange ermöglicht es außerdem, die Pakete innerhalb eines einzelnen Flusses in der richtigen Reihenfolge zu halten. Wenn ein Datenfluss die Switches durchläuft, kann für diesen Fluss eine flussspezifische Eingangswarteschlange an jedem Eingangsanschluss zugewiesen werden, und diese Eingangswarteschlangen werden verknüpft, so dass sie effektiv eine lange Warteschlange bilden, die sich über die gesamte Fabric für diesen Fluss erstreckt, und die Pakete dieses Flusses können in der richtigen Reihenfolge gehalten werden.
  • Der Fortschritt der erfolgreichen Zustellung von Paketen, die zu einem Fluss gehören, kann durch eine Folge von ACKs gemeldet werden, die vom Edge-Port eines Egress-Switches erzeugt werden. Die ACK-Pakete können sich in umgekehrter Richtung entlang des von den Datenpaketen durchlaufenen Datenpfads bewegen und von den Vermittlungsstellen gemäß den in den Datenflusstabellen gespeicherten Weiterleitungsinformationen weitergeleitet werden. Während sich die ACK-Pakete stromaufwärts bewegen, können sie vom Eingangswarteschlangen-Manager jedes Switches verarbeitet werden, der die Zustandsinformationen des entsprechenden Flusses auf der Grundlage der in den ACK-Paketen enthaltenen Informationen aktualisieren kann. Die ACK-Pakete können ein Typ-Feld enthalten, um erweiterte Informationen über den nachgelagerten Datenpfad, z. B. eine Überlastung, bereitzustellen. Der Eingangswarteschlangen-Manager eines Switches kann diese Informationen nutzen, um Entscheidungen über die anstehenden Datenpakete, die derzeit in seinen Eingangswarteschlangen gepuffert sind, zu treffen, z. B. die Drosselung der Übertragungsrate oder die Änderung des Weiterleitungspfads. Darüber hinaus kann der Eingangswarteschlangenmanager die in einem ACK-Paket enthaltenen Informationen auf der Grundlage der Zustandsinformationen eines gepufferten Datenflusses aktualisieren, so dass die vorgelagerten Vermittlungsstellen die richtigen Entscheidungen treffen können. Wenn beispielsweise eine Eingangswarteschlange für einen bestimmten Datenfluss überlastet ist (z. B. wenn die Datenmenge in der Warteschlange einen vorgegebenen Schwellenwert überschreitet), kann der Eingangswarteschlangen-Manager ein ACK-Paket, das an die nächste vorgelagerte Vermittlungsstelle weitergeleitet wird, so aktualisieren, dass es diese Überlastungsinformationen enthält.
  • Wenn ein ACK dem letzten Paket eines Flusses entspricht, kann ein Switch feststellen, dass es keine weiteren unbestätigten Daten für diesen Fluss gibt. Dementsprechend kann der Switch den Flow-Kanal freigeben, indem er den entsprechenden Eintrag in der Flow-Tabelle entfernt.
  • Wie bereits erwähnt, kann der Eingangswarteschlangen-Manager an jeder Vermittlungsstelle Informationen über übertragene, aber nicht quittierte Daten eines bestimmten Datenflusses speichern. zeigt ein Beispiel dafür, wie Schalter entlang eines Datenpfads Informationen über den Status des Datenflusses speichern können. In diesem Beispiel kann der Datenpfad, der von einem Datenfluss durchlaufen wird, die Schalter 222, 224 und 226 umfassen. Die Menge der übertragenen, aber nicht bestätigten Flussdaten kann durch eine Variable „flow_extent“ angegeben werden, die in der Anzahl der Dateneinheiten fester Länge, z. B. 256 Byte, gemessen werden kann. Darüber hinaus können der „flow extent“ und andere Informationen über den Zustand des Datenflusses von der Warteschlangenverwaltung einer Vermittlungsstelle verwaltet werden, die alle flussspezifischen Warteschlangen kontinuierlich überwachen kann.
  • Im Beispiel in ist der Wert von flow extent am Eingangswarteschlangenmanager des Switches 1, da eine Dateneinheit aus der Eingangswarteschlange gesendet und über den Crossbar-Switch weitergeleitet wurde. Beachten Sie, dass ein von einer Eingangswarteschlange gesendetes Datenpaket aufgrund der Planung aller über eine Ausgangsverbindung zu übertragenden Datenpakete vorübergehend im Ausgangsübertragungspuffer zwischengespeichert werden kann. Wenn ein solches Paket im Sendepuffer des Ausgangsport gepuffert wird, kann das Paket von der Eingangswarteschlange zum Zweck der Aktualisierung des flow_extent-Wertes weiterhin als übertragen betrachtet werden.
  • Da die Eingabewarteschlange für den gegebenen Datenfluss am Schalter 226 sechs Dateneinheiten in der Warteschlange enthält und sich zwei zusätzliche Dateneinheiten im Transit zwischen den Schaltern 224 und 226 befinden, beträgt der flow_extent-Wert am Schalter 224 9. Entsprechend beträgt der flow extent-Wert am Schalter 222 13, da sich drei Dateneinheiten in der Eingabewarteschlange am Schalter 224 befinden und eine Dateneinheit im Transit zwischen den Schaltern 222 und 224.
  • Im Allgemeinen kann ein Flusskanal einem einzelnen Fluss zugewiesen bleiben, bis alle ACKs für alle über den Flusskanal gesendeten Pakete zurückgegeben wurden. Das bedeutet, dass Flow-Channel-Tabelleneinträge in der Nähe des Ingress-Edge-Ports des Netzes länger aktiv bleiben können als in der Nähe des Egress-Edge-Ports. Wenn ein einzelnes Paket in das Netz eingespeist wird, kann ein Flusskanal für den Eingangs-Edge-Port zugewiesen werden und dann ein weiterer Flusskanal für den nächsten Fabric-Link, den das Paket durchläuft, und so weiter, bis der letzte Flusskanal zugewiesen ist, wenn das Paket den letzten Fabric-Link erreicht. Jede Zuweisung kann eine Flow-ID erzeugen, die als Variable „flow_id“ bezeichnet wird, um die Einträge in den Flow-Tabellen des Fabric Link zu identifizieren. (Weitere Einzelheiten zu den Flusskanaltabellen sind in der nachfolgenden Beschreibung in Verbindung mit enthalten. ) Dieses erste Paket kann die Zuweisung einer anderen flow_id auf jeder der Fabric-Verbindungen verursachen, die das Paket über die Switch-Fabric durchläuft.
  • In der Eingangswarteschlange jedes Switches können die Flow-Channel-Tabelleneinträge die Zustandsinformationen jedes Flows, einschließlich des flow_extent-Werts, von diesem Punkt aus stromabwärts bis zum Egress-Ziel-Edge-Port des Flows angeben. Am lokalen Eingangsport empfangene Pakete können diesen flow extent-Wert um die Menge der eingehenden Daten erhöhen, und ACKs können den flow_extent-Wert um die Menge der bestätigten, zugestellten Daten verringern.
  • Wenn ein Paket den endgültigen Ziel-Egress-Port erreicht, kann ein ACK-Paket für dieses Paket erzeugt und zurückgeschickt werden. Dieses ACK-Paket kann unter Verwendung der Datenpfadinformationen weitergeleitet werden, die in dem entsprechenden Eintrag der Flusskanaltabellen an jedem Switch entlang des Datenpfads gespeichert sind. Optional muss das ACK-Paket selbst keine Pfadinformationen enthalten und kann daher klein und leicht sein. Wenn kein anderes Datenpaket auf dem Datenfluss gesendet wird, kann das ACK jeden Flusskanal in umgekehrter Reihenfolge freigeben. Nach der Freigabe kann der Flusskanal an jedem Switch einem anderen Fluss zugewiesen werden.
  • Folgt auf das erste Paket im gleichen Fluss ein weiteres Paket, müsste das ACK für das zweite Paket empfangen werden, bevor der Flusskanal an einem bestimmten Schalter freigegeben werden kann. In einer Ausführungsform kann der Flusskanal erst freigegeben werden, wenn ACKs für alle übertragenen Pakete desselben Flusses zurückgegeben wurden.
  • In der Regel erfordern verschiedene Protokolle eine geordnete Zustellung der Pakete. Die Flusskanäle können verwendet werden, um diese Zustellungsreihenfolge zu gewährleisten, selbst wenn die Fabric adaptives Routing für den Lastausgleich über mehrere Datenpfade verwendet. Wenn Pakete zwischen einem Ingress-Edge-Port und einem Egress-Edge-Port, vielleicht in einem anderen Switch auf der anderen Seite der Fabric, mit einer sehr niedrigen Rate eingespeist werden, dann könnte jedes eingespeiste Paket sein Ziel erreichen und ein ACK zurück an die Quelle senden, bevor das nächste Paket eingespeist wird. In diesem Fall kann jedes Paket ein Lead-Paket sein und jeden beliebigen Weg über die Fabric nehmen, wobei die beste verfügbare dynamische adaptive Routing-Auswahl verwendet wird. Dies ist möglich, weil das erste Paket den Weg des Datenflusses durch die Fabric bestimmen kann.
  • Nehmen wir nun an, dass die Paketinjektionsrate leicht erhöht wird, so dass das nächste Paket desselben Datenflusses injiziert wird, bevor das ACK des aktuellen Pakets zur Quelle zurückgekehrt ist. Das zweite Paket kann das ACK des ersten Pakets irgendwo auf dem Datenpfad des Flusses passieren. Jenseits dieses Übergabepunkts hat das ACK die dem ersten Paket zugewiesenen Flusskanäle freigegeben, da der mit dem ersten Paket verbundene flow_extent-Wert auf Null zurückgesetzt wird, wenn das ACK von der Logik des Flusskanals verarbeitet wird. In der Zwischenzeit kann das zweite Paket nun einen neuen Fluss definieren, da es erneut die Zuweisung von Flusskanälen auf jeder der nachfolgenden Fabric Links verursacht. Dieses zweite Paket kann, während es die Zuweisung von Flusskanälen über den Übergabepunkt hinaus bewirkt, auf der Grundlage des dynamischen adaptiven Routings an einen anderen Pfad weitergeleitet werden. Andererseits kann das zweite Paket vor dem Übergabepunkt den ausstehenden Fluss, der durch das erste Paket erzeugt wurde, um das zweite Paket erweitern. Das bedeutet, dass die ACK des ersten Pakets den Wert von flow extent nicht auf Null reduzieren kann und die Flusskanäle vor dem Übergabepunkt aktiv bleiben können. Es bedeutet auch, dass das zweite Paket genau dem Weg folgen kann, den das erste Paket bis zum Übergabepunkt genommen hat. Beachten Sie, dass das zweite Paket, während es dem vorherigen Paket folgt, nicht vor dem ersten Paket am Egress-Edge-Port ankommen kann, so dass die korrekte Reihenfolge der Pakete beibehalten werden kann.
  • Wenn die Injektionsrate für diesen Fluss weiter erhöht wird, wird das zweite Paket das ACK des ersten Pakets an einer Stelle passieren, die näher am Ziel-Edge-Port liegt. Es ist auch möglich, dass ein drittes, viertes, fünftes oder zusätzliches Paket in das Netz gelangt, bevor das ACK des ersten Pakets an den Quell-Edge-Port zurückgesendet wird, abhängig von der Datenpaket-Injektionsrate dieses Flusses und der Datenpaket-ACK-Roundtrip-Verzögerung. Die maximale Paketrate kann von der Größe der Pakete und der Bandbreite der Verbindungen abhängen. Die Round-Trip-Verzögerung des Datenpakets und des ACK kann ein wichtiger Parameter für eine Fabric-Implementierung sein und kann zusammen mit der maximalen Paketrate verwendet werden, um die maximal erforderliche Anzahl von Flusskanälen für jede Verbindung zu berechnen. Im Idealfall kann ein Entwurf unabhängig vom Verkehrsmuster eine angemessene Anzahl von nicht zugewiesenen Flusskanälen bereitstellen. Der Bedarf an Flow Channels kann hoch sein, wenn eine große Anzahl von Paketen mit unterschiedlichen Zielen an einem Ingress-Edge-Port eintrifft und diese Pakete kleine Größen und hohe Injektionsraten haben. Im extremsten Fall könnte jedem Paket ein anderer Datenflusskanal zugewiesen werden. Diese Flusskanäle werden freigegeben, wenn die ACKs der Pakete zurückgegeben werden. Dementsprechend kann die Anzahl der benötigten Flusskanäle berechnet werden als ((Paketrate) * (durchschnittliche Paket-zu-ACK-Latenzzeit)).
  • Beachten Sie, dass die Paketrate auf einem einzelnen Flusskanal nicht mit der Paketrate auf einer Verbindung verwechselt werden darf. Wenn das Verkehrsmuster so beschaffen ist, dass viele kleine Pakete an verschiedene Ziele gesendet werden, dann können aufeinanderfolgende Pakete, die auf der Verbindung gesendet werden, verschiedene Ziele haben. Das bedeutet, dass jedes Paket zu einem anderen Fluss gehören könnte und das einzige Paket sein könnte, das den entsprechenden Flusskanal nutzt. In diesem Beispiel kann die Verbindung eine hohe Paketrate aufweisen, aber die Paketrate der einzelnen Flüsse kann niedrig sein. Optional kann eine Anzahl von ACKs (z. B. 48 ACKs) für die Übertragung über eine Verbindung zu einem einzigen ACK-Rahmen zusammengefasst und durch eine Rahmenprüfsequenz (z. B. eine 32-Bit-FCS) geschützt werden. Die ACKs können z. B. jeweils 25 Bit belegen, und der Rahmen kann einen Overhead von 9 Byte enthalten. Das heißt, der Overhead pro ACK bei einem Rahmen voller Größe beträgt ungefähr 9/(25/8 * 48) * 100% = 6%. Die Logik kann die Anzahl der ACKs pro Frame optimieren, so dass eine ACK nicht zu lange warten muss, um aggregiert zu werden, wenn die ACKs langsam eintreffen. Der Logikblock für die ACK-Aggregation kann z. B. drei Zeitgeber verwenden, um die ACK-Übertragung auf der Grundlage der Aktivität einer ausgehenden Verbindung zu steuern. Diese Zeitgeber können gestartet werden, wenn ein neues ACK beim ACK-Aggregationslogikblock eintrifft. Wenn die ausgehende Verbindung im Leerlauf ist, kann ein erster Zeitgeber, der beispielsweise auf 30 ns eingestellt werden kann, verwendet werden, um die ACK zu halten, während auf das Eintreffen weiterer ACKs gewartet wird. Wenn dieser Timer abläuft, können alle innerhalb des entsprechenden Zeitfensters empfangenen ACK zu einem Rahmen zusammengefasst und auf die abgehende Verbindung übertragen werden. Ist die ausgehende Verbindung ausgelastet, kann ein zweiter Timer, der z. B. auf 60ns eingestellt werden kann, verwendet werden, um auf weitere ACKs zu warten. Durch die Verwendung dieses zweiten Timers können mehr ACKs in einem einzigen Frame zusammengefasst werden, und dieser Frame kann nur übertragen werden, wenn eine vorher festgelegte Anzahl von ACKs gesammelt wurde. Es ist zu beachten, dass aufgrund der Beschränkungen des Ethernet-Rahmens eine bestimmte Anzahl von ACKs in einem einzigen Rahmen weniger Leitungsbandbreite pro ACKs beanspruchen kann als eine andere Anzahl von ACKs. Wenn keine effiziente Anzahl von ACKs gesammelt wird und die ausgehende Verbindung weiterhin mit dem Senden normaler Datenpakete beschäftigt ist, kann ein dritter Timer verwendet werden, der z. B. auf 90ns eingestellt werden kann. Sobald dieser dritte Zeitgeber abläuft, können alle gesammelten ACKs in einem Rahmen zusammengefasst und auf die Verbindung übertragen werden. Durch die Verwendung dieser drei Zeitgeber kann das System den Overhead für das Senden von ACKs auf der abgehenden Verbindung erheblich reduzieren.
  • In einigen Beispielen kann der Eingangs-Edge-Port eines Switches ein empfangenes Datenpaket mit einem Fabric-Header einkapseln, was die Weiterleitung des Pakets über Flow-Channels ermöglicht. zeigt einen beispielhaften Fabric-Header für ein Datenpaket. Der Fabric-Header kann ein flow_id-Feld enthalten, das den Flusskanal identifizieren kann, und ein „data_flow“-Feld, das den Verlauf des gesamten Flusses angeben kann.
  • Wenn ein Datenpaket an sein Ziel zugestellt wird, kann mindestens ein ACK erzeugt werden. zeigt ein beispielhaftes ACK-Paketformat. Ein ACK-Paket kann ein „flow_id“-Feld, ein „ack_flow“-Feld, ein „ACK type“-Feld und ein CRC-Feld (cyclic redundancy check) enthalten. Das „flow_id“-Feld kann den Fluss angeben, zu dem dieses ACK-Paket gehört. Das „ack_flow“-Feld kann dem „data_flow“-Wert entsprechen, der zu dem Datenpaket gehört, das dieses ACK-Paket bestätigt. Es sei daran erinnert, dass jeder Switch einen flow_ extent-Wert beibehalten kann, der die Menge der übertragenen, aber nicht quittierten Daten angibt. Der Wert von flow_extent kann wie folgt abgeleitet werden flow extent = data flow - ack_ flow, wobei der data_ flow-Wert dem zuletzt übertragenen Datenpaket entnommen wird.
  • Das Feld ACK-Typ kann verschiedene Arten von ACKs angeben. Wie bereits erwähnt, kann im Normalbetrieb, wenn ein Datenpaket an den Ziel-Edge-Port geliefert wird, ein normales ACK-Paket erzeugt und an die Quelle zurückgeschickt werden. Dementsprechend kann das ACK-Typ-Feld im ACK-Paket ein normales ACK anzeigen. Wenn eine Überlastung auftritt, kann das ACK-Typ-Feld verwendet werden, um verschiedene Arten und Schweregrade von Überlastungen anzuzeigen, z. B. eine neue Überlastung eines Flusses, eine anhaltende Überlastung eines Flusses, eine schwere Überlastung am Ausgangs-Edge-Port oder eine lokale Überlastung in der Mitte der Fabric, die eine Umleitung des Flusses erfordert, um die Last über die gesamte Fabric auszugleichen. Darüber hinaus kann unter besonderen Umständen, wie z. B. bei einer stark überlasteten Fabric-Verbindung, verworfenen Paketen oder Verbindungsfehlern, ein ACK auch von einem Zwischen-Switch erzeugt werden, der nicht das endgültige Ziel ist, und das ACK-Typ-Feld kann verwendet werden, um Upstream-Switches über verschiedene Arten von Netzwerkbedingungen zu informieren. Auch andere zusätzliche Felder können in ein ACK-Paket aufgenommen werden.
  • zeigt die Beziehung zwischen verschiedenen Variablen, die zur Ableitung und Aufrechterhaltung von Zustandsinformationen eines Flusses verwendet werden. In diesem Beispiel kann eine Vermittlungsstelle die Variable „total_extent“ verwenden, um die Gesamtmenge der unbestätigten übertragenen Daten und der Daten, die sich derzeit in der Warteschlange der Vermittlungsstelle befinden, zu verfolgen. Der Wert von „total extent“ kann der Summe von „flow_ extent“, d. h. der Menge der übertragenen und unbestätigten Daten, und „queue_extent“, d. h. der Menge der in der Eingangswarteschlange für den entsprechenden Fluss gespeicherten Daten, entsprechen. Die Variable „ack_flow“ kann die Datenposition angeben, die dem letzten ACK für diesen Datenfluss entspricht. Die Variable „data_flow“ kann die Position des nächsten zu übertragenden Datenpakets angeben, die ebenfalls dem Datenpaket entspricht, das am Anfang der Eingangswarteschlange gespeichert ist. Die Variable „next_data_flow“ kann die Position des nächsten Datenpakets angeben, das der Switch vom Upstream-Switch erwarten kann. Es ist zu beachten, dass queue extent = next data flow - data flow, und flow_extent = data_ flow - ack_flow.
  • In einigen Beispielen können Flow-Channel-Tabellen verwendet werden, um Flow-Channels in einer Fabric zu erleichtern. Flusskanaltabellen sind Datenstrukturen, die die Weiterleitungs- und Statusinformationen für einen bestimmten Fluss am Anschluss eines Switches speichern. zeigt ein Beispiel dafür, wie Flow-Channel-Tabellen verwendet werden können, um Statusinformationen zu speichern, die mit mehreren Flows verbunden sind. Diese Zustandsinformationen können für jeden Fluss spezifisch sein und effizient in einer Tabelle gespeichert werden. Angenommen, ein Quellhost 402 sendet Datenpakete über eine Fabric an einen Zielhost 404. Der Datenpfad, den die Datenpakete durchlaufen, kann einen Eingangs-Edge-Switch 406, Zwischen-Switches 408 und 430 sowie einen Ausgangs-Edge-Switch 432 umfassen.
  • Wenn ein Paket auf einer Eingangs-Edge-Verbindung 403 des Switches 406 ankommt, kann der Header des Pakets von einem Adressübersetzungslogikblock 410 analysiert werden. Der Adressübersetzungslogikblock 410 kann die Fabric-Zieladresse des Ausgangsschalters (in diesem Fall Schalter 432) auf der Grundlage der Ethernet-, IP- oder HPC-Kopfinformationen des Pakets bestimmen. Beachten Sie, dass Header-Informationen, die mit anderen Protokollen oder einer Kombination verschiedener Protokolle verbunden sind, auch vom Adressübersetzungslogikblock 410 verwendet werden können. Die vom Adressübersetzungslogikblock 410 ermittelte Fabric-Zieladresse kann dann verwendet werden, um eine Suche in einer Edge-Flow-Channel-Tabelle (EFCT) 412 durchzuführen. Die EFCT 412 kann eine Nachschlageoperation für das Paket durchführen, wobei die Fabric-Zieladresse des Pakets und optional zusätzliche Werte verwendet werden, die aus dem Header des Pakets extrahiert werden, was als Übereinstimmungsmuster bezeichnet werden kann. EFCT 412 kann das Übereinstimmungsmuster des Pakets mit den gespeicherten Übereinstimmungsmustern aller vorhandenen zugewiesenen Flüsse vergleichen. Wird eine Übereinstimmung gefunden, dann ist dieses Paket Teil eines bestehenden Flusses und die zuvor zugewiesene Fluss-ID kann für dieses Paket zurückgegeben werden. Wird keine Übereinstimmung gefunden, kann für dieses Paket eine neue Fluss-ID zugewiesen und ein Übereinstimmungsmuster zu EFCT 412 hinzugefügt werden. Mit anderen Worten: EFCT 412 kann verwendet werden, um festzustellen, ob für das eingehende Paket bereits ein Flusskanal existiert oder ob ein neuer Flusskanal zugewiesen werden muss. Neben der Fabric-Zieladresse können auch andere Paketkopfinformationen wie Verkehrsklasse, TCP- oder UDP-Portnummer und Prozess- oder Thread-ID verwendet werden, um Flow-IDs zuzuordnen oder zuzuweisen.
  • Die von der EFCT 412 erhaltene Fluss-ID kann dann als Index für die Zuordnung zu einem Eintrag in einer Eingangsflusskanaltabelle (IFCT) 414 verwendet werden. Jeder Eintrag in der IFCT 414 kann durch eine Fluss-ID indiziert werden und Zustandsinformationen für den entsprechenden Fluss speichern. Ein Eintrag in der IFCT 414 kann die Werte von next_data_flow, data_ flow und ack_flow (siehe ) speichern, die mit einem Datenfluss verbunden sind. Darüber hinaus kann ein IFCT-Eintrag andere Parameter für die Staukontrolle und das dynamische Routing für einen Datenfluss speichern.
  • Die Fluss-ID kann auch zur Identifizierung oder Zuweisung einer flussspezifischen Eingangswarteschlange verwendet werden, in der das eingehende Paket vorübergehend gespeichert werden kann. Die Zustandsinformationen für eine bestimmte Warteschlange sowie Parameter für die Überwachung und Steuerung der Warteschlange (z. B. Schwellenwert für die Erkennung einer Überlastung) können in dem entsprechenden Eintrag in IFCT 414 gespeichert werden. Ein Logikblock für die Verwaltung der Eingangswarteschlange kann auf der Grundlage von Flusssteuerungsparametern, die in dem Eintrag in IFCT 414 gespeichert sind, bestimmen, wann ein Paket aus der Eingangswarteschlange entfernt und an einen Datenkreuzschienenschalter 413 gesendet werden kann.
  • Wenn ein Paket aus der Eingangswarteschlange entfernt und über den Crossbar-Switch 413 an einen Ausgangsport gesendet wird, wird das Paket mit der Nummer des Eingangsports gesendet, an dem es am Switch 406 angekommen ist. Wenn das Paket den Sendepuffer eines Ausgangsports erreicht, kann der Kopf des Pakets auf der Grundlage der Fluss-ID und der Eingangsportnummer des Pakets mit einer neuen Fluss-ID aktualisiert werden, die von der nächsten Vermittlungsstelle (d. h. Vermittlungsstelle 408) für denselben Fluss verwendet wird. Dies liegt daran, dass jede Verbindung in jeder Richtung über eine eigene Gruppe von Flusskanälen verfügen kann, die durch ihre jeweiligen Fluss-IDs identifiziert werden. Die Zuordnung von der eingehenden Flow-ID zur ausgehenden Flow-ID, die auf der nächsten Verbindung verwendet wird, kann durch Nachschlagen in einer Output Flow Channel Table (OFCT) 416 erfolgen. Die OFCT 416 kann eine Suche anhand eines Übereinstimmungsmusters durchführen, das eine Kombination aus der lokalen Eingangsanschlussnummer, die der Verbindung 403 entspricht, und der Fluss-ID des Pakets ist, die von der EFCT 412 erzeugt wird. Wird eine Übereinstimmung gefunden, so wurde der Fluss bereits definiert, und die Fluss-ID des Pakets wird mit dem Wert aktualisiert, der dem Übereinstimmungsmuster entspricht (diese neue ausgehende Fluss-ID wird vom nachgeschalteten Next-Hop-Switch 408 verwendet). Wird keine Übereinstimmung gefunden, kann ein neuer Datenflusskanal mit einer neuen, ausgehenden Datenfluss-ID zugewiesen werden, die auf die Eingangsanschlussnummer und die vorherige, eingehende Datenfluss-ID abgebildet werden kann. Ein Eintrag mit der Kennung des ausgehenden Verkehrsflusses, der Nummer des Eingangsanschlusses und der Kennung des eingehenden Verkehrsflusses kann im OFCT 416 gespeichert werden.
  • In dem Fall, dass das Paket das erste Paket im Fluss ist, würde ein Nachschlagen in OFCT 416 keine Zuordnung ergeben. Im Gegenzug kann OFCT 416 dem Paket einen Flusskanal mit einer Fluss-ID zuweisen, der vom Eingangsanschluss und IFCT 418 am Switch 408 verwendet wird. Dieser neue Flusskanal, der durch seine Fluss-ID identifiziert wird, kann dem Paketkopf für die Übertragung auf der Verbindung 417 hinzugefügt werden und kann von der IFCT 418 des Verbindungspartners (d. h. des Switches 408) verwendet werden, um auf die Überlastungsinformationen des Flusskanals zuzugreifen. Wie zuvor kann OFCT 424 einen neuen Flusskanal generieren, wenn keine Übereinstimmung gefunden wird, indem es das Übereinstimmungsmuster seiner unmittelbaren Upstream-Eingangsportnummer und der mit der Verbindung 417 verbundenen Fluss-ID verwendet. OFCT 424 kann dann einen neuen Flusskanal zuweisen, der durch eine neue Fluss-ID identifiziert wird. Beachten Sie, dass OFCT 416 auch als Weiterleitungstabelle für ACKs dieses Flusses in Upstream-Richtung fungieren kann. Nachdem das ACK-Paket vom Switch 408 an den Switch 406 weitergeleitet wurde, kann es mit der dem Edge Link 403 zugeordneten Flow-ID aktualisiert und an den entsprechenden Eingangsport des Switches 406 weitergeleitet werden, wie durch den entsprechenden Eintrag in OFCT 416 angegeben. Die ACK-Pakete können von einem ACK-Crossbar-Switch 415 in Upstream-Richtung an den Eingangsport weitergeleitet werden.
  • Wenn das Paket dann bei der Vermittlungsstelle 408 ankommt, kann seine Fluss-ID verwendet werden, um eine zu verwendende Eingangswarteschlange zu identifizieren und einen Eintrag in IFCT 418 zu bestimmen. Wenn die Fluss-ID des Pakets nicht zuvor von der Vermittlungsstelle 408 zugewiesen wurde, kann eine neue Eingangswarteschlange bereitgestellt und ein neuer Eintrag in IFCT 418 erstellt werden. Von diesem Punkt an kann ein ähnlicher Prozess durchgeführt werden, um das Paket über die Vermittlungsstellen 408 und 430 weiterzuleiten, bis das Paket die Ausgangsvermittlung 432 erreicht.
  • Wenn das Paket den Switch 432 erreicht, nachdem es von einem Daten-Crossbar-Switch 423 weitergeleitet wurde, kann ein ACK-Generator-Logikblock 420 ein ACK-Paket auf der Grundlage der Flow-ID des Pakets und der Eingangsportnummer erzeugen. Dieses ACK-Paket kann dann durch einen ACK-Crossbar-Switch 422 in die Upstream-Richtung weitergeleitet werden. Gleichzeitig kann ein IFCT 421 auf der Grundlage des ACK-Pakets die Zustandsinformationen für den Fluss in dem entsprechenden Tabelleneintrag aktualisieren. Wenn das ACK-Paket den Switch 430 erreicht, kann ein OFCT 419 nachgeschlagen werden, um die Upstream-Flow-ID und den Upstream-Eingangsport zu bestimmen, an den das ACK-Paket weitergeleitet werden soll. Die Fluss-ID des ACK-Pakets kann dann aktualisiert und an den entsprechenden Eingangsanschluss in Upstream-Richtung weitergeleitet werden. Während das ACK-Paket den Datenpfad stromaufwärts auf ähnliche Weise durchläuft, kann der IFCT an jedem Switch seinen Tabelleneintrag für den Fluss auf der Grundlage des ACK aktualisieren.
  • Beachten Sie, dass die Variable flow_extent ein wichtiger Parameter sein kann, da sie die Gesamtmenge der nachgelagerten Paketdaten für einen Fluss darstellt. Ein Flow-Kanal gilt als frei, um einem anderen Flow neu zugewiesen zu werden, wenn der flow_ extent eines Eintrags Null ist. Im Allgemeinen kann die Eingangslogik beim Empfang eines neuen Pakets eine Anforderung zum Senden von Daten an einen Ausgangsanschluss stellen. Der ausgewählte Ausgangsport kann eine Funktion des im IFCT gespeicherten flow_ extent sein. Wenn flow_ extent gleich Null ist, gibt es keine Pakete, die im Fluss zum Ziel-Egress-Edge-Port nachgelagert sind. Infolgedessen kann der Switch eine lastbasierte adaptive Routenauswahl verwenden, um einen beliebigen gültigen Pfad zu wählen, der zum Ziel führt. In einem Netz mit mehreren Pfaden kann das dynamische adaptive Routing durchgeführt werden, ohne dass die Pakete neu geordnet werden müssen. Ist flow_ extent ungleich Null und ist eine ordnungsgemäße Zustellung erforderlich, kann das Paket denselben Weg benutzen, den die vorherigen Pakete genommen haben. Der IFCT kann ein Feld haben, das die Nummer eines früheren Ausgangsportes speichert, die geladen wird, wenn eine Paketanforderung an einen Ausgangsport gestellt wird, und die verwendet werden kann, um eine Verbindung mit dem zuvor verwendeten Ausgangsport sicherzustellen.
  • Wie bereits erwähnt, können die Flow Channels eine Match-Funktion verwenden, um Pakete zu erkennen, die zu einem bestehenden Flow gehören. Empfangene Ethernet-Rahmen oder andere Arten von Paketen können in Echtzeit analysiert werden, wenn der Rahmen oder das Paket an einem Eingangs-Edge-Port empfangen wird, und einige Felder des Paketkopfes können für eine Suche in einem CAM oder Ternary Content Addressable Memory (TCAM) verwendet werden. Wenn es eine Übereinstimmung gibt, kann die Übereinstimmungsadresse die Fluss-ID werden, die zur Auswahl eines Flusskanals verwendet wird. Wenn keine Übereinstimmung vorliegt, kann die Switch-Hardware das Muster, das nicht übereinstimmt, direkt in eine freie Zeile des CAM laden, was ohne zusätzliche Verzögerung erfolgen kann. Infolgedessen kann jedes nachfolgende Paket an diesen neuen Eintrag angepasst werden, ohne dass ein erheblicher Pufferbedarf entsteht. Der gewählte freie Eintrag wird die neue Fluss-ID für den neuen Flusskanaleintrag. Beachten Sie, dass für das Laden des neuen Eintrags kein externer Softwareeingriff erforderlich ist. Der Prozess kann autonom von der Switch-Hardware durchgeführt werden.
  • Die Aufhebung der Zuweisung von Fluss-IDs und entsprechenden CAM-Match-Linien kann auch automatisch von der Hardware vorgenommen werden, wenn das letzte ACK für den Fluss zurückgegeben wird. Die Aufhebung der Zuweisung kann in Bezug auf potenziell passende neue Pakete in der Hardware erfolgen, ohne dass externe Software eingreift.
  • In einigen Beispielen kann der Eingangs-Edge-Switch 406 einen Fine-Grain-Flusssteuerungslogikblock 434 enthalten, der mit einem Netzwerkschnittstellen-Controller (NIC) 401 auf dem Host 402 kommunizieren kann, um die Flusssteuerung auf einer Einzelflussbasis anzuwenden. Weitere Einzelheiten zur Flusssteuerung nach dem Feinkornprinzip werden weiter unten in Verbindung mit der Beschreibung des Überlastungsmanagements erläutert.
  • zeigt ein Beispiel für einen EFCT. In diesem Beispiel kann ein EFCT ein data_flow-Feld 454, ein ACK_flow-Feld 456 und optional zusätzliche Felder enthalten. Der EFCT kann mit einem Eingangsanschluss verbunden sein, und die Einträge im EFCT können durch flow_ID-Werte, wie flow_ID 452, indiziert werden. In einer Ausführungsform kann sich das Abgleichsmusterfeld im Abgleichsfunktionslogikblock befinden, der ein CAM oder TCAM enthalten kann. Der Abgleichsfunktionslogikblock kann das Abgleichsmuster verwenden, um den flow_ID-Wert zu erzeugen, der wiederum als Index für den entsprechenden EFCT-Eintrag verwendet werden kann. Aus der Sicht dieser EFCT kann der flow_ extent (d. h. data flow - ack_flow) alle unbestätigten Daten nach dieser Tabelle umfassen, was die lokale flow_queue plus den flow_extent-Wert der entsprechenden IFCT einschließen kann.
  • zeigt ein Beispiel für einen IFCT. In diesem Beispiel kann ein IFCT einem Eingangsanschluss zugeordnet sein und ein follow_port-Feld 466, ein next_data_flow-Feld 468, ein data_ flow-Feld 470, ein ACK_ flow-Feld 472, ein epcongestion-Feld 474, ein upstream metering (UM)-Flag-Feld 477, ein downstream metering (DM)-Flag-Feld 478 und optional zusätzliche Felder enthalten. Der flow_ID-Wert eines eingehenden Pakets, z. B. flow_ID 464, kann als Index verwendet werden, um die Nummer des Ausgangsportes, die durch das follow_port-Feld 466 angegeben wird, und die mit dem entsprechenden Fluss verbundenen Zustandsinformationen nachzuschlagen. Staukontrollinformationen im Zusammenhang mit Endpunktstau (z. B. ep_congestion-Feld 474) und (hop-by-hop credit-based flow control) (z. B. UM-Flag-Feld 477 und DM-Feld 478), die später in diesem Dokument ausführlicher beschrieben werden, können ebenfalls im IFCT gespeichert werden. Die IFCT kann ferner Informationen über die dynamische Leitweglenkung in Verbindung mit verschiedenen Strömen speichern.
  • zeigt ein Beispiel für einen OFCT. In diesem Beispiel kann ein OFCT einem Ausgangsport zugeordnet sein und ein input_port-Feld 482, ein input_port_flow_ID-Feld 484 (das der bestehenden flow_ID eines Pakets bei dessen Ankunft an einem Eingangsport entspricht), ein data_flow-Feld 486, ein ACK_flow-Feld 488 und optional zusätzliche Felder enthalten. Das data_ flow-Feld 486 und das ACK_ flow-Feld 488 können verwendet werden, um den Wert von flow_ extent ab diesem OFCT zu bestimmen. Die Kombination aus input_port-Feld 482 und input_port_flow_ID-Feld 484 (das auch als „incoming tlow_ID“ bezeichnet werden kann) kann verwendet werden, um die outgoing flow_ID eines Pakets zu bestimmen oder zuzuweisen, das für die Übertragung auf der diesem OFCT entsprechenden abgehenden Verbindung bereit ist. In einer Ausführungsform können die abgehenden flow_ ID-Werte, wie flow ID 486, als Index zum Nachschlagen von Einträgen in der OFCT verwendet werden.
  • Im Allgemeinen ist es wünschenswert, eine logische Partitionierung des Netzes zu implementieren, so dass verschiedene Endhosts und Anwendungen getrennt werden können. Der VLAN-Mechanismus im Ethernet ist ein solches Beispiel. Die Implementierung eines logischen Partitionierungsschemas basiert auf der Fähigkeit, den Verkehr als zu einer bestimmten Partition gehörig zu identifizieren und zu verhindern, dass der Verkehr fälschlicherweise an ein Zielsegment geliefert wird, das nicht zu dieser Partition gehört. Um dies zu erreichen, kann der Switch im vorliegenden System in einer Ausführungsform ein eindeutiges Header-Feld namens Virtual Network Identifier (VNI) verwenden, das in jedem Frame im Fabric-Format L2-Header enthalten ist. Der VNI kann zum Beispiel 16 Bits lang sein. Die Definition der Bits im VNI-Feld kann je nach ausgedrücktem Protokoll unterschiedlich sein.
  • Für Datenverkehr, der benutzerdefinierte Protokolle wie Portale oder das Anfrage/Antwort-Protokoll der Fabric nutzt, kann das 16-Bit-VNI-Feld beispielsweise in ein 8-Bit-Partitionsfeld und ein 8-Bit-JobID- oder Anwendungs-ID-Feld unterteilt werden. Das Partitionsfeld kann verwendet werden, um einen physischen Port als Mitglied einer bestimmten Partition zu identifizieren. Das JobID-Feld kann ein Schutzkennzeichen enthalten, das HPC-Anwendungen Zugriff auf ein bestimmtes Speichersegment gewährt. In einer Ausführungsform kann die JobID von einem Betriebssystemdienst bereitgestellt und von der NIC an der Quelle sicher hinzugefügt werden. Am Zielort wird die JobID überprüft, bevor auf das Speichersegment zugegriffen wird, das zuvor als zu einem bestimmten Auftrag oder Dienst gehörig identifiziert worden sein muss.
  • Für den Ethernet-Verkehr kann das Partitionierungsschema des Netzes auf der VLAN-Architektur basieren, wie sie in der IEEE 802. I Q-Spezifikation beschrieben ist, obwohl es Unterschiede in der Art und Weise geben kann, wie die Header-Felder in Bezug auf die Partitionierung definiert und eingesetzt werden.
  • Alle Rahmen, die das Netz über die Switch-Fabric durchqueren, können einen Fabric-Header enthalten. Dieser Header kann das VNI-Feld enthalten. Die Zugehörigkeit zu einer bestimmten Partition kann von einem Partitionsmanager zugewiesen werden. Je nach dem im Netz implementierten Vertrauensmodell gibt es zwei Mechanismen zum Einfügen des VNI-Werts. In einer Ausführungsform ist ein vertrauenswürdiges Betriebssystem ein Betriebssystem, dem die Zuweisung der Mitgliedschaft in einer Partition zugetraut werden kann; ein nicht vertrauenswürdiges Betriebssystem ist ein Betriebssystem, dem dies nicht zugetraut werden kann. Im letzteren Fall kann der VNI-Wert von einem vertrauenswürdigen Akteur zugewiesen werden.
  • In Fällen, in denen das Betriebssystem des Endknotens nicht vertrauenswürdig ist, kann der Switch den VNI-Wert am Ingress-Edge-Port zuweisen und dabei jedes VLAN-Feld im vorhandenen Ethernet-L2-Header ignorieren. In diesem Modus kann die minimale Granularität die Zuweisung des Edge-Ports zu einer bestimmten Partition sein. In einer Ausführungsform ist die Aufteilung des Verkehrs von diesem Port in verschiedene Partitionen nicht zulässig.
  • In Fällen, in denen das Betriebssystem des Endknotens vertrauenswürdig ist, kann der Switch am Ingress-Edge-Port das VLAN-Feld des Frames verwenden, um den VNI-Wert zuzuweisen. Dies bedeutet, dass Ressourcen innerhalb des Endknotens verschiedenen Partitionen zugewiesen werden können, selbst wenn diese Ressourcen denselben Anschluss nutzen. Dies hat zur Folge, dass man sich darauf verlassen kann, dass das Betriebssystem das richtige VLAN für eine bestimmte Art von Datenverkehr verwendet. In diesem Fall stellt der Switch sicher, dass nur die autorisierte Gruppe von VLANs von jedem Port in die Fabric zugelassen wird.
  • In beiden Fällen kann die Partitionserzwingung vom Switch durchgeführt werden, wenn ein Paket die Fabric über einen Edge-Port verlässt und entweder für einen NIC-Port oder ein anderes Ethernet-Gerät bestimmt ist.
  • Bei einer NIC, die den VNI-Mechanismus kennt, kann die NIC das VNI-Feld direkt in den Paketkopf einfügen, wenn das Paket in die Fabric injiziert wird. Dadurch kann die Partitionierung bis zum Endknoten erweitert werden.
  • Die unteren Bits der VNI können auch dazu verwendet werden, die Trennung der Warteschlangen von Anwendungen beim Eintritt in die Fabric und beim Austritt aus ihr zu steuern. Auf diese Weise können verschiedene Anwendungen unabhängig von den von ihnen verursachten Verkehrsmustern beim Zugriff auf die Fabric auf faire Weise getrennt werden. Wenn diese Trennung erwünscht ist, kann das System die Zuweisung von VNI-Nummern einschränken, und es kann eine einzige globale VNI-Nummernzuweisungsrichtlinie verwendet werden.
  • Exemplarische Schalterarchitektur
  • In einer Ausführungsform kann ein Switch-Chip, der die vorgenannten Merkmale unterstützt, 64 Netzwerkanschlüsse bereitstellen, von denen jeder mit 100 oder 200 Gbit/s arbeiten kann, mit einem Gesamtdurchsatz von 12,8 Tbit/s. Andere Anzahlen von Anschlüssen und Datenraten sind ebenfalls möglich. Jeder Netzwerk-Edge-Port kann verschiedene Arten von Protokollen unterstützen, z. B. IEEE 802.3 Ethernet, optimierte IP-basierte Protokolle und HPC-Portal-Protokoll. Ethernet-Frames können auf der Grundlage ihrer Layer-2-Adressen überbrückt oder auf der Grundlage ihrer Layer-3-Adressen (IPv4/IPv6) geroutet werden. Optimized-IP-Frames haben nur einen Layer-3-Header (IPv4/IPv6) und werden daher in der Regel auf der Grundlage von Layer-3-Adressen geroutet. Die erweiterten Portals-Format-Frames verwenden in der Regel spezielle NICs und können direkt auf das erweiterte Fabric-Format des Switches abgebildet werden.
  • Wenn ein Switch-Chip mit einem anderen Switch-Chip verbunden ist, können sie über das erweiterte Fabric-Frame-Format kommunizieren, das zusätzliche Steuer- und Statusfelder zur Unterstützung einer Multi-Chip-Fabric bereitstellt. Eines der Unterscheidungsmerkmale der gegenwärtigen Switch-Architektur im Vergleich zu Ethernet-Switches oder alternativen Technologien wie InfiniBand besteht darin, dass der gegenwärtige Switch eine Flow-Channel-basierte Staukontrolle bieten kann. Das erweiterte Fabric-Frame-Format, das zwischen den Switch-Chips arbeitet, kann eine Vorwärts- und Rückwärtspfad-Signalisierung des Zustands von Flüssen ermöglichen.
  • In einer Ausführungsform kann der Switch-Chip auf der Grundlage einer Crossbar-Architektur mit kombinierter virtueller Ausgangswarteschlange und Crossbar-Warteschlange implementiert werden. Die Pufferung und Weiterleitung von Datenpaketen kann mit einem kreditbasierten Anforderungs- und Gewährungsmechanismus erfolgen.
  • zeigt eine beispielhafte Schalterarchitektur. In einer Ausführungsform kann der Switch-Chip einen Empfänger (RX)-Block 502 und einen Sender (TX)-Block 504 umfassen. Wenn der Datenverkehr vom RX-Block 502 empfangen wird und der Switch-Chip als Edge-Switch konfiguriert ist, können die Datenpakete an einen Ethernet-Look-Up-Block (ELU) 506 gesendet werden. Der ELU-Block 506 kann eine Adressübersetzung (Lookup) von einer externen MAC- oder IP-Adresse (hauptsächlich, aber es können auch andere Header-Felder verwendet werden) in die interne Fabric-Adresse (FA) vornehmen. ELU-Block 506 kann auch eine Zuordnung von der eigenen Verkehrsklassenkennung eines Pakets (z. B. Ethernet-Verkehrsklasse) zu einer Fabric-Verkehrsklassenkennung vornehmen, die durch ein Fabric-Tag (FTAG) in einem Fabric-Header identifiziert werden kann.
  • In einer Ausführungsform können Pakete im IEEE 802.3- und Optimized-IP-Format durch den ELU-Block 506 geleitet werden. Der ELU-Block 506 kann geeignete Kopfzeilen zur Verwendung im Suchprozess extrahieren und ein Suchergebnis an einen Ethernet-Eingangs-Warteschlangen (EIQ)-Block 508 zurückgeben, der Kopfzeilen für die Flusskanalzuweisung im EFCT-Block 510 in eine Warteschlange stellt. Der EIQ-Block 508 kann auch die Adressen von Paketen, die im Eingangspuffer (IBUF) Block 512 gespeichert sind, mit ihrem übersetzten Header verknüpfen. Bei IEEE 802.3- und optimierten IP-Paketen kann der ELU-Block 506 einen Lookup durchführen, um Felder für die Weiterleitung der Pakete innerhalb der Fabric zu erstellen.
  • Für einen Edge-Port am Eingang kann der EIQ-Block 508 die Paketköpfe in eine Warteschlange stellen und darauf warten, dass der EFCT-Block 510 einen Flusskanal zuweist. Wenn dem EFCT-Block 510 die Flusskanäle ausgehen, kann sich die FIFO-Warteschlange im EIQ-Block 508 füllen, und bei Überschreiten konfigurierbarer Schwellenwerte können Pausenpakete erzeugt werden. Für Pakete, die von einem Fabric-Port empfangen werden, ist keine Zuweisung eines Flusskanals erforderlich, und daher werden ihre Kopfzeilen nicht in die Warteschlange des EIQ-Blocks 508 gestellt.
  • Ein mit dem IBUF-Block 512 gekoppelter Input-Header-Block (IHDR) 514 kann Änderungen an einem empfangenen Paket vornehmen und die Fabric-Header-Felder eines Pakets aktualisieren. Der IHDR-Block 514 kann Paketdaten, Eingangszeitstempel und Grant-Header (die Änderungsdaten und Anweisungen enthalten können) vom IBUF-Block 512 empfangen. Solche Modifikationen können das Entfernen verschiedener Ethernet-Schicht-2-Kopffelder und das Hinzufügen eines Fabric-Headers umfassen. Der IHDR-Block 514 kann Pakete „on the fly“ modifizieren, wenn sie aus dem IBUF-Block 512 ausgelesen und an die Datenkreuzschiene 516 gesendet werden.
  • Der IBUF-Block 512 kann unveränderte Pakete speichern, wenn sie vom Switch-Chip empfangen werden, und kann verschiedene Formate unterstützen. Die gespeicherte Paketadresse, bei der es sich um einen Zeiger mit der Bezeichnung sop_ptr handelt, und der Index des Pakets können vom IBUF-Block 512 an den EIQ-Block 508 gesendet werden, der das Paket mit dem Header-Lookup-Ergebnis des ELU-Blocks 506 abgleichen kann.
  • Zu einem bestimmten Zeitpunkt wird jedes im IBUF-Block 512 gespeicherte Paket entweder auf der Grundlage einer über eine Grant-Kreuzschiene 518 und einen Input Queues (INQ)-Block 520 (siehe unten) gesendeten Genehmigung über die Daten-Kreuzschiene 516 an einen Zielanschluss gesendet oder verworfen. Beide Vorgänge können auf der Grundlage eines Verweises auf sop_ptr durchgeführt werden. Ein Grant kann auch andere Felder aus ELU-Block 506 und EFCT 510 enthalten, die mit dem Paket an IHDR-Block 514 gesendet werden können. Der IHDR-Block 514 kann seinerseits die Steuerinformationen aus dem Grant-Header verwenden, um geeignete Paketänderungen vorzunehmen, bevor das Paket über die Datenkreuzschiene 516 an den Zielport weitergeleitet wird. Wenn der Puffer im IBUF-Block 512 voll ist, können konfigurierbare Schwellenwerte überschritten werden, die verschiedene Flusskontroll- und Überlastungsmanagementmechanismen auslösen können.
  • EFCT 510 kann Paketen abhängig von der FTAG, der Zieladresse und der VNI Flusskanäle zuweisen. Das Übereinstimmungsmuster kann die Trennung zwischen Flüssen mit separaten Ordnungs- und Prioritätseinschränkungen zwischen denselben Quell- und Ziel-Fabric-Ports ermöglichen. Typischerweise können verschiedene Kerne auf einem Knoten mit unterschiedlichen VNI betrieben werden, und diese Trennung der Flüsse ermöglicht die Entkopplung der verschiedenen Kerne.
  • Wenn der Übereinstimmungswert derzeit eindeutig ist, kann ein neuer Flusskanal zugewiesen werden. Wenn der Übereinstimmungswert mit dem Übereinstimmungswert eines bereits zugewiesenen Flusskanals identisch ist, wird das Paket dem entsprechenden bestehenden Fluss zugewiesen. Die Größe des Pakets kann verwendet werden, um den data_flow-Wert des Flusses zu erhöhen. In einer Ausführungsform kann für einen Edge Port ein OFCT 522 als EFCT verwendet werden. Die Bestätigungen, die von nachgelagerten Flusskanaltabellen zurückgegeben werden, werden verwendet, um den ack_ flow-Wert eines Flusses zu erhöhen. Wenn dieser Wert mit dem data flow-Wert übereinstimmt, kann der Flusskanal automatisch freigegeben und sein Übereinstimmungsmuster ungültig gemacht werden.
  • Der INQ-Block 520 kann die Header-Anforderungen vom EIQ-Block 508 und bei einem Ingress Edge Port auch vom EFCT 510 empfangen. Der INQ-Block 520 kann die Suchergebnis-Kopfzeile in seinen Kopfzeilen-RAMs speichern. Der Zeiger auf jeden Header kann in einer von mehreren Warteschlangen gespeichert werden, die auf dem entsprechenden Flusskanal des Headers basieren. An den Edge-Ports können die Paketköpfe für die Weiterleitung in einer Art und Weise arbitriert werden, die durch Anwendungsgruppen (APPGs) fair ist, die dazu verwendet werden können, Anwendungen in verschiedene Verkehrsklassen einzuteilen. An Fabric-Ports können Header auf der Grundlage ihrer Flusskanäle arbitriert werden. Wenn ein Header für das Routing in Frage kommt, kann er an einen Fabric Routing Function (FRF)-Block 524 und anschließend auch an einen IFCT 526 weitergeleitet werden.
  • Der FRF-Block 524 kann die Routing-Funktion auf der Grundlage der Netztopologie ausführen und den Ausgangsport (oder die Ports für Multicast) auswählen, an den ein Paket weitergeleitet werden soll. Dieses Routing-Ergebnis kann an IFCT 526 weitergeleitet werden, wo es mit dem Rest des Headers kombiniert wird, und IFCT 526 kann entweder das Ergebnis von FRF-Block 524 verwenden oder sich dafür entscheiden, die vorherige Route für einen bestimmten Fluss zu verwenden, wenn die Einhaltung der Paketreihenfolge wichtig ist. IFCT 526 kann dann das Weiterleitungsergebnis (d. h. die Ausgangsanschlussinformationen für ein bestimmtes Paket) als neue Anforderung an den INQ-Block 520 zurückgeben. Diese Anforderung kann dann verwendet werden, um das Paket so zu planen, dass es die Datenkreuzschiene 516 in Richtung des gewünschten Ausgangsports durchläuft.
  • Die Anforderung kann dann in eine Anforderungs-Warteschlange (oder - Warteschlangen) im INQ-Block 520 auf der Grundlage einer Formgebungsfunktion, die dem Flusskanal entspricht, einer Kennung für einen virtuellen Kanal (VC) und dem Ausgangsanschluss eingeordnet werden. (Man beachte, dass VCs verwendet werden können, um eine physische Verbindung in Gruppen virtueller Verbindungen zu unterteilen, um Deadlocks zu vermeiden). Nach der Arbitrierung kann die Anforderung über eine Anforderungskreuzschiene 528 an einen Alterswarteschlangenblock (AGEQ) 530 gesendet werden. Später kann über die Grant-Kreuzschiene 518 ein entsprechender Grant zurückgegeben werden. Wenn die Gewährung zurückgegeben wird, kann der INQ-Block 520 den entsprechenden Header abrufen und ihn an den IBUF-Block 512 zurücksenden, wo der Header wieder mit seiner Nutzlast verbunden wird, bevor er an den IHDR-Block 514 und anschließend an die Datenkreuzschiene 516 weitergeleitet wird.
  • Wie bereits beschrieben, kann IFCT 526 die Menge der in den lokalen Warteschlangen für den Datenfluss gepufferten Daten messen. Es kann auch die Menge der unbestätigten Daten messen, die dem Datenstrom nachgelagert sind. IFCT 526 kann auch zurückgegebene Quittungscodewerte in seinen Tabellen speichern und diese flussspezifischen Zustandsinformationen zusammen mit den durch den FTAG-Wert eines Pakets indizierten Konfigurationsinformationen verwenden, um zu bestimmen, ob der Kopf der empfangenen Pakete weitergeleitet, verworfen oder länger gewartet werden soll. Der Fall „warten lassen“ kann realisiert werden, indem der Header nicht aus der Warteschlange des Datenflusses entfernt wird. Der Header kann schließlich aus der Warteschlange entfernt werden, und die Entscheidung über Weiterleitung, Verwerfen oder Wartenlassen kann erneut getroffen werden. In einer Ausführungsform kann IFCT 516 eine „Discard“-Schnittstelle zum IBUF-Block 512 haben, die es ermöglicht, den sop_ptr-Wert an den IBUF-Block 512 zu übergeben, wenn ein Paket verworfen werden soll. Daraufhin kann der Kopf des Pakets verworfen werden, bevor es in eine Anforderungswarteschlange aufgenommen wird. IFCT 516 kann außerdem die entsprechenden Statistiken für verworfene Pakete inkrementieren.
  • Der FRF-Block 524 kann für jedes empfangene Paket Routing-Anforderungen vom INQ-Block 520 empfangen und für jede Routing-Anforderung eine Routing-Antwort an den IFCT 526 zurücksenden. Die Routing-Antwort kann angeben, an welchen Port oder welche Ports das Paket weitergeleitet werden soll und an welchen VC es weitergeleitet werden soll. Bei Nicht-Multicast-Anfragen kann die Antwort sowohl einen bevorzugten Port als auch einen Satz akzeptabler Ports angeben, an die das Paket weitergeleitet werden kann, wodurch IFCT 526 die Möglichkeit erhält, den bevorzugten Port für einen neuen Fluss oder einen umgeleiteten Fluss zu verwenden oder für einen bestehenden Fluss den aktuellen Pfad über einen Port beizubehalten, der möglicherweise nicht die aktuelle bevorzugte Wahl des FRF-Blocks 524 ist. Im Falle von Fehlern kann der FRF dem IFCT auch mitteilen, dass es keinen legalen Port gibt, an den das Paket weitergeleitet werden kann. Wenn dies der Fall ist, wird das Paket verworfen.
  • Die Routing-Entscheidungen des FRF-Blocks 524 können auf einer Kombination aus softwarekonfigurierbaren, tabellenbasierten Regeln, dynamischen Lastinformationen und Pseudo-Zufallsauswahl beruhen. Die Regeln können Faktoren wie das Ziel des Pakets, die Position auf seinem Weg (z. B. Quellgruppe, Zwischengruppe, Zielgruppe, Zielschalter), den VC, auf dem es empfangen wird, und die Art des Ports (Edge, lokal oder global), an dem es empfangen wird, berücksichtigen. AGEQ-Block 530 kann den FRF-Block 524 mit der aktuellen Last versorgen, die an der Ausgangsseite des einer bestimmten FRF-Instanz zugeordneten Ports vorliegt. Jede FRF-Instanz kann mit jeder anderen FRF-Instanz innerhalb des Switch-Chips kommunizieren, um die aktuelle Last an jedem Ausgangsport und den Status der Verbindung nach oben/unten für jeden Port zu erfahren. FRF-Instanzen können auch mit FRF-Instanzen in benachbarten Switch-Chips kommunizieren, um den lastbezogenen Status der benachbarten Geräte zu erfahren. In einer Ausführungsform kann der FRF-Block 524 so konfiguriert werden, dass er mehrere Netztopologien unterstützt.
  • Der AGEQ-Block 530 kann Anfragen von allen Eingangsanschlüssen über die Anforderungsquerleiste 528 entgegennehmen, sie zwischenspeichern, zwischen ihnen nach Verkehrsklassen unter Verwendung eines Traffic Shapers entscheiden und sie an den OFCT-Block 522 weiterleiten, damit ihnen die Grant-Querleiste 518 gewährt wird. Die Pufferung von Anfragen innerhalb des AGEQ-Blocks 530 kann so verwaltet werden, dass jeder Eingang genügend Platz zum Senden von Anfragen hat, während ein Eingang mit mehreren Strömen, die auf einen bestimmten Ausgang abzielen, mehr Platz benötigt. Der AGEQ-Block 530 kann auch für die Verwaltung des Zugriffs auf die Verbindung verantwortlich sein, indem er entweder eine kreditbasierte Flusskontrolle für den IBUF-Block eines benachbarten Switch-Chips oder eine pausenbasierte Flusskontrolle für Nicht-Fabric-Links verwendet. Wenn ein Paket von AGEQ-Block 530 freigegeben wird (d. h. für das Paket, das im IBUF-Block 512 wartet, wird eine entsprechende Erlaubnis erteilt), muss das Paket auf die abgehende Verbindung gelegt werden. Darüber hinaus kann der AGEQ-Block 530 einen Pfad aufweisen, der es Paketen, die an einem bestimmten Anschluss initiiert werden (z. B. Wartungs- oder Verkleinerungspakete), ermöglicht, sich um Ressourcen an diesem Anschluss zu bemühen.
  • OFCT 522 kann so programmiert werden, dass er entweder als EFCT für einen Egress Edge Port oder als OFCT für einen Fabric Port arbeitet. Wenn der Block als EFCT für einen Egress-Edge-Port programmiert ist, können die vom AGEQ-Block 530 empfangenen Header weitgehend unverändert durch den EFCT zur Grant-Crossbar 518 geleitet werden. Der EFCT kann auch neue ACKs von einem Ausgangspuffer (OBUF) Block 532 empfangen, um Pakete zu bestätigen, die die Fabric verlassen. Diese ACKs können an die ACK-Kreuzschiene 534 zurückgesendet werden und werden die ACKs sein, die die Flüsse in den vorgelagerten Flusstabellen schließen. Der EFCT kann auch Überlastungsmeldungen erzeugen, wenn der AGEQ-Block 530 eine Überlastung meldet. Dieser Stau an einem Egress-Edge-Port stellt in der Regel ein Incast-Forming dar und wird dazu verwendet, den Fluss am Ingress-Edge-Port zu verlangsamen.
  • Für den Fabric-Port-Betrieb kann OFCT 522 die Zuweisung der Flusskanäle für den nächsten Hop-Switch über eine abgehende Verbindung verwalten. Es kann mit dem IFCT des Fabric-Link-Partners zusammenarbeiten und Erweiterungen für die Flows erstellen, die das IFCT des Link-Partners zur Verwaltung des Vorwärtsfortschritts der Pakete verwenden kann.
  • OFCT 522 kann auch die von der Fabric-Verbindung empfangenen ACKs verwalten und diese ACKs über die ACK-Kreuzschiene 534 stromaufwärts zurücksenden. Nachdem ein bestehender Fluss erstellt oder erweitert wurde, kann OFCT 522 die flow ID- und data_flow-Werte generieren, die durch den IHDR-Block 514 zum Next-Hop-Fabric-Header hinzugefügt werden können, und diese Werte dem Grant hinzufügen, der mit anderen Header-Werten an die Grant-Crossbar 518 zurückgegeben wird.
  • Der Ausgangspuffer (OBUF) Block 532 kann Pakete erfassen, die über die Datenkreuzschiene 516 an den entsprechenden Ausgangsanschluss gesendet wurden. Die Pakete können z. B. auf vier verschiedenen Spaltenbussen ankommen und werden z. B. in vier separate FIFO-Warteschlangen eingereiht (ausführlicher erläutert in Verbindung mit ). Der OBUF-Block 532 kann zwischen diesen FIFO-Warteschlangen vermitteln, indem er prüft, ob jedes Paket ein Datenreduktionspaket ist. Jedes Datenreduktionspaket, das mit einem Deskriptor im RED-Block 534 übereinstimmt, kann vom RED-Block 534 verbraucht werden. Alle anderen Pakete können in die elastische FIFO-Warteschlange eingereiht werden, wo sie darauf warten, zur ausgehenden Verbindung übertragen zu werden. Der OBUF-Block 532 kann einen Ausgangs-Arbiter enthalten, der Pakete aus der elastischen FIFO-Warteschlange, abgeschlossene Reduktionspakete aus dem RED-Block 534, Steuerpakete aus einem Control Packet Transmitter (CFTX)-Block 536 und injizierte Pakete von einer Management-Schnittstelle zur Übertragung an die ausgehende Verbindung auswählen kann.
  • Der OBUF-Block 532 kann auch ACK-Werte erzeugen, um eine Überlastung in der Mitte des Netzes anzuzeigen, wenn der AGEQ-Block 530 beginnt, sich zu füllen oder ACKs zu verwerfen, wenn der AGEQ-Block 530 ein Paket verworfen hat.
  • In einer Ausführungsform kann ein Kontrollpaket-Empfänger (CFRX) Block 538 alle kontrollbezogenen Pakete verarbeiten, die aus dem IBUF-Block 512 extrahiert werden können. Diese steuerungsrelevanten Pakete können u. a. Überlastungssignalisierungspakete, Pakete zur Vergabe von Flusssteuerungskrediten und Flusskanal-ACKs umfassen. Die Überlastungssignalisierungsinformationen können an den FRF-Block 524 gesendet und für Routing-Entscheidungen verwendet werden. Die kreditbasierten Flusssteuerungsinformationen können an den AGEQ-Block 530 gesendet werden, um die Weiterleitung von Paketen an den nachgeschalteten Switch zu planen. ACKs können an OFCT 522 gesendet werden, der wiederum den Eingangsanschluss identifizieren kann, an den die ACK weitergeleitet werden soll, und anschließend an die ACK-Kreuzschiene 534 gesendet werden.
  • Dementsprechend kann der CFTX-Block 536 die ACKs (auf der Grundlage von IFCT 526), die kreditbasierten Flusskontrollpakete (auf der Grundlage des Zustands des IBUF-Blocks 512) und die Überlastungssignalisierungspakete an den entsprechenden Ausgangsport senden.
  • OBUF-Block 532 kann auch eine Kreditrückmeldung an AGEQ-Block 530 erzeugen, die den für ausgehende Datenpakete verfügbaren Landeplatz angibt (zu beachten ist, dass dieser Kredit für die Crossbar-Planung zwischen Eingängen und Ausgängen der Crossbar verwendet wird und sich von den Krediten unterscheidet, die für die Flusssteuerung zwischen den Vermittlungsstellen verwendet werden). Diese Kreditinformationen werden vom AGEQ-Block 530, gegebenenfalls über eine Kredit-Kreuzschiene 540, an den INQ-Block 520 weitergeleitet, der diese Kreditinformationen zur Planung der Paketentnahme aus dem IBUF-Block 512 verwendet.
  • Wie bereits erwähnt, kann es in einem Switch-Chip fünf Crossbars geben: Request Crossbar 528, Grant Crossbar 518, Credit Crossbar 540, ACK Crossbar 534 und Data Crossbar 516.
  • Die Anforderungskreuzschiene 528 kann Anforderungen von einem Eingang an den AGEQ-Block des Zielausgangs senden. Ein Kreditprotokoll kann verwendet werden, um zu gewährleisten, dass am Ausgang ein Landeplatz für eine Anforderung vorhanden ist. Jede Anforderung kann einen Zeiger (sop_ptr) auf den Speicherort des Pakets im IBUF-Block 512 enthalten.
  • Die Grant-Kreuzschiene 518 kann einen Grant an den Eingang zurückgeben, der eine Anforderung erfüllt. Die Gewährung kann den Zeiger (sop_ptr) zurückgeben. Ein Grant wird nur zurückgegeben, wenn im OBUF-Block 532 Platz für das entsprechende Paket vorhanden ist. Die Gewährung kann optional auch ein Guthaben für den angeforderten Speicherplatz im OBUF-Block 532 zurückgeben.
  • Die Guthaben-Kreuzschiene 540 kann Guthaben für angeforderten Speicherplatz im OBUF-Block 532 zurückgeben. Die ACK-Kreuzschiene 534 kann ACK-Pakete auf der Grundlage von OFCT 522 von den Ausgangsanschlüssen zu den Eingangsanschlüssen weiterleiten. Die Daten-Kreuzschiene 516 kann bewilligte Pakete vom IBUF-Block 512 in den Ziel-OBUF-Block 532 übertragen. Bewilligungen werden nur zurückgegeben, wenn ein garantierter Landeplatz für das Paket am Ausgang vorhanden ist, so dass Pakete nicht blockiert werden können.
  • zeigt eine beispielhafte Kreuzschiene. In diesem Beispiel kann eine Kreuzschienen-Kachelmatrix 550 für die Weiterleitung von Daten, ACKs, Anforderungen, Zuschüssen und Gutschriften verwendet werden. Die Daten-Crossbar kann Multitakt-Pakete mit Headern und Datennutzlast weiterleiten, während die anderen vier Crossbars nur Header von Paketen mit einem Takt weiterleiten. Alle fünf Crossbars können dieselbe Grundarchitektur verwenden. Wie in gezeigt, kann die Kreuzschienen-Kachelmatrix 550 ein 64x64-Gerät sein, das aus einer 8x4-Matrix von 32 Kreuzschienen-Kacheln besteht. Jede Kachel kann ein 16x8-Kreuzschienenschalter mit 16 Eingängen sein, einer für jeden Anschluss in der entsprechenden Zeile (z. B. Zeile 552), und 8 Ausgängen, einer für jeden Anschluss in der entsprechenden Spalte (z. B. Spalte 554).
  • zeigt eine beispielhafte Architektur einer Crossbar-Kachel. In diesem Beispiel kann eine Crossbar-Kachel 570 16 Eingangsanschlüsse und 8 Ausgangsanschlüsse haben. Der Eingangspuffer eines jeweiligen Eingangsanschlusses, z. B. Eingang 0, kann in separate virtuelle Ausgangswarteschlangen, z. B. Warteschlange 572, unterteilt werden. Jede virtuelle Ausgangswarteschlange entspricht einem entsprechenden Ausgangsanschluss. Durch die Anordnung der virtuellen Ausgangswarteschlangen kann eine Blockierung der Eingangswarteschlangen vermieden werden. Darüber hinaus gibt es an jedem Kreuzschienen-Schaltpunkt eine Kreuzschienen-Warteschlange, wie z. B. Warteschlange 574, die ein Paket aufnehmen kann, das von einem entsprechenden Eingang auf einem Zeilenbus an den entsprechenden Spaltenbus gesendet wird. Durch die Kreuzschienen-Warteschlangen können Blockierungen auf den Ausgangsbussen (Spaltenbussen) vermieden werden, und die Spaltenbusse können in einem viel größeren Umfang genutzt werden. Während des Betriebs erfolgt die Übertragung eines Pakets von einem Eingang zu einem Ausgang mit einem „requestgrant“-Mechanismus. In der ersten Runde der Arbitrierung kann jede virtuelle Ausgangswarteschlange eine Anfrage zum Senden ihres gespeicherten Pakets (falls vorhanden) stellen. Die Übertragung der Anforderungen aller virtuellen Ausgangswarteschlangen von einem Eingang aus erfolgt durch einen Eingangs-Arbiter, z. B. den Arbiter 576. Sobald diese Anforderungen gestellt sind, werden die entsprechenden Bewilligungen von einem Output-Scheduler erteilt. Nachdem die Zuweisungen an den Eingangsanschlüssen eingegangen sind, werden die entsprechenden Datenpakete aus der Warteschlange der virtuellen Ausgangswarteschlangen entfernt und über den Crossbar-Switch weitergeleitet. Die Pakete werden dann in den Crossbar-Warteschlangen für den entsprechenden Ausgangsbus (Spalte) zwischengespeichert. Ein zweiter Arbiter, z. B. der Arbiter 578, kann verwendet werden, um die Entnahme von Paketen aus den mehreren Crossbar-Warteschlangen, die einem bestimmten Spaltenbus entsprechen, zu planen.
  • Zurück zu : Jede Zeile kann 16 Zeilenbusse (z. B. Zeilenbus 553) haben, die Eingangsdaten an alle Kacheln in dieser Zeile weiterleiten. Jede Spalte kann über 8 Spaltenbusse (z. B. Spaltenbus 555) verfügen, die die weitergeleiteten Daten an die entsprechenden Ausgangsports liefern. Zeilenbusse können von jeder Quelle in einer Zeile zu allen 8 Kreuzschienen-Kacheln in dieser Zeile geleitet werden. Jede Reihe kann identische Verbindungen mit den One-to-All-Reihenbusverbindungen für eine einzelne Reihe haben. Die Arbitrierung kann an der Kreuzschiene von den 16 Zeilenbussen in dieser Zeile zu den 8 Spaltenbussen in einer bestimmten Spalte erfolgen. An jeder 16x8-Kreuzschienenkachel für jeden der Zeilenbusse ist eine Pufferung vorgesehen, um Pakete während der Zeiten aufzufangen, in denen es zu einem Wettbewerb um einen Spaltenbus kommt. In einer Ausführungsform wird ein Nicht-Jumbo-Paket nur dann auf einen Zeilenbus gelegt, wenn im Eingangspuffer der Ziel-Crossbar Platz für das gesamte Paket ist. Um Platz auf dem Chip zu sparen, können Jumbo-Pakete auf einem Zeilenbus platziert werden, auch wenn der Platz nicht ausreicht, wobei der Zeilenbus blockiert wird, bis das Paket die Arbitrierung gewinnt und Platz frei wird, wenn es auf einen Spaltenbus verschoben wird (d.h. der Eingangspuffer kann nur so groß sein, dass er ein Nicht-Jumbo-Paket aufnehmen kann). Spaltenbusse können von einer bestimmten Kreuzschiene zu jedem Zielport innerhalb einer Spalte geführt werden. Jeder Zielport führt eine weitere Arbitrationsebene zwischen den Spaltenbussen der 4 Zeilen durch. Mit 16 Zeilenbussen, die 8 Kreuzschienen ansteuern, von denen jede 8 Spaltenbusse speist, kann eine 4-fache Beschleunigung zwischen Zeilen und Spalten erreicht werden.
  • In einer Ausführungsform können sowohl Zeilen- als auch Spaltenbusse ein kreditbasiertes Protokoll verwenden, um zu bestimmen, wann sie senden können (siehe Arbiters 576 und 578 in ). Im Falle von Zeilenbussen kann der Quellanschluss die Anzahl der Guthaben für die Eingangspuffer der Kreuzschienen in dieser Zeile verwalten. Bei der Datenkreuzschiene hängt es von der Konfiguration und dem Zustand der Warteschlange ab, wann ein Paket auf einen Reihenbus gelangen darf. Wenn Zuweisungen, die auf einen bestimmten Eingangspuffer einer Kreuzschiene abzielen, alle über eine einzige Warteschlange laufen, wird vor Beginn der Paketübertragung Platz für das Paket am Kopf der Warteschlange benötigt. Wenn die Zuweisungen über mehrere Warteschlangen verteilt sind, wird eine Paketübertragung erst dann gestartet, wenn im Puffer Platz für das größte Paket ist, um zu verhindern, dass kleine Pakete große Pakete verdrängen. Auf diese Weise wird eine einmal begonnene Paketübertragung auf einem Zeilenbus erst dann beendet, wenn das gesamte Paket übertragen wurde. Dementsprechend sind die Eingangspuffer der Crossbars groß genug, um die maximale Paketgröße plus zusätzlichen Platz für den schlimmsten Fall eines Roundtrips (vom Senden des Pakets bis zur Rückgabe des Guthabens) zu verarbeiten. Bei Jumbo-Paketen ist dies jedoch möglicherweise nicht der Fall. Um bei Jumbo-Paketen Pufferfläche zu sparen, können die Crossbar-Eingangspuffer so eingestellt werden, dass sie gerade genug Platz haben, um ein Paket ohne Jumbo-Größe mit maximaler Übertragungseinheit (MTU, z. B. ca. 1500 Byte) zu verarbeiten, wobei ein Jumbo-Paket einen Zeilenbus blockieren darf, während es darauf wartet, Zugang zum Zielspaltenbus zu erhalten.
  • Bei Spaltenbussen kann jede Kreuzschienenkachel die Anzahl der Guthaben für die Eingangspuffer an jedem Zielanschluss in dieser Spalte speichern. Im Gegensatz zu Zeilenbussen ist es nicht erforderlich, dass für das größte Paket Kreditpunkte verfügbar sind, bevor die Übertragung dieses Pakets auf einem Spaltenbus beginnt. Einzelne Wörter des Pakets können verschoben werden, wenn Guthaben verfügbar wird. Daher muss der Eingangspuffer am Ziel für jeden Spaltenbus nur so groß sein, dass er im schlimmsten Fall den Hin- und Rückweg abdeckt (z. B. vom Senden des Pakets bis zur Rückgabe des Guthabens).
  • Wie in und kann jede Kreuzschienen-Kachel 16 Zeilenbus-Eingangspuffer und 8 mögliche Ziele haben. Zwischen den 16 Quellen für jedes Ziel kann ein Round-Robin-Schiedsverfahren verwendet werden. Bei der Datenkreuzschiene kann eine Quelle, sobald sie die Arbitrierung gewonnen hat, die Kontrolle über den Zielspaltenbus behalten, bis das gesamte Paket gesendet worden ist.
  • In einer Ausführungsform kann ein Ausgangskontrollblock dafür verantwortlich sein, Anforderungen von allen Eingangsanschlüssen über die Anforderungsquerleiste anzunehmen, sie zu puffern und sie an den OFCT weiterzuleiten, damit sie über die Erteilungsquerleiste gewährt werden. Der AGEQ-Raum kann vom Ausgangskontrollblock verwaltet werden, damit ein einzelner Eingang mit mehreren Flüssen, die auf einen bestimmten Ausgang abzielen, seine Anforderungen in den AGEQ verschieben kann. Der Ausgangskontrollblock kann auch für die Verwaltung des Platzes im Eingangspuffer eines nachgelagerten benachbarten Switches (d. h. des Verbindungspartners, der einem Ausgangsport entspricht) und die Zuweisung von Flusskanälen zuständig sein. Darüber hinaus kann der Ausgangskontrollblock über einen Pfad verfügen, der es ermöglicht, dass Pakete, die an einem bestimmten Anschluss initiiert werden, wie z. B. Wartungs- oder Verkleinerungspakete, für Ressourcen an diesem Anschluss entschieden werden.
  • Anfragen können über einen Spaltenbus von jeder Zeile der Matrix in den Ausgangskontrollblock gelangen. Jeder Spaltenbus kann eine unabhängige FIFO-Warteschlange speisen, wobei der Platz in der FIFO-Warteschlange über Kredite verwaltet wird. Diese FIFO-Warteschlangen können ausreichend tief dimensioniert werden, um die maximale Umlaufverzögerung abzudecken und zusätzlich etwas Platz zu schaffen, damit die Anfragen aus den Kreuzschienen herausgeschoben werden können und um ein Blockieren der Kopfzeile zu verhindern. Bevor die Anforderung in eine FIFO-Warteschlange geschrieben wird, kann sie auf einen gültigen Fehlerprüfcode (ECC) geprüft werden. Wird ein Fehler festgestellt, kann das Paket mit einer Fehlermarkierung verworfen werden.
  • In einer Ausführungsform kann die LRU-Arbitrierung (Least Recently Used) zwischen den FIFO-Warteschlangen des Spaltenbusses verwendet werden, um zu entscheiden, welche FIFO-Warteschlange ausgewählt und die entsprechende Anfrage an den AGEQ-Block weitergeleitet wird. Wenn Anforderungen aus jeder FIFO-Warteschlange entfernt werden, können Guthaben an die entsprechende Kreuzschiene zurückgegeben werden.
  • Der Ausgangspuffer kann an den Ausgangskontrollblock Anforderungen für das Senden von Reduzierungs- und Wartungspaketen über die entsprechende ausgehende Verbindung stellen. Diesen Anforderungen kann eine höhere Priorität eingeräumt werden. In einer Ausführungsform verwenden Reduktionspakete keine Flusskanäle und Wartungspakete können Loopback verwenden, um einen Fluss zu erzeugen, so dass es nicht notwendig ist, die Verfügbarkeit von Flusskanälen zu prüfen oder den OFCT zu verwenden, um einen Grant zu erzeugen. Sie verbrauchen auch keinen Platz im Ausgangspuffer, so dass eine Überprüfung des Platzes nicht erforderlich ist.
  • Die Größe der nächsten zu verarbeitenden Anfrage aus dem Ausgabepuffer kann mit der maximalen Paketgröße verglichen werden. Überschreitet sie diesen Wert, wird der Auftrag nicht verarbeitet und es kann ein Fehlerflag gesetzt werden. Dies kann dazu führen, dass der Auftragspfad für den Ausgangspuffer blockiert wird, bis ein Warm-Reset durchgeführt wird.
  • In einer Ausführungsform kann jedem Eingangsanschluss ein fester Betrag an AGEQ-Speicherplatz zugewiesen werden, der als fixed_alloc bezeichnet wird. Dieser Platz kann ausreichend groß sein, um jede dem jeweiligen Eingangsanschluss zugeordnete Verkehrsklasse unterzubringen, wobei genügend zusätzlicher Platz vorhanden sein muss, um den Hin- und Rückweg zwischen Anfrage und Guthaben abzudecken. Die Aufteilung dieses festen Platzes auf verschiedene Verkehrsklassen innerhalb desselben Eingangsanschlusses kann konfiguriert werden. Eine Verkehrsklasse kann durch eine Kombination aus der Kennung der Shaping-Queue (SQ) und der Kennung des virtuellen Kanals (VC) identifiziert werden. In einer Ausführungsform kann die AGEQ 8k Plätze haben, wobei jeder Platz einer Verkehrseinheit entspricht. Die Gesamtmenge des fest zugewiesenen Platzes kann (64*fixed_alloc) betragen, und der verbleibende Platz kann 8k-64*fixed_ alloc sein. Dieser verbleibende Platz kann auf alle Eingänge aufgeteilt werden.
  • Der Shared Space kann von der Ausgabe verwaltet werden. Eingehende Anfragen können bei ihrem Eintreffen vom statischen in den Shared Space verschoben werden, wenn im Shared Space Platz vorhanden ist, vorbehaltlich der Grenzen pro Eingabe. Wenn eine Anfrage in den Shared Space verschoben wird, kann sofort ein Guthaben über die Guthaben-Kreuzschiene zurückgegeben werden, wobei die Anfrage in der AGEQ als im Shared Space befindlich markiert wird. Wird die Anfrage bewilligt und ist sie als im Shared Space befindlich gekennzeichnet, wird der Shared Space gutgeschrieben. Wenn sie nicht als gemeinsam genutzter Speicherplatz gekennzeichnet ist, wird davon ausgegangen, dass sie den statischen Speicherplatz genutzt hat, und ein Guthaben wird mit der Gewährung an den Eingang zurückgegeben.
  • Aufgrund von Konflikten in der Credit-Crossbar ist es möglich, dass Credits nicht in jeder Taktperiode gesendet werden können. Eine FIFO-Warteschlange kann verwendet werden, um diese vorübergehenden Störungen zu puffern. In einer Ausführungsform kann eine Anforderung von der Anforderungs-Kreuzschiene nur angenommen werden, wenn in dieser FIFO-Warteschlange Platz ist. Eine FIFO-Warteschlange mit einer Tiefe von z. B. 32 Plätzen kann verwendet werden, um die Möglichkeit eines Rückstaus in die Anforderungskreuzschiene zu begrenzen.
  • Der gemeinsam genutzte Speicherplatz in AGEQ kann Grenzen dafür setzen, wie viel Platz eine einzelne Eingabe beanspruchen kann. Diese Grenzen können als Prozentsatz des verfügbaren Speicherplatzes festgelegt werden. Ist die Grenze beispielsweise auf 50 % festgelegt und ist nur ein Eingang aktiv, kann dieser auf 50 % des gemeinsam genutzten Speicherplatzes zugreifen. Bei zwei aktiven Eingängen kann jeder Eingang auf 37,5 % des gemeinsam genutzten Platzes zugreifen, was sich wie folgt berechnet: (space _used_by_1 + space_left*0.5)/2 = (50%+50%*0.5)/2 = 37,5%. Bei drei aktiven Eingängen kann jeder Eingang auf 29,2 % des gemeinsam genutzten Bereichs zugreifen, was sich wie folgt berechnet: (space_used_by_2 + space_left*0.5)/3 = (75%+25%*0.5)/3 = 29,2 %, usw. Der gesamte gemeinsam genutzte Speicherplatz, der von allen aktiven Eingängen genutzt werden kann, ist auf die Gesamtzahl begrenzt, die in diesen drei Beispielen jeweils 50%, 75% und 87,5% beträgt. Bei dieser Konfiguration kann der jedem Eingang zugewiesene gemeinsame Speicherplatz dynamisch variieren, je nachdem, wie viele Eingänge gerade aktiv sind. Das Hinzufügen eines aktiven Eingangs kann dazu führen, dass andere aktive Eingänge ihren gemeinsam genutzten Speicherplatz aufgeben, der dann dem neuen Eingang zugewiesen wird.
  • Da die Hardware-Implementierung der Teilung kostspielig sein kann, kann diese dynamische Zuweisungsfunktion des gemeinsam genutzten AGEQ-Raums als Nachschlagetabelle mit z. B. 64 Einträgen implementiert werden, wobei jeder Eintrag einer Anzahl aktiver Eingangsanschlüsse entspricht. Die Anzahl der aktiven Eingangsanschlüsse kann als Index für die Tabelle verwendet werden. Die Werte in der Tabelle können die Obergrenze des gemeinsam genutzten Speicherplatzes darstellen, auf den jeder Eingang zugreifen kann, sowie den gesamten Speicherplatz, den sie insgesamt beanspruchen können. Mit einer softwarebasierten Funktion können die Werte in der Tabelle entsprechend der Gesamtmenge des gemeinsam genutzten Speicherplatzes und dem Prozentsatz, den jeder Eingang nutzen darf, programmiert werden. Je mehr Eingänge aktiv werden, desto weniger Platz wird jedem Eingang zugestanden, und der insgesamt verfügbare Platz nimmt zu. Eingehende Anfragen von Eingängen, die über diesem Grenzwert oder insgesamt über dem Grenzwert für den Gesamtspeicherplatz liegen, dürfen keinen weiteren gemeinsamen Speicherplatz beanspruchen.
  • Um die Anzahl der aktiven Eingänge in AGEQ zu verfolgen, kann ein Satz von 64 Zählern (einer für jeden Eingang) verwendet werden. Diese Zähler können aufwärts zählen, wenn eine Anfrage in AGEQ gestellt wird, und abwärts zählen, wenn sie herausgenommen (gewährt) werden. Ein zweiter Zähler, der die Anzahl der von Null abweichenden Zählungen zählt, kann als Index in der Nachschlagetabelle für die gemeinsame Speicherplatzzuweisung verwendet werden. Zur Verwaltung des gemeinsam genutzten Speicherplatzes kann außerdem ein zusätzlicher Satz von 64 Zählern verwendet werden, um die aktuelle Nutzung des gemeinsam genutzten Speicherplatzes durch jeden Eingang zu verfolgen. Es kann auch ein einziger Zähler vorhanden sein, der die Gesamtnutzung des gemeinsam genutzten Speicherplatzes erfasst. Diese Zähler können mit den aktuellen Quoten verglichen werden, um festzustellen, ob eine Anfrage den gemeinsam genutzten Speicherplatz nutzen darf. In einer Ausführungsform können alle Zähler 13 Bit breit sein, was ausreicht, um z. B. die 8K Speicherplätze in AGEQ abzudecken.
  • zeigt eine beispielhafte Implementierung der Alterswarteschlangen. In diesem Beispiel können die Alterungswarteschlangen einen Anforderungs-RAM 580 verwenden, der z. B. 8K Speicherplätze hat. Diese Speicherplätze können dynamisch einer Anzahl separater Warteschlangen 582 zugewiesen werden, die der Gesamtzahl der Kombinationen aus Verkehrsklasse (identifiziert durch den SQ-Wert) und virtuellem Kanal (identifiziert durch den VC-Wert) entsprechen können. In einer Ausführungsform kann eine physische Verbindung in vier VCs unterteilt werden, und das System kann 8 Verkehrsklassen unterstützen. Dementsprechend gibt es insgesamt 32 (d. h. 4*8) separate Warteschlangen, jede für eine eindeutige SQ/VC-Kombination. Jede Warteschlange kann eine verknüpfte Liste von Speicherplätzen innerhalb des Speichers sein. Dies gibt jeder SQ/VC-Kombination die Möglichkeit, bei Bedarf mehr Speicherplatz zu belegen.
  • Wie in dargestellt, kann jede Warteschlange einen vorderen Zeiger enthalten, der auf den Anfang der verknüpften Liste zeigt. Jedes Element in der verknüpften Liste enthält auch einen Zeiger, der auf das nächste Element in der verknüpften Liste verweist. In einer Ausführungsform können die Zeiger, die auf das nächste Element zeigen, in einem nächsten Zeiger-RAM gespeichert werden. Die letzte Position in der Warteschlange kann durch einen Rückwärtszeiger angezeigt werden. Jede Position in einer Warteschlange kann eine Anfrage aufnehmen. Anfragen können vom Anfang der Warteschlange entfernt und am Ende der Warteschlange eingefügt werden.
  • Zusätzlich zu der Datenstruktur mit verknüpften Listen kann jede Warteschlange auch eine FIFO-Warteschlange, wie die FIFO-Warteschlange 584 der Anforderungen, an ihrem Kopf haben. Diese FIFO-Warteschlangen können verwendet werden, um sicherzustellen, dass eine Warteschlange bei jedem Takt eine Anforderung mit einer Lesezugriffszeit von mehreren Takten aus dem Anforderungs-RAM erhalten kann. Wenn eine neue Anforderung eintrifft und die FIFO-Warteschlange am Kopf der Warteschlange nicht voll ist, kann die Anforderung das Anforderungs-RAM umgehen und direkt in die FIFO-Warteschlange am Kopf geschrieben werden. Sobald Anforderungen für eine bestimmte Warteschlange in den Anforderungs-RAM geschrieben werden, werden auch nachfolgende Anforderungen in den Anforderungs-RAM geschrieben, um die Ordnung aufrechtzuerhalten. Der Bypass-Pfad kann wieder verwendet werden, sobald sich keine Anfragen mehr für diese Warteschlange im Anforderungs-RAM befinden und im entsprechenden Kopf-FIFO Platz ist.
  • Wenn eine Anforderung aus einer Kopf-FIFO-Warteschlange gelesen wird und sich entsprechende Anforderungen im Anforderungs-RAM in der Warteschlange befinden, kann eine Dequeue-Operation eingeleitet werden. Da jeweils nur eine Head-FIFO-Warteschlange gelesen wird, kann nur ein einziger Dequeue-Vorgang pro Taktperiode eingeleitet werden. Es kann eine Logik eingebaut werden, um die verschiedenen Wettlaufbedingungen zwischen einer laufenden oder bevorstehenden Enqueue-Operation und einer gelesenen Head-FIFO-Warteschlange zu behandeln.
  • Die Freie Liste RAM kann eine einfache FIFO-Warteschlange sein, die bei jedem Reset mit Zeigern auf alle Einträge (z.B. 8k Einträge) initialisiert wird. Eine Zählung kann beibehalten werden, um zu verfolgen, wie viele Einträge im Free List RAM gültig sind. Wenn Einträge entnommen werden, werden sie von der Vorderseite des Fl FO gepoppt und verwendet. Wenn Einträge zurückgegeben werden, werden sie an die Rückseite einer FIFO-Warteschlange 585 geschoben. Eine Anzahl von Einträgen (z. B. 3) am Anfang der Freien Liste RAM kann in Flops gehalten werden, damit sie für einen schnellen Zugriff verfügbar sind.
  • Um die volle Leistung für kleine Pakete zu unterstützen, müssen die Alter-Warteschlangen in jeder Taktperiode sowohl eine Enqueue-Operation als auch eine Dequeue-Operation unterstützen. Die Operationen an den Datenstrukturen für eine Enqueue-Operation sind unten aufgeführt. Sie unterscheiden sich je nachdem, ob die zu schreibende Warteschlange leer ist oder nicht. In den meisten Fällen kann ein gleichzeitiger Enqueue- und Dequeue-Vorgang in einer bestimmten Warteschlange gehandhabt werden, da sie separate Felder verwenden und aktualisieren. Ein Sonderfall wäre der, bei dem die Warteschlange durch die Dequeue-Operation geleert wird. Um diesen Fall zu behandeln, kann die Dequeue-Operation logischerweise zuerst stattfinden, gefolgt von der Enqueue-Operation. Dies kann durch die Verwendung eines Leer-Flags für die Warteschlange ermöglicht werden, das gesetzt werden kann, wenn die Warteschlange durch die Dequeue-Operation geleert wird, und dann aufgrund der Enqueue-Operation gelöscht wird.
  • Fairness beim Austritt
  • Ein Switch kann bei der Weiterleitung von Paketen über seine Ausgangsports eine Traffic-Shaping-Funktion bereitstellen. Eine solche Egress-Fairness-Funktion kann mit Hilfe von Shaping-Queues im AGEQ implementiert werden. Wie bereits erwähnt, können Pakete klassifiziert werden, um die SQ auszuwählen, an die ihre Anfrage weitergeleitet wird. Dadurch kann der mit einer Anwendung verbundene Verkehr anders gestaltet werden als der Verkehr einer anderen Anwendung oder einer anderen Verkehrsklasse. Diese Funktion ist vor allem an den Edge-Ports wichtig, die mit einer Netzwerkkarte verbunden sind, da die Anwendungen in der Regel so konfiguriert sind, dass sie einen Teil der Ressourcen des Knotens nutzen und ihnen auch ein Teil der Netzwerkbandbreite zugewiesen wird. In einer Ausführungsform kann diese Klassifizierung auf dem FTAG- und VNI-Wert des Pakets im Fabric-Header basieren, der zugewiesen wird, wenn das Paket in die Fabric eintritt. FTAG und VNI können auch zur Auswahl der Shaping-Warteschlange verwendet werden, wenn das Paket die Fabric verlässt. Ein Konfigurationsregister kann verwendet werden, um FTAGs auf SQs abzubilden.
  • In einer Ausführungsform kann die AGEQ eine Anzahl von Shaping-Warteschlangen haben, die durch {SQ, VC} adressiert werden. Wenn beispielsweise 8 SQs und 4 VCs vorhanden sind, kann es insgesamt 32 individuelle Shaping-Warteschlangen geben. Der entsprechende 3-Bit-SQ-Index kann eine Shaping-Funktion sein, und der VC-Wert kann einer von vier Warteschlangen (entsprechend den 4 VCs) innerhalb dieser Shaping-Funktion zugeordnet werden.
  • Die Zuteilung kann unter den Anforderungen erfolgen, die unter Berücksichtigung der Verwaltung des Eingangspuffers, des Ausgangspuffers und der Flusskanalquoten gewährt werden dürfen. Die Zuteilung kann auch gestoppt werden, wenn keine Guthaben für die OFCT-FIFO-Warteschlange vorhanden sind. In einer Ausführungsform kann die Arbitrierung in zwei Stufen erfolgen, eine für die SQs und eine für die VCs. Für die Arbitrierung zwischen den SQs kann eine Traffic-Shaping-Arbitrierung verwendet werden. In einer Ausführungsform kann ein Deficit Round-Robin (DRR) Arbitrierungsschema verwendet werden, um zwischen VCs innerhalb einer gegebenen SQ zu arbitrieren.
  • In einer Ausführungsform kann die Schlichtung zur Verkehrsgestaltung eine Reihe von Token-Buckets verwenden, um die Bandbreite jeder SQ zu steuern. Wenn beispielsweise 8 SQs vorhanden sind, kann es 8 „leaf buckets“ (einen für jede SQ), bis zu 4 „branch buckets“ und einen „head bucket“ geben. zeigt eine beispielhafte Token-Bucket-Anordnung für die Arbitrierung zwischen 8 SQs.
  • Buckets können mit einer bestimmten Rate mit einer bestimmten Anzahl von Token gefüllt werden, um die Bandbreite dieses Buckets darzustellen. Wenn Pakete die Arbitrierung gewinnen, werden Token aus den entsprechenden Buckets genommen, um die beanspruchte Bandbreite darzustellen. Es wird erwartet, dass in einem Bucket eine maximale Framegröße (MAX FRAME _SIZE) zur Verfügung steht, um die Entnahme von Token aus diesem Bucket zu ermöglichen. Buckets werden zur Konfiguration verwendet:
    • Zugesicherte Bandbreite - Die reservierte Bandbreite für diesen Bucket
    • Maximalbandbreite - Die maximale Bandbreite für diesen Bereich
    • Priorität - Die Priorität dieses Bereiches (0=niedrigste, 7=höchste)
  • Die Bucket-Größe definiert die Zeitspanne, über die die gemeinsame Nutzung der Bandbreite verteilt werden kann. Bei 25-Bit-Buckets in Einheiten von 8B ergibt dies ein Maximum von 256 MB an Guthaben. In einer Ausführungsform würde die Annahme, dass nur ein SQ aktiv ist, bedeuten, dass bei voller Leitungsrate mindestens ~10 ms Guthaben vorhanden sind. Der tatsächliche Wert kann größer sein, da dem Bucket weiterhin Token hinzugefügt werden können, während sie verbraucht werden.
  • Zu den allgemeinen Einstellungen, die für alle Buckets verwendet werden können, gehören:
    • MAX_FRAME_SIZE - Die maximale Rahmengröße. Ein Bucket sollte größer oder gleich dieser Anzahl von Token sein, damit ein Paket Token aus diesem Bucket verwenden kann.
    • ARB_FILL_RATE - Die Anzahl der Takte, die zwischen jedem Hinzufügen von Token zu allen Buckets gezählt wird. Wird dieser Wert auf 0 gesetzt, wird das Füllen aller Buckets deaktiviert.
  • Leaf Bucket Configuration - jeder Leaf Bucket hat die unten aufgeführten Werte:
    • BUFCLASS - Die diesem SQ zugewiesene Linkpartner-Eingangspufferklasse.
    • VCSET - Der diesem SQ zugewiesene VC-Satz.
    • VC_QUANTA - Quanta-Wert für die VC Deficit Round-robin (DRR) Arbitrierung in diesem SQ.
    • PRI - Die diesem Bucket zugewiesene Priorität (0=niedrigste, 7=höchste).
    • PARENT - Der übergeordnete Bereich des Blattbereichs, der entweder einer der 4 Zweigbereiche oder der Hauptbereich sein kann.
    • FILL_QTY (für zugesicherte Bandbreite) - Die Anzahl der 16-Byte-Token, die dem zugesicherten Bucket bei jedem fill_rate-Takt hinzugefügt werden.
    • LIMIT (für zugesicherte Bandbreite) - Die Obergrenze für die Anzahl der Token, die im zugesicherten Bucket enthalten sein können, in Einheiten von 1K-Byte.
    • FILL_QTY (für ceiling bandwidth) - Die Anzahl der 16-Byte-Token, die dem ceiling bucket pro fill_rate clocks hinzugefügt werden.
    • LIMIT (für Ceiling-Bandbreite) - Die Obergrenze für die Anzahl der Token, die im Ceiling-Bucket enthalten sein können, in Einheiten von 1K-Byte.
    • ENABLE - Deckenfreigabe. Wenn diese Option gesetzt ist, wird anhand von climit/ctokens geprüft, ob in diesem Bucket noch Platz ist. Ist diese Option nicht gesetzt, ist diese Prüfung deaktiviert und es wird angenommen, dass unbegrenzter Speicherplatz zur Verfügung steht.
  • In einer Ausführungsform kann die AGEQ die folgenden Register für die Leaf-Buckets verwalten: rtokens[24:0] - Aktuelle Anzahl zugesicherter Token in Einheiten von 8 Bytes. Dieser Bereich wird in jedem fill_rate-Takt mit rfill-Tokens gefüllt und durch Paketgrößen-Tokens geleert, wenn eine Arbitration diesen Bereich verwendet. Dieser Bereich ist bei rlimit-Tokens begrenzt.
    ctokens[24:0] - Aktuelle Anzahl von Ceiling-Token in Einheiten von 8 Bytes. Dieser Bereich wird alle fill_rate-Takte mit cfill-Tokens gefüllt und durch packet-size-Tokens geleert, wenn eine Arbitration diesen Bereich verwendet. Dieser Bucket ist auf climit-Token begrenzt.
  • Konfiguration der Verzweigungseimer - Verzweigungseimer haben den Haupteimer als übergeordneten Bereich. Jeder Verzweigungsbereich hat die folgenden Werte:
    • PRI - Die diesem Bucket zugewiesene Priorität (0=niedrigste, 7=höchste).
    • FILL_QTY (für zugesicherte Bandbreite) - Die Anzahl der 16-Byte-Token, die dem zugesicherten Bucket bei jedem fill _rate-Takt hinzugefügt werden.
    • LIMIT (für zugesicherte Bandbreite) - Die Obergrenze für die Anzahl der Token, die im zugesicherten Bucket enthalten sein können, in Einheiten von 1K-Byte.
    • FILL_QTY (für ceiling bandwidth) - Die Anzahl der 16-Byte-Token, die dem ceiling bucket pro fill_rate clocks hinzugefügt werden.
    • LIMIT (für ceiling bandwidth) - Die Obergrenze für die Anzahl der Token, die im ceiling bucket in Einheiten von 1K-Byte enthalten sein können.
    • ENABLE - Deckenfreigabe. Wenn diese Option gesetzt ist, wird anhand von climit/ctokens ermittelt, ob in diesem Eimer Deckenplatz vorhanden ist. Ist die Option deaktiviert, ist diese Prüfung nicht möglich, und es wird von einem unbegrenzten Deckenplatz ausgegangen.
  • In einer Ausführungsform kann die AGEQ-Logik die folgenden Register für die Verzweigungseimer verwalten:
    • rtokens[24:0] - Aktuelle Anzahl zugesicherter Token in Einheiten von 8 Bytes. Dieser Bereich wird alle fill_rate-Takte mit rfill-Tokens gefüllt und um Paketgrößen-Tokens geleert, wenn eine Arbitrierung diesen Bereich verwendet. Dieser Bereich ist auf rlimit-Token begrenzt.
    • ctokens[24:0] - Aktuelle Anzahl von Ceiling-Token in Einheiten von 8 Bytes. Dieser Bereich wird alle fill_rate-Takte mit cfill-Tokens gefüllt und um Paketgrößen-Tokens geleert, wenn eine Arbitration diesen Bereich verwendet. Dieser Bucket ist auf climit-Token begrenzt.
  • Head Bucket-Konfiguration: Der Head Bucket verfügt über keine Einstellungen für die zugesicherte Bandbreite. Er verwaltet die Höchstbandbreite und hat die folgenden Werte: FILL_QTY - Die Anzahl der 16-Byte-Token, die dem Ceiling Bucket bei jedem fill _rate-Takt hinzugefügt werden. LIMIT - Die Obergrenze für die Anzahl der Token, die im Ceiling Bucket enthalten sein können, in Einheiten von 1K-Byte. ENABLE - Freigabe des Ceilings. Wenn gesetzt, wird climit/ctokens verwendet, um festzustellen, ob in diesem Bucket noch Platz ist. Ist diese Option nicht gesetzt, ist diese Prüfung deaktiviert und es wird von einem unbegrenzten Speicherplatz ausgegangen.
  • In einer Ausführungsform kann die AGEQ-Logik die folgenden Steuerregister für den Kopfeimer verwalten:
    • ctokens[24:0] - Aktuelle Anzahl von Ceiling Tokens in Einheiten von 8 Bytes. Dieser Bereich wird alle fill_rate-Takte mit cfill-Token gefüllt und um Paketgrößen-Token geleert, wenn eine Arbitrierung diesen Bereich verwendet. Dieser Bucket ist auf climit-Token begrenzt.
  • Die Schlichtung kann in drei Gruppen unterteilt werden: Gruppe 1 kann die höchste Priorität haben, gefolgt von Gruppe 2 und dann Gruppe 3. Für die Gruppen 1 und 2 kann die Schlichtung unter den in Frage kommenden SQs auf die gleiche Weise erfolgen. Zwischen den SQs kann für jede der 8 Prioritätsstufen eine x8-Round-robin-Schlichtung durchgeführt werden (8 parallele Round-robin-Schlichtungsvorgänge). Zwischen den Prioritätsebenen kann eine feste Arbitrierung durchgeführt werden. Die Arbitrierung der Gruppe 3 hat keine Prioritäten und kann eine einzelne x8-Round-robin-Arbitrierung sein.
  • Die Anforderungen für die Aufnahme in Gruppe 1 sind:
    • -Blatteimer hat eine gesicherte und eine maximale Bandbreite zur Verfügung; Verzweigungsbereich (falls der Flügel einen hat) hat zugesicherte und maximale Bandbreite zur Verfügung; und Der Kopfbereich verfügt über eine Höchstbandbreite.
  • Die Anforderungen für die Aufnahme in die Gruppe 2 sind:
    • -Leaf Bucket hat eine Höchstbandbreite zur Verfügung; Abzweigeimer hat gesicherte und maximale Bandbreite zur Verfügung; und Der Kopfbereich verfügt über eine Höchstbandbreite.
  • Die Anforderungen für die Aufnahme in Gruppe 3 sind:
    • -Leaf Bucket hat eine Höchstbandbreite zur Verfügung; Der Abzweigbereich verfügt über eine Höchstbandbreite; und Der Kopfbereich verfügt über eine Höchstbandbreite.
  • Bei einer Schlichtung der Gruppe 1 ergibt sich die Priorität für jeden aus der Einstellung in den Blatt-Eimern. Bei der Gruppe 2 ergibt sich die Priorität aus der Einstellung in den Zweigbereichen. In allen Fällen sind die Bereiche, die für diese Gruppe in Frage kommen, auch die Bereiche, aus denen Paketgrößen-Token entnommen werden, wenn diese Anfrage die Schlichtung gewinnt.
  • Beachten Sie, dass durch die Einstellung von ARB_FILL_RATE auf 0 (was das Füllen der Eimer deaktiviert) und die Einstellung des Ceiling-Enable-Flags für das Blatt, die Verzweigung (falls verwendet) und den Kopf auf 0, die Arbitrierung zu einem einfachen Round-Robin zwischen den 8 SQs degradiert wird.
  • Ein einfaches Beispiel mit den sich ergebenden Bandbreiten für jeden SQ ist in dargestellt. In diesem Beispiel entsprechen SQ0, SQ1 und SQ2 den Blatteimern 590-6, 590-8 bzw. 590-10. Die Blattbecher 590-6 und
    590-8 befinden sich unter dem Abzweigbecher 590-4, der mit dem Kopfeimer 590-2 verbunden ist. Die Blattschaufel ist direkt mit der Hauptschaufel 590-2 verbunden, ohne irgendwelche Abzweigschaufeln. Wie in zu sehen ist, können alle drei SQs die zugesicherte Bandbreite erhalten, die ihren Blatteimern zugeordnet ist. SQ 0 und 1 teilen sich zu gleichen Teilen die zugesicherte Bandbreite ihres Verzweigungseimers 590-4. Alle drei SQs teilen sich gleichermaßen die verbleibende Bandbreite am Kopf. In diesem Fall schränken die Einstellungen für die Höchstbandbreite keine der SQs ein.
  • Eine defizitäre Round-Robin-Arbitration kann zwischen VCs durchgeführt werden, um die Arbitrationsbandbreite fair zu gestalten. Dies wird dadurch erreicht, dass jeder VC einen Zähler hat. Alle Zähler beginnen mit einem programmierbaren Quantenwert (VC_QUANTA). Wenn ein VC die Arbitrierung gewinnt, wird sein Zähler um die Paketgröße erhöht. Der Zählerwert wird mit dem Quantenwert verglichen. Ist der Zählerwert kleiner als der Quantenwert, darf diese Anfrage an der Schlichtung teilnehmen. Wenn es gültige Anfragen gibt und keine davon zugelassen werden kann, weil ihr Zählwert zu hoch ist, wird ein Quanta von allen Zählwerten abgezogen (der Wert darf nicht unter 0 sinken). Dadurch werden alle Anfragen freigegeben und der Vorgang kann wiederholt werden. Mit dieser Arbitrierung wird ein VC mit kleinen Paketen häufiger die Arbitrierung gewinnen als ein VC mit großen Paketen, vorausgesetzt, es gibt einen stetigen Strom von Paketen.
  • zeigt ein Flussdiagramm eines beispielhaften Alterswarteschlangen-Arbitrierungsprozesses, der die Fairness beim Ausgang erleichtert. Während des Betriebs kann der Switch zunächst ein empfangenes Paket in seinem Eingangspuffer speichern (Vorgang 590-102). Das System kann dann die Shaping-Warteschlange auf der Grundlage der FTAG und VNI des Pakets bestimmen (Vorgang 590-104). Als Nächstes kann der Eingangswarteschlangen-Logikblock (siehe z. B. INQ-Block 520 in ) eine Anfrage an den AGEQ zur Weiterleitung des Pakets senden (Vorgang 509-106). Auf der AGEQ-Seite kann ein Scheduler-Logikblock eine Arbitrierung der im AGEQ gespeicherten Anfragen auf der Grundlage ihrer zugehörigen SQs und VCs durchführen (Vorgang 509-108). In einer Ausführungsform kann die Arbitrierung auf der Grundlage eines Token-Bucket-Schemas wie oben beschrieben erfolgen. Anschließend kann der Anforderung stattgegeben werden (Vorgang 509-110), und der Eingangspuffer kann das entsprechende Paket zur Übertragung an den Ausgangspuffer weiterleiten (Vorgang 509-112).
  • zeigt einen beispielhaften AGEQ-Arbitrierungsmechanismus, der die Fairness beim Austritt erleichtert. Der in gezeigte Teil eines Switches kann ein Teil der in gezeigten Gesamtarchitektur sein. In diesem Beispiel ist ein Scheduler-Logikblock 590-204 mit AGEQ 590-202 gekoppelt und kann die Token-Bucket-basierte Arbitrierung zwischen allen SQs und VCs durchführen, um die Gewährung von in den Alterswarteschlangen gespeicherten Anforderungen zu planen. Ein Ausgabepuffer 590-204 kann die Guthaben für die Erteilung von Genehmigungen auf der Grundlage des verfügbaren Platzes bereitstellen.
  • Staumanagement
  • Wie oben beschrieben, kann jeder Fluss an einem bestimmten Switch seine eigene private Warteschlange mit Paketen haben. Diese Konfiguration ermöglicht eine separate Flusskontrolle für jeden Fluss. Infolgedessen kann das Netz weitgehend verlustfrei bleiben, und ein Fluss, der eine Verbindung nutzt, kann blockiert werden, ohne dass ein anderer Fluss, der dieselbe Verbindung nutzt, blockiert wird. Im Gegensatz zu einem herkömmlichen paketvermittelten Netz kann sich eine Überlastung in einem Teil des Netzes nur auf die Datenströme auswirken, die zu der Überlastung beitragen. In einem herkömmlichen Netz können sich zum Beispiel die Puffer vor einer überlasteten Verbindung schnell mit den Paketen füllen, die die Überlastung verursachen. Dies wiederum kann den Switch dazu zwingen, einen Pausenbefehl zu erteilen oder eine andere Methode der Flusskontrolle anzuwenden, um benachbarte Switches daran zu hindern, Pakete an die überlastete Verbindung zu senden. Infolgedessen können die Pakete, die die Überlastung verursachen, gestoppt oder verlangsamt werden, und alle anderen Pakete, die nicht für die überlastete Verbindung bestimmt sind, können ebenfalls gestoppt oder verlangsamt werden. Infolgedessen kann sich die Überlastung seitwärts ausbreiten und den Sättigungsbaum aus topologischer Sicht vergrößern.
  • Im Gegensatz dazu kann bei Flusskanälen die Last der zur Überlastung beitragenden Flüsse auf den zur Überlastung führenden Verbindungen reduziert werden. Diese Verringerung der Last kann es anderen Flüssen, die diese Verbindungen gemeinsam nutzen, ermöglichen, mehr Verbindungsbandbreite zu verwenden und ihre Nutzlast schneller zu liefern, während nur die Pakete, die zu der überlasteten Verbindung beitragen, verlangsamt werden.
  • Herkömmliche Netze können in der Regel normal arbeiten, solange die Netzlast nicht die volle Kapazität erreicht oder annähernd erreicht. Dies ist bei kleinen oder mittelgroßen Netzen meistens der Fall. Bei großen oder sehr großen Netzen, die mit mehreren bandbreitenintensiven Anwendungen betrieben werden, kann jedoch jederzeit ein Teil des Netzes mit der Verkehrslast gesättigt sein. Unter diesen Umständen kann es zu einer unfairen Paketzustellung kommen, selbst wenn einzelne Switches lokal faire Richtlinien implementieren.
  • zeigt ein Beispiel, bei dem eine unfaire Aufteilung der Verbindungsbandbreite in einem Netz auftreten kann. In diesem Beispiel versucht jede der Quellen A bis K, einen Paketstrom an das Ziel L zu senden, wodurch ein Incast-Szenario entsteht, in dem mehrere Quellen Pakete an ein einziges Ziel senden. Die Quellknoten A, B und C sind mit dem Switch 602 verbunden; die Quellknoten D, E und F sind mit dem Switch 604 verbunden; die Quellknoten G, H und I sind mit dem Switch 606 verbunden; die Quellknoten J und K sowie der Zielknoten L sind mit dem Switch 608 verbunden. Nehmen wir an, dass jeder Switch eine faire Arbitrierungspolitik verfolgt, indem er eine gleiche Anzahl von Paketen von jedem seiner Eingangsports zu einem bestimmten Ausgangsport auswählt. Wie jedoch in zu sehen ist, können Quellen, die näher am Ziel liegen, einen viel höheren Anteil der endgültigen Verbindungsbandbreite erhalten als Quellen, deren Verkehr mehrere Vermittlungsstufen durchlaufen muss. Die Vermittlungsstelle 608 verfügt über drei Quellen eingehender Daten von den Knoten J, K und der Vermittlungsstelle 606 und kann die Bandbreite auf der abgehenden Verbindung zum Knoten L gleichmäßig auf die einzelnen Quellen aufteilen. Somit können die Knoten J und K jeweils 33,3 % der Bandbreite auf der abgehenden Verbindung zum Zielknoten L nutzen.
  • Der nächstgelegene Schalter, Schalter 606, kann dasselbe tun und so weiter. In diesem Beispiel mit nur vier Vermittlungsstufen und nur drei oder vier Eingängen auf jeder Stufe und mit insgesamt 11 Eingängen, die versuchen, an den Zielknoten L zu senden, beanspruchen drei Eingangsquellen (Knoten A, B und C) nur 1/48 der Bandbreite, die von zwei anderen Eingangsquellen (Knoten J und K) auf der abgehenden Verbindung zum Zielknoten L belegt wird. Eine realistischere Netztopologie kann mehr Vermittlungsstufen, eine größere Anzahl von Vermittlungseingängen und mehr Quellen umfassen, die versuchen, an ein einziges Ziel zu senden. Ein mittelgroßer Incast könnte zu einem Unterschied von sechs Größenordnungen zwischen den zugewiesenen Bandbreiten der verschiedenen Quellen führen.
  • Das oben beschriebene Problem der Unfairness wird häufig dadurch verursacht, dass die von einem Switch implementierten Arbitrierungsrichtlinien auf den Eingangsports basieren. Das heißt, die Bandbreitendrosselung erfolgt mit einer Granularität pro Port. Im Gegensatz dazu kann ein Netzwerk durch die Erleichterung von Flusskanälen und die Implementierung von flussspezifischer Drosselung das Ausmaß an Unfairness zwischen verschiedenen Flüssen erheblich reduzieren. Wenn die Switches beispielsweise in dem in dargestellten Szenario eine faire Bandbreitenzuweisung pro Fluss implementieren, können alle acht Quellknoten einen im Wesentlichen gleichen Anteil an der Bandbreite der Randverbindung zwischen Switch 608 und Zielknoten L nutzen. Bei großen Systeminstallationen ist die Beherrschung der maximalen Latenzzeiten durch ein Netzwerk oft ein wichtiges Anliegen der Architekten. Oft kann dies nur erreicht werden, indem die Eingangsbandbreite in ein Netz auf einen kleinen Prozentsatz der Spitzenbandbreite begrenzt wird. Beispielsweise ist eine Begrenzung der Eingangsbandbreite auf 20 % der Spitzenbandbreite typisch für große Rechenzentren. Mit Flow Channels und geeigneten Kontrollmechanismen ist es dagegen jetzt möglich, ein Netz aufzubauen, das keine derartigen Beschränkungen auferlegt.
  • Neben der Fairness ist eine weitere Herausforderung für die Netzarchitekten die Überlastung. Im Allgemeinen können zwei Arten von Überlastungen in einem Netz auftreten. Bei der ersten Art handelt es sich um eine Überlastung des Endpunkts, bei der ein mit einem Zielgerät verbundener Egress-Edge-Link überlastet ist. Bei der zweiten Art handelt es sich um eine Überlastung der Fabric-Verbindung, bei der eine zwischengeschaltete Fabric-Verbindung überlastet ist.
  • zeigt ein Beispiel für eine Überlastung des Endpunkts. In diesem Beispiel senden zwei Quellhosts 612 und 614 Daten an einen Zielhost 616. Der Verkehr von den Quell-Hosts 612 und 614 konvergiert am Edge-Switch 620, und eine Egress-Edge-Verbindung 618 zwischen Switch 620 und Host 616 kann überlastet werden. Dieses Überlastungsszenario kann typischerweise bei Incast auftreten, wenn mehrere Quellen Datenverkehr an ein einziges Ziel senden. Eine Überlastung kann auftreten, wenn die Ausgangsrandverbindung ihre volle Datenübertragungskapazität erreicht oder wenn der Zielhost 616 nicht alle eingehenden Pakete mit ausreichender Geschwindigkeit verarbeiten kann. In jedem Fall kann der Ausgangsübertragungspuffer des Switches 620, der mit der Verbindung 618 gekoppelt ist, einen Anstieg der gespeicherten Datenmenge verzeichnen, wenn ein Stau am Endpunkt auftritt.
  • Ein Switch kann eine Überlastung des Endpunkts erkennen und abmildern, indem er den Ausgangspuffer auf einem Egress Edge Link überwacht und ACKs mit Überlastungsinformationen an Upstream-Switches und Quellknoten sendet. Genauer gesagt kann der mit einem Egress-Edge-Link verbundene Ausgangspuffer den Zustand des Puffers überwachen und eine Überlastung erkennen, wenn bestimmte Kriterien erfüllt sind. Wenn ein Paket bei einem Ausgangspuffer ankommt oder diesen verlässt, kann der Ausgangspuffer drei Parameter zur Stauerkennung berechnen, wie z. B.: (1) die Menge der im Puffer gespeicherten Daten, (2) die Anzahl der im Puffer gespeicherten Pakete und (3) die Änderungsrate der Puffertiefe (Menge der im Puffer gespeicherten Daten). Für diese drei überwachten Parameter können jeweils drei Schwellenwerte festgelegt werden, wobei auch mehr oder weniger festgelegt werden können. Eine Überlastung gilt als gegeben, wenn mindestens einer dieser Parameter den entsprechenden Schwellenwert überschreitet.
  • Wenn eine Überlastung festgestellt wird, kann der Switch eine Endpunkt-Überlastungsbenachrichtigung (ACK) für das Paket, das gerade in den Ausgangspuffer gelangt ist, generieren und übertragen. Die ACK kann einen Wert enthalten, der den Schweregrad der Überlastung angibt. Es ist zu beachten, dass diese Endpunkt-Stau-Benachrichtigung (ACK) nicht dazu gedacht ist, die vorgelagerten Vermittlungsstellen über die erfolgreiche Zustellung des Pakets zu informieren, sondern um sie über das Vorhandensein und den Grad des Staus an der Ausgangsverbindung zu informieren. (Wenn diese ACK-Benachrichtigung für den Endpunkt gesendet wird, befindet sich das Paket möglicherweise noch im Ausgangspuffer und wartet darauf, auf den Egress-Edge-Link übertragen zu werden). Dieser schnelle, explizite Staumelde-Mechanismus ermöglicht es den Vermittlungsstellen, schnell auf einen bestimmten Fluss zu reagieren, der zur Überlastung beiträgt.
  • Außerdem kann der Ausgangspuffer die Überlastungserkennungsparameter aktualisieren, wenn ein Paket aus der Warteschlange genommen und an den Egress Edge Link übertragen wird. Wenn keine Überlastung vorliegt, wird ein reguläres ACK generiert und gesendet, das alle früheren Überlastungsmeldungen löschen kann, die von den vorgelagerten Vermittlungsstellen für den entsprechenden Fluss empfangen wurden. Liegt ein Stau vor, kann das ACK mit einer Markierung versehen werden, die es ermöglicht, die Vermittlungsstellen über einen anhaltenden Stau auf dem Egress-Edge-Link sowie über die erfolgreiche Zustellung des Pakets zu informieren.
  • zeigt ein Flussdiagramm eines beispielhaften Prozesses der Erzeugung einer expliziten Endpunkt-Stau-Benachrichtigung ACK. Während des Betriebs kann das System den Ausgangspuffer eines Egress Edge Link kontinuierlich überwachen. Das System kann dann ein Paket am Ausgangspuffer empfangen (Vorgang 702). Nach Empfang des Pakets kann das System die drei Überlastungsparameter (Gesamtdatenmenge, Gesamtzahl der Pakete und Änderungsrate der Puffertiefe) für den Ausgangspuffer berechnen (Vorgang 704). Das System kann ferner feststellen, ob einer der Parameter einen entsprechenden Schwellenwert überschreitet (Vorgang 706). Wenn mindestens ein Parameter den Schwellenwert überschreitet, wird davon ausgegangen, dass eine Überlastung vorliegt. Dementsprechend kann das System ein explizites Endpunkt-Stau-Benachrichtigungs-ACK-Paket erzeugen und an die vorgelagerten Vermittlungsstellen senden, das dem Paketfluss entspricht (Vorgang 708). Wenn keine Überlastung festgestellt wird, kann das System zum Normalbetrieb zurückkehren.
  • zeigt einen beispielhaften Endpunkt-Stauverwaltungslogikblock. In diesem Beispiel kann ein Endpunkt-Überlastungsmanagement-Logikblock 730 einen Ausgangspuffer-Monitor 732, einen Logikblock 734 zur Berechnung von Überlastungsparametern und einen Logikblock 736 zur Erzeugung von ACKs für die Endpunkt-Überlastungsbenachrichtigung umfassen. Während des Betriebs kann der Ausgangspuffer-Monitor 732 den Zustand eines Ausgangspuffers überwachen, der mit einem Egress Edge Link verbunden ist. Basierend auf dem Zustand des überwachten Ausgangspuffers kann der Logikblock 734 zur Berechnung der Überlastungsparameter die drei Überlastungsparameter berechnen (siehe Vorgang 704 im Flussdiagramm in ). Wenn einer dieser Parameter den entsprechenden Schwellenwert überschreitet, kann der Logikblock 736 zur Erzeugung einer Endpunkt-Überlastungsbenachrichtigung (ACK) eine Endpunkt-Überlastungsbenachrichtigung (ACK) erzeugen und die ACK an den vorgelagerten Switch übertragen.
  • zeigt ein Flussdiagramm eines beispielhaften Prozesses zur Erzeugung einer ACK als Reaktion auf ein Paket, das aus der Warteschlange eines Ausgangspuffers entfernt wurde. In diesem Beispiel nimmt das System zunächst ein Paket aus der Warteschlange des Ausgangspuffers (Vorgang 802). Anschließend kann das System die drei Überlastungsparameter (Gesamtdatenmenge, Gesamtzahl der Pakete und Änderungsrate der Puffertiefe) für den Ausgangspuffer berechnen (Vorgang 804). Das System kann feststellen, ob einer der Parameter einen entsprechenden Schwellenwert überschreitet (Vorgang 806). Wenn mindestens ein Parameter den Schwellenwert überschreitet, wird davon ausgegangen, dass eine Überlastung vorliegt. Dementsprechend kann das System ein ACK-Paket mit einem markierten Flag erzeugen, das eine anhaltende Überlastung anzeigt (Vorgang 808). Wenn keine Überlastung festgestellt wird, kann das System ein reguläres ACK-Paket erzeugen (Vorgang 809). Das System kann anschließend das ACK-Paket an die vorgelagerten Vermittlungsstellen senden (Vorgang 810) und das Datenpaket aus der Warteschlange auf die Ausgangsrandverbindung übertragen (Vorgang 812).
  • Beachten Sie, dass der in gezeigte Endpunkt-Überlastungsmanagement-Logikblock auch die im Flussdiagramm in beschriebenen Operationen durchführen kann. Mit anderen Worten, der Logikblock 730 für das Endpunkt-Staumanagement kann potenziell allgemeine ACKs für die Endpunkt-Staumeldung beim Eintreffen eines Pakets im Ausgangspuffer sowie beim Verlassen des Pakets aus dem Ausgangspuffer ausgeben.
  • Wenn eine ACK-Benachrichtigung über eine Überlastung des Endpunkts die Fabric durchläuft, können die IFCTs der Switches entlang des Pfads Bandbreitenbeschränkungen auf den der ACK entsprechenden Fluss anwenden. Dadurch kann die Fabric die Zustellung dieses Datenflusses an jedem Switch entlang des Datenpfads auf verteilte Weise verlangsamen. Wenn ein Endpunkt-Stau-Benachrichtigungs-ACK einen IFCT passiert, kann sein Wert im Tabelleneintrag des Flusses als ep_congestion-Wert gespeichert werden, der zur Auswahl einer gewünschten maximalen Bandbreite für den Fluss verwendet werden kann. Jeder Wert von ep_congestion kann einen entsprechenden Satz von Hoch-, Ziel- und Abfall-Wasserzeichenwerten haben. Bei hoher Überlastung, wenn ep _congestion einen hohen Wert hat, können die Wasserzeichenwerte niedrigere Werte haben, so dass die Überlastung aggressiver gemildert werden kann. Bei geringer Überlastung, wenn ep _congestion einen niedrigen Wert hat, kann ein anderer Satz größerer Hoch-, Ziel- und Abwurf-Wasserzeichenwerte für eine höhere Durchsatzbandbreite verwendet werden. So kann beispielsweise eine Tabelle verwendet werden, die durch den ep_congestion-Wert indiziert ist. Für jeden ep _congestion-Wert kann die Tabelle einen entsprechenden Satz von Hoch-, Ziel- und Abwurf-Wasserzeichenwerten angeben. Die Einträge dieser Tabelle können im Voraus festgelegt werden, so dass die Vermittlungsstelle beim Empfang einer Endpunkt-Stau-Benachrichtigung (ACK) den ep _congestion-Wert verwenden kann, um in dieser Tabelle nachzuschlagen und die drei entsprechenden Wasserzeichenwerte auf den identifizierten Fluss anzuwenden.
  • Wenn die Quelle Daten auf gierige Weise einspeist, reicht es in manchen Fällen nicht aus, die Weiterleitung innerhalb des Netzwerks zu verlangsamen, um die Überlastung vollständig zu beseitigen. Um dieses Problem zu lösen, kann ein Ingress-Edge-Switch so konfiguriert werden, dass er das Quellgerät (das sich in der Regel außerhalb der Fabric befindet) anweist, die Dateneinspeisung auf einer feinkörnigen, flussbezogenen Basis zu begrenzen. Dieser Switch-to-Host-Flusskontrollmechanismus kann als Fine Gran Flow Control (FGFC) bezeichnet werden.
  • Insbesondere in einer HPC-Umgebung kann ein Endhost oder Rechenknoten über eine große Anzahl von Kernen verfügen, auf denen zahlreiche Threads, Prozesse oder virtuelle Maschinen ausgeführt werden, von denen jede ihren eigenen Datenstrom über einen gemeinsamen physischen Netzwerkschnittstellen-Controller (NIC) in das Netz einspeist. Wenn eine Überlastung vorliegt, kann eine portbasierte Flusskontrolle nur die Gesamtdatenrate über einen einzelnen Port der Netzwerkkarte drosseln, die 40 Gbit/s oder mehr betragen kann. Die Drosselung der Gesamtdatenrate auf dem gesamten Port kann zu einer unfairen Behandlung von Flüssen führen, die nicht zur Überlastung beitragen. FGFC kann das Konzept der einzelnen Ströme oder der Gruppe verbundener Ströme auf ihre ultimative Quelle ausweiten, die ein einzelner Thread sein kann, der auf einem der Kerne ausgeführt wird.
  • Um die Dateneinspeisung von der Quelle zu verlangsamen, kann ein FGFC-Logikblock an einem Eingangs-Edge-Switch (z. B. der FGFC-Logikblock 434 im Edge-Switch 406 in ) eine hybride Methode aus Pause und Kredit verwenden, um eingehende Daten zu drosseln, die einem bestimmten Fluss oder einer Gruppe von Flüssen zugeordnet sind. Bei einer pausenbasierten Methode gibt das empfangende Ende in der Regel einen Pausenbefehl an das sendende Ende aus, das daraufhin die Übertragung bis auf weiteres stoppen kann. Bei einer auf Guthaben basierenden Methode kann die empfangende Seite der sendenden Seite Übertragungsguthaben erteilen, die es der sendenden Seite ermöglichen, mehr Daten zu senden, jedoch nur bis zu der durch den Guthabenwert festgelegten Menge. Mit diesem Mechanismus kann die empfangende Seite die Tiefe des Eingangspuffers genauer steuern, um einen Überlauf zu vermeiden, während die Übertragung fortgesetzt werden kann. FGFC kann ein hybrides Verfahren verwenden, bei dem der Eingangs-Edge-Switch bei Erkennung einer Überlastung ein FGFC-Paket für einen oder mehrere Ströme mit einem festgelegten Zeitwert an die NIC des EndHosts (z. B. NIC 401 auf dem End-Host 402 in ) senden kann. Nach dem Empfang des FGFC-Pakets kann der Ingress-Edge-Switch einen kreditbasierten Flusskontrollmodus einschalten. Daraufhin kann der NIC die Übertragungsdatenrate für den/die entsprechenden Datenfluss/e auf der Grundlage des empfangenen Guthabens drosseln, während andere Datenflüsse mit der normalen Datenrate übertragen werden können. Nach Ablauf des vorbestimmten Zeitgebers kann der NIC des Endhosts für den/die gedrosselten Datenfluss/e zur normalen Übertragung zurückkehren, sofern kein weiterer Pausenbefehl empfangen wird. Ein gedrosselter Datenfluss kann durch ein beliebiges Feld aus einem Paket identifiziert werden. Ein gedrosselter Datenfluss kann sich auf einen einzelnen Prozess oder Thread beziehen, der auf dem Endhost ausgeführt wird.
  • FGFC kann die Steuerkommunikation zwischen einem Edge-Switch und einer End-Host-NIC unter Verwendung eines Ethernet-Frames mit einem um einen Organizationally Unique Identifier (OUI) erweiterten Ether_ Type-Feld implementieren. Diese Rahmen können eine oder mehrere der folgenden Angaben enthalten: (1) das Protokoll, das von dem zu kontrollierenden Datenfluss verwendet wird; (2) einen Identifikator, der die Quelle (z. B. Anwendung, Prozess oder Thread) angibt, die die zu drosselnden Pakete erzeugt; (3) einen Wert für die Pausenzeit, für die die Datenflusskontrolle gelten soll (was eine Blockierung verhindern kann, wenn nachfolgende FGFC-Frames aufgrund von Fehlern verloren gehen), und (4) einen Guthabenwert, der Null sein kann, um die Anzahl der Frames oder die Datenmenge anzugeben, die während der Pausenzeit gesendet werden können.
  • Beachten Sie, dass die Kennung zur Angabe des Quellflusses, der der Flusskontrolle unterliegt, je nach dem mit dem Fluss verbundenen Protokoll unterschiedlich sein kann. Beim Schicht-2-Ethernet-VLAN-Verkehr kann der Bezeichner die VLAN-Nummer enthalten. Beim IPv4-Verkehr kann der Bezeichner ein IP-Adressenpaar für Quelle und Ziel, ein UDP- oder TCP/IP-5-Tupel mit UDP- oder TCP-Portnummern oder ein optionales Flusslabel enthalten. Bei IPv6-Verkehr kann der Bezeichner eine oder mehrere IPv6-Adressen oder ein IPv6-Flow-Label enthalten. Bei proprietärem HPC-Protokollverkehr kann der Bezeichner eine Prozess- oder Thread-ID enthalten. Im Allgemeinen wird dieser Bezeichner auch in der EFCT des Edge-Switch gespeichert, da er verwendet wird, um den entsprechenden Verkehr einer Flusskennung zuzuordnen.
  • Um FGFC auszulösen, kann der IFCT eines Ingress Edge Switches seine flussspezifischen Eingangswarteschlangen überwachen. Für jede Warteschlange kann der entsprechende IFCT-Eintrag drei Wasserzeichenwerte angeben: Hoch, Ziel und Abwurf, die zur Messung der Warteschlangentiefe verwendet werden können. In einigen Beispielen können diese Wasserzeichenwerte als zusätzliche Felder in die IFCT aufgenommen werden, wie in gezeigt, oder sie können in einer separaten Tabelle gespeichert und durch ein Feld in der IFCT verknüpft werden. Wenn die Warteschlangentiefe unter dem Zielwert liegt, ist keine FGFC erforderlich. Wenn die Warteschlangentiefe den Zielwert für das Wasserzeichen erreicht, kann der IFCT mit einem FGFC-Logikblock kommunizieren, um FGFC mit dem NIC eines Endhosts zu initiieren. Wenn die Warteschlangentiefe unter den Wasserzeichenwert sinkt, kann die FGFC gestoppt und die normale Übertragung des Datenstroms wieder aufgenommen werden.
  • zeigt ein Flussdiagramm eines beispielhaften FGFC-Prozesses. Während des Betriebs kann das System an einem Eingangsrandschalter die flussspezifischen Eingangswarteschlangen überwachen (Vorgang 902). Das System kann außerdem für einen bestimmten Fluss feststellen, ob FGFC gerade eingeschaltet ist (Vorgang 904). Wenn FGFC für diese Bewegung eingeschaltet ist, kann das System feststellen, ob die Warteschlangentiefe unter der Drop-Watermark liegt (Operation 906). Wenn die Warteschlangentiefe nicht unter die Drop-Watermarke gesunken ist, kann das System die kreditbasierte Übertragung im FGFC-Modus fortsetzen (Vorgang 912). Wenn die Warteschlangentiefe unter die Drop-Watermarke gesunken ist, kann das System zur normalen Übertragung für den Fluss zurückkehren (Vorgang 914). Zurück zu Vorgang 904: Wenn FGFC derzeit nicht eingeschaltet ist, kann das System feststellen, ob die Warteschlangentiefe größer als die Zielwasserstandsmarke ist (Vorgang 908). Ist dies der Fall, kann das System FGFC für den Fluss einleiten (Vorgang 910). Der FGFC-Logikblock im Edge-Switch kann flussidentifizierende Informationen (z. B. VLAN-Tag, TCP/IP-5-Tupel, Thread-ID usw.) aus dem EFCT-Eintrag, der dem Fluss entspricht, abrufen und einen FGFC-Ethernet-Frame an die NIC auf dem Endhost senden. Anschließend kann das System mit der Überwachung der Eingangswarteschlangen fortfahren (Vorgang 902). Ist die Warteschlangentiefe nicht größer als das Zielwasserzeichen, kann das System die reguläre Datenübertragung fortsetzen (Vorgang 914)
  • Zur Erleichterung von FGFC kann ein NIC so konfiguriert werden, dass er den FGFC-Ethernet-Frame verarbeitet, so dass der NIC mit der Anwendung oder dem Prozess auf einem Endhost, der die Daten erzeugt, kommunizieren kann. Das Parsing des FGFC-Ethernet-Frames und die Kommunikation mit der Anwendung oder dem Prozess kann in Software, Hardware oder einer Kombination aus beidem erfolgen. zeigt ein Beispiel für eine FGFC-fähige NIC. In diesem Beispiel kann ein NIC 930 einen Prozessor 932, einen Speicher 934, einen Sender 936, einen Empfänger 938, einen FGFC-Logikblock 940 und einen Kommunikationslogikblock 942 umfassen. Während des Betriebs können der Sender 936 und der Empfänger 938 eine Kommunikation zu und von einem Flankenschalter über eine Flankenverbindung durchführen. Der Kommunikationslogikblock 942 kann über einen Datenbus (z. B. einen Peripheral Component Interconnect Express (PCIe)-Bus) mit der zentralen Verarbeitungseinheit des Endhosts kommunizieren, in dem sich die NIC 930 befindet. Der Prozessor 932 und der Speicher 934, die in der NIC 930 integriert sind, können die Daten lokal verarbeiten. Während des Betriebs kann der FGFC-Logikblock 940 mit einem Edge-Switch zusammenarbeiten, um FGFC auf einer Pro-Flow-Basis anzuwenden. Darüber hinaus kann der FGFC-Logikblock 940 über den Kommunikationslogikblock 942 mit der zentralen Verarbeitungseinheit des Endhosts kommunizieren, um die Dateneinspeisung einer einzelnen Anwendung oder eines einzelnen Prozesses zu drosseln, die bzw. der dem spezifischen, der FGFC unterliegenden Fluss entspricht, und so die Menge der in die Fabric eingespeisten Daten zu steuern.
  • Wie bereits erwähnt, können in einem Netz zwei Arten von Überlastungen auftreten. Die erste Art ist die Überlastung der Endpunkte und die zweite Art ist die Überlastung der Netzverbindung. zeigt ein Beispiel für eine Fabric-Link-Überlastung. In diesem Beispiel stehen zwei Zwischen-Switches 1002 und 1006 über eine Fabric-Verbindung 1004 in Verbindung. Mehrere Quell-/Zielpaare können Verkehr über die Fabric Link 1004 senden. Infolgedessen kann die Fabric-Verbindung 1004 überlastet sein, obwohl die Verbindungen, die zu und von der Fabric-Verbindung 1004 führen, möglicherweise nicht überlastet sind. Fabric Link 1004 kann als „Hot Spot“ erscheinen, wenn eine solche Überlastung auftritt.
  • Um eine Überlastung der Fabric-Links abzumildern, kann ein Switch eine dynamische kreditbasierte Flusskontrolle pro Fluss anwenden. Wenn sich in einem Switch eine Eingangswarteschlange zu füllen beginnt und der queue _extent-Wert für diesen Fluss einen vorbestimmten Schwellenwert erreicht, kann der Switch ein spezielles ACK erzeugen, um den IFCT des Upstream-Switches über die Überlastung zu informieren. Dieses spezielle ACK pro Hop kann als „HeadroomACK“ bezeichnet werden. Nach Erhalt des HeadroomACK kann das IFCT des Upstream-Switch eine kreditbasierte Flusskontrolle mit dem Downstream-Switch starten. Im Downstream-IFCT-Eintrag kann ein Flag Upstream Metering (UM) gesetzt werden, um anzuzeigen, dass die Datenübertragung vom Upstream-Switch nun auf der Grundlage der Credits gemessen wird. Das HeadroomACK-Paket kann auch einen Guthabenwert enthalten.
  • Wenn die vorgelagerte Vermittlungsstelle ein HeadroomACK empfängt, kann im entsprechenden Eintrag des IFCT ein Kennzeichen namens Downstream Metered (DM) gesetzt werden. Der IFCT kann auch ein signiertes Headroom-Feld im IFCT-Eintrag mit dem von der HeadroomACK übertragenen Credit-Wert speichern (d. h., der Headroom-Wert gibt die Anzahl der Credits an). Dieses Headroom-Feld kann die Datenmenge darstellen, die an den nachgeschalteten Switch weitergeleitet werden kann. Dadurch wird eine kreditbasierte Flusskontrolle für den entsprechenden Fluss eingerichtet. Wenn der vorgelagerte IFCT ein HeadroomACK empfängt, während das DM-Flag im Eintrag des Flusses bereits gesetzt ist, kann der im HeadroomACK enthaltene Kreditwert zum bestehenden Headroom-Wert addiert werden.
  • Neue Pakete, die vom vorgelagerten IFCT empfangen werden, können blockiert werden, wenn der Headroom-Wert nicht größer als Null ist (d. h. kein Guthaben verfügbar ist). Diese Pakete können die Eingangswarteschlange dieses Datenflusses Rillen und können wiederum dazu führen, dass der IFCT mit seinem vorgelagerten IFCT eine auf Guthaben basierende Datenflusskontrolle pro Datenfluss einleitet, usw. Wenn der Headroom-Wert größer als Null ist, kann ein in der Eingangswarteschlange gespeichertes Paket aus der Warteschlange genommen und an die nachgelagerte Vermittlungsstelle weitergeleitet werden, und der Headroom-Wert kann um die Größe des weitergeleiteten Pakets verringert werden, was dazu führen kann, dass der Headroom-Wert Null oder negativ wird.
  • Da der Datenfluss nicht mehr in der Lage ist, neue Pakete an den nachgelagerten IFCT zu senden, kann sich die Eingangswarteschlange des nachgelagerten IFCT in Abhängigkeit von der Überlastung des nachgelagerten IFCT mit einer gewissen Geschwindigkeit leeren. Wie oben beschrieben, kann die Eingangswarteschlange jedes Datenflusses drei Wasserzeichenwerte für die Warteschlangentiefe haben, nämlich „hoch“, „Ziel“ und „Abfall“, die für die kreditbasierte Datenflusskontrolle verwendet werden können. Das Ziel-Wasserzeichen kann annähernd die ideale Warteschlangentiefe für die gewünschte Flussbandbreite sein. Sie zeigt an, dass genügend Puffer für die Übertragung von Daten im Downstream vorhanden ist. Bei Überlastung kann der Mechanismus der kreditbasierten Flusssteuerung versuchen, den queue extent-Wert des Flusses annähernd bei dieser Zielwassermarke zu halten.
  • Liegt der queue _extent-Wert zwischen der High-Watermark und der Drop-Watermark und ist größer als die Target-Watermark, kann bei der Weiterleitung eines Pakets etwas weniger als die Kreditgröße dieses Pakets mit einem HeadroomACK an den Upstream-Switch zurückgegeben werden. Wenn der queue_extent-Wert die Ziel-Wassermarke nicht überschreitet, kann bei der Weiterleitung eines Pakets etwas mehr als die Kreditgröße dieses Pakets mit dem HeadroomACK an die vorgelagerte Vermittlungsstelle zurückgegeben werden.
  • Ist die queue extent depth größer als die High Watermark, wird bei der Weiterleitung von Paketen keine Gutschrift erteilt. Dieser Mechanismus kann den queue _extent-Wert schneller senken und wird in der Regel verwendet, wenn eine Überlastung zum ersten Mal festgestellt wird. Wenn sich der Stau auflöst, kann sich die Eingangswarteschlange des Datenstroms schneller leeren. Wenn die Warteschlangentiefe kleiner ist als die Drop-Watermark, kann die kreditbasierte Flusskontrolle abgeschaltet werden. Dazu wird das UM-Flag im IFCT-Eintrag gelöscht und ein HeadroomACK mit dem maximalen Credit-Wert an die vorgelagerte Vermittlungsstelle zurückgesendet. Wenn die HeadroomACK von der vorgelagerten IFCT empfangen wird, wird das DM-Flag des Eintrags gelöscht und die Flusskontrolle in Bezug auf den Headroom-Wert wird ausgeschaltet.
  • Beachten Sie, dass es in einer typischen Netztopologie eine Reihe von Switches geben kann und zwischen zwei Endpunkten mehrere Datenpfade bestehen können. In einem Netz mit mehreren Pfaden ist es möglich, verschiedene Methoden zur Kontrolle der Überlastung von Fabric Links einzusetzen. Zum Beispiel können die später in diesem Dokument beschriebenen Injektionsgrenzen die maximale Gesamtdatenmenge im gesamten Fabric kontrollieren. Das bedeutet, dass ein Datenfluss bei Überlastung einer bestimmten Fabric-Verbindung einen anderen Datenpfad verwenden kann, der nicht über die überlastete Verbindung führt. Es ist möglich, eine überlastete Verbindung zu erkennen und „Reroute“-ACKs für eine Reihe von Flüssen zu erzeugen. Die Reroute-ACKs können den Datenfluss in einem vorgelagerten Switch vorübergehend blockieren. Wenn alle ACKs für diesen Datenfluss zurückgegeben wurden, kann der Datenfluss wieder freigegeben werden und einen anderen Pfad über die Fabric nutzen. Ein dynamischer, lastbasierter, adaptiver Routing-Mechanismus kann dann das führende Paket auf einen anderen, nicht überlasteten Fabric-Link leiten. Dadurch kann die Last über die gesamte Fabric ausgeglichener werden.
  • zeigt ein Flussdiagramm eines Beispiels für die Anwendung einer kreditbasierten Flusskontrolle auf einer überlasteten Fabric-Verbindung. Während des Betriebs kann ein Vermittlungssystem seine flussspezifischen Eingangswarteschlangen überwachen (Vorgang 1102). Das System kann feststellen, ob ein Eintrag in seiner IFCT ein UM-Flag gesetzt hat (Vorgang 1104). Wenn das UM-Flag gesetzt ist, was bedeutet, dass die kreditbasierte Flusskontrolle eingeschaltet ist, kann das System ferner feststellen, ob der queue_extent-Wert kleiner als der drop watermark-Wert ist (Vorgang 1106). Wenn der queue _extent-Wert kleiner als der drop watermark-Wert ist, kann das System das UM-Flag löschen, die kreditbasierte Flusskontrolle ausschalten und die normale Datenübertragung wieder aufnehmen (Vorgang 1014). Wenn der queue_extent-Wert größer ist als der drop watermark-Wert, kann das System die kreditbasierte Flusskontrolle fortsetzen (Vorgang 1106). Zurück zu Vorgang 1104: Wenn das UM-Flag nicht gesetzt ist, was bedeutet, dass sich das System im regulären Übertragungsmodus befindet, kann das System feststellen, ob der queue_extent-Wert größer ist als der target watermark-Wert (Vorgang 1108). Ist dies der Fall, kann das System eine kreditbasierte Flusskontrolle einleiten und eine HeadroomACK an die vorgelagerte Vermittlungsstelle senden (Vorgang 1110). Ist der queue _extent-Wert nicht größer als der Zielwasserzeichenwert, kann das System mit der regulären Datenübertragung fortfahren (Vorgang 1112).
  • Im Allgemeinen kann ein Flow-Channel-Switch eine Kombination aus mehreren Überlastungserkennungs- und Kontrollmechanismen verwenden. Beispielsweise können verschiedene Grade der Endpunktüberlastung mit Hilfe des ACKs „endpoint-congestionnotification“ gemeldet werden, das vom endgültigen Fabric-Egress-Edge-Port zurückgegeben werden kann. Dieser ACK-Typ kann verwendet werden, um die Bandbreite von Flüssen in einen stark überlasteten Egress-Edge-Port zu verwalten. Das System kann auch eine auf Guthaben basierende Flusssteuerung pro Hop verwenden, um eine Überlastung der Fabric-Verbindung zu verwalten. Dieser Per-Hop-Überlastungsmanagement-Mechanismus kann bei geringer bis mittlerer Überlastung wirksam sein, da die Reaktionszeit viel kürzer sein kann als die netzweite Round-Trip-Verzögerung.
  • Wenn die Überlastung schwerwiegend ist, z. B. durch einen großen Incast, kann das System auch ein Limit für die Injektion pro Fluss anwenden. Das Injektionslimit eines Flusses kann auf der Grundlage des ep_congestion-Wertes bestimmt werden. Die Injektionsgrenze kann mit dem tlow_extent-Wert in allen IFCTs verglichen werden, die der Fluss durchläuft. Ist der tlow_extent-Wert größer als dieser Grenzwert, kann die IFCT die Weiterleitung von Paketen aus der Eingangswarteschlange für diesen Fluss blockieren. Dieser Mechanismus kann die Weiterleitungsrate von Paketen über einen gesamten Fluss auf ein einziges Paket reduzieren.
  • Das System kann auch nicht zusammenhängenden Verkehr vor extremen Überlastungen schützen, die durch Überschneidungen mit einer großen Anzahl von Teilnehmern verursacht werden. In diesem Fall kann der ep_congestion-Wert auf einen hohen Wert gesetzt und die durchschnittliche Datenmenge eines Flusses auf einen kleinen Bruchteil eines Pakets reduziert werden. Dies kann dadurch erreicht werden, dass das nächste Paket eines einzelnen Datenflusses erst dann vom IFCT des Eingangs-Edge-Ports in die Fabric freigegeben wird, wenn eine programmierbare Verzögerung seit dem Empfang des ACK des vorherigen Pakets verstrichen ist.
  • Zusätzlich zu den Grenzwerten für die Injektion pro Fluss kann das System die Datenmenge messen, die pro Ingress-Port in die Fabric eingespeist wurde, und Grenzwerte für die Injektion festlegen, um eine Obergrenze für die Gesamtdatenmenge festzulegen, die ein Port in die Fabric einspeisen kann. Da jeder Eingangsport dieses Injektionslimit anwenden kann, kann das System die maximal zulässige Datenmenge innerhalb der Fabric kontrollieren. Durch die Begrenzung der Gesamtdatenmenge, die in die Fabric eingespeist wird, kann sichergestellt werden, dass bei knapper Bandbreite keine Puffererschöpfung eintritt. Dadurch wird der Verkehr, der nicht die Pfade mit reduzierter Bandbreite nutzt, nicht beeinträchtigt.
  • Um die Begrenzung der Einspeisung pro Port zu erleichtern, kann ein IFCT eine Gesamtzahl des Datenverkehrs verwalten. Jedes Mal, wenn ein Paket vom Edge-Port in die Fabric eingespeist wird, kann die Gesamtzahl erhöht werden. Wenn das ACK eines Datenflusses zurückgegeben wird, kann die Gesamtzahl des Datenverkehrs verringert werden. Sobald alle ACKs aller Ströme eines Eingangsports zurückgegeben wurden (d. h. wenn die Summe der tlow_extent-Werte für alle Ströme Null wird), kann die Gesamtverkehrszahl auf Null gesetzt werden.
  • zeigt ein beispielhaftes Edge-Switching-System, das Flusskanäle ermöglicht (was z. B. dem Schalter 406 in entsprechen kann). In diesem Beispiel kann ein Schalter 1202 eine Reihe von Kommunikationsanschlüssen, wie z. B. Anschluss 1220, umfassen. Jeder Anschluss kann einen Sender und einen Empfänger enthalten. Der Schalter 1202 kann auch einen Prozessor 1204, eine Speichervorrichtung 1206 und einen Logikblock 1208 zur Flusskanalumschaltung enthalten. Das Flusskanalvermittlungsmodul 1208 kann mit allen Kommunikationsanschlüssen gekoppelt werden und kann außerdem einen Kreuzschienenschalter 1210, einen EFCT-Logikblock 1212, einen IFCT-Logikblock 1214 und einen OFCT-Logikblock 1216 umfassen.
  • Crossbar-Switch 1210 kann einen oder mehrere Crossbar-Switch-Chips enthalten, die so konfiguriert werden können, dass sie Datenpakete und Steuerpakete (wie ACK-Pakete) zwischen den Kommunikationsanschlüssen weiterleiten. Der EFCT-Logikblock 1212 kann von einem Edge-Link empfangene Pakete verarbeiten und die empfangenen Pakete auf der Grundlage eines oder mehrerer Header-Felder in den Paketen entsprechenden Flüssen zuordnen. Darüber hinaus kann der EFCT-Logikblock 1212 FGFC-Ethernet-Frames zusammenstellen, die an einen Endhost übermittelt werden können, um die von einzelnen Prozessen oder Threads eingespeiste Datenmenge zu steuern. Der IFCT-Logikblock 1214 kann den IFCT enthalten und verschiedene Flusssteuerungsmethoden als Reaktion auf Steuerpakete durchführen, wie z. B. ACKs zur Endpunkt-Stau-Benachrichtigung und auf Fabric-Link-Credits basierende Flusssteuerungs-ACKs. Der OFCT-Logikblock 1216 kann eine Speichereinheit enthalten, die die OFCT speichert und mit dem IFCT-Logikblock eines anderen Switches kommuniziert, um die Fluss-ID eines Pakets zu aktualisieren, wenn das Paket an einen Next-Hop-Switch weitergeleitet wird.
  • zeigt ein beispielhaftes Vermittlungssystem, das Flusskanäle ermöglicht (die beispielsweise den Schaltern 408 und 430 in entsprechen können). In diesem Beispiel kann ein Schalter 1302 eine Reihe von Kommunikationsanschlüssen, wie z. B. Anschluss 1320, umfassen. Jeder Anschluss kann einen Sender und einen Empfänger enthalten. Der Schalter 1302 kann auch einen Prozessor 1304, eine Speichervorrichtung 1306 und einen Logikblock 1308 zur Flusskanalumschaltung enthalten. Das Flusskanalvermittlungsmodul 1308 kann mit allen Kommunikationsanschlüssen gekoppelt werden und kann außerdem einen Kreuzschienenschalter 1310, einen EFCT-Logikblock 1312, einen IFCT-Logikblock 1314 und einen OFCT-Logikblock 1316 umfassen.
  • Crossbar-Switch 1310 kann einen oder mehrere Crossbar-Switch-Chips enthalten, die so konfiguriert werden können, dass sie Datenpakete und Steuerpakete (wie ACK-Pakete) zwischen den Kommunikationsanschlüssen weiterleiten. Der EFCT-Logikblock 1312 kann von einem Edge-Link empfangene Pakete verarbeiten und die empfangenen Pakete auf der Grundlage eines oder mehrerer Header-Felder in den Paketen entsprechenden Flüssen zuordnen. Darüber hinaus kann der EFCT-Logikblock 1312 FGFC-Ethernet-Frames zusammenstellen, die an einen Endhost übermittelt werden können, um die von einzelnen Prozessen oder Threads eingespeiste Datenmenge zu steuern. Der IFCT-Logikblock 1314 kann den IFCT enthalten und verschiedene Flusssteuerungsmethoden als Reaktion auf Steuerpakete durchführen, wie z. B. ACKs zur Endpunkt-Stau-Benachrichtigung und auf Fabric-Link-Credits basierende Flusssteuerungs-ACKs. Der OFCT-Logikblock 1316 kann eine Speichereinheit enthalten, die die OFCT speichert und mit dem IFCT-Logikblock eines anderen Switches kommuniziert, um die Fluss-ID eines Pakets zu aktualisieren, wenn das Paket an einen Next-Hop-Switch weitergeleitet wird.
  • Zusammenfassend beschreibt die vorliegende Offenlegung Systeme und Verfahren, die die Fairness bei Netzwerkausgängen erleichtern können. Insbesondere kann ein Switch die Weiterleitung empfangener Pakete auf der Grundlage ihrer Verkehrsklasse planen und bei der Planung der Paketübertragung eine faire Arbitrierung durchführen. Shaping-Warteschlangen können verwendet werden, um die gewünschte Bandbreitenzuweisung zwischen verschiedenen Verkehrsklassen und virtuellen Kanälen zu erreichen.
  • Die oben beschriebenen Methoden und Prozesse können von Hardware-Logikblöcken, Modulen oder Geräten ausgeführt werden. Zu den Hardware-Logikblöcken, - Modulen oder -Vorrichtungen können unter anderem anwendungsspezifische integrierte Schaltungen (ASIC), feldprogrammierbare Gate-Arrays (FPGAs), dedizierte oder gemeinsam genutzte Prozessoren, die einen Code zu einem bestimmten Zeitpunkt ausführen, und andere bekannte oder später entwickelte programmierbare Logikgeräte gehören. Wenn die Hardware-Logikblöcke, -Module oder -Geräte aktiviert werden, führen sie die darin enthaltenen Methoden und Prozesse aus.
  • Die hier beschriebenen Methoden und Prozesse können auch als Code oder Daten verkörpert werden, die in einem Speichergerät oder computerlesbaren Speichermedium gespeichert werden können. Wenn ein Prozessor den gespeicherten Code oder die Daten liest und ausführt, kann der Prozessor diese Methoden und Prozesse durchführen.
  • Die vorstehenden Beschreibungen von Ausführungsformen der vorliegenden Erfindung wurden nur zur Veranschaulichung und Beschreibung vorgelegt. Sie erheben keinen Anspruch auf Vollständigkeit und beschränken die vorliegende Erfindung nicht auf die dargestellten Formen. Dementsprechend werden viele Modifikationen und Variationen für den Fachmann auf dem Gebiet der Technik offensichtlich sein. Außerdem soll die vorliegende Erfindung durch die obige Offenbarung nicht eingeschränkt werden. Der Umfang der vorliegenden Erfindung wird durch die beigefügten Ansprüche definiert.

Claims (21)

  1. Vermittlungsstelle, die Folgendes umfasst: einen Eingangspuffer zum Speichern empfangener Pakete; einen Ausgangspuffer zum Speichern von über einen Ausgangsanschluss zu übertragenden Paketen; einen Satz von Alterswarteschlangen zum Speichern interner Anforderungen für die Weiterleitung empfangener Pakete vom Eingangspuffer zum Ausgangspuffer; und einen Scheduler-Logikblock, der mit den Alterswarteschlangen gekoppelt ist und unter Verwendung eines Satzes von Formungswarteschlangen eine Verkehrsformung für die in den Alterswarteschlangen gespeicherten Anforderungen durchführt, wodurch die Arbitrierung der Bandbreite unter den Paketen erleichtert wird, während eine Ausgangsgerechtigkeit bereitgestellt wird.
  2. Vermittlungsstelle nach Anspruch 1, wobei der Scheduler-Logikblock während der Durchführung des Traffic Shaping ferner eine Shaping-Warteschlange für ein Paket auf der Grundlage eines Fabric-Tags und einer virtuellen Netzwerkkennung, die dem Paket zugeordnet sind, bestimmt; wobei das Fabric-Tag einer Verkehrsklasse für das Paket entspricht; und wobei die virtuelle Netzwerkkennung einer logischen Partition eines Netzwerks entspricht, mit dem der Switch verbunden ist.
  3. Vermittlungsstelle nach Anspruch 1, wobei der Scheduler-Logikblock während der Durchführung des Traffic Shaping eine Arbitrierung zwischen den Shaping-Warteschlangen unter Verwendung einer Reihe von Token-Buckets durchführt, die in drei Ebenen angeordnet sind, die einen oder mehrere Leaf-Buckets, einen oder mehrere Branch-Buckets und einen Head-Bucket umfassen; wobei jede Shaping-Warteschlange einem Leaf-Bucket entspricht; und wobei die Token-Buckets verwendet werden, um eine zugesicherte Bandbreite, eine Höchstbandbreite und eine Priorität für jede Shaping-Warteschlange zu bestimmen.
  4. Vermittlungsstelle nach Anspruch 3, wobei der Scheduler-Logikblock während der Durchführung der Arbitrierung ferner: die Arbitrierung in drei Gruppen mit hoher, mittlerer bzw. niedriger Priorität unterteilt; für die Gruppe mit hoher Priorität und die Gruppe mit mittlerer Priorität eine Round-Robin-Arbitrierung zwischen Shaping-Warteschlangen innerhalb jeder Prioritätsstufe und eine feste Arbitrierung zwischen Prioritätsstufen durchführt; und für die Gruppe mit niedriger Priorität eine Round-Robin-Arbitrierung zwischen Shaping-Warteschlangen durchführt.
  5. Vermittlungsstelle nach Anspruch 4, wobei eine Bedingung dafür, dass eine entsprechende Shaping-Warteschlange in die Gruppe mit hoher Priorität aufgenommen wird, Folgendes umfasst: ein entsprechender Leaf-Bucket hat sowohl zugesicherte als auch maximale Bandbreite zur Verfügung; ein entsprechender Branch-Bucket über eine zugesicherte und eine Ceiling-Bandbreite verfügt; und der Head-Bucket über eine verfügbare Plafond-Bandbreite verfügt; wobei eine Bedingung dafür, dass eine jeweilige Shaping-Queue in der Gruppe mittlerer Priorität enthalten ist, Folgendes umfasst: ein entsprechender Blatt-Bucket hat eine verfügbare Höchstbandbreite; ein entsprechender Branch-Bucket eine gesicherte und eine Ceiling-Bandbreite zur Verfügung hat; und der Head-Bucket über eine verfügbare Plafond-Bandbreite verfügt; und wobei eine Bedingung dafür, dass eine entsprechende Shaping-Warteschlange in der Gruppe mit niedriger Priorität enthalten ist, Folgendes umfasst: ein entsprechender Leaf-Bucket hat eine verfügbare Plafond-Bandbreite; ein entsprechender Zweigbereich über eine verfügbare Höchstbandbreite verfügt; und der Head-Bucket über eine verfügbare Höchstbandbreite verfügt.
  6. Vermittlungsstelle nach Anspruch 1, wobei eine entsprechende Shaping-Warteschlange Pakete aufnehmen kann, die zu einem Satz virtueller Kanäle gehören, die verwendet werden können, um Netzwerk-Sackgassen zu vermeiden oder eine Verkehrstrennung unter Verwendung virtueller Netzwerkkennungen bereitzustellen.
  7. Vermittlungsstelle nach Anspruch 6, wobei der Scheduler-Logikblock während der Durchführung des Traffic Shaping weiterhin eine Deficit-Round-Robin-Arbitrierung zwischen VCs durchführt, die einer entsprechenden Shaping-Warteschlange zugeordnet sind.
  8. Verfahren, das Folgendes umfasst: Speichern von empfangenen Paketen in einem Eingangspuffer; Speichern von Paketen, die über einen Ausgangsanschluss übertragen werden sollen, in einem Ausgangspuffer. Speichern interner Anforderungen zum Weiterleiten empfangener Pakete von dem Eingangspuffer zu dem Ausgangspuffer in einem Satz von Alterswarteschlangen; und Durchführen einer Verkehrsformung für die in den Alterswarteschlangen gespeicherten Anforderungen unter Verwendung eines Satzes von Formungswarteschlangen, wodurch eine Aufteilung der Bandbreite zwischen den Paketen erleichtert wird, während eine Ausgangsgerechtigkeit bereitgestellt wird.
  9. Verfahren nach Anspruch 8, wobei die Durchführung von Traffic Shaping das Bestimmen einer Shaping-Warteschlange für ein Paket auf der Grundlage eines Fabric-Tags und einer virtuellen Netzwerkkennung, die dem Paket zugeordnet sind, umfasst; wobei das Fabric-Tag einer Verkehrsklasse für das Paket entspricht; und wobei die virtuelle Netzwerkkennung einer logischen Partition eines Netzwerks entspricht, mit dem der Switch verbunden ist.
  10. Verfahren nach Anspruch 8, wobei während der Durchführung der Verkehrsformung eine Arbitrierung zwischen den Formungswarteschlangen unter Verwendung einer Reihe von Token-Buckets durchgeführt wird, die in drei Ebenen angeordnet sind, welche einen oder mehrere Blatt-Buckets, einen oder mehrere BrSTOREanch-Buckets und einen Head-Bucket umfassen; wobei jede Formungswarteschlange einem Blatt-Bucket entspricht; und wobei die Token-Buckets verwendet werden, um eine zugesicherte Bandbreite, eine Höchstbandbreite und eine Priorität für jede Formungswarteschlange zu bestimmen.
  11. Verfahren nach Anspruch 10, wobei die Durchführung der Arbitrierung Folgendes umfasst: Aufteilen der Arbitrierung in drei Gruppen mit hoher, mittlerer bzw. niedriger Priorität; für die Gruppe mit hoher Priorität und die Gruppe mit mittlerer Priorität, Durchführen einer Round-Robin-Arbitrierung zwischen Shaping-Warteschlangen innerhalb jeder Prioritätsstufe und Durchführen einer festen Arbitrierung zwischen Prioritätsstufen; und für die Gruppe mit niedriger Priorität, Durchführen einer Round-Robin-Arbitrierung zwischen Shaping-Warteschlangen.
  12. Verfahren nach Anspruch 10, wobei eine Bedingung dafür, dass eine entsprechende Shaping-Warteschlange in die Gruppe mit hoher Priorität aufgenommen wird, Folgendes umfasst: eine entsprechende Blatt-Warteschlange hat sowohl gesicherte als auch maximale Bandbreite zur Verfügung; ein entsprechender Branch-Bucket sowohl eine zugesicherte als auch eine Ceiling-Bandbreite zur Verfügung hat; und der Head-Bucket über eine verfügbare Plafond-Bandbreite verfügt; wobei eine Bedingung dafür, dass eine jeweilige Shaping-Queue in der Gruppe mittlerer Priorität enthalten ist, Folgendes umfasst: ein entsprechender Blatt-Bucket hat eine verfügbare Höchstbandbreite; ein entsprechender Branch-Bucket eine zugesicherte und eine Ceiling-Bandbreite zur Verfügung hat; und der Head-Bucket über eine verfügbare Plafond-Bandbreite verfügt; und wobei eine Bedingung dafür, dass eine entsprechende Shaping-Queue in der Gruppe mit niedriger Priorität enthalten ist, Folgendes umfasst: ein entsprechender Leaf-Bucket hat eine verfügbare Plafond-Bandbreite; ein entsprechender Zweigbereich über eine verfügbare Höchstbandbreite verfügt; und der Head-Bucket über eine verfügbare Höchstbandbreite verfügt.
  13. Verfahren nach Anspruch 8, wobei eine entsprechende Shaping-Warteschlange Pakete aufnehmen kann, die zu einem Satz virtueller Kanäle gehören, die verwendet werden können, um Netzsperren zu vermeiden oder eine Verkehrstrennung unter Verwendung virtueller Netzkennungen bereitzustellen.
  14. Verfahren nach Anspruch 13, wobei die Durchführung von Traffic Shaping die Durchführung von Deficit-Round-Robin-Arbitration zwischen VCs umfasst, die mit einer jeweiligen Shaping-Warteschlange verbunden sind.
  15. Netzwerksystem, das Folgendes umfasst: eine Anzahl miteinander verbundener Switches, wobei ein jeweiliger Switch Folgendes umfasst: einen Eingangspuffer zum Speichern empfangener Pakete; einen Ausgangspuffer zum Speichern von über einen Ausgangsanschluss zu übertragenden Paketen; einen Satz von Alterswarteschlangen zum Speichern interner Anforderungen zum Weiterleiten empfangener Pakete vom Eingangspuffer zum Ausgangspuffer; und einen Scheduler-Logikblock, der mit den Alterswarteschlangen gekoppelt ist und zum Durchführen einer Verkehrsformung für die in den Alterswarteschlangen gespeicherten Anforderungen unter Verwendung eines Satzes von Formungswarteschlangen dient, wodurch die Aufteilung der Bandbreite unter den Paketen erleichtert wird, während eine Ausgangsgerechtigkeit bereitgestellt wird.
  16. Netzwerksystem nach Anspruch 15, wobei der Scheduler-Logikblock während der Durchführung der Verkehrsformung ferner eine Formungswarteschlange für ein Paket auf der Grundlage eines Fabric-Tags und einer virtuellen Netzwerkkennung, die dem Paket zugeordnet sind, bestimmt; wobei das Fabric-Tag einer Verkehrsklasse für das Paket entspricht; und wobei die virtuelle Netzwerkkennung einer logischen Partition eines Netzwerks entspricht, mit dem der Switch verbunden ist.
  17. Netzwerksystem nach Anspruch 15, wobei der Scheduler-Logikblock während der Durchführung des Traffic Shaping eine Arbitrierung zwischen den Shaping-Warteschlangen unter Verwendung einer Reihe von Token-Buckets durchführt, die in drei Ebenen angeordnet sind, die einen oder mehrere Leaf-Buckets, einen oder mehrere Branch-Buckets und einen Head-Bucket umfassen; wobei jede Shaping-Warteschlange einem Leaf-Bucket entspricht; und wobei die Token-Buckets verwendet werden, um eine zugesicherte Bandbreite, eine Höchstbandbreite und eine Priorität für jede Shaping-Warteschlange zu bestimmen.
  18. Netzwerksystem nach Anspruch 17, wobei der Scheduler-Logikblock während der Durchführung der Arbitrierung ferner: die Arbitrierung in drei Gruppen mit hoher, mittlerer bzw. niedriger Priorität unterteilt; für die Gruppe mit hoher Priorität und die Gruppe mit mittlerer Priorität eine Round-Robin-Arbitrierung zwischen Shaping-Warteschlangen innerhalb jeder Prioritätsstufe und eine feste Arbitrierung zwischen Prioritätsstufen durchführt; und für die Gruppe mit niedriger Priorität eine Round-Robin-Arbitrierung zwischen Shaping-Warteschlangen durchführt.
  19. Netzwerksystem nach Anspruch 18, wobei eine Bedingung dafür, dass eine entsprechende Shaping-Warteschlange in die Gruppe mit hoher Priorität aufgenommen wird, Folgendes umfasst: ein entsprechender Blatt-Bucket hat sowohl zugesicherte als auch maximale Bandbreite verfügbar; ein entsprechender Branch-Bucket sowohl eine zugesicherte als auch eine Ceiling-Bandbreite zur Verfügung hat; und der Head-Bucket über eine verfügbare Plafond-Bandbreite verfügt; wobei eine Bedingung dafür, dass eine jeweilige Shaping-Queue in der Gruppe mittlerer Priorität enthalten ist, Folgendes umfasst: ein entsprechender Blatt-Bucket hat eine verfügbare Höchstbandbreite; ein entsprechender Branch-Bucket eine zugesicherte und eine Ceiling-Bandbreite zur Verfügung hat; und der Head-Bucket über eine verfügbare Plafond-Bandbreite verfügt; und wobei eine Bedingung dafür, dass eine entsprechende Shaping-Warteschlange in der Gruppe mit niedriger Priorität enthalten ist, Folgendes umfasst: ein entsprechender Leaf-Bucket hat eine verfügbare Plafond-Bandbreite; ein entsprechender Zweigbereich über eine verfügbare Höchstbandbreite verfügt; und der Head-Bucket über eine verfügbare Höchstbandbreite verfügt.
  20. Netzwerksystem nach Anspruch 15, wobei eine entsprechende Shaping-Warteschlange Pakete aufnehmen kann, die zu einem Satz virtueller Kanäle gehören, die verwendet werden können, um Netzwerk-Sackgassen zu vermeiden oder eine Verkehrstrennung unter Verwendung virtueller Netzwerkkennungen bereitzustellen.
  21. Netzwerksystem nach Anspruch 20, wobei der Scheduler-Logikblock während der Durchführung des Traffic Shaping weiterhin eine Deficit-Round-Robin-Arbitrierung zwischen VCs durchführt, die mit einer entsprechenden Shaping-Warteschlange verbunden sind.
DE112020002490.3T 2019-05-23 2020-03-23 Verfahren und system zur gewährleistung der fairness beim netzaustritt zwischen anwendungen Pending DE112020002490T5 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201962852203P 2019-05-23 2019-05-23
US201962852273P 2019-05-23 2019-05-23
US201962852289P 2019-05-23 2019-05-23
US62/852,273 2019-05-23
US62/852,203 2019-05-23
US62/852,289 2019-05-23
PCT/US2020/024237 WO2020236266A1 (en) 2019-05-23 2020-03-23 Method and system for providing network egress fairness between applications

Publications (1)

Publication Number Publication Date
DE112020002490T5 true DE112020002490T5 (de) 2022-04-28

Family

ID=73458112

Family Applications (18)

Application Number Title Priority Date Filing Date
DE112020002509.8T Pending DE112020002509T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der effizienten paketinjektion in einen ausgangspuffer in einer netzwerkschnittstellensteuerung (nic)
DE112020002493.8T Pending DE112020002493T5 (de) 2019-05-23 2020-03-23 Fat-tree adaptive leitweglenkung
DE112020002481.4T Pending DE112020002481T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der selbststeuerung von reduktionsmotoren
DE112020002494.6T Pending DE112020002494T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung von tracer-paketen in einem datengesteuerten intelligenten netz
DE112020002490.3T Pending DE112020002490T5 (de) 2019-05-23 2020-03-23 Verfahren und system zur gewährleistung der fairness beim netzaustritt zwischen anwendungen
DE112020002510.1T Pending DE112020002510T5 (de) 2019-05-23 2020-03-23 Verfahren und system zur gewährleistung von fairness zwischen anwendungen beim netzeintritt
DE112020002500.4T Pending DE112020002500T5 (de) 2019-05-23 2020-03-23 System und verfahren zur durchführung einer fliegenden reduktion in einem netz
DE112020002498.9T Pending DE112020002498T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung einer effizienten paketweiterleitung in einer netzwerkschnittstellensteuerung (nic)
DE112020002512.8T Pending DE112020002512T5 (de) 2019-05-23 2020-03-23 Systeme und verfahren zur verkehrsklassenbezogenen leitweglenkung
DE112020002491.1T Pending DE112020002491T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der dynamischen befehlsverwaltung in einer netzwerkschnittstellensteuerung (nic)
DE112020002499.7T Pending DE112020002499T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines datengesteuerten intelligenten netzes mit kreditbasierter flusskontrolle pro fluss
DE112020002528.4T Pending DE112020002528T5 (de) 2019-05-23 2020-03-23 Algorithmen für die verwendung von lastinformationen von benachbarten knoten bei der adaptiven leitweglenkung
DE112020002501.2T Pending DE112020002501T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines effizienten lastausgleichs in einer netzwerkschnittstellensteuerung (nic)
DE112020002497.0T Pending DE112020002497T5 (de) 2019-05-23 2020-03-23 System und verfahren zur dynamischen zuweisung von reduktionsmotoren
DE112020002484.9T Pending DE112020002484T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der feinkörnigen flusssteuerung in einer netzwerkschnittstellensteuerung (nic)
DE112020002754.6T Pending DE112020002754T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines effizienten nachrichtenabgleichs in einer netzwerkschnittstellensteuerung (nic)
DE112020002496.2T Pending DE112020002496T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines effizienten host-speicherzugriffs von einer netzwerkschnittstellensteuerung (nic)
DE112020002495.4T Pending DE112020002495T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der betriebsverwaltung in einer netzwerkschnittstellensteuerung (nic) für beschleuniger

Family Applications Before (4)

Application Number Title Priority Date Filing Date
DE112020002509.8T Pending DE112020002509T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der effizienten paketinjektion in einen ausgangspuffer in einer netzwerkschnittstellensteuerung (nic)
DE112020002493.8T Pending DE112020002493T5 (de) 2019-05-23 2020-03-23 Fat-tree adaptive leitweglenkung
DE112020002481.4T Pending DE112020002481T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der selbststeuerung von reduktionsmotoren
DE112020002494.6T Pending DE112020002494T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung von tracer-paketen in einem datengesteuerten intelligenten netz

Family Applications After (13)

Application Number Title Priority Date Filing Date
DE112020002510.1T Pending DE112020002510T5 (de) 2019-05-23 2020-03-23 Verfahren und system zur gewährleistung von fairness zwischen anwendungen beim netzeintritt
DE112020002500.4T Pending DE112020002500T5 (de) 2019-05-23 2020-03-23 System und verfahren zur durchführung einer fliegenden reduktion in einem netz
DE112020002498.9T Pending DE112020002498T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung einer effizienten paketweiterleitung in einer netzwerkschnittstellensteuerung (nic)
DE112020002512.8T Pending DE112020002512T5 (de) 2019-05-23 2020-03-23 Systeme und verfahren zur verkehrsklassenbezogenen leitweglenkung
DE112020002491.1T Pending DE112020002491T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der dynamischen befehlsverwaltung in einer netzwerkschnittstellensteuerung (nic)
DE112020002499.7T Pending DE112020002499T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines datengesteuerten intelligenten netzes mit kreditbasierter flusskontrolle pro fluss
DE112020002528.4T Pending DE112020002528T5 (de) 2019-05-23 2020-03-23 Algorithmen für die verwendung von lastinformationen von benachbarten knoten bei der adaptiven leitweglenkung
DE112020002501.2T Pending DE112020002501T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines effizienten lastausgleichs in einer netzwerkschnittstellensteuerung (nic)
DE112020002497.0T Pending DE112020002497T5 (de) 2019-05-23 2020-03-23 System und verfahren zur dynamischen zuweisung von reduktionsmotoren
DE112020002484.9T Pending DE112020002484T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der feinkörnigen flusssteuerung in einer netzwerkschnittstellensteuerung (nic)
DE112020002754.6T Pending DE112020002754T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines effizienten nachrichtenabgleichs in einer netzwerkschnittstellensteuerung (nic)
DE112020002496.2T Pending DE112020002496T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung eines effizienten host-speicherzugriffs von einer netzwerkschnittstellensteuerung (nic)
DE112020002495.4T Pending DE112020002495T5 (de) 2019-05-23 2020-03-23 System und verfahren zur erleichterung der betriebsverwaltung in einer netzwerkschnittstellensteuerung (nic) für beschleuniger

Country Status (5)

Country Link
US (53) US11968116B2 (de)
EP (11) EP3942749A4 (de)
CN (29) CN113728598A (de)
DE (18) DE112020002509T5 (de)
WO (43) WO2020236298A1 (de)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11108704B2 (en) 2018-12-04 2021-08-31 Nvidia Corp. Use of stashing buffers to improve the efficiency of crossbar switches
EP3942749A4 (de) 2019-05-23 2023-06-07 Hewlett Packard Enterprise Development LP Optimiertes adaptives routing zur reduzierung der anzahl von sprüngen
US20220353001A1 (en) * 2019-07-25 2022-11-03 Maxlinear, Inc. Multiple ports with different baud rate over a single serdes
CN112511323B (zh) * 2019-09-16 2022-06-14 华为技术有限公司 处理网络拥塞的方法和相关装置
US11240151B2 (en) 2019-12-10 2022-02-01 Juniper Networks, Inc. Combined input and output queue for packet forwarding in network devices
WO2021214847A1 (ja) * 2020-04-21 2021-10-28 日本電信電話株式会社 ネットワーク設定装置、方法及びプログラム
US11616734B2 (en) * 2020-07-08 2023-03-28 Hughes Network Systems, Llc Home network resource management
US11693800B2 (en) * 2020-07-13 2023-07-04 EMC IP Holding Company LLC Managing IO path bandwidth
DE102021121105A1 (de) * 2020-09-28 2022-03-31 Samsung Electronics Co., Ltd. Intelligente ablagespeichervorrichtung
US20210281618A1 (en) * 2020-11-12 2021-09-09 Intel Corporation System, apparatus, and method for streaming input/output data
US20220166718A1 (en) * 2020-11-23 2022-05-26 Pensando Systems Inc. Systems and methods to prevent packet reordering when establishing a flow entry
GB2601732A (en) * 2020-11-25 2022-06-15 Metaswitch Networks Ltd Packet processing
US20210149821A1 (en) * 2020-12-23 2021-05-20 Intel Corporation Address translation technologies
WO2022146507A1 (en) * 2020-12-30 2022-07-07 Arris Enterprises Llc System to dynamically detect and enhance classifiers for low latency traffic
CN116889024A (zh) * 2021-02-22 2023-10-13 华为技术有限公司 一种数据流传输方法、装置及网络设备
US20220358002A1 (en) * 2021-05-04 2022-11-10 Xilinx, Inc. Network attached mpi processing architecture in smartnics
US20220385587A1 (en) * 2021-05-25 2022-12-01 Google Llc Acknowledgement Coalescing Module Utilized In Content Addressable Memory (CAM) Based Hardware Architecture For Data Center Networking
US20220400073A1 (en) * 2021-06-15 2022-12-15 Applied Materials, Inc. Router architecture for multi-dimensional topologies in on-chip and on-package networks
US11870682B2 (en) 2021-06-22 2024-01-09 Mellanox Technologies, Ltd. Deadlock-free local rerouting for handling multiple local link failures in hierarchical network topologies
US11637778B2 (en) 2021-06-25 2023-04-25 Cornelis Newtorks, Inc. Filter with engineered damping for load-balanced fine-grained adaptive routing in high-performance system interconnect
US11677672B2 (en) * 2021-06-25 2023-06-13 Cornelis Newtorks, Inc. Telemetry-based load-balanced fine-grained adaptive routing in high-performance system interconnect
CN115695560A (zh) * 2021-07-23 2023-02-03 伊姆西Ip控股有限责任公司 内容分发方法、电子设备和计算机程序产品
US11714765B2 (en) * 2021-07-23 2023-08-01 Hewlett Packard Enterprise Development Lp System and method for implementing a network-interface-based allreduce operation
US11665113B2 (en) * 2021-07-28 2023-05-30 Hewlett Packard Enterprise Development Lp System and method for facilitating dynamic triggered operation management in a network interface controller (NIC)
US11729099B2 (en) * 2021-07-30 2023-08-15 Avago Technologies International Sales Pte. Limited Scalable E2E network architecture and components to support low latency and high throughput
WO2023027693A1 (en) * 2021-08-24 2023-03-02 Zeku, Inc. Serializer / deserializer forward flow control
US11824791B2 (en) * 2021-09-08 2023-11-21 Nvidia Corporation Virtual channel starvation-free arbitration for switches
US11722437B2 (en) * 2021-09-14 2023-08-08 Netscout Systems, Inc. Configuration of a scalable IP network implementation of a switch stack
CN113630331B (zh) * 2021-10-11 2021-12-28 北京金睛云华科技有限公司 全流量存储回溯分析系统中父子连接的处理方法
US11968115B2 (en) * 2021-10-31 2024-04-23 Avago Technologies International Sales Pte. Limited Method for verifying data center network performance
US20230153249A1 (en) * 2021-11-18 2023-05-18 Ati Technologies Ulc Hardware translation request retry mechanism
EP4187868A1 (de) * 2021-11-24 2023-05-31 INTEL Corporation Lastausgleich und netzwerkrichtlinienleistung durch eine paketverarbeitungspipeline
US11765103B2 (en) * 2021-12-01 2023-09-19 Mellanox Technologies, Ltd. Large-scale network with high port utilization
US11985067B2 (en) * 2021-12-10 2024-05-14 Nokia Solutions And Networks Oy Flowlet switching using memory instructions
US20230229599A1 (en) * 2022-01-18 2023-07-20 Nvidia Corporation Multicast and reflective memory behavior for memory model consistency
US11770215B2 (en) * 2022-02-17 2023-09-26 Nvidia Corp. Transceiver system with end-to-end reliability and ordering protocols
CN114401226B (zh) * 2022-02-21 2024-02-27 李超 一种流媒体数据的路由流量控制方法及系统
WO2023177704A1 (en) * 2022-03-16 2023-09-21 F5, Inc. Multi-destination dma for packet broadcast
US20230318969A1 (en) * 2022-03-31 2023-10-05 Lenovo (United States) Inc. Optimizing network load in multicast communications
CN117014376A (zh) * 2022-04-28 2023-11-07 华为技术有限公司 拥塞流识别方法、装置、设备及计算机可读存储介质
US20230385138A1 (en) * 2022-05-25 2023-11-30 Meta Platforms, Inc. Chip-to-chip interconnect with a layered communication architecture
US11799929B1 (en) * 2022-05-27 2023-10-24 Hewlett Packard Enterprise Development Lp Efficient multicast control traffic management for service discovery
CN115622933A (zh) * 2022-09-07 2023-01-17 天翼数字生活科技有限公司 一种路由分发方法、装置和设备
US20240094910A1 (en) * 2022-09-19 2024-03-21 Microsoft Technology Licensing, Llc Round Robin Arbitration Using Random Access Memory
US20240214325A1 (en) * 2022-12-22 2024-06-27 Juniper Networks, Inc. Dynamic resource reservation protocol resource handling and deadlock avoidance
CN116662016B (zh) * 2023-07-25 2023-10-20 太平金融科技服务（上海）有限公司 端口切换方法、装置、计算机设备、存储介质和程序产品
CN117061423B (zh) * 2023-10-09 2024-01-23 苏州元脑智能科技有限公司 一种胖树网络的多机路由方法、装置、系统及存储介质

Family Cites Families (573)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4807118A (en) 1987-01-14 1989-02-21 Hewlett-Packard Company Method for handling slot requests over a network
US5138615A (en) 1989-06-22 1992-08-11 Digital Equipment Corporation Reconfiguration system and method for high-speed mesh connected local area network
US5457687A (en) 1993-09-02 1995-10-10 Network Equipment Technologies, Inc. Method and apparatus for backward explicit congestion notification (BECN) in an ATM network
US5754120A (en) * 1995-12-21 1998-05-19 Lucent Technologies Network congestion measurement method and apparatus
US5983332A (en) 1996-07-01 1999-11-09 Sun Microsystems, Inc. Asynchronous transfer mode (ATM) segmentation and reassembly unit virtual address translation unit architecture
US5937436A (en) 1996-07-01 1999-08-10 Sun Microsystems, Inc Network interface circuit including an address translation unit and flush control circuit and method for checking for invalid address translations
US6493347B2 (en) 1996-12-16 2002-12-10 Juniper Networks, Inc. Memory organization in a switching device
US6026075A (en) * 1997-02-25 2000-02-15 International Business Machines Corporation Flow control mechanism
US6112265A (en) 1997-04-07 2000-08-29 Intel Corportion System for issuing a command to a memory having a reorder module for priority commands and an arbiter tracking address of recently issued command
US5960178A (en) 1997-08-08 1999-09-28 Bell Communications Research, Inc. Queue system and method for point-to-point message passing having a separate table for storing message state and identifier of processor assigned to process the message
US7237036B2 (en) * 1997-10-14 2007-06-26 Alacritech, Inc. Fast-path apparatus for receiving data corresponding a TCP connection
US7133940B2 (en) 1997-10-14 2006-11-07 Alacritech, Inc. Network interface device employing a DMA command queue
US6434620B1 (en) * 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US6226680B1 (en) 1997-10-14 2001-05-01 Alacritech, Inc. Intelligent network interface system method for protocol processing
US6230252B1 (en) 1997-11-17 2001-05-08 Silicon Graphics, Inc. Hybrid hypercube/torus architecture
US5970232A (en) 1997-11-17 1999-10-19 Cray Research, Inc. Router table lookup mechanism
US6545981B1 (en) 1998-01-07 2003-04-08 Compaq Computer Corporation System and method for implementing error detection and recovery in a system area network
US6563835B1 (en) * 1998-02-20 2003-05-13 Lucent Technologies Inc. Call processing arrangement for ATM switches
US6714553B1 (en) 1998-04-15 2004-03-30 Top Layer Networks, Inc. System and process for flexible queuing of data packets in network switching
US6490276B1 (en) * 1998-06-29 2002-12-03 Nortel Networks Limited Stackable switch port collapse mechanism
US6321276B1 (en) 1998-08-04 2001-11-20 Microsoft Corporation Recoverable methods and systems for processing input/output requests including virtual memory addresses
ATE441275T1 (de) 1998-10-30 2009-09-15 Virnetx Inc Netzwerkprotokol zur sicheren kommunikation mit gesicherter systemverfügbarkeit
US6246682B1 (en) 1999-03-05 2001-06-12 Transwitch Corp. Method and apparatus for managing multiple ATM cell queues
US6615282B1 (en) 1999-05-21 2003-09-02 Intel Corporation Adaptive messaging
US6424591B1 (en) * 1999-05-28 2002-07-23 Advanced Micro Devices, Inc. Network interface supporting fifo-type and SRAM-type accesses to internal buffer memory
US6674720B1 (en) 1999-09-29 2004-01-06 Silicon Graphics, Inc. Age-based network arbitration system and method
US6542941B1 (en) 1999-09-30 2003-04-01 Intel Corporation Efficient command delivery and data transfer
US7076630B2 (en) * 2000-02-08 2006-07-11 Mips Tech Inc Method and apparatus for allocating and de-allocating consecutive blocks of memory in background memo management
US6977930B1 (en) 2000-02-14 2005-12-20 Cisco Technology, Inc. Pipelined packet switching and queuing architecture
US7545755B2 (en) 2000-03-03 2009-06-09 Adtran Inc. Routing switch detecting change in session identifier before reconfiguring routing table
US6735173B1 (en) 2000-03-07 2004-05-11 Cisco Technology, Inc. Method and apparatus for accumulating and distributing data items within a packet switching system
US6728211B1 (en) 2000-03-07 2004-04-27 Cisco Technology, Inc. Method and apparatus for delaying packets being sent from a component of a packet switching system
US6633580B1 (en) 2000-03-07 2003-10-14 Sun Microsystems N×N crossbar packet switch
WO2001069851A2 (en) 2000-03-13 2001-09-20 The Trustees Of Columbia University In The City Of New York Method and apparatus for allocation of resources
US7215637B1 (en) 2000-04-17 2007-05-08 Juniper Networks, Inc. Systems and methods for processing packets
US6894974B1 (en) 2000-05-08 2005-05-17 Nortel Networks Limited Method, apparatus, media, and signals for controlling packet transmission rate from a packet source
US20020146022A1 (en) * 2000-05-31 2002-10-10 Van Doren Stephen R. Credit-based flow control technique in a modular multiprocessor system
US8619793B2 (en) 2000-08-21 2013-12-31 Rockstar Consortium Us Lp Dynamic assignment of traffic classes to a priority queue in a packet forwarding device
US6985956B2 (en) 2000-11-02 2006-01-10 Sun Microsystems, Inc. Switching system
US6910148B1 (en) 2000-12-07 2005-06-21 Nokia, Inc. Router and routing protocol redundancy
US7127056B2 (en) 2000-12-26 2006-10-24 Nortel Networks Limited Dynamic adaptation to congestion in connection-oriented networks
US6732212B2 (en) 2001-02-14 2004-05-04 Fujitsu Limited Launch raw packet on remote interrupt
DE60237433D1 (de) 2001-02-24 2010-10-07 Ibm Neuartiger massivparalleler supercomputer
CN1269053C (zh) 2001-02-24 2006-08-09 国际商业机器公司 分组路由方法、系统及用于分组路由的可扩展网络交换机
EP1249972A1 (de) * 2001-04-09 2002-10-16 Telefonaktiebolaget L M Ericsson (Publ) Verfahren zum Steuern eines Warteschlangenpuffers
US20020152328A1 (en) * 2001-04-11 2002-10-17 Mellanox Technologies, Ltd. Network adapter with shared database for message context information
US6687781B2 (en) 2001-05-01 2004-02-03 Zettacom, Inc. Fair weighted queuing bandwidth allocation system for network switch port
US7260104B2 (en) 2001-12-19 2007-08-21 Computer Network Technology Corporation Deferred queuing in a buffered switch
US7042842B2 (en) * 2001-06-13 2006-05-09 Computer Network Technology Corporation Fiber channel switch
US7218637B1 (en) 2001-07-20 2007-05-15 Yotta Networks, Llc System for switching data using dynamic scheduling
US7382787B1 (en) * 2001-07-30 2008-06-03 Cisco Technology, Inc. Packet routing and switching device
EP1419614B1 (de) 2001-08-21 2006-06-14 Telefonaktiebolaget LM Ericsson (publ) Mehrfachsendung in paketvermittelten punkt-zu-punkt-netzwerken
US7415531B2 (en) 2001-08-22 2008-08-19 Mips Technologies, Inc. Method and apparatus for predicting characteristics of incoming data packets to enable speculative processing to reduce processor latency
KR100624610B1 (ko) 2001-08-24 2006-09-19 인텔 코오퍼레이션 데이터 무결성을 관리하는 범용 입출력 아키텍쳐 프로토콜및 관련 방법
US7464180B1 (en) 2001-10-16 2008-12-09 Cisco Technology, Inc. Prioritization and preemption of data frames over a switching fabric
US7110360B1 (en) * 2001-11-05 2006-09-19 Juniper Networks, Inc. Credit-based flow control over unreliable links
US7092401B2 (en) * 2001-11-15 2006-08-15 International Business Machines Corporation Apparatus and method for managing work and completion queues using head and tail pointers with end-to-end context error cache for reliable datagram
US7457297B2 (en) 2001-11-16 2008-11-25 Enterasys Networks, Inc. Methods and apparatus for differentiated services over a packet-based network
US6698003B2 (en) 2001-12-06 2004-02-24 International Business Machines Corporation Framework for multiple-engine based verification tools for integrated circuits
US7023856B1 (en) 2001-12-11 2006-04-04 Riverstone Networks, Inc. Method and system for providing differentiated service on a per virtual circuit basis within a packet-based switch/router
US20030126280A1 (en) * 2001-12-31 2003-07-03 Maxxan Systems, Inc. XON/XOFF flow control for computer network
JP3875107B2 (ja) 2002-01-10 2007-01-31 株式会社エヌ・ティ・ティ・ドコモ パケット交換システム、パケット交換方法、ルーティング装置、パケットデータ及びその生成方法
JP2003244196A (ja) 2002-02-20 2003-08-29 Fujitsu Ltd 負荷分散制御をするルータ及びネットワーク制御装置
US8626957B2 (en) 2003-08-22 2014-01-07 International Business Machines Corporation Collective network for computer structures
US7782776B2 (en) 2002-03-15 2010-08-24 Broadcom Corporation Shared weighted fair queuing (WFQ) shaper
US7245620B2 (en) 2002-03-15 2007-07-17 Broadcom Corporation Method and apparatus for filtering packet data in a network device
US7181531B2 (en) 2002-04-30 2007-02-20 Microsoft Corporation Method to synchronize and upload an offloaded network stack connection with a network stack
US7283558B2 (en) 2002-06-04 2007-10-16 Lucent Technologies Inc. Distributed weighted fair arbitration and forwarding
US7376755B2 (en) * 2002-06-11 2008-05-20 Pandya Ashish A TCP/IP processor and engine using RDMA
US7191249B1 (en) 2002-06-14 2007-03-13 Juniper Networks, Inc. Packet prioritization systems and methods using address aliases
BR0215746B1 (pt) 2002-06-19 2015-02-10 Ericsson Telefon Ab L M Arquitetura de acionador de dispositivo de rede, sistema e método para habilitar acesso de espaço de núcleo de sistema operacional como também acesso de espaço de usuário para um controlador de interface de rede (nic), e, método para habilitar acesso entre o espaço de núcleo de sistema operacional e um controlador de interface de rede (nic) como também entre o espaço de usuário e o dito nic
US7649882B2 (en) 2002-07-15 2010-01-19 Alcatel-Lucent Usa Inc. Multicast scheduling and replication in switches
US20040019895A1 (en) * 2002-07-29 2004-01-29 Intel Corporation Dynamic communication tuning apparatus, systems, and methods
EP1552409B1 (de) 2002-08-19 2013-07-24 Broadcom Corporation One-shot-rdma
US20040049580A1 (en) 2002-09-05 2004-03-11 International Business Machines Corporation Receive queue device with efficient queue flow control, segment placement and virtualization mechanisms
US7206858B2 (en) 2002-09-19 2007-04-17 Intel Corporation DSL transmit traffic shaper structure and procedure
US8478811B2 (en) 2002-10-08 2013-07-02 Netlogic Microsystems, Inc. Advanced processor with credit based scheme for optimal packet flow in a multi-processor system on a chip
US7327678B2 (en) 2002-10-18 2008-02-05 Alcatel Lucent Metro ethernet network system with selective upstream pause messaging
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7269180B2 (en) 2002-11-04 2007-09-11 World Wide Packets, Inc. System and method for prioritizing and queuing traffic
CN1260915C (zh) 2002-11-19 2006-06-21 华为技术有限公司 一种城域网传输设备的流量控制方法
US8103788B1 (en) * 2002-11-19 2012-01-24 Advanced Micro Devices, Inc. Method and apparatus for dynamically reallocating buffers for use in a packet transmission
US7317718B1 (en) 2002-12-06 2008-01-08 Juniper Networks, Inc. Flexible counter update and retrieval
US7397797B2 (en) 2002-12-13 2008-07-08 Nvidia Corporation Method and apparatus for performing network processing functions
US7441267B1 (en) 2003-03-19 2008-10-21 Bbn Technologies Corp. Method and apparatus for controlling the flow of data across a network interface
US7660908B2 (en) 2003-05-01 2010-02-09 International Business Machines Corporation Implementing virtual packet storage via packet work area
US7573827B2 (en) 2003-05-06 2009-08-11 Hewlett-Packard Development Company, L.P. Method and apparatus for detecting network congestion
JP4175185B2 (ja) 2003-06-06 2008-11-05 日本電気株式会社 ネットワーク情報記録装置
US20050108518A1 (en) 2003-06-10 2005-05-19 Pandya Ashish A. Runtime adaptable security processor
US7483374B2 (en) 2003-08-05 2009-01-27 Scalent Systems, Inc. Method and apparatus for achieving dynamic capacity and high availability in multi-stage data networks using adaptive flow-based routing
US8050180B2 (en) 2003-10-31 2011-11-01 Brocade Communications Systems, Inc. Network path tracing method
EP1528478A1 (de) * 2003-11-03 2005-05-04 Sun Microsystems, Inc. Allgemeines Adressierungsverfahren für fern-firekt-speicherzugrifffähige Geräte
US7613184B2 (en) 2003-11-07 2009-11-03 Alcatel Lucent Method and apparatus for performing scalable selective backpressure in packet-switched networks using internal tags
US20050108444A1 (en) 2003-11-19 2005-05-19 Flauaus Gary R. Method of detecting and monitoring fabric congestion
US7912979B2 (en) * 2003-12-11 2011-03-22 International Business Machines Corporation In-order delivery of plurality of RDMA messages
US7441006B2 (en) 2003-12-11 2008-10-21 International Business Machines Corporation Reducing number of write operations relative to delivery of out-of-order RDMA send messages by managing reference counter
US20050129039A1 (en) * 2003-12-11 2005-06-16 International Business Machines Corporation RDMA network interface controller with cut-through implementation for aligned DDP segments
US7385985B2 (en) * 2003-12-31 2008-06-10 Alcatel Lucent Parallel data link layer controllers in a network switching device
RU2006129488A (ru) * 2004-01-15 2008-02-20 Мацусита Электрик Индастриал Ко., Лтд. (Jp) Устройство динамического управления сетью и способ динамического управления сетью
US7774461B2 (en) 2004-02-18 2010-08-10 Fortinet, Inc. Mechanism for determining a congestion metric for a path in a network
JP4521206B2 (ja) * 2004-03-01 2010-08-11 株式会社日立製作所 ネットワークストレージシステム、コマンドコントローラ、及びネットワークストレージシステムにおけるコマンド制御方法
GB0404696D0 (en) * 2004-03-02 2004-04-07 Level 5 Networks Ltd Dual driver interface
JP2007526706A (ja) 2004-03-05 2007-09-13 ザイラテックス・テクノロジー・リミテッド ネットワークにおける輻輳管理方法、シグナリングプロトコル、スイッチ、エンドステーション、及びネットワーク
US7286853B2 (en) 2004-03-24 2007-10-23 Cisco Technology, Inc. System and method for aggregating multiple radio interfaces into a single logical bridge interface
US8081566B1 (en) 2004-04-19 2011-12-20 Rockstar BIDCO, LLP Method and apparatus for indicating congestion in a source routed network
US7826457B2 (en) * 2004-05-11 2010-11-02 Broadcom Corp. Method and system for handling out-of-order segments in a wireless system via direct data placement
US7672243B2 (en) 2004-06-04 2010-03-02 David Mayhew System and method to identify and communicate congested flows in a network fabric
US7483442B1 (en) 2004-06-08 2009-01-27 Sun Microsystems, Inc. VCRC checking and generation
US7639616B1 (en) 2004-06-08 2009-12-29 Sun Microsystems, Inc. Adaptive cut-through algorithm
US20050281282A1 (en) * 2004-06-21 2005-12-22 Gonzalez Henry J Internal messaging within a switch
US7453810B2 (en) 2004-07-27 2008-11-18 Alcatel Lucent Method and apparatus for closed loop, out-of-band backpressure mechanism
US20060067347A1 (en) 2004-09-29 2006-03-30 Uday Naik Cell-based queue management in software
US8353003B2 (en) 2004-10-01 2013-01-08 Exelis Inc. System and method for controlling a flow of data a network interface controller to a host processor
US7633869B1 (en) 2004-10-18 2009-12-15 Ubicom, Inc. Automatic network traffic characterization
US7593329B2 (en) 2004-10-29 2009-09-22 Broadcom Corporation Service aware flow control
US7620071B2 (en) 2004-11-16 2009-11-17 Intel Corporation Packet coalescing
US7826481B2 (en) * 2004-11-30 2010-11-02 Broadcom Corporation Network for supporting advance features on legacy components
US7796579B2 (en) 2004-12-03 2010-09-14 Telefonaktiebolaget Lm Ericsson (Publ) Technique for interconnecting intermediate network nodes
US7804504B1 (en) * 2004-12-13 2010-09-28 Massachusetts Institute Of Technology Managing yield for a parallel processing integrated circuit
US7562366B2 (en) 2005-02-03 2009-07-14 Solarflare Communications, Inc. Transmit completion event batching
US7831749B2 (en) 2005-02-03 2010-11-09 Solarflare Communications, Inc. Including descriptor queue empty events in completion events
US7464174B1 (en) 2005-03-07 2008-12-09 Pericom Semiconductor Corp. Shared network-interface controller (NIC) using advanced switching (AS) turn-pool routing field to select from among multiple contexts for multiple processors
US7643420B2 (en) 2005-03-11 2010-01-05 Broadcom Corporation Method and system for transmission control protocol (TCP) traffic smoothing
BRPI0608941B1 (pt) 2005-03-31 2019-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Método e sistema para prover segurança de dados para um protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, receptor, transmissor, e, alocador de protocolo de segurança
US10270700B2 (en) 2015-03-03 2019-04-23 Opanga Networks, Inc. Systems and methods for pacing data flows
WO2006109207A1 (en) * 2005-04-13 2006-10-19 Koninklijke Philips Electronics N.V. Electronic device and method for flow control
US7856026B1 (en) 2005-06-28 2010-12-21 Altera Corporation Configurable central memory buffered packet switch module for use in a PLD
US8045454B2 (en) 2005-09-12 2011-10-25 Cisco Technology, Inc. Multimedia data flow dropping
US7733891B2 (en) 2005-09-12 2010-06-08 Zeugma Systems Inc. Methods and apparatus to support dynamic allocation of traffic management resources in a network element
US7430559B2 (en) 2005-09-21 2008-09-30 Microsoft Corporation Generalized idempotent requests
EP1934733B1 (de) 2005-09-21 2011-07-27 Solarflare Communications, Inc. Raten-pacing
US8660137B2 (en) 2005-09-29 2014-02-25 Broadcom Israel Research, Ltd. Method and system for quality of service and congestion management for converged network interface devices
US7953002B2 (en) 2005-11-10 2011-05-31 Broadcom Corporation Buffer management and flow control mechanism including packet-based dynamic thresholding
US7873048B1 (en) * 2005-12-02 2011-01-18 Marvell International Ltd. Flexible port rate limiting
US7889762B2 (en) * 2006-01-19 2011-02-15 Intel-Ne, Inc. Apparatus and method for in-line insertion and removal of markers
US7376807B2 (en) 2006-02-23 2008-05-20 Freescale Semiconductor, Inc. Data processing system having address translation bypass and method therefor
US7664904B2 (en) 2006-03-10 2010-02-16 Ricoh Company, Limited High speed serial switch fabric performing mapping of traffic classes onto virtual channels
US20070237082A1 (en) * 2006-03-31 2007-10-11 Woojong Han Techniques for sharing connection queues and performing congestion management
GB2448851B (en) 2006-04-05 2011-01-05 Xyratex Tech Ltd A method for congestion management of a network, a switch, and a network
US20070242611A1 (en) 2006-04-13 2007-10-18 Archer Charles J Computer Hardware Fault Diagnosis
US7577820B1 (en) 2006-04-14 2009-08-18 Tilera Corporation Managing data in a parallel processing environment
US7620791B1 (en) 2006-04-14 2009-11-17 Tilera Corporation Mapping memory in a parallel processing environment
US7733781B2 (en) 2006-04-24 2010-06-08 Broadcom Corporation Distributed congestion avoidance in a network switching system
US7596628B2 (en) 2006-05-01 2009-09-29 Broadcom Corporation Method and system for transparent TCP offload (TTO) with a user space library
US20070268825A1 (en) * 2006-05-19 2007-11-22 Michael Corwin Fine-grain fairness in a hierarchical switched system
US8082289B2 (en) * 2006-06-13 2011-12-20 Advanced Cluster Systems, Inc. Cluster computing support for application programs
US7693072B2 (en) 2006-07-13 2010-04-06 At&T Intellectual Property I, L.P. Method and apparatus for configuring a network topology with alternative communication paths
US7836274B2 (en) 2006-09-05 2010-11-16 Broadcom Corporation Method and system for combining page buffer list entries to optimize caching of translated addresses
US7624105B2 (en) 2006-09-19 2009-11-24 Netlogic Microsystems, Inc. Search engine having multiple co-processors for performing inexact pattern search operations
US7839786B2 (en) 2006-10-06 2010-11-23 International Business Machines Corporation Method and apparatus for routing data in an inter-nodal communications lattice of a massively parallel computer system by semi-randomly varying routing policies for different packets
US7587575B2 (en) 2006-10-17 2009-09-08 International Business Machines Corporation Communicating with a memory registration enabled adapter using cached address translations
US8045456B1 (en) * 2006-11-27 2011-10-25 Marvell International Ltd. Hierarchical port-based rate limiting
US20080313364A1 (en) * 2006-12-06 2008-12-18 David Flynn Apparatus, system, and method for remote direct memory access to a solid-state storage device
US20080147881A1 (en) 2006-12-19 2008-06-19 Krishnamurthy Rajaram B System and method for placing computation inside a network
CA2669932A1 (en) * 2006-12-19 2008-06-26 International Business Machines Corporation Apparatus and method for analysing a network flow
US20080155154A1 (en) * 2006-12-21 2008-06-26 Yuval Kenan Method and System for Coalescing Task Completions
US7975120B2 (en) 2006-12-27 2011-07-05 Freescale Semiconductor, Inc. Dynamic allocation of message buffers
US9049095B2 (en) 2006-12-29 2015-06-02 Alcatel Lucent Methods and devices for providing ingress routing in selective randomized load balancing
JP4259581B2 (ja) * 2007-02-07 2009-04-30 日立電線株式会社 スイッチングハブおよびｌａｎシステム
US7904642B1 (en) 2007-02-08 2011-03-08 Netlogic Microsystems, Inc. Method for combining and storing access control lists
US7916718B2 (en) * 2007-04-19 2011-03-29 Fulcrum Microsystems, Inc. Flow and congestion control in switch architectures for multi-hop, memory efficient fabrics
US7864792B2 (en) 2007-04-20 2011-01-04 Cray, Inc. Load balancing for communications within a multiprocessor computer system
US7925795B2 (en) * 2007-04-30 2011-04-12 Broadcom Corporation Method and system for configuring a plurality of network interfaces that share a physical interface
US20080298248A1 (en) * 2007-05-28 2008-12-04 Guenter Roeck Method and Apparatus For Computer Network Bandwidth Control and Congestion Management
US10389736B2 (en) 2007-06-12 2019-08-20 Icontrol Networks, Inc. Communication protocols in integrated systems
US8331387B2 (en) 2007-06-22 2012-12-11 Broadcom Corporation Data switching flow control with virtual output queuing
US8199648B2 (en) 2007-07-03 2012-06-12 Cisco Technology, Inc. Flow control in a variable latency system
US8478834B2 (en) 2007-07-12 2013-07-02 International Business Machines Corporation Low latency, high bandwidth data communications between compute nodes in a parallel computer
US7936772B2 (en) 2007-07-13 2011-05-03 International Business Machines Corporation Enhancement of end-to-end network QoS
US20140173731A1 (en) * 2007-07-27 2014-06-19 Redshift Internetworking, Inc. System and Method for Unified Communications Threat Management (UCTM) for Converged Voice, Video and Multi-Media Over IP Flows
WO2009018232A1 (en) 2007-07-27 2009-02-05 Redshift Internetworking, Inc A system and method for unified communications threat management (uctm) for converged voice, video and multi-media over ip flows
US8121038B2 (en) 2007-08-21 2012-02-21 Cisco Technology, Inc. Backward congestion notification
US8014387B2 (en) * 2007-08-27 2011-09-06 International Business Machines Corporation Providing a fully non-blocking switch in a supernode of a multi-tiered full-graph interconnect architecture
US20090070765A1 (en) 2007-09-11 2009-03-12 Bea Systems, Inc. Xml-based configuration for event processing networks
CN101399746B (zh) 2007-09-26 2011-03-16 华为技术有限公司 报文路由方法、系统、设备和选择备份资源的方法、系统
CN101431466B (zh) 2007-11-09 2011-04-06 华为技术有限公司 快速重路由方法及标签交换路由器
US7782869B1 (en) 2007-11-29 2010-08-24 Huawei Technologies Co., Ltd. Network traffic control for virtual device interfaces
US9519540B2 (en) * 2007-12-06 2016-12-13 Sandisk Technologies Llc Apparatus, system, and method for destaging cached data
US8014278B1 (en) * 2007-12-17 2011-09-06 Force 10 Networks, Inc Adaptive load balancing between ECMP or LAG port group members
US8160085B2 (en) 2007-12-21 2012-04-17 Juniper Networks, Inc. System and method for dynamically allocating buffers based on priority levels
US7779148B2 (en) 2008-02-01 2010-08-17 International Business Machines Corporation Dynamic routing based on information of not responded active source requests quantity received in broadcast heartbeat signal and stored in local data structure for other processor chips
US8219778B2 (en) * 2008-02-27 2012-07-10 Microchip Technology Incorporated Virtual memory interface
US8249072B2 (en) 2009-03-12 2012-08-21 Oracle America, Inc. Scalable interface for connecting multiple computer systems which performs parallel MPI header matching
WO2009130218A1 (en) 2008-04-24 2009-10-29 Xelerated Ab A traffic manager and a method for a traffic manager
US8040799B2 (en) 2008-05-15 2011-10-18 International Business Machines Corporation Network on chip with minimum guaranteed bandwidth for virtual communications channels
GB2460070B (en) 2008-05-15 2010-10-13 Gnodal Ltd A method of data delivery across a network
US9137739B2 (en) * 2009-01-28 2015-09-15 Headwater Partners I Llc Network based service policy implementation with network neutrality and user privacy
GB2461132B (en) 2008-06-27 2013-02-13 Gnodal Ltd Method of data delivery across a network
GB2462492B (en) * 2008-08-14 2012-08-15 Gnodal Ltd A multi-path network
US20100049942A1 (en) 2008-08-20 2010-02-25 John Kim Dragonfly processor interconnect network
US8755396B2 (en) 2008-09-11 2014-06-17 Juniper Networks, Inc. Methods and apparatus related to flow control within a data center switch fabric
US7996484B2 (en) 2008-12-11 2011-08-09 Microsoft Corporation Non-disruptive, reliable live migration of virtual machines with network data reception directly into virtual machines' memory
US8103809B1 (en) 2009-01-16 2012-01-24 F5 Networks, Inc. Network devices with multiple direct memory access channels and methods thereof
US20100183024A1 (en) 2009-01-21 2010-07-22 Brocade Communications Systems, Inc Simplified rdma over ethernet and fibre channel
US8510496B1 (en) 2009-04-27 2013-08-13 Netapp, Inc. Scheduling access requests for a multi-bank low-latency random read memory device
US8255475B2 (en) 2009-04-28 2012-08-28 Mellanox Technologies Ltd. Network interface device with memory management capabilities
US8170062B2 (en) * 2009-04-29 2012-05-01 Intel Corporation Packetized interface for coupling agents
WO2010142432A2 (en) 2009-06-09 2010-12-16 Martin Vorbach System and method for a cache in a multi-core processor
JP4688946B2 (ja) 2009-06-15 2011-05-25 富士通株式会社 スイッチ及びアドレス学習方法
WO2010151099A1 (en) 2009-06-26 2010-12-29 Telekom Malaysia Berhad Method and system for service-based regulation of traffic flow to customer premises devices
US8605584B2 (en) 2009-07-02 2013-12-10 Qualcomm Incorporated Transmission of control information across multiple packets
US8175107B1 (en) 2009-08-18 2012-05-08 Hewlett-Packard Development Company, L.P. Network routing based on MAC address subnetting
CN101651625B (zh) 2009-09-03 2011-09-21 中兴通讯股份有限公司 多业务恢复的选路装置及选路方法
CN102577275B (zh) * 2009-09-10 2016-05-04 日本电气株式会社 中继控制设备、中继控制系统、中继控制方法
US20110103391A1 (en) * 2009-10-30 2011-05-05 Smooth-Stone, Inc. C/O Barry Evans System and method for high-performance, low-power data center interconnect fabric
KR101638061B1 (ko) 2009-10-27 2016-07-08 삼성전자주식회사 플래시 메모리 시스템 및 그것의 플래시 조각 모음 방법
US8953603B2 (en) 2009-10-28 2015-02-10 Juniper Networks, Inc. Methods and apparatus related to a distributed switch fabric
US8443151B2 (en) 2009-11-09 2013-05-14 Intel Corporation Prefetch optimization in shared resource multi-core systems
TWI416336B (zh) 2009-11-10 2013-11-21 Realtek Semiconductor Corp 可共享緩衝器的網路介面卡與緩衝器共享方法
US8780926B2 (en) 2009-12-01 2014-07-15 Polytechnic Institute Of New York University Updating prefix-compressed tries for IP route lookup
CN101729609B (zh) 2009-12-03 2012-02-22 北京交通大学 一种向量交换实现方法
US9054996B2 (en) 2009-12-24 2015-06-09 Juniper Networks, Inc. Dynamic prioritized fair share scheduling scheme in over-subscribed port scenario
US8719543B2 (en) 2009-12-29 2014-05-06 Advanced Micro Devices, Inc. Systems and methods implementing non-shared page tables for sharing memory resources managed by a main operating system with accelerator devices
US8285915B2 (en) 2010-01-13 2012-10-09 International Business Machines Corporation Relocating page tables and data amongst memory modules in a virtualized environment
US8280671B2 (en) * 2010-01-29 2012-10-02 Microsoft Corporation Compressive data gathering for large-scale wireless sensor networks
US8544026B2 (en) 2010-02-09 2013-09-24 International Business Machines Corporation Processing data communications messages with input/output control blocks
US8862682B2 (en) 2010-02-17 2014-10-14 Emulex Corporation Accelerated sockets
US9001663B2 (en) 2010-02-26 2015-04-07 Microsoft Corporation Communication transport optimized for data center environment
US20110225297A1 (en) 2010-03-11 2011-09-15 International Business Machines Corporation Controlling Access To A Resource In A Distributed Computing System With A Distributed Access Request Queue
US8971345B1 (en) 2010-03-22 2015-03-03 Riverbed Technology, Inc. Method and apparatus for scheduling a heterogeneous communication flow
US8606979B2 (en) * 2010-03-29 2013-12-10 International Business Machines Corporation Distributed administration of a lock for an operational group of compute nodes in a hierarchical tree structured network
US8379642B2 (en) * 2010-04-26 2013-02-19 International Business Machines Corporation Multicasting using a multitiered distributed virtual bridge hierarchy
CN102859949B (zh) 2010-04-30 2015-12-02 惠普发展公司，有限责任合伙企业 用于在胖树网络中路由数据分组的方法
US9288137B2 (en) 2010-05-09 2016-03-15 Citrix Systems, Inc. Systems and methods for allocation of classes of service to network connections corresponding to virtual channels
US8335157B2 (en) 2010-05-17 2012-12-18 Cisco Technology, Inc. Adaptive queue-management
US8489859B2 (en) 2010-05-28 2013-07-16 International Business Machines Corporation Performing a deterministic reduction operation in a compute node organized into a branched tree topology
US8949577B2 (en) * 2010-05-28 2015-02-03 International Business Machines Corporation Performing a deterministic reduction operation in a parallel computer
US9065773B2 (en) 2010-06-22 2015-06-23 Juniper Networks, Inc. Methods and apparatus for virtual channel flow control associated with a switch fabric
US8898324B2 (en) 2010-06-24 2014-11-25 International Business Machines Corporation Data access management in a hybrid memory server
US8719455B2 (en) 2010-06-28 2014-05-06 International Business Machines Corporation DMA-based acceleration of command push buffer between host and target devices
JP5498889B2 (ja) * 2010-08-06 2014-05-21 アラクサラネットワークス株式会社 パケット中継装置および輻輳制御方法
EP2606575B1 (de) 2010-08-19 2018-05-30 Telefonaktiebolaget LM Ericsson (publ) Verfahren und vorrichtung zur auswahl des transportformats in einem drahtlosen kommunikationssystem
US20120102506A1 (en) 2010-10-20 2012-04-26 Microsoft Corporation Web service patterns for globally distributed service fabric
JP5913912B2 (ja) 2010-11-05 2016-04-27 インテル コーポレイション Ｄｒａｇｏｎｆｌｙプロセッサ相互接続ネットワークにおける革新的な適応型ルーティング
JP5860670B2 (ja) 2010-11-05 2016-02-16 インテル コーポレイション Ｄｒａｇｏｎｆｌｙプロセッサ相互接続ネットワークにおけるテーブル駆動型ルーティング
US8473783B2 (en) 2010-11-09 2013-06-25 International Business Machines Corporation Fault tolerance in distributed systems
US8533285B2 (en) 2010-12-01 2013-09-10 Cisco Technology, Inc. Directing data flows in data centers with clustering services
US8996644B2 (en) 2010-12-09 2015-03-31 Solarflare Communications, Inc. Encapsulated accelerator
US9436651B2 (en) 2010-12-09 2016-09-06 Intel Corporation Method and apparatus for managing application state in a network interface controller in a high performance computing system
US9047178B2 (en) * 2010-12-13 2015-06-02 SanDisk Technologies, Inc. Auto-commit memory synchronization
US10817502B2 (en) 2010-12-13 2020-10-27 Sandisk Technologies Llc Persistent memory management
US9208071B2 (en) 2010-12-13 2015-12-08 SanDisk Technologies, Inc. Apparatus, system, and method for accessing memory
EP2652623B1 (de) * 2010-12-13 2018-08-01 SanDisk Technologies LLC Vorrichtung, system, und verfahren für einen auto-commit-speicher
US9218278B2 (en) 2010-12-13 2015-12-22 SanDisk Technologies, Inc. Auto-commit memory
US9008113B2 (en) * 2010-12-20 2015-04-14 Solarflare Communications, Inc. Mapped FIFO buffering
US8462632B1 (en) * 2010-12-28 2013-06-11 Amazon Technologies, Inc. Network traffic control
US8780896B2 (en) 2010-12-29 2014-07-15 Juniper Networks, Inc. Methods and apparatus for validation of equal cost multi path (ECMP) paths in a switch fabric system
US20120170462A1 (en) 2011-01-05 2012-07-05 Alcatel Lucent Usa Inc. Traffic flow control based on vlan and priority
KR20120082739A (ko) 2011-01-14 2012-07-24 한국과학기술원 멀티 라디오 모바일 애드혹 네트워크에서의 링크 품질 기반 라우팅 방법
DE102011009518B4 (de) 2011-01-26 2013-09-12 Ruprecht-Karls-Universität Heidelberg Schaltungsanordnung für Verbindungsschnittstelle
US8467294B2 (en) * 2011-02-11 2013-06-18 Cisco Technology, Inc. Dynamic load balancing for port groups
US8776207B2 (en) * 2011-02-16 2014-07-08 Fortinet, Inc. Load balancing in a network with session information
US20120213118A1 (en) 2011-02-18 2012-08-23 Lindsay Steven B Method and system for network interface controller (nic) address resolution protocol (arp) batching
US8982688B2 (en) * 2011-03-09 2015-03-17 Cray Inc Congestion abatement in a network interconnect
US9032089B2 (en) * 2011-03-09 2015-05-12 Juniper Networks, Inc. Methods and apparatus for path selection within a network based on flow duration
US8953442B2 (en) * 2011-03-09 2015-02-10 Cray Inc. Congestion detection in a network interconnect
US9716659B2 (en) 2011-03-23 2017-07-25 Hughes Network Systems, Llc System and method for providing improved quality of service over broadband networks
WO2012132264A1 (ja) 2011-03-28 2012-10-04 パナソニック株式会社 中継器、中継器の制御方法、およびプログラム
US8644157B2 (en) 2011-03-28 2014-02-04 Citrix Systems, Inc. Systems and methods for handling NIC congestion via NIC aware application
WO2012130264A1 (en) 2011-03-29 2012-10-04 Nec Europe Ltd. User traffic accountability under congestion in flow-based multi-layer switches
US8677031B2 (en) 2011-03-31 2014-03-18 Intel Corporation Facilitating, at least in part, by circuitry, accessing of at least one controller command interface
US9154400B2 (en) 2011-05-10 2015-10-06 Cray Inc. Dynamically updating routing information while avoiding deadlocks and preserving packet order after a configuration change
US9225628B2 (en) 2011-05-24 2015-12-29 Mellanox Technologies Ltd. Topology-based consolidation of link state information
US8804752B2 (en) 2011-05-31 2014-08-12 Oracle International Corporation Method and system for temporary data unit storage on infiniband host channel adaptor
US9716592B1 (en) * 2011-06-10 2017-07-25 Google Inc. Traffic distribution over multiple paths in a network while maintaining flow affinity
US8553683B2 (en) 2011-07-05 2013-10-08 Plx Technology, Inc. Three dimensional fat tree networks
US11636031B2 (en) 2011-08-11 2023-04-25 Pure Storage, Inc. Optimized inline deduplication
US8711867B2 (en) * 2011-08-26 2014-04-29 Sonics, Inc. Credit flow control scheme in a router with flexible link widths utilizing minimal storage
US8694994B1 (en) 2011-09-07 2014-04-08 Amazon Technologies, Inc. Optimization of packet processing by delaying a processor from entering an idle state
US8713240B2 (en) * 2011-09-29 2014-04-29 Intel Corporation Providing multiple decode options for a system-on-chip (SoC) fabric
US20130083660A1 (en) 2011-10-03 2013-04-04 Cisco Technology, Inc. Per-Group ECMP for Multidestination Traffic in DCE/TRILL Networks
US8811183B1 (en) 2011-10-04 2014-08-19 Juniper Networks, Inc. Methods and apparatus for multi-path flow control within a multi-stage switch fabric
US9065745B2 (en) * 2011-10-06 2015-06-23 International Business Machines Corporation Network traffic distribution
US8831010B1 (en) * 2011-10-20 2014-09-09 Google Inc. Providing routing information for weighted multi-path routing
US9143467B2 (en) 2011-10-25 2015-09-22 Mellanox Technologies Ltd. Network interface controller with circular receive buffer
WO2013060378A1 (en) 2011-10-28 2013-05-02 Telecom Italia S.P.A. Apparatus and method for selectively delaying network data flows
EP2592871B1 (de) 2011-11-11 2014-05-28 Itron, Inc. Leitung von Kommunikationen basierend auf der Verknüpfungsqualität
US8966457B2 (en) * 2011-11-15 2015-02-24 Global Supercomputing Corporation Method and system for converting a single-threaded software program into an application-specific supercomputer
US8948175B2 (en) 2011-11-18 2015-02-03 Ciena Corporation Selecting a link of a link group based on contents of a concealed header
US9065749B2 (en) 2011-11-21 2015-06-23 Qualcomm Incorporated Hybrid networking path selection and load balancing
CN104115129B (zh) 2011-12-21 2017-09-08 英特尔公司 用于从处理器到存储器子系统智能刷新数据的系统和方法
US9055114B1 (en) 2011-12-22 2015-06-09 Juniper Networks, Inc. Packet parsing and control packet classification
US8996840B2 (en) 2011-12-23 2015-03-31 International Business Machines Corporation I/O controller and method for operating an I/O controller
DE112013000601T5 (de) * 2012-01-17 2014-12-18 Intel Corporation Techniken für die Befehlsbestätigung für den Zugriff auf ein Speichergerät durch einen entfernten Client
US8908682B2 (en) * 2012-02-02 2014-12-09 International Business Machines Corporation Switch discovery protocol for a distributed fabric system
US8868735B2 (en) 2012-02-02 2014-10-21 Cisco Technology, Inc. Wide area network optimization
US8812005B2 (en) 2012-02-03 2014-08-19 Apple Inc. System and method for scheduling packet transmission on a client device using traffic classes and opportunistic behavior
US9007901B2 (en) 2012-02-09 2015-04-14 Alcatel Lucent Method and apparatus providing flow control using on-off signals in high delay networks
US9960872B2 (en) 2012-03-08 2018-05-01 Marvell International Ltd. Systems and methods for performing a soft-block of a queue based on a size of a remaining period of a guard band
US9088496B2 (en) 2012-03-16 2015-07-21 Brocade Communications Systems, Inc. Packet tracing through control and data plane operations
US9264382B2 (en) 2012-05-11 2016-02-16 Oracle International Corporation System and method for routing traffic between distinct infiniband subnets based on fat-tree routing
CN104303472B (zh) 2012-05-15 2018-03-16 马维尔国际贸易有限公司 以太网包的扩展优先级
US10936591B2 (en) 2012-05-15 2021-03-02 Microsoft Technology Licensing, Llc Idempotent command execution
US9122810B2 (en) 2012-05-18 2015-09-01 Dell Products, Lp System and method for providing input/output functionality to a processing node
US9898317B2 (en) 2012-06-06 2018-02-20 Juniper Networks, Inc. Physical path determination for virtual network packet flows
US8817807B2 (en) 2012-06-11 2014-08-26 Cisco Technology, Inc. System and method for distributed resource control of switches in a network environment
US8989049B2 (en) 2012-06-15 2015-03-24 Cisco Technology, Inc. System and method for virtual portchannel load balancing in a trill network
JP2014007681A (ja) 2012-06-27 2014-01-16 Hitachi Ltd ネットワークシステム、および、その管理装置、そのスイッチ
ES2395955B2 (es) * 2012-07-05 2014-01-22 Universidad De Cantabria Método de encaminamiento adaptativo en redes jerárquicas
US20140036680A1 (en) 2012-07-31 2014-02-06 Futurewei Technologies, Inc. Method to Allocate Packet Buffers in a Packet Transferring System
US9049137B1 (en) 2012-08-06 2015-06-02 Google Inc. Hash based ECMP load balancing with non-power-of-2 port group sizes
US9635121B2 (en) 2012-08-06 2017-04-25 Paypal, Inc. Systems and methods for caching HTTP post requests and responses
US9705804B2 (en) 2012-08-30 2017-07-11 Sonus Networks, Inc. Opportunistic wireless resource utilization using dynamic traffic shaping
US9350665B2 (en) 2012-08-31 2016-05-24 Cisco Technology, Inc. Congestion mitigation and avoidance
CN103227757B (zh) * 2012-08-31 2016-12-28 杭州华三通信技术有限公司 一种报文转发方法及设备
US9424214B2 (en) 2012-09-28 2016-08-23 Mellanox Technologies Ltd. Network interface controller with direct connection to host memory
US9049233B2 (en) 2012-10-05 2015-06-02 Cisco Technology, Inc. MPLS segment-routing
US9215093B2 (en) 2012-10-30 2015-12-15 Futurewei Technologies, Inc. Encoding packets for transport over SDN networks
CN102932203B (zh) 2012-10-31 2015-06-10 东软集团股份有限公司 异构平台间的深度报文检测方法及装置
US9424228B2 (en) 2012-11-01 2016-08-23 Ezchip Technologies Ltd. High performance, scalable multi chip interconnect
US9286620B2 (en) 2012-11-05 2016-03-15 Broadcom Corporation Annotated tracing for data networks
JP5958293B2 (ja) 2012-11-14 2016-07-27 富士通株式会社 通信方法、通信プログラム、および、ノード装置
US8989017B2 (en) 2012-12-14 2015-03-24 Intel Corporation Network congestion management by packet circulation
US9094321B2 (en) 2013-01-03 2015-07-28 International Business Machines Corporation Energy management for communication network elements
US9154438B2 (en) 2013-01-24 2015-10-06 Cisco Technology, Inc. Port-based fairness protocol for a network element
US9460178B2 (en) 2013-01-25 2016-10-04 Dell Products L.P. Synchronized storage system operation
US9634940B2 (en) * 2013-01-31 2017-04-25 Mellanox Technologies, Ltd. Adaptive routing using inter-switch notifications
US9544220B2 (en) * 2013-02-05 2017-01-10 Cisco Technology, Inc. Binary search-based approach in routing-metric agnostic topologies for node selection to enable effective learning machine mechanisms
US9705957B2 (en) 2013-03-04 2017-07-11 Open Garden Inc. Virtual channel joining
US10275375B2 (en) 2013-03-10 2019-04-30 Mellanox Technologies, Ltd. Network interface controller with compression capabilities
US11966355B2 (en) 2013-03-10 2024-04-23 Mellanox Technologies, Ltd. Network adapter with a common queue for both networking and data manipulation work requests
US9053012B1 (en) 2013-03-15 2015-06-09 Pmc-Sierra, Inc. Systems and methods for storing data for solid-state memory
US9769074B2 (en) * 2013-03-15 2017-09-19 International Business Machines Corporation Network per-flow rate limiting
US9444748B2 (en) * 2013-03-15 2016-09-13 International Business Machines Corporation Scalable flow and congestion control with OpenFlow
US9253096B2 (en) 2013-03-15 2016-02-02 International Business Machines Corporation Bypassing congestion points in a converged enhanced ethernet fabric
CN105191235A (zh) * 2013-03-20 2015-12-23 马维尔国际贸易有限公司 针对慢速和快速端口的直通处理
US9692706B2 (en) 2013-04-15 2017-06-27 International Business Machines Corporation Virtual enhanced transmission selection (VETS) for lossless ethernet
US9571402B2 (en) 2013-05-03 2017-02-14 Netspeed Systems Congestion control and QoS in NoC by regulating the injection traffic
US9075557B2 (en) * 2013-05-15 2015-07-07 SanDisk Technologies, Inc. Virtual channel for data transfers between devices
US9788210B2 (en) 2013-06-11 2017-10-10 Sonus Networks, Inc. Methods and systems for adaptive buffer allocations in systems with adaptive resource allocation
US9405724B2 (en) 2013-06-28 2016-08-02 Intel Corporation Reconfigurable apparatus for hierarchical collective networks with bypass mode
EP3014821A4 (de) 2013-06-28 2017-02-22 Intel Corporation Mechanismus zur steuerung eines ressourcenverbrauchs mit adaptiver leitweglenkung
US9674098B2 (en) * 2013-07-02 2017-06-06 Intel Corporation Credit flow control for ethernet
US9282041B2 (en) * 2013-07-16 2016-03-08 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Congestion profiling of computer network devices
US9467522B2 (en) 2013-07-19 2016-10-11 Broadcom Corporation Ingress based headroom buffering for switch architectures
US9781041B2 (en) 2013-07-24 2017-10-03 Dell Products Lp Systems and methods for native network interface controller (NIC) teaming load balancing
CN105556908B (zh) 2013-08-28 2019-05-28 Kt株式会社 基于多流式分组的带宽提供方法
US9509550B2 (en) 2013-08-30 2016-11-29 Microsoft Technology Licensing, Llc Generating an idempotent workflow
US10261813B2 (en) 2013-09-25 2019-04-16 Arm Limited Data processing system for dispatching tasks from a plurality of applications to a shared resource provided by an accelerator
US9276771B1 (en) * 2013-09-27 2016-03-01 Google Inc. Lossless multipath table compression
US9239804B2 (en) 2013-10-03 2016-01-19 Advanced Micro Devices, Inc. Back-off mechanism for a peripheral page request log
US20150103667A1 (en) 2013-10-13 2015-04-16 Mellanox Technologies Ltd. Detection of root and victim network congestion
US10089220B1 (en) 2013-11-01 2018-10-02 Amazon Technologies, Inc. Saving state information resulting from non-idempotent operations in non-volatile system memory
US9740606B1 (en) 2013-11-01 2017-08-22 Amazon Technologies, Inc. Reliable distributed messaging using non-volatile system memory
EP3605971B1 (de) 2013-11-05 2021-10-13 Cisco Technology, Inc. Netzwerk-fabric-überlagerung
CN104639470B (zh) * 2013-11-14 2019-05-31 中兴通讯股份有限公司 流标识封装方法及系统
US9674042B2 (en) 2013-11-25 2017-06-06 Amazon Technologies, Inc. Centralized resource usage visualization service for large-scale network topologies
US9762497B2 (en) 2013-11-26 2017-09-12 Avago Technologies General Ip (Singapore) Pte. Ltd. System, method and apparatus for network congestion management and network resource isolation
US9419908B2 (en) * 2013-11-27 2016-08-16 Cisco Technology, Inc. Network congestion management using flow rebalancing
US9311044B2 (en) 2013-12-04 2016-04-12 Oracle International Corporation System and method for supporting efficient buffer usage with a single external memory interface
US10158538B2 (en) 2013-12-09 2018-12-18 Nicira, Inc. Reporting elephant flows to a network controller
US9455915B2 (en) 2013-12-12 2016-09-27 Broadcom Corporation Hierarchical congestion control with congested flow identification hardware
US9648148B2 (en) 2013-12-24 2017-05-09 Intel Corporation Method, apparatus, and system for QoS within high performance fabrics
US9495204B2 (en) 2014-01-06 2016-11-15 International Business Machines Corporation Constructing a logical tree topology in a parallel computer
US9513926B2 (en) 2014-01-08 2016-12-06 Cavium, Inc. Floating mask generation for network packet flow
KR102171348B1 (ko) * 2014-01-08 2020-10-29 삼성전자주식회사 어플리케이션 검출 방법 및 장치
US9391844B2 (en) 2014-01-15 2016-07-12 Dell Products, L.P. System and method for network topology management
CN104811396A (zh) * 2014-01-23 2015-07-29 中兴通讯股份有限公司 一种负荷均衡的方法及系统
JP2015146115A (ja) 2014-02-03 2015-08-13 富士通株式会社 演算処理装置、情報処理装置及び演算処理装置の制御方法
US9753883B2 (en) 2014-02-04 2017-09-05 Netronome Systems, Inc. Network interface device that maps host bus writes of configuration information for virtual NIDs into a small transactional memory
US9628382B2 (en) * 2014-02-05 2017-04-18 Intel Corporation Reliable transport of ethernet packet data with wire-speed and packet data rate match
KR102093296B1 (ko) * 2014-02-11 2020-03-25 한국전자통신연구원 시간 확정적으로 대용량 경로를 전환하는 데이터 처리 시스템 및 데이터 처리 시스템의 동작 방법
US9584637B2 (en) 2014-02-19 2017-02-28 Netronome Systems, Inc. Guaranteed in-order packet delivery
US20150244804A1 (en) 2014-02-21 2015-08-27 Coho Data, Inc. Methods, systems and devices for parallel network interface data structures with differential data storage service capabilities
US9294385B2 (en) * 2014-03-03 2016-03-22 International Business Machines Corporation Deadlock-free routing in fat tree networks
KR101587379B1 (ko) 2014-03-04 2016-01-20 주식회사 케이티 큐 사이즈의 동적 제어 방법 및 이를 수행하는 장치
US9762488B2 (en) 2014-03-06 2017-09-12 Cisco Technology, Inc. Segment routing extension headers
US9838500B1 (en) 2014-03-11 2017-12-05 Marvell Israel (M.I.S.L) Ltd. Network device and method for packet processing
US9325641B2 (en) 2014-03-13 2016-04-26 Mellanox Technologies Ltd. Buffering schemes for communication over long haul links
US9727503B2 (en) 2014-03-17 2017-08-08 Mellanox Technologies, Ltd. Storage system and server
WO2015142336A1 (en) 2014-03-20 2015-09-24 Intel Corporation A method, apparatus, and system for controlling power consumption of unused hardware of a link interface
US20160154756A1 (en) 2014-03-31 2016-06-02 Avago Technologies General Ip (Singapore) Pte. Ltd Unordered multi-path routing in a pcie express fabric environment
US9846658B2 (en) * 2014-04-21 2017-12-19 Cisco Technology, Inc. Dynamic temporary use of packet memory as resource memory
CN103973482A (zh) * 2014-04-22 2014-08-06 南京航空航天大学 具有全局通信事务管理能力的容错片上网络系统及方法
US10142220B2 (en) 2014-04-29 2018-11-27 Hewlett Packard Enterprise Development Lp Efficient routing in software defined networks
US10031857B2 (en) 2014-05-27 2018-07-24 Mellanox Technologies, Ltd. Address translation services for direct accessing of local memory over a network fabric
US10261814B2 (en) 2014-06-23 2019-04-16 Intel Corporation Local service chaining with virtual machines and virtualized containers in software defined networking
US9930097B2 (en) * 2014-07-03 2018-03-27 Qualcomm Incorporated Transport accelerator systems and methods
US9519605B2 (en) 2014-07-08 2016-12-13 International Business Machines Corporation Interconnection network topology for large scale high performance computing (HPC) systems
US9369397B1 (en) * 2014-07-16 2016-06-14 Juniper Networks, Inc. Apparatus to achieve quality of service (QoS) without requiring fabric speedup
US9699067B2 (en) 2014-07-22 2017-07-04 Mellanox Technologies, Ltd. Dragonfly plus: communication over bipartite node groups connected by a mesh network
US10257083B2 (en) 2014-08-29 2019-04-09 Cisco Technology, Inc. Flow cache based mechanism of packet redirection in multiple border routers for application awareness
US9742855B2 (en) 2014-09-04 2017-08-22 Mellanox Technologies, Ltd. Hybrid tag matching
EP3192299B1 (de) 2014-09-10 2020-01-15 Telefonaktiebolaget LM Ericsson (publ) Explizite überlastungsbenachrichtigungsmarkierung von benutzerverkehr
US9882814B2 (en) * 2014-09-25 2018-01-30 Intel Corporation Technologies for bridging between coarse-grained and fine-grained load balancing
US9548872B2 (en) 2014-09-26 2017-01-17 Dell Products, Lp Reducing internal fabric congestion in leaf-spine switch fabric
WO2016061766A1 (zh) 2014-10-22 2016-04-28 华为技术有限公司 对象存储系统中的业务流控制方法、控制器和系统
US9722932B1 (en) * 2014-10-28 2017-08-01 Amazon Technologies, Inc. Packet path selection using shuffle sharding
US10153967B2 (en) 2014-11-06 2018-12-11 Juniper Networks, Inc. Deterministic and optimized bit index explicit replication (BIER) forwarding
US10033641B2 (en) 2014-11-06 2018-07-24 Juniper Networks, Inc. Deterministic and optimized bit index explicit replication (BIER) forwarding
GB2532052A (en) 2014-11-07 2016-05-11 Ibm NC-SI port controller
GB2532053A (en) 2014-11-07 2016-05-11 Ibm NC-SI port controller
US10148738B2 (en) 2014-11-12 2018-12-04 Zuora, Inc. System and method for equitable processing of asynchronous messages in a multi-tenant platform
US10050896B2 (en) 2014-11-14 2018-08-14 Cavium, Inc. Management of an over-subscribed shared buffer
US10003544B2 (en) 2014-12-11 2018-06-19 Futurewei Technologies, Inc. Method and apparatus for priority flow and congestion control in ethernet network
US9369200B1 (en) 2014-12-18 2016-06-14 Juniper Networks, Inc. Network controller having predictable analytics and failure avoidance in packet-optical networks
US10148575B2 (en) 2014-12-22 2018-12-04 Telefonaktiebolaget Lm Ericsson (Publ) Adaptive load balancing in packet processing
US9800508B2 (en) 2015-01-09 2017-10-24 Dell Products L.P. System and method of flow shaping to reduce impact of incast communications
WO2016122637A1 (en) 2015-01-30 2016-08-04 Hewlett Packard Enterprise Development Lp Non-idempotent primitives in fault-tolerant memory
US9894000B2 (en) 2015-01-30 2018-02-13 Huawei Technologies Co., Ltd Method for forwarding data packets in a network and programmable ingress and egress nodes therefore
US9894013B2 (en) 2015-02-03 2018-02-13 Avago Technologies General Ip (Singapore) Pte. Ltd. Early queueing network device
US20160241474A1 (en) * 2015-02-12 2016-08-18 Ren Wang Technologies for modular forwarding table scalability
US9594521B2 (en) 2015-02-23 2017-03-14 Advanced Micro Devices, Inc. Scheduling of data migration
US10341221B2 (en) 2015-02-26 2019-07-02 Cisco Technology, Inc. Traffic engineering for bit indexed explicit replication
US10009270B1 (en) 2015-03-01 2018-06-26 Netronome Systems, Inc. Modular and partitioned SDN switch
US10033574B2 (en) 2015-03-20 2018-07-24 Oracle International Corporation System and method for efficient network reconfiguration in fat-trees
US20170237654A1 (en) 2015-03-25 2017-08-17 Hewlett Packard Enterprise Development Lp Fast failover recovery in software defined networks
CN107209724B (zh) 2015-03-27 2020-02-14 华为技术有限公司 数据处理方法、内存管理单元及内存控制设备
WO2016159945A1 (en) 2015-03-28 2016-10-06 Intel Corporation Distributed routing table system with improved support for multiple network topologies
US10305772B2 (en) 2015-03-30 2019-05-28 Mellanox Technologies, Ltd. Using a single work item to send multiple messages
US9444769B1 (en) * 2015-03-31 2016-09-13 Chelsio Communications, Inc. Method for out of order placement in PDU-oriented protocols
US9876698B2 (en) 2015-04-09 2018-01-23 International Business Machines Corporation Interconnect congestion control in a storage grid
US10180792B1 (en) * 2015-04-30 2019-01-15 Seagate Technology Llc Cache management in data storage systems
US9842083B2 (en) 2015-05-18 2017-12-12 Red Hat Israel, Ltd. Using completion queues for RDMA event detection
US10033638B1 (en) * 2015-05-29 2018-07-24 Netronome Systems, Inc. Executing a selected sequence of instructions depending on packet type in an exact-match flow switch
US10158712B2 (en) * 2015-06-04 2018-12-18 Advanced Micro Devices, Inc. Source-side resource request network admission control
US9847936B2 (en) * 2015-06-25 2017-12-19 Intel Corporation Apparatus and method for hardware-accelerated packet processing
US9674090B2 (en) 2015-06-26 2017-06-06 Microsoft Technology Licensing, Llc In-line network accelerator
US9888095B2 (en) 2015-06-26 2018-02-06 Microsoft Technology Licensing, Llc Lightweight transport protocol
US9942171B2 (en) 2015-07-02 2018-04-10 Arista Networks, Inc. Network data processor having per-input port virtual output queues
KR102430187B1 (ko) * 2015-07-08 2022-08-05 삼성전자주식회사 RDMA NVMe 디바이스의 구현 방법
EP3323227B1 (de) * 2015-07-16 2020-06-03 Telefonaktiebolaget LM Ericsson (PUBL) Wiederherstellen eines mpls-ringnetzwerks
US9626232B2 (en) 2015-07-23 2017-04-18 Arm Limited Event queue management
US9830273B2 (en) 2015-07-30 2017-11-28 Netapp, Inc. Deduplicated host cache flush to remote storage
US10009277B2 (en) * 2015-08-04 2018-06-26 Mellanox Technologies Tlv Ltd. Backward congestion notification in layer-3 networks
US20170048144A1 (en) 2015-08-13 2017-02-16 Futurewei Technologies, Inc. Congestion Avoidance Traffic Steering (CATS) in Datacenter Networks
US9749266B2 (en) 2015-08-28 2017-08-29 International Business Machines Corporation Coalescing messages using a network interface controller
US10284383B2 (en) * 2015-08-31 2019-05-07 Mellanox Technologies, Ltd. Aggregation protocol
CN108353030B (zh) * 2015-09-02 2021-02-19 瑞典爱立信有限公司 用于处理无线无线电自组织网络中的应答的方法和设备
US10193824B2 (en) 2015-09-06 2019-01-29 RISC Networks, LLC Systems and methods for intelligent application grouping
CN106559336B (zh) 2015-09-24 2020-04-03 新华三技术有限公司 应用于sdn中的路径倒换方法、转发表项下发方法和装置
US20170093770A1 (en) * 2015-09-25 2017-03-30 Intel Corporation Technologies for receive side message inspection and filtering
US10120809B2 (en) 2015-09-26 2018-11-06 Intel Corporation Method, apparatus, and system for allocating cache using traffic class
US10216533B2 (en) 2015-10-01 2019-02-26 Altera Corporation Efficient virtual I/O address translation
US10652112B2 (en) * 2015-10-02 2020-05-12 Keysight Technologies Singapore (Sales) Pte. Ltd. Network traffic pre-classification within VM platforms in virtual processing environments
US10423625B2 (en) 2015-10-08 2019-09-24 Samsung Sds America, Inc. Exactly-once semantics for streaming analytics in non-idempotent output operations
US10063481B1 (en) 2015-11-10 2018-08-28 U.S. Department Of Energy Network endpoint congestion management
US20170153852A1 (en) 2015-11-30 2017-06-01 Mediatek Inc. Multi-port memory controller capable of serving multiple access requests by accessing different memory banks of multi-bank packet buffer and associated packet storage design
JP6244349B2 (ja) * 2015-12-17 2017-12-06 アンリツ株式会社 移動端末試験装置とそのフロー制御閾値の設定方法
US10423568B2 (en) 2015-12-21 2019-09-24 Microsemi Solutions (U.S.), Inc. Apparatus and method for transferring data and commands in a memory management environment
US10498654B2 (en) * 2015-12-28 2019-12-03 Amazon Technologies, Inc. Multi-path transport design
US9959214B1 (en) * 2015-12-29 2018-05-01 Amazon Technologies, Inc. Emulated translation unit using a management processor
US9985903B2 (en) 2015-12-29 2018-05-29 Amazon Technologies, Inc. Reliable, out-of-order receipt of packets
US9985904B2 (en) 2015-12-29 2018-05-29 Amazon Technolgies, Inc. Reliable, out-of-order transmission of packets
CN106936713B (zh) * 2015-12-30 2020-02-21 华为技术有限公司 一种标签管理方法，数据流处理方法及设备
US10331569B2 (en) * 2016-01-05 2019-06-25 Friday Harbor Llc Packet router buffer management
US10616118B2 (en) * 2016-01-28 2020-04-07 Oracle International Corporation System and method for supporting aggressive credit waiting in a high performance computing environment
EP3420690B1 (de) * 2016-02-25 2019-11-13 Telefonaktiebolaget LM Ericsson (PUBL) Rückdrucksteuerung in einem telekommunikationsnetz
US10355981B1 (en) * 2016-03-02 2019-07-16 Innovium, Inc. Sliding windows
US10175891B1 (en) * 2016-03-15 2019-01-08 Pavilion Data Systems, Inc. Minimizing read latency for solid state drives
US10079782B2 (en) 2016-03-31 2018-09-18 Mellanox Technologies Tlv Ltd. Facilitating communication of data packets using credit-based flow control
US10120814B2 (en) 2016-04-01 2018-11-06 Intel Corporation Apparatus and method for lazy translation lookaside buffer (TLB) coherence
US9985891B2 (en) 2016-04-07 2018-05-29 Oracle International Corporation Congestion management in distributed systems using autonomous self-regulation
US10461864B2 (en) 2016-04-14 2019-10-29 Calix, Inc. Channel bonding techniques in a network
JP6750985B2 (ja) 2016-04-15 2020-09-02 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 通信装置および通信方法
US10454830B2 (en) 2016-05-05 2019-10-22 City University Of Hong Kong System and method for load balancing in a data network
US10732621B2 (en) 2016-05-09 2020-08-04 Strong Force Iot Portfolio 2016, Llc Methods and systems for process adaptation in an internet of things downstream oil and gas environment
CN107493238A (zh) * 2016-06-13 2017-12-19 华为技术有限公司 一种网络拥塞控制方法、设备及系统
US10430374B2 (en) 2016-06-29 2019-10-01 Mellanox Technologies, Ltd. Selective acknowledgement of RDMA packets
US10331590B2 (en) 2016-06-30 2019-06-25 Intel Corporation Graphics processing unit (GPU) as a programmable packet transfer mechanism
US10305805B2 (en) 2016-07-01 2019-05-28 Intel Corporation Technologies for adaptive routing using aggregated congestion information
US10432532B2 (en) 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US20180026878A1 (en) 2016-07-24 2018-01-25 Mellanox Technologies Tlv Ltd. Scalable deadlock-free deterministic minimal-path routing for dragonfly networks
US10419808B2 (en) 2016-09-08 2019-09-17 Gvbb Holdings S.A.R.L. System and method for scalable physical layer flow of packetized media streams
US10715446B2 (en) 2016-09-12 2020-07-14 Huawei Technologies Co., Ltd. Methods and systems for data center load balancing
US10061613B1 (en) 2016-09-23 2018-08-28 Amazon Technologies, Inc. Idempotent task execution in on-demand network code execution systems
US10623526B2 (en) 2016-10-03 2020-04-14 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Dynamically configuring multi-mode hardware components based on workload requirements
US10936533B2 (en) * 2016-10-18 2021-03-02 Advanced Micro Devices, Inc. GPU remote communication with triggered operations
US20180115469A1 (en) 2016-10-21 2018-04-26 Forward Networks, Inc. Systems and methods for an interactive network analysis platform
US10397058B2 (en) * 2016-10-31 2019-08-27 Cisco Technology, Inc. Full path diversity for virtual acess point (VAP) enabled networks
US10656972B2 (en) 2016-11-10 2020-05-19 International Business Machines Corporation Managing idempotent operations while interacting with a system of record
US10425327B2 (en) 2016-11-10 2019-09-24 Argela Yazilim Ve Bilisim Teknolojileri San Ve Tic. A.S. System and method for routing in software defined networks using a flow header
US10084687B1 (en) * 2016-11-17 2018-09-25 Barefoot Networks, Inc. Weighted-cost multi-pathing using range lookups
US20180150256A1 (en) 2016-11-29 2018-05-31 Intel Corporation Technologies for data deduplication in disaggregated architectures
US10423511B2 (en) 2016-11-29 2019-09-24 International Business Machines Corporation Packet flow tracing in a parallel processor complex
US10171369B2 (en) 2016-12-22 2019-01-01 Huawei Technologies Co., Ltd. Systems and methods for buffer management
US10394784B2 (en) * 2016-12-22 2019-08-27 Intel Corporation Technologies for management of lookup tables
WO2018119843A1 (en) 2016-12-29 2018-07-05 Intel Corporation Network interface controller with non-volatile random access memory write packet log
US10320677B2 (en) * 2017-01-02 2019-06-11 Microsoft Technology Licensing, Llc Flow control and congestion management for acceleration components configured to accelerate a service
US10326696B2 (en) 2017-01-02 2019-06-18 Microsoft Technology Licensing, Llc Transmission of messages by acceleration components configured to accelerate a service
US10454835B2 (en) 2017-01-20 2019-10-22 Google Llc Device and method for scalable traffic shaping with a time-indexed data structure
US10284472B2 (en) 2017-01-24 2019-05-07 Cisco Technology, Inc. Dynamic and compressed trie for use in route lookup
US10498672B2 (en) 2017-01-30 2019-12-03 Mellanox Technologies, Ltd. Mechanism for distributing MPI tag matching
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US10402355B2 (en) 2017-02-08 2019-09-03 Texas Instruments Incorporated Apparatus and mechanism to bypass PCIe address translation by using alternative routing
US10389646B2 (en) 2017-02-15 2019-08-20 Mellanox Technologies Tlv Ltd. Evading congestion spreading for victim flows
US10404619B1 (en) 2017-03-05 2019-09-03 Barefoot Networks, Inc. Link aggregation group failover for multicast
US10237206B1 (en) 2017-03-05 2019-03-19 Barefoot Networks, Inc. Equal cost multiple path group failover for multicast
US10360149B2 (en) 2017-03-10 2019-07-23 Oracle International Corporation Data structure store in persistent memory
US10419329B2 (en) 2017-03-30 2019-09-17 Mellanox Technologies Tlv Ltd. Switch-based reliable multicast service
WO2018176393A1 (en) 2017-03-31 2018-10-04 Intel Corporation Techniques for virtual machine transfer and resource management
US10579412B2 (en) * 2017-04-07 2020-03-03 Nec Corporation Method for operating virtual machines on a virtualization platform and corresponding virtualization platform
US10476629B2 (en) 2017-05-02 2019-11-12 Juniper Networks, Inc. Performing upper layer inspection of a flow based on a sampling rate
US11212048B2 (en) * 2017-05-05 2021-12-28 Samsung Electronics Co., Ltd. System, data transmission method and network equipment supporting PDCP duplication function method and device for transferring supplementary uplink carrier configuration information and method and device for performing connection mobility adjustment
CN108809847B (zh) * 2017-05-05 2021-11-19 华为技术有限公司 实现负载均衡的方法、装置和网络系统
US10423357B2 (en) 2017-05-18 2019-09-24 Avago Technologies International Sales Pte. Limited Devices and methods for managing memory buffers
US20180341494A1 (en) 2017-05-26 2018-11-29 Intel Corporation Accelerating network security monitoring
US10862617B2 (en) * 2017-05-30 2020-12-08 Marvell Asia Pte, Ltd. Flowlet scheduler for multicore network processors
US10499376B2 (en) * 2017-06-16 2019-12-03 Kt Corporation Methods for managing resource based on open interface and apparatuses thereof
US10855420B2 (en) * 2017-06-16 2020-12-01 Ofinno, Llc Distributed unit configuration update
WO2018236867A2 (en) * 2017-06-19 2018-12-27 Intel Corporation CONTROL PANEL AND USER PLANE SEPARATION IN NEW RADIO (NR) SYSTEMS
CN109218215B (zh) * 2017-06-29 2021-11-19 华为技术有限公司 一种报文传输的方法和网络设备
US11362968B2 (en) 2017-06-30 2022-06-14 Intel Corporation Technologies for dynamic batch size management
US10353833B2 (en) 2017-07-11 2019-07-16 International Business Machines Corporation Configurable ordering controller for coupling transactions
US10467159B2 (en) 2017-07-14 2019-11-05 Arm Limited Memory node controller
US10541866B2 (en) 2017-07-25 2020-01-21 Cisco Technology, Inc. Detecting and resolving multicast traffic performance issues
US9853900B1 (en) 2017-08-07 2017-12-26 Mellanox Technologies Tlv Ltd. Using consistent hashing for ECMP routing
KR102380619B1 (ko) * 2017-08-11 2022-03-30 삼성전자 주식회사 이동 통신 시스템 망에서 혼잡 제어를 효율적으로 수행하는 방법 및 장치
US10498631B2 (en) 2017-08-15 2019-12-03 Hewlett Packard Enterprise Development Lp Routing packets using distance classes
US10374943B2 (en) * 2017-08-16 2019-08-06 Hewlett Packard Enterprise Development Lp Routing packets in dimensional order in multidimensional networks
US20190058663A1 (en) 2017-08-18 2019-02-21 Futurewei Technologies, Inc. Flowlet-Based Load Balancing
US10693787B2 (en) 2017-08-25 2020-06-23 Intel Corporation Throttling for bandwidth imbalanced data transfers
US20190044809A1 (en) * 2017-08-30 2019-02-07 Intel Corporation Technologies for managing a flexible host interface of a network interface controller
JP6897434B2 (ja) * 2017-08-31 2021-06-30 富士通株式会社 情報処理システム、情報処理装置及び情報処理プログラム
US11194753B2 (en) 2017-09-01 2021-12-07 Intel Corporation Platform interface layer and protocol for accelerators
JP6833644B2 (ja) 2017-09-13 2021-02-24 株式会社東芝 転送装置、転送方法及びプログラム
US10880204B1 (en) * 2017-09-26 2020-12-29 Amazon Technologies, Inc. Low latency access for storage using multiple paths
US10789011B2 (en) 2017-09-27 2020-09-29 Alibaba Group Holding Limited Performance enhancement of a storage device using an integrated controller-buffer
US11178262B2 (en) 2017-09-29 2021-11-16 Fungible, Inc. Fabric control protocol for data center networks with packet spraying over multiple alternate data paths
US10965586B2 (en) 2017-09-29 2021-03-30 Fungible, Inc. Resilient network communication using selective multipath packet flow spraying
US10200279B1 (en) 2017-10-03 2019-02-05 Amer Omar Aljaedi Tracer of traffic trajectories in data center networks
US20190108332A1 (en) 2017-10-06 2019-04-11 Elwha Llc Taint injection and tracking
CN109660463A (zh) 2017-10-11 2019-04-19 华为技术有限公司 一种拥塞流识别方法及网络设备
US11502948B2 (en) * 2017-10-16 2022-11-15 Mellanox Technologies, Ltd. Computational accelerator for storage operations
EP4236255A1 (de) 2017-11-06 2023-08-30 Huawei Technologies Co., Ltd. Paketweiterleitungsverfahren, weiterleitungsvorrichtung und netzwerkvorrichtung
US10841243B2 (en) 2017-11-08 2020-11-17 Mellanox Technologies, Ltd. NIC with programmable pipeline
CN109936510B (zh) 2017-12-15 2022-11-15 微软技术许可有限责任公司 多路径rdma传输
KR101850749B1 (ko) 2017-12-18 2018-04-20 주식회사 에프아이시스 멀티 코어 기반 nic에서 동적 패킷 버퍼 할당 방법
US10552344B2 (en) 2017-12-26 2020-02-04 Intel Corporation Unblock instruction to reverse page block during paging
US11157336B2 (en) 2017-12-30 2021-10-26 Intel Corporation Technologies for extending triggered operations
US11277350B2 (en) 2018-01-09 2022-03-15 Intel Corporation Communication of a large message using multiple network interface controllers
IL276064B2 (en) * 2018-02-15 2024-04-01 Vitec Inc Distribution and playback of media content
US10986021B2 (en) 2018-03-06 2021-04-20 International Business Machines Corporation Flow management in networks
US10789194B2 (en) 2018-03-26 2020-09-29 Nvidia Corporation Techniques for efficiently synchronizing data transmissions on a network
US11082347B2 (en) * 2018-03-26 2021-08-03 Nvidia Corporation Techniques for reducing congestion in a computer network
CN110324249B (zh) 2018-03-28 2023-05-26 清华大学 一种蜻蜓网络架构及其组播路由方法
US20190044872A1 (en) 2018-03-30 2019-02-07 Intel Corporation Technologies for targeted flow control recovery
US20190044827A1 (en) 2018-03-30 2019-02-07 Intel Corporatoin Communication of a message using a network interface controller on a subnet
US10567307B2 (en) 2018-04-27 2020-02-18 Avago Technologies International Sales Pte. Limited Traffic management for high-bandwidth switching
US10887231B2 (en) * 2018-05-18 2021-01-05 Juniper Networks, Inc. Packet fragment forwarding without reassembly
US10789200B2 (en) * 2018-06-01 2020-09-29 Dell Products L.P. Server message block remote direct memory access persistent memory dialect
EP3808041A1 (de) * 2018-06-14 2021-04-21 Nokia Solutions and Networks Oy Flussspezifische schnelle umleitung von source-routed-paketen
US10958587B2 (en) 2018-07-24 2021-03-23 Intel Corporation Transmission latency reduction
US20190114195A1 (en) 2018-08-22 2019-04-18 Intel Corporation Virtual device composition in a scalable input/output (i/o) virtualization (s-iov) architecture
US11102129B2 (en) 2018-09-09 2021-08-24 Mellanox Technologies, Ltd. Adjusting rate of outgoing data requests for avoiding incast congestion
US11444886B1 (en) 2018-09-21 2022-09-13 Marvell Asia Pte Ltd Out of order packet buffer selection
US10802828B1 (en) 2018-09-27 2020-10-13 Amazon Technologies, Inc. Instruction memory
US10820057B2 (en) 2018-11-07 2020-10-27 Nvidia Corp. Scalable light-weight protocols for wire-speed packet ordering
DE112019005604T5 (de) 2018-11-08 2021-09-09 Intel Corporation Function-as-a-service-system-verbesserungen (faas-system-verbesserungen)
US11108704B2 (en) 2018-12-04 2021-08-31 Nvidia Corp. Use of stashing buffers to improve the efficiency of crossbar switches
US11416749B2 (en) 2018-12-11 2022-08-16 Amazon Technologies, Inc. Execution synchronization and tracking
US10754816B2 (en) * 2018-12-21 2020-08-25 Intel Corporation Time sensitive networking device
US11025564B2 (en) 2019-02-22 2021-06-01 Microsoft Technology Licensing, Llc RDMA transport with hardware integration and out of order placement
US11068412B2 (en) 2019-02-22 2021-07-20 Microsoft Technology Licensing, Llc RDMA transport with hardware integration
US11805065B2 (en) * 2019-02-27 2023-10-31 Intel Corporation Scalable traffic management using one or more processor cores for multiple levels of quality of service
US11743240B2 (en) 2019-03-08 2023-08-29 Intel Corporation Secure stream protocol for serial interconnect
US10970238B2 (en) 2019-04-19 2021-04-06 Intel Corporation Non-posted write transactions for a computer bus
US11099891B2 (en) * 2019-04-22 2021-08-24 International Business Machines Corporation Scheduling requests based on resource information
US11088967B2 (en) 2019-04-26 2021-08-10 Intel Corporation Shared resources for multiple communication traffics
US10922250B2 (en) 2019-04-30 2021-02-16 Microsoft Technology Licensing, Llc Monitoring and steering service requests to acceleration components
US10931588B1 (en) * 2019-05-10 2021-02-23 Innovium, Inc. Network switch with integrated compute subsystem for distributed artificial intelligence and other applications
US10740243B1 (en) * 2019-05-13 2020-08-11 Western Digital Technologies, Inc. Storage system and method for preventing head-of-line blocking in a completion path
US20200364088A1 (en) * 2019-05-16 2020-11-19 Nvidia Corporation Resource sharing by two or more heterogeneous processing cores
EP3942749A4 (de) 2019-05-23 2023-06-07 Hewlett Packard Enterprise Development LP Optimiertes adaptives routing zur reduzierung der anzahl von sprüngen
US11381515B2 (en) 2019-06-28 2022-07-05 Intel Corporation On-demand packet queuing in a network device
US11128561B1 (en) 2019-07-29 2021-09-21 Innovium, Inc. Auto load balancing
US11057318B1 (en) * 2019-08-27 2021-07-06 Innovium, Inc. Distributed artificial intelligence extension modules for network switches
CN110601888B (zh) 2019-09-10 2020-11-06 清华大学 一种时间敏感网络中确定性故障检测与定位方法及系统
US11797539B2 (en) 2019-09-12 2023-10-24 Oracle International Corporation Accelerated building and probing of hash tables using symmetric vector processing
US11178042B2 (en) * 2019-10-14 2021-11-16 Red Hat, Inc. Protocol and state analysis in a dynamic routing network
US11444881B2 (en) 2019-11-19 2022-09-13 Oracle International Corporation System and method for supporting use of forward and backward congestion notifications in a private fabric in a high performance computing environment
US11451493B2 (en) 2021-01-06 2022-09-20 Mellanox Technologies, Ltd. Connection management in a network adapter
US20220311711A1 (en) * 2021-09-23 2022-09-29 Intel Corporation Congestion control based on network telemetry

Also Published As

Publication number Publication date
WO2020236290A1 (en) 2020-11-26
US20220210054A1 (en) 2022-06-30
WO2020236297A1 (en) 2020-11-26
US11792114B2 (en) 2023-10-17
US20220200923A1 (en) 2022-06-23
US11876702B2 (en) 2024-01-16
US20220197845A1 (en) 2022-06-23
US20220214934A1 (en) 2022-07-07
WO2020236282A1 (en) 2020-11-26
CN113767601A (zh) 2021-12-07
US20240121181A1 (en) 2024-04-11
DE112020002497T5 (de) 2022-04-28
WO2020236270A1 (en) 2020-11-26
CN113748652A (zh) 2021-12-03
WO2020236271A1 (en) 2020-11-26
US20240160584A1 (en) 2024-05-16
US20220232111A1 (en) 2022-07-21
US11757763B2 (en) 2023-09-12
US20220200913A1 (en) 2022-06-23
CN113728592A (zh) 2021-11-30
WO2020236273A1 (en) 2020-11-26
WO2020236284A1 (en) 2020-11-26
EP3942754A1 (de) 2022-01-26
US20220210081A1 (en) 2022-06-30
CN113692725A (zh) 2021-11-23
US20220217078A1 (en) 2022-07-07
CN113748647A (zh) 2021-12-03
EP3942759A4 (de) 2023-04-05
DE112020002495T5 (de) 2022-04-28
DE112020002498T5 (de) 2022-04-28
US20220191128A1 (en) 2022-06-16
US11985060B2 (en) 2024-05-14
CN113711551A (zh) 2021-11-26
EP3942754A4 (de) 2023-05-31
US20220200897A1 (en) 2022-06-23
US11855881B2 (en) 2023-12-26
DE112020002494T5 (de) 2022-04-28
US11968116B2 (en) 2024-04-23
WO2020236294A1 (en) 2020-11-26
WO2020236265A1 (en) 2020-11-26
WO2020236281A1 (en) 2020-11-26
WO2020236285A1 (en) 2020-11-26
US20220217079A1 (en) 2022-07-07
US11916781B2 (en) 2024-02-27
EP3942755A4 (de) 2023-05-31
US20220214975A1 (en) 2022-07-07
US12021738B2 (en) 2024-06-25
DE112020002500T5 (de) 2022-04-14
CN113767599A (zh) 2021-12-07
EP3942422A4 (de) 2022-11-16
WO2020236299A1 (en) 2020-11-26
WO2020236258A1 (en) 2020-11-26
EP3942422A1 (de) 2022-01-26
US20240121180A1 (en) 2024-04-11
US20240039836A1 (en) 2024-02-01
US20240121179A1 (en) 2024-04-11
US11902150B2 (en) 2024-02-13
US20220200900A1 (en) 2022-06-23
WO2020236291A1 (en) 2020-11-26
EP3942398A4 (de) 2023-04-05
WO2020236295A1 (en) 2020-11-26
US11991072B2 (en) 2024-05-21
DE112020002484T5 (de) 2022-04-28
US20220224628A1 (en) 2022-07-14
CN113711173A (zh) 2021-11-26
DE112020002754T5 (de) 2022-03-31
DE112020002512T5 (de) 2022-02-17
US20240113961A1 (en) 2024-04-04
US20220311544A1 (en) 2022-09-29
US12003411B2 (en) 2024-06-04
EP3942749A4 (de) 2023-06-07
US20220217090A1 (en) 2022-07-07
EP3949290A1 (de) 2022-02-09
CN113711550A (zh) 2021-11-26
US20220197831A1 (en) 2022-06-23
WO2020236292A1 (en) 2020-11-26
US20220245072A1 (en) 2022-08-04
CN114073054A (zh) 2022-02-18
US11876701B2 (en) 2024-01-16
CN113692581A (zh) 2021-11-23
WO2020236264A1 (en) 2020-11-26
WO2020236278A1 (en) 2020-11-26
US11750504B2 (en) 2023-09-05
WO2020236266A1 (en) 2020-11-26
US20220210055A1 (en) 2022-06-30
WO2020236272A1 (en) 2020-11-26
WO2020236279A1 (en) 2020-11-26
US20240171506A1 (en) 2024-05-23
US20220231965A1 (en) 2022-07-21
CN113728595A (zh) 2021-11-30
WO2020236280A1 (en) 2020-11-26
CN113711548A (zh) 2021-11-26
US20220210094A1 (en) 2022-06-30
WO2020236267A1 (en) 2020-11-26
WO2020236269A1 (en) 2020-11-26
DE112020002481T5 (de) 2022-04-28
US20220166705A1 (en) 2022-05-26
EP3942757A4 (de) 2023-05-31
EP3942398A1 (de) 2022-01-26
US20220217096A1 (en) 2022-07-07
CN113728596A (zh) 2021-11-30
WO2020236262A3 (en) 2021-02-04
US20220182309A1 (en) 2022-06-09
WO2020236276A1 (en) 2020-11-26
CN113785536A (zh) 2021-12-10
US20240106736A1 (en) 2024-03-28
US20220353199A1 (en) 2022-11-03
US11848859B2 (en) 2023-12-19
EP3942759A1 (de) 2022-01-26
EP3942758A4 (de) 2023-05-31
EP3942758A1 (de) 2022-01-26
WO2020236274A1 (en) 2020-11-26
US20220214919A1 (en) 2022-07-07
US11973685B2 (en) 2024-04-30
US20240121182A1 (en) 2024-04-11
US20240171507A1 (en) 2024-05-23
US20220210058A1 (en) 2022-06-30
EP3942749A2 (de) 2022-01-26
US11929919B2 (en) 2024-03-12
EP3942757A1 (de) 2022-01-26
WO2020236283A1 (en) 2020-11-26
CN113711547A (zh) 2021-11-26
CN113728315A (zh) 2021-11-30
DE112020002501T5 (de) 2022-08-11
WO2020236289A1 (en) 2020-11-26
DE112020002491T5 (de) 2022-04-28
WO2020236300A1 (en) 2020-11-26
US11765074B2 (en) 2023-09-19
WO2020236287A1 (en) 2020-11-26
EP3949290A4 (de) 2023-05-31
DE112020002528T5 (de) 2022-03-24
US11757764B2 (en) 2023-09-12
US11777843B2 (en) 2023-10-03
CN113785541A (zh) 2021-12-10
EP3942763A4 (de) 2023-08-09
WO2020236268A1 (en) 2020-11-26
US20230396533A1 (en) 2023-12-07
CN113728599A (zh) 2021-11-30
WO2020236275A1 (en) 2020-11-26
US20220217076A1 (en) 2022-07-07
US11784920B2 (en) 2023-10-10
WO2020236288A1 (en) 2020-11-26
DE112020002510T5 (de) 2022-03-10
WO2020236286A1 (en) 2020-11-26
WO2020236259A1 (en) 2020-11-26
EP3942747A1 (de) 2022-01-26
WO2020236277A1 (en) 2020-11-26
US11863431B2 (en) 2024-01-02
CN113711549A (zh) 2021-11-26
EP3942755A1 (de) 2022-01-26
US11818037B2 (en) 2023-11-14
CN113728594A (zh) 2021-11-30
WO2020236302A1 (en) 2020-11-26
US20220217094A1 (en) 2022-07-07
US20220231962A1 (en) 2022-07-21
CN113728593A (zh) 2021-11-30
EP3942747A4 (de) 2023-05-24
DE112020002493T5 (de) 2022-04-28
US20220255884A1 (en) 2022-08-11
WO2020236301A1 (en) 2020-11-26
CN113728598A (zh) 2021-11-30
WO2020236264A9 (en) 2021-01-21
US11799764B2 (en) 2023-10-24
CN113748648A (zh) 2021-12-03
WO2020236298A1 (en) 2020-11-26
CN113874848A (zh) 2021-12-31
WO2020236262A2 (en) 2020-11-26
US20220239587A1 (en) 2022-07-28
US20220200912A1 (en) 2022-06-23
DE112020002496T5 (de) 2022-04-28
WO2020236296A1 (en) 2020-11-26
US20220224639A1 (en) 2022-07-14
US20230046350A1 (en) 2023-02-16
CN113728597A (zh) 2021-11-30
US20220210092A1 (en) 2022-06-30
US20220229800A1 (en) 2022-07-21
WO2020236261A1 (en) 2020-11-26
EP3942763A1 (de) 2022-01-26
US11962490B2 (en) 2024-04-16
US20220191127A1 (en) 2022-06-16
CN113767600A (zh) 2021-12-07
US11899596B2 (en) 2024-02-13
US11882025B2 (en) 2024-01-23
CN113767598A (zh) 2021-12-07
WO2020236293A1 (en) 2020-11-26
US20220217073A1 (en) 2022-07-07
DE112020002509T5 (de) 2022-03-03
US11916782B2 (en) 2024-02-27
US20220197838A1 (en) 2022-06-23
CN113785543A (zh) 2021-12-10
DE112020002499T5 (de) 2022-08-25
US20220329521A1 (en) 2022-10-13
US20220206956A1 (en) 2022-06-30
US20230370364A1 (en) 2023-11-16

Similar Documents

Publication Publication Date Title
DE112020002490T5 (de) Verfahren und system zur gewährleistung der fairness beim netzaustritt zwischen anwendungen
DE60031515T2 (de) Netzwerkvermittlung
DE102015017100B3 (de) Verteilte Switch-Architektur
DE60125678T2 (de) Vermittlungstelle mit Flusssteurungverwaltung
DE102020105776A1 (de) Kostengünstige Überlastungsisolierung für verlustfreies Ethernet
DE602005005291T2 (de) Erweiterbare Pipelinearchitektur für ein Netzwerkgerät
US20240056385A1 (en) Switch device for facilitating switching in data-driven intelligent network
DE60022870T2 (de) Verfahren zur überlastungsverwaltung in einer netzwerkvermittlung
DE102015014167B4 (de) Verteilte switch-architektur
US12034633B2 (en) System and method for facilitating tracer packets in a data-driven intelligent network

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TX, US

R082 Change of representative

Representative=s name: FLEUCHAUS & GALLO PARTNERSCHAFT MBB - PATENT- , DE

Representative=s name: FLEUCHAUS & GALLO PARTNERSCHAFT MBB PATENTANWA, DE

R012 Request for examination validly filed