WO2017123253A1 - Génération d'adresses de réseau entre homologues - Google Patents

Génération d'adresses de réseau entre homologues Download PDF

Info

Publication number
WO2017123253A1
WO2017123253A1 PCT/US2016/013686 US2016013686W WO2017123253A1 WO 2017123253 A1 WO2017123253 A1 WO 2017123253A1 US 2016013686 W US2016013686 W US 2016013686W WO 2017123253 A1 WO2017123253 A1 WO 2017123253A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
modules
peer
network
network bus
Prior art date
Application number
PCT/US2016/013686
Other languages
English (en)
Inventor
Peter Hansen
Patrick A. Raymond
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
Priority to PCT/US2016/013686 priority Critical patent/WO2017123253A1/fr
Publication of WO2017123253A1 publication Critical patent/WO2017123253A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • 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
    • 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/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/604—Address structures or formats
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses

Definitions

  • Networks and server systems supporting high-end cloud applications include embedded management microprocessors that, when combined with an array of sensors, memories, and I/O devices, form a management subsystem. These devices often use some form of low cost, reliable interconnect or bus technology to function correctly.
  • Some examples of bus technologies include Serial Peripheral Interfaces (SPI) bus, Inter Integrated Circuit (I2C) bus, serial Universal Asynchronous
  • UART Receiver/Transmitter
  • CAN Control Area Network
  • 1 -wire bus for example.
  • Such connections may be bus or point-to-point configurations, for example.
  • the decision on which management bus to implement in a given subsystem is based on tradeoffs that can include bus speed, cost, pin count, and participating component compatibility with the bus.
  • these subsystems are customizable with some form of modular chassis that accepts multiple types of feature options (e.g., computer components, storage components, I/O components, and so forth) that plug in with connectors and may communicate to each other, such as using one of the above mentioned bus
  • FIG. 1 is a block diagram illustrating an example of an apparatus to generate a peer-to-peer network address in accordance with the present disclosure.
  • FIG. 2 is a block diagram illustrating an example of a system to employ peer- to-peer network addressing that includes module functionality and location in the network address in accordance with the present disclosure.
  • FIG. 3 is a block diagram illustrating an example of a network address specifying module functionality and location in the network address in accordance with the present disclosure.
  • FIG. 4 is a block diagram illustrating an example of a system to employ a bridge module to facilitate communications between an internal network bus and an external public network in accordance with the present disclosure.
  • FIG. 5 is a flow chart illustrating an example of a method of power-up operations for modules using a network employing peer-to-peer network addressing in accordance with the present disclosure.
  • FIG. 6 is a block diagram illustrating an example of a controller to facilitate peer-to-peer network communications in accordance with the present disclosure.
  • This disclosure relates to network address identification for peer-to-peer communication among modules in a local network.
  • an apparatus includes a module to interface to a network bus.
  • a module descriptor on the module specifies functionality of the module.
  • the functionality specified in the network address can include the type or purpose of the module (e.g., it is for computing, storage, I/O, cooling, and so forth).
  • the functionality specified in the network address can further specify functional features of the module, such as power conversion capabilities, communications capabilities, and/or infrastructure support of the module (e.g., cooling capabilities, such as single or dual fan module).
  • a port on the module is to connect to a mating connector (e.g., a rack connection to a backplane) and receives a slot location in the bus where the module is connected.
  • a controller on the module generates a peer-to-peer network address for the module to enable
  • the peer-to- peer network address of a module incorporates or is derived from the module descriptor for the module and the slot location to provide a unique network address for the network bus.
  • the peer-to-peer network address enables other peer modules connected to the network bus to communicate directly with the module in a peer-to-peer manner without going through a master base controller or an address resolution cycle as with other systems.
  • Systems implementing such peer-to-peer communications are afforded efficient discovery of module functionality and reduction of complex controller firmware operations (e.g., where the firmware comprises a set of machine-readable instructions) to support master and slave bus operations.
  • the network addressing further enables a discovery process that locates not only the presence of specific modules by function in a chassis ecosystem, but also the respective location and possibly other meta-data associated with the module (e.g., additional functional features of the module).
  • Peer-to- peer network addressing as disclosed herein, also provides a multi-master capability to the subcomponents communicating on the network bus to facilitate their discovery of each other.
  • a base controller can initiate module discovery to all modules in a rack and can sequence power-up operations depending on detected capabilities and needs of modules in a rack. For example, the base controller discovers a system requirement of each of the plurality modules and sequences power-up operations among the plurality of modules in a particular sequence to enhance synergy among the modules.
  • the power-up sequence can be implemented, for instance, to enable cooling modules to be powered before system computing and storage modules that may need additional cooling from the cooling module.
  • the internal network bus utilizing the peer-to-peer network addressing described herein can be connected to external public networks via a bridge module that bridges communications between the internal network bus and the external public network.
  • a module e.g.
  • FIG. 1 illustrates an example of an apparatus 100 that generates a peer-to- peer network address that includes module functionality and location in the network address.
  • the apparatus 100 includes a module 1 10 to interface to a network bus 120.
  • a module descriptor 124 on the module 1 10 specifies functionality of the module.
  • the module descriptor 124 can be a firmware designation, register setting, and/or switch setting to specify the module's functionality and/or other module features.
  • a port 130 on the module 1 10 connects to a mating connector 140 and receives a slot location where the module is connected.
  • the mating connector 140 can receive pin encodings from a given slot in a rack where the module 1 10 is located on the bus (See e.g., FIG. 2). If an eight slot rack were employed for example, three pins in the mating connector 140 would be utilized to identify the module's slot location to the module 1 10 via the port 130.
  • a controller 150 includes an address generator to generate a peer-to- peer network address for the module to communicate on the network bus 120. The peer-to-peer network address generated by the controller 150 incorporates the module descriptor 124 and the slot location received from the port 130 to generate a unique network address for the network bus 120.
  • the peer-to-peer network address enables other peer modules on the network bus 120 to communicate directly with the module 1 10 and without intervention of another module, such as a base controller operating the network bus 120.
  • another module such as a base controller operating the network bus 120.
  • the port 130 is shown as a separate component in this example, it could be an internal port on the controller 150 in another example.
  • the network bus 120 utilizes an Ethernet protocol to facilitate communications on the network bus.
  • Other network protocols are possible, such as ARPNet or Token Ring, for example.
  • the module descriptor 124 and the slot location received from the port 130 can be encoded as a MAC address within the bus protocol (e.g., Ethernet).
  • the module descriptor 124 can include a field to describe the module's primary role, a field to describe the module's communications capability to another network external to the network bus, or a field to describe the module's infrastructure capability to support other modules.
  • the field to describe the module's primary role can include a compute node identifier (e.g., processing resources), a storage identifier (e.g., memory resources), an I/O identifier (e.g., module input and/or output capability), a cooling identifier (e.g., fan capability), or a power capability identifier (e.g., AC or DC power source).
  • a compute node identifier e.g., processing resources
  • a storage identifier e.g., memory resources
  • an I/O identifier e.g., module input and/or output capability
  • a cooling identifier e.g., fan capability
  • a power capability identifier e.g., AC or DC power source.
  • the field to describe the module's communications capability to other networks can include an Ethernet identifier (e.g., 10 Gbyte or 1 GByte capability), a fiber channel identifier, or an infiniband identifier, for example.
  • the field to describe the module's infrastructure capability to support other modules can include a power converter identifier (e.g., DC/DC converter), a rectifier identifier (e.g., AC/DC rectifier or high voltage rectifier), or a fan type identifier (e.g., single rotor fan, dual rotor fan).
  • a power converter identifier e.g., DC/DC converter
  • a rectifier identifier e.g., AC/DC rectifier or high voltage rectifier
  • a fan type identifier e.g., single rotor fan, dual rotor fan.
  • the Ethernet protocol includes communications frames including packets of data that contain a header followed by a payload.
  • the header portion of an Ethernet packet can be 14 bytes and contains a plurality of (e.g., three or more) fields. For example, a six byte destination MAC address in the header portion identifies the node the packet is being sent to. A six byte source MAC address identifies the network adapter that sent the frame.
  • a two byte "ethertype" identifier that in this example includes the values 0x0800 can identify the frame as IPv4 formatted, but is neutral to higher level protocols running over the network bus 120 since such protocols are generally unnecessary in a closed communications environment (e.g., closed to global communications) as described herein.
  • the six byte MAC addresses in Ethernet is further subdivided into two fields - an organizationally unique identifier (OUI) that is unique among all Ethernet products produced by an organization and a network interface controller (NIC) specific address that is 24 bits long and unique among this controller's organization that manufactured it.
  • UMI organizationally unique identifier
  • NIC network interface controller
  • the module's MAC address can be repurposed to specify the modules functionality described herein where local uniqueness on the network bus 120 is maintained via the slot location derived from the port 130.
  • the network bus is many orders of magnitude faster than a conventional I2C bus for example which can be useful in high bandwidth management functions such as firmware update.
  • the network bus can be configured as a differential low voltage network that facilitates noise immunity.
  • the peer-to-peer addressing has a high level of compatibility with embedded microprocessor modules where data that is being collected inside a module can be increased over conventional systems and efficiently
  • Ethernet with its speeds to 10 Gb/s or greater can be supported on the network bus 120.
  • FIG. 2 illustrates an example of a system 200 that employs peer-to-peer network addressing that includes module functionality and location in the network address.
  • the system 200 includes a plurality of modules shown as modules 1 though M with M being a positive integer, to interface to a network bus 210.
  • Each of the plurality of modules can be inserted in to a slot shown as slots 1 though N which are housed in a rack 220, where N is at least equal to M.
  • the rack 220 includes slots that computers, servers, routers, storage, I/O modules and/or other devices are mounted in.
  • the term slot refers to a location where a module can be located in the rack 220.
  • Another type of slot is a bay that can similarly house a module similar to the slot.
  • a rack 220 can include both slots and bay locations which can be alternatively identified in the peer-to-peer addresses described herein.
  • Each of the plurality of modules 1 -M can include a module descriptor on the respective module to specify functionality of the respective module and a port on the respective module to connect to a mating connector on the respective module and to receive a slot location where the respective module is connected (See e.g., of FIG. 1 ).
  • a controller on each of the modules 1 -M can generate a peer-to-peer network address for the respective module to communicate on the network bus 210.
  • the peer- to-peer network address is based on the module descriptor of the respective module and the slot location of the respective module to generate a unique network address for communicating via the network bus 210.
  • a base controller 230 e.g., baseboard management controller [BMC], which may provide out-of-band functionality mounted on a baseboard circuit 240 can communicate with each of the plurality of modules 1 -M via the network bus 210.
  • the peer-to-peer network address of the respective modules on the network bus can enable discovery among each of the plurality of modules on the network bus without intervention from the base controller 230 based on the specified functionality of the module descriptor of the respective module.
  • the network bus 210 can utilize an Ethernet protocol to facilitate
  • the base controller 230 can provide a predetermined MAC address (e.g.,
  • each of the modules 1 -M can be provided (e.g., during an initialization process) with the predetermined address of the base controller 230 or can have the predetermined address preprogrammed in a register or dip switch setting, for example.
  • the base controller 230 can perform system level discovery of modules via iterative polling of modules and/or via broadcast discovery requests generated from the base controller, for example.
  • the modules 1 -M can implement a higher level request / response type of protocol that can use the hardware MAC addresses for their respective OSI layer 2 level communications medium, for example.
  • the protocol could be an industry standard - such as TCP/IP or UDP/IP - or it could be a proprietary protocol using the Ethernet payload in ways deemed suitable for the application.
  • Discovery of both the function and location of all the devices in the system can be achieved according to different processes. In one process, the base controller 230 can iteratively send out all possible packets with destination MACs set to the target's slot ID, and role. For modules that are present, they can respond and the base controller 230 can learn of their presence.
  • the base controller 230 can send out a broadcast request over the network bus 210 (e.g., destination MAC is all 1 s (OxFFFFFFFFFF) so that all devices on the bus can detect it and respond.
  • the base controller 230 collects the responses and stores the responses (e.g., in a table indicating functional capabilities of each module in rack) according to the detected functionality.
  • a discovery process can continually run, run periodically or be run intermittently in response to an event to discover insertions and removals of modules from the rack 220.
  • Another benefit of the peer-to-peer capability described herein is that it provides a multi-master capability to the modules communicating on the network bus 210 since each module can determine network address and functions of other modules by analyzing network traffic on the bus.
  • the modules can discover each other in a manner similar to base controller discovery (or during) and they can directly address the other modules by formulating their MAC addresses via module descriptors and slot location as described herein.
  • Such module-based discovery can be of benefit in baseboard computer systems that have product side-bus arrangements such as direct attach storage nodes on separate modules in an adjacent slot in a system or a "sidecar" or storage blade that is located in the slot next to its associated computing node and keyed with another bus (e.g., an expansion bus, such as a PCI-E bus), for example.
  • product side-bus arrangements such as direct attach storage nodes on separate modules in an adjacent slot in a system or a "sidecar” or storage blade that is located in the slot next to its associated computing node and keyed with another bus (e.g., an expansion bus, such as a PCI-E bus), for example.
  • an expansion bus such as a PCI-E bus
  • the discovery process described herein can also support other operations such as sequential start-up of modules within the rack 220.
  • the base controller 230 may power some modules down until other modules have had a chance to enter a normal operating state (e.g., for a predetermined time until a given status is received such as temperature).
  • Sequential operations can include ensuring there is enough cooling capacity for temperature sensitive modules in the correct locations in a system prior to powering them on, for example. This can include performing desired I/O keying operations such as verifying and/or matching appropriate production bus and technologies in the rack 220 prior to powering on certain modules.
  • a base controller 230 can employ the unique network address of the modules (learned from the discovery process), to identify the types and capabilities of the respective modules. The base controller 230 can then configure and implement a sequential process to provide for efficient and safe operation of the respective modules. As an example, the controller can power on I/O devices, then storage (so it can connect to the I/O), then compute nodes (so they can connect to both I/O and storage) to ensure desired connectivity of these components as they power up. Other orders can be implemented, which may be established by the controller according to the particular functions and locations of the respective module 1 -M on the network bus 210.
  • FIG. 3 illustrates an example of a network address 300 specifying module functionality and location in the network address.
  • the network address can be provided as part of an Ethernet MAC address.
  • the network address 300 can include a field specifying a module's role (e.g., the module's function) at 310.
  • a module's role e.g., the module's function
  • Such role can be specified via bits in the address 330 and, for example, can include computing, storage, cooling, power, infrastructure support, and so forth.
  • the network address 300 can include data specifying communications capabilities (specified as bits), such as providing access to another network outside the network bus described herein.
  • Example networks can include Ethernets operating at different speeds (e.g., 1 G, 10G, 100G), fiber channel networks, and Infiniband networks, for example which can also operate at different speeds.
  • a field in the network address 300 can be reserved for future functional capabilities of the module that are not presently available.
  • a field in the network address 300 can specify infrastructure capability of a given module. If the module is a functional module such as a compute module, storage module, or I/O module, this field can be set to zero. If the module is an infrastructure support module, depending on bit pattern, this field 340 can specify DC/DC converter, AC/DC rectifier, HVDC rectifier, single rotor fan, dual rotor fan, and so forth.
  • the module's slot identifier (ID) is provided reflecting the slot location determined by the controller reading the module port described herein.
  • FIG. 4 illustrates an example of a system 400 that employs a bridge module 410 to facilitate communications between modules and devices coupled to an internal network bus 420 and an external network (e.g., a wide area network (WAN), such as the Internet or other public network) 430.
  • a module 440 can send a peer-to- peer (P2P) message to the bridge module 410, where the bridge module reformats the message according to the protocol of the external network.
  • P2P peer-to- peer
  • the bridge module 410 would provide a globally unique address for the external Ethernet network while utilizing a local Ethernet address derived from function and slot location of the bridge module, as described herein, to communicate with the module 440 over the internal network bus 420.
  • a base controller 450 could also communicate to the external network 430 via the bridge module 410.
  • the base controller 450 could route a message over the internal network bus 420 to the module 440 which could then re-route the received base controller message to the bridge module 410.
  • the bridge module 410 enables one base controller (e.g., the base controller 450) to control multiple chassis systems.
  • a bridge module 410 can include a small microcontroller with two network interfaces. One contains a MAC that identifies it as a bridging device. The other network controller would be an external facing "public" interface that would follow the guidelines of such a module (e.g., operating on a public Ethernet network).
  • a bridging protocol can be constructed in the payload of the
  • Ethernet frame and the module would then convert and route the internal packets to external networks and vice versa - building a routing table in the process.
  • FIG. 5 illustrates an example of a method 500 that utilizes peer-to-peer network addressing that includes module functionality and location in the addressing to sequence power-up operations between modules (e.g., modules 1 10, 1 -M, 440).
  • the method 500 includes generating a discovery request on a network bus (e.g., bus 120, 210, 420) to discover functionality of a plurality of modules communicating on the network bus (e.g., via the base controller 230 of FIG. 2).
  • the discovery request can be encoded as a predetermined MAC address that is unique to base controller for the network bus, for example.
  • discovery can include sending a broadcast request to the network bus to discover the functionality of each of the plurality of modules.
  • discovery can include iteratively polling each module to discover its respective functionality.
  • the method 500 includes receiving (e.g., at the base controller 230 of FIG. 2) a discovery response from each of the plurality of modules on the network bus.
  • the discovery response from each of the modules can include an address (e.g., MAC address) having a module descriptor on the respective module to specify the
  • the method 500 includes sequencing power- up operations of each of the plurality of modules based on the functionality of the modules determined based on the discovery response received from each of the plurality of modules (e.g., via the base controller 230 of FIG. 2). As noted herein, for example, this can include powering up some modules in a prescribed order to achieve desired level of functionality (e.g., cooling and power) before powering other modules (e.g., computing or storage modules).
  • desired level of functionality e.g., cooling and power
  • other modules e.g., computing or storage modules.
  • FIG. 6 illustrates an example of a controller 600 to facilitate peer-to-peer network communications.
  • the controller 600 includes a network interface 610 to send and receive addresses and associated messages on the network bus.
  • An address generator 620 configures network addresses utilizing the slot location and module descriptor as previously described. For example, the address generator 620 receives the slot location and the module descriptor from the controller 600 and formats a MAC address packet. The MAC address can contain other network data along with the module descriptor and slot location data. After formatting the MAC address, the address generator 620 submits the formulated network address to the network interface that provides the address to the network bus.
  • the address can be generated in response to a discovery request from the base controller and/or in response to a message request from another module and/or the base controller.
  • An address parser 630 analyzes network packets received by the network interface 610. The address parser 630 can isolate the slot locations and module functionality associated with the respective modules in the rack to build a functional table of module destinations that can then be used by the controller 600 to send peer messages to other modules in the rack.

Abstract

L'invention concerne un appareil qui comprend un module pour servir d'interface avec un bus de réseau. Un dispositif de description de module spécifie la fonctionnalité du module. Un port sur le module se connecte à un connecteur homologue et reçoit un emplacement de fente où le module est connecté. Un dispositif de commande génère une adresse de réseau entre homologues pour que le module communique sur le bus de réseau. L'adresse de réseau entre homologues comprend le dispositif de description de module et l'emplacement de fente pour générer une adresse de réseau unique pour le bus de réseau. L'adresse de réseau entre homologues permet à d'autres modules d'homologue sur le bus de réseau de communiquer directement avec le module.
PCT/US2016/013686 2016-01-15 2016-01-15 Génération d'adresses de réseau entre homologues WO2017123253A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2016/013686 WO2017123253A1 (fr) 2016-01-15 2016-01-15 Génération d'adresses de réseau entre homologues

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/013686 WO2017123253A1 (fr) 2016-01-15 2016-01-15 Génération d'adresses de réseau entre homologues

Publications (1)

Publication Number Publication Date
WO2017123253A1 true WO2017123253A1 (fr) 2017-07-20

Family

ID=59311923

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/013686 WO2017123253A1 (fr) 2016-01-15 2016-01-15 Génération d'adresses de réseau entre homologues

Country Status (1)

Country Link
WO (1) WO2017123253A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040255172A1 (en) * 2003-06-13 2004-12-16 International Business Machines Corporation Remote power control in a multi-node, partitioned data processing system
US20130231151A1 (en) * 2012-03-01 2013-09-05 Nokia Corporation Method, apparatus, and computer program product for probe request and response exchange
US20140258395A1 (en) * 2013-03-06 2014-09-11 Qualcomm Incorporated Peer-to-peer pre-association discovery operations
US20140314065A1 (en) * 2011-11-15 2014-10-23 Lg Electronics Inc. Method and device for searching for supported service through wifi direct network
WO2015020502A1 (fr) * 2013-08-09 2015-02-12 삼성전자 주식회사 Technique de découverte de service dans un réseau de communication sans fil pour former un groupe p2p

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040255172A1 (en) * 2003-06-13 2004-12-16 International Business Machines Corporation Remote power control in a multi-node, partitioned data processing system
US20140314065A1 (en) * 2011-11-15 2014-10-23 Lg Electronics Inc. Method and device for searching for supported service through wifi direct network
US20130231151A1 (en) * 2012-03-01 2013-09-05 Nokia Corporation Method, apparatus, and computer program product for probe request and response exchange
US20140258395A1 (en) * 2013-03-06 2014-09-11 Qualcomm Incorporated Peer-to-peer pre-association discovery operations
WO2015020502A1 (fr) * 2013-08-09 2015-02-12 삼성전자 주식회사 Technique de découverte de service dans un réseau de communication sans fil pour former un groupe p2p

Similar Documents

Publication Publication Date Title
US8214528B2 (en) Address identifier scaling in converged networks
JP5585664B2 (ja) ネットワークシステム、及び経路制御方法
US9985820B2 (en) Differentiating among multiple management control instances using addresses
US8892723B2 (en) Method and apparatus for enabling communication between iSCSI devices and SAS devices
EP3036873B1 (fr) Architecture de trajet de commande dédié pour commutation de paquets empilés
US10797893B2 (en) Single pair ethernet management interface
US11128741B2 (en) Auto-negotiation over extended backplane
CN1514586B (zh) 模拟多用户、多连接的数据通讯设备测试方法
US20160248619A1 (en) Differentiating among multiple management control instances using ip addresses
EP3167580B1 (fr) Procédé, système et logique pour configurer une liaison locale sur la base d'un partenaire de liaison à distance
CN102742228A (zh) 以太网节点端口虚拟器
US20070223494A1 (en) Method for the resolution of addresses in a communication system
US10567274B1 (en) Method, system, and apparatus for proxying intra-subnet traffic across multiple interfaces within networks
WO2017014758A1 (fr) Fourniture de puissance à un serveur
US8582576B2 (en) Method of bus configuration to enable device bridging over dissimilar buses
CN207926623U (zh) 车载网络系统及汽车
US7843966B2 (en) Communication system for flexible use in different application scenarios in automation technology
WO2017123253A1 (fr) Génération d'adresses de réseau entre homologues
KR20070068844A (ko) Ｕｔｐ/광 통합 네트워크의 이더넷 스위치/라우터 및 그방법
JP2006025369A (ja) 情報処理装置および方法、並びにプログラム
CN111770000B (zh) 一种网口速率测试方法及系统
US8867376B1 (en) Host verification at an optical circuit switch
CN117539812A (zh) 服务器及数据传输方法
EP4254880A1 (fr) Vérification d'en-tête ethernet matériel
US8886816B2 (en) Auto-detection and selection of an optimal I/O system resource virtualization protocol

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16885352

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16885352

Country of ref document: EP

Kind code of ref document: A1