WO2020238875A1 - 确定端口属性的方法和装置 - Google Patents

确定端口属性的方法和装置 Download PDF

Info

Publication number
WO2020238875A1
WO2020238875A1 PCT/CN2020/092209 CN2020092209W WO2020238875A1 WO 2020238875 A1 WO2020238875 A1 WO 2020238875A1 CN 2020092209 W CN2020092209 W CN 2020092209W WO 2020238875 A1 WO2020238875 A1 WO 2020238875A1
Authority
WO
WIPO (PCT)
Prior art keywords
port
network device
pdu
network
lldp
Prior art date
Application number
PCT/CN2020/092209
Other languages
English (en)
French (fr)
Inventor
尹超
陈永献
刘和洋
于翔
郑合文
孙黎阳
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP20815650.5A priority Critical patent/EP3968571A4/en
Publication of WO2020238875A1 publication Critical patent/WO2020238875A1/zh
Priority to US17/534,408 priority patent/US20220086051A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • 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/44—Star or tree networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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/48—Routing tree calculation
    • 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
    • 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
    • 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/44—Star or tree networks
    • H04L2012/445—Star or tree networks with switching in a hub, e.g. ETHERNET switch
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks

Definitions

  • the first network device may determine whether the first port is an uplink port or a downlink port based on the PDU sent by the second network device, which provides a basis for subsequent assistance in reducing the load of the SDN controller. This avoids that in the prior art, the network device cannot learn the above configuration situation, resulting in the inability to help the SDN controller to reduce the load.
  • the first network device determines that the first port is the uplink port or the downlink port according to the number of stages of the first network device, including: the first The network device determines whether the first port is an uplink port or a downlink port according to the number of stages of the first network device and the number of stages of the second network device.
  • FIG. 14 is a schematic block diagram of a network device according to another embodiment of the present application.
  • the TLV (ie, the "second TLV") representing the level of the network device can be carried in any one of the above-mentioned reserved TLVs, for example, reserved TLV#1445 can be occupied.
  • the second TLV may include the type 446 of the second TLV, the length 447 of the second TLV (TLV length), and the value 448 of the second TLV.
  • the type 446 of the second TLV may be the TLV type corresponding to the reserved TLV#1, that is, 9.
  • the length 447 of the second TLV is used to indicate the length of the data carried in the value of the second TLV.
  • the value 448 of the second TLV represents the actual value, that is, the level of the network device.
  • the method shown in FIG. 8 includes step 810 to step 830. Assuming that from the root node to the server, the number of levels of nodes at different levels decreases by a step length of 1, and it is predetermined that if the network device is adjacent to the server, the number of levels of the network device is 1.
  • the following takes the leaf node 3 sending an LLDP request as an example for description. Assume that the port attribute of port P 1 of leaf node 3 is unknown.
  • the root cause of the PFC deadlock is the downstream-upstream data flow generated in the network.
  • the data stream in the downstream-upstream direction is transmitted by a network device, two uplink ports in the network device are used.
  • the port attributes of the inport (inport) P r and the out port (outport) P r+1 are both uplink ports. Therefore, in order to avoid the generation of downstream-upstream data flows in the network, thereby preventing the occurrence of PFC deadlock, an anti-PFC deadlock rule can be deployed on each leaf node in the network. For example, an anti-PFC deadlock rule can be deployed in the leaf node 3.
  • control plane of the first network device may maintain a linked list, one of which is ⁇ first port, third port, priority 1, Z>, indicating that the first port is used as an ingress port within a preset time period.
  • the third port is used as an egress port, and the number of times corresponding to priority 1 is Z.
  • the first network device is the first port, and the third port generates an anti-PFC deadlock rule.
  • the processing module is further configured to: determine the number of levels of the first network device according to the preset value, wherein, in the network, the level of the first network device The level represented by the number is adjacent to the level where the root node is located.
  • the device further includes a sending module configured to send an LLDP request to the second network device, and the LLDP request is used to request the second network device's The port attribute of the second port, and/or the level of the second network device in the network.
  • a sending module configured to send an LLDP request to the second network device, and the LLDP request is used to request the second network device's The port attribute of the second port, and/or the level of the second network device in the network.
  • the sending module is further configured to receive the instruction information sent by the second network device through the first port, and the instruction information is used to indicate the instruction information in the second network device
  • the capacity of the buffer corresponding to the third sending queue exceeds a threshold, and the inflow of the third sending queue is 0, and the priority of the data flow buffered by the third sending queue is the same as the priority of the first data flow;
  • the processing module is configured to determine the number of times according to the instruction information.
  • the sending module 1310 may be an outgoing port 1440
  • the processing module 1320 may be a processor 1420
  • the network device may further include a memory 1410 and an ingress port 1430, as shown in FIG. 14 .

Abstract

本申请提供一种确定端口属性的方法和装置，可以应用于数据中心网络，例如胖树(fat-tree)网络。该方法包括：第一网络设备通过第一端口接收第二网络设备发送的协议数据单元PDU；所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口。在本申请实施例中，第一网络设备可以基于第二网络设备发送的PDU，可以确定第一端口为上联口还是下联口，为后续帮助SDN控制器减轻负载提供基础。避免了现有技术中，网络设备无法获知上述配置情况，导致无法帮助SDN控制器减轻负载。

Description

确定端口属性的方法和装置
本申请要求于2019年05月31日提交中国专利局、申请号为201910470325.9、申请名称为“确定端口属性的方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及本申请涉及信息技术领域，并且更具体地，涉及确定端口属性的方法和装置。
背景技术
软件定义网络(Software Defined Network，SDN)是网络虚拟化的一种实现方式，旨在将网络设备的控制面与数据面分离开来，从而实现了数据流的灵活控制，使网络作为管道变得更加智能，为核心网络及应用的创新提供了良好的平台。
目前，SDN技术被广泛应用于数据中心网络，由SDN控制器对数据中心网络中的交换机进行管理。例如，获取数据中心网络的网络拓扑，并基于网络拓扑对数据中心中传输的数据流情况生成流量控制策略，发送至网络设备，由网络设备基于流量控制策略对数据流进行控制。也就是说，SDN控制器需要获取数据中心网络的配置情况，例如，数据中心网络网络拓扑，网络设备的端口属性等。而对于网络设备而言，网络设备无需知道数据中心的配置情况，仅基于SDN控制器的指示，传输数据流即可。
随着数据中心网络的规模不断的扩张，SDN控制器的负载越来越大，会对数据中心的性能产生影响。为了减少SDN控制器的负载，希望将原先由SDN控制器实现的功能可以转由网络设备自主实现。然而，目前由于网络设备无法获知上述配置情况，导致无法帮助SDN控制器减轻负载。
发明内容
本申请提供一种确定端口属性的方法和装置，以使网络设备可以获知自身端口的端口属性，为后续帮助SDN控制器减轻负载提供基础。
第一方面，提供了一种确定端口属性的方法，包括：第一网络设备通过第一端口接收第二网络设备发送的协议数据单元PDU；所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口。
在本申请实施例中，第一网络设备可以基于第二网络设备发送的PDU，可以确定第一端口为上联口还是下联口，为后续帮助SDN控制器减轻负载提供基础。避免了现有技术中，网络设备无法获知上述配置情况，导致无法帮助SDN控制器减轻负载。
在一种可能的实现方式中，所述PDU携带网络中所述第二网络设备的级数，和/或所述PDU携带所述第二网络设备发送所述PDU使用的第二端口的端口属性，所述第二端口 的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
在本申请实施例中，通过在PDU中携带第二网络设备的级数，以及第二端口的端口属性中的至少一种信息，有利于更加直观的辅助第一网络设备确定第一端口为上联口还是下联口。
在一种可能的实现方式中，所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口，包括：所述第一网络设备根据所述PDU确定在所述网络中所述第一网络设备的级数；所述第一网络设备根据所述第一网络设备的级数，确定所述第一端口为上联口或下联口。
在本申请实施例中，第一网络设备根据第一网络设备的级数确定第一端口为上联口还是下联口，有利于提高确定第一端口的端口属性的准确性。
在一种可能的实现方式中，所述网络包括多个网络设备，所述多个网络设备包括所述第二网络设备，所述第一网络设备通过第一端口接收第二网络设备发送的协议数据单元PDU，包括：所述第一网络设备通过多个端口接收所述多个网络设备发送的多个PDU，所述多个端口包括所述第一端口，所述多个PDU包括所述第二网络设备发送的所述PDU；所述第一网络设备根据所述PDU确定在所述网络中所述第一网络设备的级数，包括：所述第一网络设备根据所述多个PDU，确定在所述网络中所述多个网络设备的级数；所述第一网络设备从所述多个网络设备的级数中选择目标级数；所述第一网络设备根据所述目标级数以及预设规则确定所述第一网络设备的级数。
在本申请实施例中，第一网络设备基于多个网络设备的级数确定目标级数，再根据目标级数以及预设的规则确定第一网络设备的级数，使得第一网络设备可以基于多个网络设备的级数确定第一网络设备的级数，有利于提高确定第一网络设备的级数的可靠性。
可选地，上述多个网络设备是与第一网络设备直接相连的网络设备，也就是说，网络中多个网络设备所在的层级与第一网络设备所在的层级相邻。
需要说明的是，上述多个网络设备所在的层级可以是一个层级也可以是多个层级。当多个网络设备所在的层级可以是一个层级时，即多个网络设备所在的层级相同，且该层级与第一网络设备的层级相邻。当多个网络设备所在的层级可以是多个层级时，多个网络设备中至少两个网络设备所在的层级不同，且该多个层级与第一网络设备的层级相邻。例如，多个层级可以包括网络中位于第一网络设备所在层级以北的一层，以及第一网络设备所在层级以南的一层。
可选地，上述多个网络网络设备还可以是与第一网络设备不相邻的网络设备。例如，多个网络设备为根节点，第一网络设备的层次与多个网络设备的层级间隔一层或多层。此时，多个网络设备可以将根节点的级数通过多个PDU发送给第一网络设备，多个PDU中可以分别记录将对应的PDU传输至第一网络设备时进过的网络设备的数量，即传输PDU至第一网络设备时所需的跳数，第一网络设备可以基于PDU以及跳数确定第一网络设备的级数。
可选地，上述预设规则可以是以目标级数为基础，增加预设值，例如，1。上述预设规则还可以是以目标级数为基础，减少预设值，例如，1。上述预设规则还可以是通过非线性的函数表示。
在一种可能的实现方式中，所述第一网络设备根据所述第一网络设备的级数，确定所 述第一端口为所述上联口或所述下联口，包括：所述第一网络设备根据所述第一网络设备的级数，以及所述第二网络设备的级数确定所述第一端口为上联口或下联口。
在本申请实施例中，第一网络设备基于第一网络设备的级数，以及第二网络设备的级数，确定第一端口为上联口还是下联口，有利于提高确定第一端口的端口属性的可靠性。
在一种可能的实现方式中，所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口，包括：所述第一网络设备根据所述PDU确定所述第二网络设备的级数；所述第一网络设备根据所述第二网络设备的级数确定所述第一端口为上联口或下联口。
在本申请实施例中，第一网络设备可以直接基于第二网络设备的级数，确定第一端口为上联口还是下联口，有利于简化确定第一端口为上联口还是下联口的过程。
在一种可能的实现方式中，所述第二网络设备为所述网络中的根节点，所述第一网络设备通过第一端口接收第二网络设备发送的PDU，包括：所述第一网络设备通过所述第一端口接收所述第二网络设备发送的所述PDU，所述PDU中携带的所述第二网络设备的级数为预设值；所述第一网络设备根据所述第二网络设备的级数确定所述第一端口为上联口或下联口，包括：所述第一网络设备根据所述预设值确定所述第一端口为上联口。
在本申请实施例中，若第二网络设备为根节点时，第二网络设备的级数为预设值，这样第一网络设备通过PDU确定第二网络设备的级数为预设值时，可以直接确定第二网络设备为根节点，相应地，与第二网络设备通信的第一端口为上联口，有利于简化确定第一端口为上联口还是下联口的过程。
在一种可能的实现方式中，所述方法还包括：所述第一网络设备根据所述预设值，确定所述第一网络设备的级数，其中，在网络中，所述第一网络设备的级数表示的层级与所述根节点所在的层级相邻。
在本申请实施例中，若第二网络设备为根节点时，第二网络设备的级数为预设值，这样，第一网络设备通过PDU确定第二网络设备的级数为预设值时，可以直接确定第一网络设备所在的层级与根节点(即第二网络设备)的层级相邻，有利于简化确定第一网络设备在网络中的层级的过程。
在一种可能的实现方式中，所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口，包括：所述第一网络设备根据所述PDU，确定所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器；所述第一网络设备确定所述第一端口为下联口。
在本申请实施例中，通过在PDU中携带第一TLV，以指示第二网络设备为服务器，这样，第一网络设备通过PDU确定第二网络设备为服务器时，可以直接确定与第二网络设备通信的第一端口为下联口，有利于简化确定第一端口的端口属性的过程。
可选地，上述第一TLV可以占用PDU中的可选TLV，或者占用PDU中的保留TLV。
可选地，所述PDU为链路层发现协议LLDP PDU。
在一种可能的实现方式中，所述第一网络设备根据所述PDU确定所述第一端口为上联口或下联口，包括：所述第一网络设备根据所述LLDP PDU中端口ID的子类型，确定所述第二网络设备为服务器；所述第一网络设备确定所述第一端口为下联口。
在本申请实施例中，基于LLDP中协议规定交换机使用的端口ID的子类型与服务器使用的端口ID的子类型不同这一规律，可以通过LLDP PDU中携带的端口ID的子类型， 确定第二网络设备为服务器，这样，与第二网络设备通信的第一端口即为下联口，有利于简化确定第一端口的端口属性的过程。
在一种可能的实现方式中，所述方法还包括：所述第一网络设备根据所述LLDP PDU中端口ID的子类型，确定所述第一网络设备的级数，其中，在网络中所述第一网络设备的级数表示的层级与所述服务器所在的层级相邻。
在本申请实施例中，基于LLDP中协议规定交换机使用的端口ID的子类型与服务器使用的端口ID的子类型不同这一规律，可以通过LLDP PDU中携带的端口ID的子类型，确定第二网络设备为服务器，这样，第一网络设备在网络中的层级与服务器相邻，有利于简化确定第一网络设备在网络中的层级的过程。
在一种可能的实现方式中，在所述第一网络设备接收第二网络设备发送的协议数据单元PDU之前，所述方法还包括：所述第一网络设备向所述第二网络设备发送LLDP请求，所述LLDP请求用于请求所述第二网络设备的第二端口的端口属性，和/或所述第二网络设备在网络中的级数。
在本申请实施例中，通过第一网络设备向第二网络设备发送LLDP请求，以触发第二网络设备向第一网络设备反馈LLDP PDU，以通过主动请求的方式，请求第二端口的端口属性和/或所述第二网络设备在网络中的级数，有利于提高第一网络设备获取上述信息的灵活性。
在一种可能的实现方式中，所述第一网络设备向所述第二网络设备发送LLDP请求，包括：若所述第一端口的端口属性未知，所述第一网络设备向所述第二网络设备发送所述LLDP请求。
在本申请实施例中，当第一端口的端口属性未知时，第一网络设备向第二网络设备发送LLDP请求，以触发第二网络设备向第一网络设备反馈LLDP PDU，即第一网络设备有端口的端口属性需要确定时，才向第二网络设备发送LLDP请求，有利于减少第一网络设备与第二网络设备之间的通信占用的传输资源。
在一种可能的实现方式中，所述LLDP PDU包括第二TLV，所述第二TLV用于指示所述第二网络设备的级数，和/或所述LLDP PDU包括第三TLV，所述第三TLV用于指示所述第二端口的端口属性。
在本申请实施例中，上述第二网络设备的级数和/或第二端口的端口属性可以以TLV的格式携带在LLDP PDU中，即复用传统LLDP PDU的封装格式携带上述信息，以避免各厂商提供的网络设备需要兼容新的机制，以支持本申请提供的确定端口的端口属性的方法，有利于减少各厂商提供的网络设备为兼容本申请提供的方法所做的改动。
可选地，上述第二TLV或第三TLV可以占用LLDP PDU中的可选TLV，例如，系统能力TLV，以减少对传统LLDP PDU的封装格式的改动。
可选地，上述第二TLV或第三TLV可以占用LLDP PDU中的保留TLV，以减少对传统LLDP PDU的中可用TLV的改动。
在一种可能的实现方式中，所述第一网络设备包括多个发送队列，所述多个发送队列包括第一发送队列和第二发送队列，所述第一发送队列为数据流对应的原始发送队列，所述方法还包括：所述第一网络设备确定所述第一端口以及所述第一网络设备的第三端口为上联口；所述第一网络设备生成防优先级流量控制PFC死锁规则，所述防PFC死锁规则 用于指示将所述数据流缓存至所述第一发送队列，所述第一数据流的入端口为所述第一端口，所述第一数据流的出端口为所述第三端口。
在本申请实施例中，第一网络设备可以获知第一端口以及第三端口为上联口，并为第一端口和第三端口生成防PFC死锁规则，以防止从第一端口转入并从第三端口转储的第一数据流在网络中与其他数据流形成PFC死锁。避免了传统的防PFC死锁规则部署方式中，需要由SDN控制器为第一端口以及第三端口生成防PFC死锁规则，并最终部署到第一网络设备中。有利于减轻SDN控制器在部署防PFC死锁规则方面的负载。
在一种可能的实现方式中，所述方法还包括：所述第一网络设备确定在预设时间段内，所述第一端口与所述第三端口为PFC死锁关联的端口的次数；所述第一网络设备生成防PFC死锁规则，包括：当所述次数高于预设阈值，所述第一网络设备确定生成所述防PFC死锁规则。
在本申请实施例中，在预设时间段内，当次数高于预设阈值时，第一网络设备才为第一端口和第三端口生成防PFC死锁规则，有利于减少第一网络设备存储防PFC死锁规则占用的存储空间。避免了无论PFC死锁是否产生，第一网络设备都为第一端口和第三端口生成防PFC死锁规则，导致第一网络设备存储防PFC死锁规则占用较大的存储空间。
在一种可能的实现方式中，所述方法还包括：所述第一网络设备通过所述第一端口接收所述第二网络设备发送的指示信息，所述指示信息用于指示所述第二网络设备中的第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0，所述第三发送队列缓存的数据流的优先级与所述第一数据流的优先级相同；所述第一网络设备根据指示信息确定所述次数。
在本申请实施例中，当第二网络设备中第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0时，第二网络设备可以向第一网络设备发送指示信息，相应地，第一网络设备可以根据指示信息确定为与第三发送队列中缓存的流量的优先级相同的流量(即第一数据流)部署防PFC死锁规则。有利于降低网络中产生PFC死锁的可能性。
可选地，上述指示信息可以为第三发送队列缓存的数据流的优先级。
可选地，上述指示信息中可以承载于PDU中。具体地，可以封装为PDU中的一个TLV。需要说明的是，上述承载指示信息的PDU与上文中确定端口的端口属性的PDU可以是相同的PDU也可以是不同的PDU，本申请对此不作限定。
在一种可能的实现方式中，在所述网络的网络拓扑中，以北向到南向的方向网络设备的级数递增。
在一种可能的实现方式中，在所述网络的网络拓扑中，以北向到南向的方向网络设备的级数递减。
上述北向到南向的方向还可以理解为从根节点到架顶交换机的方向。通常，架顶交换机为网络中的一类网络设备，通常，上述架顶交换机位于网络中与服务器相邻的层级。
上述北向到南向的方向与从北向接口(Northbound Interface)到南向接口的方向相同，其中，北向接口用于为厂商或运营商进行接入和管理网络提供的接口，即向上提供的接口。南向接口用于为厂商提供管理其他厂商的网络设备提供的接口。即向下提供的接口。
第二方面，提供了了一种确定端口属性的方法，包括：第二网络设备生成协议数据单 元PDU，所述PDU用于确定第一网络设备的第一端口为上联口或下联口；所述第二网络设备向所述第一网络设备发送所述PDU。
在本申请实施例中，第一网络设备可以基于第二网络设备发送的PDU，可以确定第一端口为上联口还是下联口，为后续帮助SDN控制器减轻负载提供基础。避免了现有技术中，网络设备无法获知上述配置情况，导致无法帮助SDN控制器减轻负载。
在一种可能的实现方式中，所述PDU携带网络中所述第二网络设备的级数，和/或所述PDU携带所述第二网络设备发送所述PDU使用的第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
在本申请实施例中，通过在PDU中携带第二网络设备的级数，以及第二端口的端口属性中的至少一种信息，有利于更加直观的辅助第一网络设备确定第一端口为上联口还是下联口。
在一种可能的实现方式中，所述第二网络设备为所述网络中的根节点，所述PDU中携带的所述第二网络设备的级数为预设值。
在本申请实施例中，若第二网络设备为根节点时，第二网络设备的级数为预设值，这样第一网络设备通过PDU确定第二网络设备的级数为预设值时，可以直接确定第二网络设备为根节点，相应地，与第二网络设备通信的第一端口为上联口，有利于简化确定第一端口为上联口还是下联口的过程。
在一种可能的实现方式中，所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器。
在本申请实施例中，通过在PDU中携带第一TLV，以指示第二网络设备为服务器，这样，第一网络设备通过PDU确定第二网络设备为服务器时，可以直接确定与第二网络设备通信的第一端口为下联口，有利于简化确定第一端口的端口属性的过程。
可选地，上述第一TLV可以占用PDU中的可选TLV，或者占用PDU中的保留TLV。
在一种可能的实现方式中，所述PDU为链路层发现协议LLDP PDU。
在一种可能的实现方式中，在所述第二网络设备向所述第一网络设备发送所述PDU之前，所述方法还包括：所述第二网络设备接收所述第一网络设备发送的LLDP请求，所述LLDP请求用于请求所述第二端口的端口属性，和/或所述第二网络设备的级数。
在本申请实施例中，通过第一网络设备向第二网络设备发送LLDP请求，以触发第二网络设备向第一网络设备反馈LLDP PDU，以通过主动请求的方式，请求第二端口的端口属性和/或所述第二网络设备在网络中的级数，有利于提高第一网络设备获取上述信息的灵活性。
在一种可能的实现方式中，所述LLDP PDU包括第二TLV，所述第二TLV用于指示所述第二网络设备的级数，和/或所述LLDP PDU包括第三TLV，所述第三TLV用于指示所述第二端口的端口属性。
在本申请实施例中，上述第二网络设备的级数和/或第二端口的端口属性可以以TLV的格式携带在LLDP PDU中，即复用传统LLDP PDU的封装格式携带上述信息，以避免各厂商提供的网络设备需要兼容新的机制，以支持本申请提供的确定端口的端口属性的方法，有利于减少各厂商提供的网络设备为兼容本申请提供的方法所做的改动。
可选地，上述第二TLV或第三TLV可以占用LLDP PDU中的可选TLV，例如，系 统能力TLV，以减少对传统LLDP PDU的封装格式的改动。
可选地，上述第二TLV或第三TLV可以占用LLDP PDU中的保留TLV(或称保留位)，以减少对传统LLDP PDU的中可用TLV的改动。
在一种可能的实现方式中，所述方法还包括：所述第二网络设备向所述第一网络设备发送指示信息，所述指示信息用于指示所述第二网络设备中的第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0，所述第三发送队列缓存的数据流的优先级与所述第一数据流的优先级相同。
在本申请实施例中，当第二网络设备中第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0时，第二网络设备可以向第一网络设备发送指示信息，相应地，第一网络设备可以根据指示信息确定为与第三发送队列中缓存的流量的优先级相同的流量(即第一数据流)部署防PFC死锁规则。有利于降低网络中产生PFC死锁的可能性。
可选地，上述指示信息可以为第三发送队列缓存的数据流的优先级。
可选地，上述指示信息中可以承载于PDU中。具体地，可以封装为PDU中的一个TLV。需要说明的是，上述承载指示信息的PDU与上文中确定端口的端口属性的PDU可以是相同的PDU也可以是不同的PDU，本申请对此不作限定。
第三方面，提供了一种第一网络设备，包括实现上述方法中第一网络设备需要执行的功能的各个模块。
第四方面，提供了一种第二网络设备，包括实现上述方法中第二网络设备需要执行的功能的各个模块。
第五方面，提供了一种第一网络设备，包括存储器以及处理器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该第一网络设备执行上述第一方面中的方法。
第六方面，提供了一种第二网络设备，包括存储器以及处理器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该第二网络设备执行上述第二方面中的方法。
第七方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
需要说明的是，上述计算机程序代码可以全部或者部分存储在第一存储介质上，其中第一存储介质可以与处理器封装在一起的，也可以与处理器单独封装，本申请实施例对此不作具体限定。
第八方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
附图说明
图1是本申请实施例适用的胖树网络的网络拓扑的示意图。
图2是本申请实施例的确定端口属性的方法的示意性流程图。
图3示出了本申请实施例的PDU的封装格式的示意图。
图4示出了本申请实施例LLDP报文的封装格式的示意图。
图5示出了本申请实施例的PDU的封装格式的示意图。
图6示出了本申请实施例的PDU的封装格式的示意图。
图7示出了本申请实施例的LLDP请求的封装格式。
图8示出了本申请实施例提供的基于LLDP协议确定端口的端口属性的方法
图9示出了本申请另一实施例提供的基于LLDP协议确定端口的端口属性的方法。
图10示出了本申请实施例适用的胖树网络的网络拓扑的示意图。
图11示出了本申请实施例的防PFC死锁规则的部署方法的流程图。
图12示出了本申请实施例的确定端口的端口属性的装置的示意性框图。
图13示出了本申请另一实施例的确定端口属性的装置的示意性框图。
图14是本申请另一实施例的网络设备的示意性框图。
具体实施方式
为了便于理解，先介绍本申请实施例涉及的术语。
一、网络设备，即连接到网络中的物理实体。例如，交换机、路由器、以及服务器等。网络设备可以包括多个端口，用于与其他网络设备进行通信。
应理解，上述端口可以是网络设备和网络设备之间级联时使用的端口，例如，可以是交换机和交换机之间级联时使用的端口，还可以是交换机和服务器之间级联使用的端口。
二、端口属性，又称“端口角色”，可以用于描述网络设备的端口在网络拓扑中的角色。具体可以包括上联口(uplink)和下联口(downlink)。
上联口，用于指网络设备发送上行数据使用的端口。其中，上行数据可以理解为与从服务器到根节点方向同向传输的数据。
下联口，用于指网络设备发送下行数据使用的端口。其中，下行数据可以理解为与根节点到叶子节点方向同向传输的数据。
三、网络设备的级数，用于指示网络设备在网络(或者说在网络拓扑)中位于哪一层。例如，在数据中心网络中，可以将网络设备到根节点的最短跳数作为该网络设备在网络中的级数。或者，可以将网络设备到服务器的最短跳数作为该网络设备在网络中的级数。
需要说明的是，上述根节点在脊-叶子(spine-leaf)网络架构中，又称为脊节点。
四、协议数据单元(Protocol Data Unit，PDU)，是指对等层次之间传递的数据单位。物理层的PDU可以指数据位(bit)，数据链路层的PDU可以指数据帧(frame)，网络层的PDU可以指数据包(packet)，传输层的PDU可以指数据段(segment)，其他更高层次的PDU可以指报文(message)。
下面将结合附图，对本申请中的技术方案进行描述。
为了便于理解，下文先结合图1介绍本申请实施例适用的胖树网络。应理解，图1所示的网络仅作为本申请实施例适用的一种可能网络架构，本申请实施例还可以适用于数据中心网络的其他网络形式，例如，传统的数据中心三层网络架构等。
图1是本申请实施例适用的胖树(fat-tree)网络的网络拓扑的示意图。图1所示的胖树网络包括多个根节点110，多个叶子节点120，多个服务器130以及SDN控制器140。需要说明的是，图1中仅示出了CLOS中的部分节点，例如，多个叶子节点中的部分叶子节点，即叶子节点1、叶子节点2以及叶子节点3。多个根节点中的部分根节点，即根节 点1、根节点2。本申请实施例对胖树网络中网络设备的具体数量不作限定。
在该胖树网络架构中属于同层的网络设备之间不能直接通信，且每个根节点以全连接的方式连接全部叶子节点。
服务器130，用于对数据进行数据处理，提供存储服务等。
叶子节点120，用于从服务器中读取数据，或者向服务器中写数据。
根节点110，用于将帮助同层的叶子节点转发数据流。例如，根节点1可以将叶子节点1的数据流转发至叶子节点2。
通常，上述叶子节点或根节点为交换器，或者具有数据转发功能的其他网络设备。
SDN控制器140，用于对数据中心网络中的网络设备(例如，交换机)进行管理。
随着数据中心网络的规模不断的扩张，SDN控制器需要管理的网络设备原来越多，SDN控制器的负载越来越大，SDN控制器的处理速度会对数据中心的性能产生影响。为了减少SDN控制器的负载，希望将原先由SDN控制器实现的功能可以转由网络设备自主实现。例如，将SDN控制器从生成防优先级流量控制(Priority Flow Control，PFC)死锁规则的功能中释放出来，让网络设备自主生成防PFC死锁规则。然而，网络设备自身实现某些功能(例如，生成防PFC死锁规则)时，需要获知各个端口的端口为上联口或下联口。
因此，本申请实施例提供了一种确定端口属性的方法，以使网络设备可以获知自身端口的端口属性，为后续帮助SDN控制器减轻负载提供基础。下文结合图2介绍本申请实施例的确定端口属性的方法。
图2是本申请实施例的确定端口属性的方法的示意性流程图。图2所示的方法包括步骤200至步骤220。需要说明的是，下文中的第一网络设备和第二网络设备可以是图2所示的网络架构中的任意两个网络设备。
200，第二网络设备生成PDU。
上述PDU可以用于第一网络设备确定第一网络设备的第一端口的端口属性。
210，第二网络设备通过第二端口向第一网络设备发送PDU，相应地，第一网络设备通过第一端口接收该PDU。
上述第一端口可以是第一网络设备的多个端口中的任意一个端口。
上述第二端口可以是第二网络设备的多个端口中的任意一个端口。
220，第一网络设备根据PDU，确定第一端口为上联口或下联口。
可选地，上述PDU可以携带网络中第二网络设备的级数，或者，PDU携带第二端口的端口属性，其中，第二端口为第二网络设备发送PDU使用的端口。又或者，上述PDU可以携带第二网络设备的级数以及第二端口的端口属性。上述PDU还可以携带第一TLV，第一TLV用于指示第二网络设备为服务器还是交换机。
第一网络设备基于PDU中携带的上述信息，可以确定第一端口的端口属性，即确定第一端口为上联口还是下联口。下文将基于PDU中携带的信息，分情况介绍确定第一端口的端口属性的方法。
为了便于理解，在介绍确定端口属性的方式之前，先介绍本申请实施例提供的确定第一网络设备的级数的方式。需要说明的是，下文介绍的确定第一网络设备的级数的方式可以单独使用，以确定第一网络设备的级数；也可以与确定端口属性的方式结合，以辅助第 一网络设备确定第一端口的端口属性，本申请实施例对此不作限定。
第一网络设备根据PDU确定第一网络设备的级数的方式很多，基于PDU中携带的信息不同，主要可以分为以下五种方式。当然，下面的五种级数的确定方式除了与确定端口数据的方式结合，还可以单独使用，本申请对此不作限定。
确定级数的方式一，若PDU中携带第二网络设备的级数，则第一网络设备可以根据第二网络设备的级数确定第一网络设备的级数。
例如，以图1所示的网络架构为例，从根节点到服务器方向上，不同层级的网络设备的级数递增，且第一网络设备为叶子节点1，第二网络设备为根节点。预配置网络中的网络设备按照从根节点到服务器的方向，逐层发送PDU。即根节点先通过所有端口发送PDU，并且在PDU中携带根节点的级数0，叶子节点1在接收到PDU后，可以以级数0为基准加1，作为叶子节点1的级数1。
又例如，以图1所示的网络架构为例，从根节点到服务器方向上，不同层级的网络设备的级数递减，且第一网络设备为叶子节点1，第二网络设备为根节点。预配置网络中的网络设备按照从根节点到服务器的方向，逐层发送PDU。即根节点先通过所有端口(即下联口)发送PDU，并且在PDU中携带根节点的级数max，叶子节点1在接收到PDU后，可以以级数max为基准减1，作为叶子节点1的级数max-1。
需要说明的是，上述max可以是网络中网络架构的最大级数，还可以是预设的大于该最大级数的任意一个值。
确定级数的方式二，若PDU中携带发送该PDU的网络设备的级数，则第一网络设备可以基于多个网络设备发送的PDU，确定第一网络设备的级数，多个网络设备可以包括上文中的第二网络设备。
即，第一网络设备通过第一端口接收多个网络设备发送的多个PDU，第一网络设备根据多个PDU，确定在网络中多个网络设备的级数；第一网络设备从多个网络设备的级数中选择目标级数；第一网络设备根据目标级数以及预设规则确定第一网络设备的级数。
上述预设规则可以包括若目标级数为多个网络设备的级数中的最大级数，则减小目标级数以得到第一网络设备的级数，或者，上述预设规则还可以包括若目标级数为多个网络设备的级数中的最小级数，则增大目标级数以得到第一网络设备的级数。当然，还可以配置其他规则，以确定第一网络设备的级数，本申请实施例对此不作限定。
上述增大或减小目标级数，可以指基于预设的变化量，增大或减少目标级数。例如预设的变化量可以为1，或者其他值。
需要说明的是，上述方法中，选择目标级数的步骤与确定第一网络设备的级数的步骤，还可以替换为，第一网络设备先基于预设规则对多个网络设备的级数进行调整，得到多个调整后的级数，在从多个调整后的级数中选择目标级数。例如，第一网络设备先对多个网络设备的级数都加1，得到多个调整后的级数，再从多个调整后的级数中选择最小的级数作为目标级数。
可选地，上述多个网络设备是与第一网络设备直接相连的网络设备，也就是说，网络中多个网络设备所在的层级与第一网络设备所在的层级相邻。
需要说明的是，上述多个网络设备所在的层级可以是一个层级也可以是多个层级。当多个网络设备所在的层级可以是一个层级时，即多个网络设备所在的层级相同，且该层级 与第一网络设备的层级相邻。当多个网络设备所在的层级可以是多个层级时，多个网络设备中至少两个网络设备所在的层级不同，且该多个层级与第一网络设备的层级相邻。多个层级可以包括网络中位于第一网络设备所在层级以北的一层，以及第一网络设备所在层级以南的一层。例如，第一网络设备为图1中的叶子节点1时，多个网络设备可以包括根节点1，即根节点1在网络中位于第一网络设备所在层级以北的一层，多个网络设备可以包括服务器a，即服务器a在网络中位于第一网络设备所在层级以南的一层。
下文以图1所示的网络架构为例，介绍本申请实施例确定网络设备的级数的方法。假设从根节点到服务器方向上，不同层级的网络设备的级数递增。通过预配置的方式配置根节点的级数为0，叶子节点的级数的初始值为max。且上述预设变化量为1。每个网络设备以T为周期，周期性地通过所有端口发送PDU，该PDU中携带发送该PDU的网络设备的级数。
由于通常不知道网络的总层数，上述初始值max可以是PDU中表示网络设备的级数的bit位能表示的最大。例如，PDU中通过2bit表示网络设备的级数时，可以配置初始值max为4。即2bit最多可以表示4层网络。如果需要表示更多的网络层级，可以扩大表示网络设备的级数的bit位的数量。
对于网络中的每个根节点而言，都以周期T主动从所有端口发出PDU，PDU携带根节点的级数0。
需要说明的是，由于每个网络设备需要通过所有的端口发送PDU，因此，对于根节点而言，也会收到其他节点发送的PDU，此时，可以配置根节点丢弃PDU。
对于网络中的任意一个叶子节点(例如叶子节点3)而言，在周期1中，会从多个端口接收分别接收多个叶子节点发送的PDU，每个PDU会携带发送该PDU的叶子节点的级数。由于网络中叶子节点的级数的初始值为max，因此，叶子节点3获取到的多个叶子节点的级数中可能包括初始值max。
这样，叶子节点3可以从接收到的多个叶子节点的级数中选择最小的级数作为目标级数，并以目标级数为基准增加1，作为周期1内叶子节点3的级数。在下一个周期2中，叶子节点3再将周期1确定的级数封装在PDU中，发送到其他的叶子节点。经过预设数量的周期后，网络中各叶子节点都可以通过上述方式获知自己在网络中的级数。
可选地，上述多个网络网络设备还可以是与第一网络设备不相邻的网络设备。例如，多个网络设备为根节点，第一网络设备的层次与多个网络设备的层级间隔一层或多层。此时，多个网络设备可以将根节点的级数通过多个PDU发送给第一网络设备，多个PDU中可以分别记录将对应的PDU传输至第一网络设备时进过的网络设备的数量，即传输PDU至第一网络设备时所需的跳数，第一网络设备可以基于PDU以及跳数确定第一网络设备的级数。
确定级数的方式三，若PDU中携带发送该PDU的网络设备的级数为预设值，则第一网络设备直接根据预设值确定自身的级数。
对于根节点来说，通常根节点的级数会被配置为预设值，例如上文中介绍的0。此时，若PDU中携带发送该PDU的网络设备的级数为预设值，则第一网络设备可以确定自身所在的层级与根节点所在的层级相邻，且第一网络设备的级数为以预设值为基准，调整预设变化量。需要说明的是，上述预设变化量的介绍可以参见上文确定级数的方式二中的介绍。
当然，也可以设置网络中服务器的级数为预设值，则第一网络设备可以确定自身所在的层级与服务器所在的层级相邻，且第一网络设备的级数为以预设值为基准，调整预设变化量。
确定级数的方式四，若上述PDU为链路层发现协议(Link Layer Discovery Protocol，LLDP)PDU，则第一网络设备根据所述LLDP PDU中端口ID的子类型，确定所述第一网络设备的级数。
通常，链路层发现协议中规定，交换机遵循IETF RFC 2863，使用的端口ID的子类型(subtype)为接口名称(Interface name)，此时，PDU中携带的端口ID的子类型为5。服务器遵循IEEE Std 802，使用的端口ID的子类型为媒体访问控制地址(media access control address)，此时，PDU中携带的端口ID的子类型为3。
这样，当第一网络设备收到LLDP PDU时，如果PDU中携带的端口ID的子类型为3，则第一网络设备可以确定自身所在的层级与服务器所在的层级相邻，则可以将自身的级数记为预设值，例如，0。
确定级数的方式五，若PDU携带第一TLV，且第一TLV指示发送PDU的网络设备(即，第二网络设备)为服务器，则第一网络设备可以确定自身所在的层级与服务器所在的层级相邻，并可以将自身的级数记为预设值，例如，0。
需要说明的是，上述确定级数的方式三至确定级数的方式五，通常用于网络中特定节点的级数的确定，例如，根节点，或者位于与服务器所在层相邻的层的节点。网络中其他层的网络设备的级数的确定可以通过其他方式确定，例如，确定级数的方式二中介绍的方式。
下文介绍本申请实施例提供的确定端口属性的五种方式，下文确定端口属性的方式一，确定端口属性的方式二以及确定端口属性的方式三中，涉及的确定第一网络设备的级数，和/或确定第二网络设备的级数的方式可以参见上文介绍。当然，第一网络设备的级数，和/或第二网络设备的级数还可以由SDN控制器指示给第一网络设备和第二网络设备，本申请实施例对此不作限定。
确定端口属性的方式一，第一网络设备确定第一网络设备的级数，并基于第一网络设备的级数确定第一端口的端口属性。
第一网络设备可以仅基于第一网络设备的级数确定第一端口的端口属性，例如，第一网络设备在确定自身为根节点后，可以直接确定全部端口的端口属性为下联口。又例如，第一网络设备在确定自身所在的层级为与服务器所在的层级相邻后，可以直接确定接收服务器发送的PDU的第一端口的下联口。当然，第一网络设备还可以结合第一网络设备的级数以及其他信息确定第一端口的端口属性。具体的确定方式在确定端口的端口属性的方式二中具体介绍。
确定端口的端口属性的方式二、第一网络设备根据第一网络设备的级数，所述第二网络设备的级数确定第一端口的端口属性。其中，第一网络设备的级数的确定可以参见上述确定级数的方式一至确定级数的方式六，为了简洁，在此不再赘述。第二网络设备的级数可以承载于PDU中。
当从根节点到服务器方向上，不同层级的网络设备的级数递增时，若第一网络设备的级数小于第二网络设备的级数，则第一网络设备可以确定第一端口为下联口。若第一网络 设备的级数大于第二网络设备的级数，则第一网络设备可以确定第一端口为上联口。
当从根节点到服务器方向上，不同层级的网络设备的级数递减时，若第一网络设备的级数大于第二网络设备的级数，则第一网络设备可以确定第一端口为上联口。若第一网络设备的级数小于第二网络设备的级数，则第一网络设备可以确定第一端口为下联口。
确定端口的端口属性的方式三、第一网络设备根据第二网络设备的级数确定第一端口的端口属性。
应理解，上述第一网络设备根据第二网络设备的级数确定第一端口的端口属性，可以包括第一网络设备仅根据第二网络设备的级数确定第一端口的端口属性，或者，第一网络设备根据第二网络设备的级数以及其他信息确定第一端口的端口属性。例如，可以根据第二网络设备的级数以及第一网络设备的级数确定第一端口的端口属性，具体的确定方式可以参见确定端口的端口属性的方式二中的介绍，本申请实施例对此不作限定。
例如，基于上文的介绍可知，如果第二网络设备为根节点或服务器，第二网络设备的级数可以被配置为预设值，那么，当第一网络设备确定第二网络设备为预设值后，第二网络设备可以直接将第一端口确定为上联口。
确定端口的端口属性的方式四、第一网络设备根据第一TLV确定第一端口的端口属性。
基于上文的介绍，如果第二网络设备为服务器时，可以在PDU中携带上述第一TLV，第一TLV指示所述第二网络设备为服务器。如此，第一网络设备在通过第一端口接收该PDU后，可以直接将第一端口确定为下联口。
确定端口的端口属性的方式五、第一网络设备可以根据PDU中端口ID(port ID)的子类型，确定第一端口的端口属性。
如上文所述，链路层发现协议中规定，交换机遵循IETF RFC 2863，使用的端口ID的子类型(subtype)为接口名称(Interface name)，此时，PDU中携带的端口ID的子类型为5。服务器遵循IEEE Std 802，使用的端口ID的子类型为媒体访问控制地址(media access control address)，此时，PDU中携带的端口ID的子类型为3。
这样，当第一网络设备收到的PDU为LLDP PDU时，如果PDU中携带的端口ID的子类型为3，则第一网络设备可以确定第一端口为下联口。
在上文介绍的确定端口的端口属性以及确定网络设备的级数的方法中，网络中的多个网络设备(例如，第二网络设备)可以周期性的自主发送PDU，以便于网络中的其他网络设备(例如，第一网络设备)可以确定端口属性或级数。当然，第一网络设备还可以借用请求应答的机制，从第二网络设备获取PDU。这种请求应答的机制可以应用于多种协议，下文仅以应用于LLDP协议为例进行介绍。
可选地，上述PDU为LLDP PDU，在步骤210之前，所述方法还包括：所述第一网络设备向所述第二网络设备发送LLDP请求，所述LLDP请求用于请求所述第二网络设备的第二端口的端口属性，和/或所述第二网络设备在网络中的级数。相应地，第二网络设备可以向第一网络设备回复上述LLDP PDU，即响应LLDP请求的过程。
当然，第一网络设备可以以周期向第二网络设备发送上述LLDP请求，但是为了减少第一网络设备与第二网络设备之间的通信次数，减少发送LLDP请求占用的传输资源，第一网络设备还可以按需向第二网络设备发送LLDP请求。即，若所述第一端口的端口属性 未知，所述第一网络设备向所述第二网络设备发送所述LLDP请求。
如上文所述，端口属性和/或网络设备的级数可以承载于PDU中。需要说明的是，关于PDU的标准化协议有很多种，使得在不同的标准中封装格式存在一定差异。下文结合图3至图6，主要介绍在慢协议和LLDP协议中的几种可能的封装格式。需要说明的是，图3至图6所示的封装格式中还可以包括通信协议中已经规定好的其他字段，或者未来通信协议中规定的其他字段，本申请实施例对此不作限定。
下文中结合图3和图4介绍携带网络设备的级数的PDU格式或报文格式。结合图5和图6介绍携带网络设备的级数以及端口的端口属性后的PDU格式或报文格式。
图3示出了本申请实施例的PDU的封装格式的示意图。图3所示的PDU包括：目的地址(Destination Address，DA)310，源地址(Source Address，SA)320，类型(Type)330，子类型(Subtype)340，标志(Flag)域350，代码(Code)360，数据(Data)域370，帧检验序列(Frame Check Sequence，FCS)380。
DA 310，表示PDU的目的MAC地址。通常，为组播MAC地址0180c2000002。
SA 320，表示PDU的源MAC地址。通常，为一个单播MAC地址。
类型330，表示PDU的协议类型，通常为0x8809。
子类型340，表示PDU的协议子类型，通常为0x03。
标志域350：包含了网络中网络设备的状态信息。
代码360，指示PDU的类型。例如，该字段的取值为0x00，表示PDU为消息(Information)PDU；该字段的取值为0x01，表示PDU为事件通知(Event Notification)PDU；该字段的取值为0x04，表示PDU为环路控制(Loopback Control)PDU。
数据域370，用于承载OAM PDU的有效载荷。
FCS 380，为PDU的尾部字段，俗称为“帧尾”，用于验证PDU在传输过程中的完整性。通常为一段4字节的循环冗余校验码。
本申请实施例中，表示网络设备的级数的TLV(又称“第二TLV”)可以承载于图3所示的PDU中的FCS 380之前的任意字段。例如，如图3所示的，第二TLV 390可以占用FCS 380之前的字段，且与FCS 380相邻。
需要说明的是，上述图3所示的PDU的封装格式还可以仅携带端口的端口属性(即第三TLV)，即将上文中的“第二TLV”替换为“第三TLV”即可，为了简洁，在此不再赘述。
图4示出了本申请实施例LLDP报文的封装格式的示意图。图4所示的LLDP报文的封装格式包括：DA 410，SA 420，类型(Type)430，LLDP PDU 440，FCS 440。
其中，DA 410，用于表示LLDP报文的接收端的媒体访问控制(Media Access Control，MAC)地址，通常可以设定为组播MAC地址，例如，0x0180-C200-000E。
SA 420，用于表示发送LLDP报文的发送端的MAC地址。
类型430，用于指示LLDP报文的类型。通常LLDP报文中，该字段的取值为0x88CC。
LLDP PDU 440，用于承载信息或数据等，可以理解为LLDP报文中进行信息交换的主体。通常，LLDP PDU采用类型长度值(type-length-value，TLV)的格式封装数据或信息。具体可以包括：底盘ID(Chassis ID TLV)441、端口ID TLV(Port ID TLV)442、生存时间(Time to Live，TTL)TLV443以及LLDP PDU的结束(End of LLDP PDU)TLV  444。其中，Chassis ID TLV441，用于表示发送端的底盘MAC地址。端口ID TLV 442，用于表示PDU的发送端的端口。TTL TLV 443，用于限制PDU在网络中存在的时间，防止PDU环路。LLDP PDU的结束444，用于标识LLDP PDU的结束。
为提高协议的可扩展性，LLDP PDU 440中还预留了多个保留TLV(reserved TLV)449，例如，保留TLV#1至保留TLV#n，其中n为正整数。通常，保留TLV对应的TLV类型为9至126。在本申请实施例中，表示网络设备的级数的TLV(即“第二TLV”)可以承载于上述多个保留TLV中的任意一个保留TLV中，例如，可以占用保留TLV#1 445。具体地，第二TLV可以包括第二TLV的类型446，第二TLV的长度(TLV length)447以及第二TLV的值(value)448。其中，第二TLV的类型446可以是保留TLV#1对应的TLV类型，即为9。第二TLV的长度447，用于指示第二TLV的值中承载的数据的长度。第二TLV的值448，表示实际的数值，即网络设备的级数。
FCS 440，LLDP报文的尾部字段，俗称为“帧尾”，用于验证LLDP报文在传输过程中的完整性。通常为一段4字节的循环冗余校验码。
可选地，上文仅列出了LLDP PDU 440中包含的部分TLV。目前，LLDP中规定LLDP PDU中的TLV可以分为两种类型，即强制TLV和可选TLV。其中，强制TLV主要包括底盘ID(Chassis ID TLV)441、端口ID TLV(Port ID TLV)442、生存时间(Time to Live，TTL)TLV443等。可选TLV主要包括端口描述(port description)TLV，系统名称(system name)TLV，系统描述(system description)TLV，系统能力(system capabilities)TLV等。为了减少对LLDP PDU中保留TLV的改动，本申请实施例还提供了一种携带网络设备的级数的TLV(即，第二TLV)的方式，即配置第二TLV占用上述任一种可选TLV对应的字段。
需要说明的是，上述图4所示的LLDP报文的封装格式还可以仅携带端口的端口属性(即第三TLV)，即将上文中的“第二TLV”替换为“第三TLV”即可，为了简洁，在此不再赘述。
图5示出了本申请实施例的PDU的封装格式的示意图。需要说明的是，图5所示的PDU的封装格式中与图3所示的PDU的封装格式中含义相同的字段采用相同的编号，具体的含义可以参见上文的介绍，为了简洁，在此不再赘述。
图5所示的PDU包括：目的地址(Destination Address，DA)310，源地址(Source Address，SA)320，类型(Type)330，子类型(Subtype)330，标志(Flag)域350，代码(Code)360，数据(Data)370，帧检验序列(Frame Check Sequence，FCS)380。本申请实施例中，表示网络设备的级数的TLV(又称“第二TLV”)，以及表示端口的端口属性的TLV(又称“第三TLV”)可以承载于图5所示的PDU中的FCS 380之前的任意字段。例如，如图5所示的，第二TLV510以及第三TLV520可以占用FCS 380之前的字段，且与FCS 380相邻。
需要说明的是，上述第二TLV510与第三TLV520之间的位置可以调换，即第三TLV可以位于第二TLV之前的字段。上述第二TLV和第三TLV之间可以不相邻也可以相邻。本申请实施例对此不作限定。
图6示出了本申请实施例的PDU的封装格式的示意图。需要说明的是，图6所示的PDU的封装格式中与图4所示的PDU的封装格式中含义相同的字段采用相同的编号，具 体的含义可以参见上文的介绍，为了简洁，在此不再赘述。
图6所示的LLDP报文的封装格式包括：DA 410，SA 420，类型(Type)430，LLDP PDU 440，FCS 440。其中，LLDP PDU 440中预留有多个保留TLV(reserved TLV)449，例如，保留TLV#1至保留TLV#n，其中n为正整数。通常，保留TLV对应的TLV类型为9至126。
在本申请实施例中，表示网络设备的级数的TLV(即“第二TLV”)可以承载于上述多个保留TLV中的任意一个保留TLV中，例如，可以占用保留TLV#1 445。具体地，第二TLV可以包括第二TLV的类型446，第二TLV的长度(TLV length)447以及第二TLV的值(value)448。其中，第二TLV的类型446可以是保留TLV#1对应的TLV类型，即为9。第二TLV的长度447，用于指示第二TLV的值中承载的数据的长度。第二TLV的值448，表示实际的数值，即网络设备的级数。
表示端口的端口属性的TLV(即“第三TLV”)可以承载于上述多个保留TLV中的任意一个保留TLV中，例如，可以占用保留TLV#2 610。具体地，第三TLV可以包括TLV类型611，TLV长度(TLV length)612以及TLV的值(value)613。其中，第三TLV的类型612可以是保留TLV#2对应的TLV类型，即10。第三TLV的长度612，用于指示第三TLV的值中承载的数据的长度。第三TLV的值613，表示实际的数值，即端口的端口属性。
可选地，上文仅列出了LLDP PDU 440中包含的部分TLV。目前，LLDP中规定LLDP PDU中的TLV可以分为两种类型，即强制TLV和可选TLV。其中，强制TLV主要包括底盘ID(Chassis ID)TLV441、端口ID TLV(Port ID TLV)442、生存时间(Time to Live，TTL)TLV443等。可选TLV主要包括端口描述(port description)TLV，系统名称(system name)TLV，系统描述(system description)TLV，系统能力(system capabilities)TLV等。为了减少对LLDP PDU中保留TLV的改动，本申请实施例还提供了一种携带第二TLV以及第三TLV的方式，即配置第二TLV以及第三TLV占用上述任两种可选TLV对应的字段。
下文结合图7介绍本申请实施例的LLDP请求的封装格式。图7所示的LLDP请求包括：DA 710，SA 720，类型(Type)730，LLDP PDU 740，FCS 770。
其中，DA 710，用于表示LLDP请求的接收端的媒体访问控制(Media Access Control，MAC)地址，通常可以设定为组播MAC地址，例如，0x0180-C200-000E。
SA 720，用于表示发送LLDP请求的发送端的MAC地址。
类型730，用于指示LLDP请求的类型。
LLDP PDU 740，用于承载信息或数据等，可以理解为LLDP信息交换的主体。通常，LLDP PDU采用类型长度值(type-length-value，TLV)的格式封装数据或信息。具体可以包括：底盘ID(Chassis ID)TLV741、端口ID TLV(Port ID TLV)742、生存时间(Time to Live，TTL)TLV 743以及LLDP PDU的结束(End of LLDP PDU)TLV 744。其中，底盘ID TLV741，用于表示发送端的底盘MAC地址。端口ID TLV 742，用于表示LLDP请求的发送端的端口。TTL TLV 743，用于限制LLDP请求在网络中存在的时间，防止LLDP请求环路。End of LLDP PDU 744，用于标识LLDP PDU的结束。
为提高协议的可扩展性，LLDP PDU 740中还预留了多个保留TLV(reserved TLV) 749，例如，保留TLV#1至保留TLV#n，其中n为正整数。通常，保留TLV对应的TLV类型为9至126。在本申请实施例中，用于请求网络设备的级数的TLV和/或用于请求端口的端口属性的TLV(统称为“请求TLV”)可以承载于上述多个保留TLV中的任意一个保留TLV中。
例如，请求TLV仅可以仅占用保留TLV#1 745。具体地，请求TLV可以包括请求TLV的类型746，请求TLV的长度(TLV length)747以及请求TLV的值(value)748。其中，请求TLV的类型746可以是保留TLV#1对应的TLV类型，即为9。请求TLV的长度747，用于指示请求TLV的值中承载的数据的长度。请求TLV的值748，表示实际的数值，即网络设备的级数和/或端口的端口属性。
FCS 740，LLDP报文的尾部字段，俗称为“帧尾”，用于验证LLDP报文在传输过程中的完整性。通常为一段4字节的循环冗余校验码。
可选地，上文仅列出了LLDP PDU 740中包含的部分TLV。目前，LLDP中规定LLDP PDU中的TLV可以分为两种类型，即强制TLV和可选TLV。其中，强制TLV主要包括底盘ID(Chassis ID TLV)741、端口ID TLV(Port ID TLV)742、生存时间(Time to Live，TTL)TLV 743等。可选TLV主要包括端口描述(port description)TLV，系统名称(system name)TLV，系统描述(system description)TLV，系统能力(system capabilities)TLV等。为了减少对LLDP PDU中保留TLV的改动，本申请实施例还提供了一种携带请求TLV的方式，即配置请求TLV占用上述任一种可选TLV对应的字段。
需要说明的是，上文中的LLDP请求的封装格式与LLDP报文的封装格式对应。例如，当上述LLDP请求用于请求网络设备的级数时，LLDP报文可以采用图4所示的封装格式。当上述LLDP请求用于请求网络设备的级数以及端口的端口类型时，LLDP报文可以采用图5所示的封装格式。
下文以图1所示的网络架构为例，结合具体的例子介绍本申请实施例的确定端口的端口属性的方法。需要说明的是，下文中的具体例子仅仅为了便于理解本申请，并不会限定本申请的范围。
图7是本申请实施例的确定端口的端口属性的方法的示意性流程图。图7所示的方法包括步骤710至步骤750。假设从根节点到服务器方向上，不同层级的网络设备的级数以步长1递增。通过预配置的方式配置根节点的级数为0，叶子节点的级数的初始值为max，以及预配置网络中每个节点(包括根节点以及叶子节点)的端口的初始端口属性为下联口。每个网络设备以T为周期，周期性地通过所有下联口发送PDU，该PDU中携带发送该PDU的网络设备的级数。
由于通常不知道网络的总层数，上述初始值max可以是PDU中表示网络设备的级数的bit位能表示的最大。例如，PDU中通过2bit表示网络设备的级数时，可以配置初始值max为4。即2bit最多可以表示4层网络。如果需要表示更多的网络层级，可以扩大表示网络设备的级数的bit位的数量。
对于网络中的每个根节点而言，都以周期T主动从所有端口发出PDU，PDU携带根节点的级数0。需要说明的是，对于根节点而言，所有的端口都是下联口。
还应理解，由于每个网络设备(包括根节点和叶子节点)都需要通过所有的端口发送PDU，因此，对于根节点而言，也会收到叶子节点发送的PDU，此时，可以配置根节点 丢弃其他节点发送的PDU。
对于网络中的任意一个叶子节点而言，叶子节点中配置有变量switch_level，switch_level用于存放叶子节点的级数，其初始值为max。叶子节点中还为每个端口配置有变量port_level，port_level用于存储根据从端口接收的PDU中携带的网络设备的级数，确定的本节点的级数，其初始值也为max。
下文以叶子节点3为例介绍确定端口的端口属性的方法。网络中的其他叶子节点确定端口的端口属性的方法与该方法类似，为了简洁，不再赘述。假设叶子节点3有三个端口分别用P 1、P 2和P 3表示，则P 1对应的变量为port_level 1，P 2对应的变量为port_level 2，P 1对应的变量为port_level 3。
710，在周期1中，叶子节点3通过P 1、P 2和P 3分别接收PDU 1，PDU 2和PDU 3，其中，PDU 1中携带的网络设备的级数为X 1，PDU 2中携带的网络设备的级数为X 2，PDU 3中携带的网络设备的级数为X 3。
720，叶子节点3将X 1保存在port_level 1中，X 2保存在port_level 2中，X 3保存在port_level 3中。
需要说明的是，若上述周期1为确定端口的端口属性的初始周期，且叶子节点的级数的初始值为max，那么上述X 1，X 2，X 3中表示叶子节点的级数的取值为max，表示叶子节点的级数的取值为0。
730，叶子节点3从X 1，X 2，X 3中，选择最小值X min，并将X min+1存储至变量switch_level。
需要说明的是，若X 1，X 2，X 3相等，则X min等于X 1，X 2，X 3中任一值。
740，叶子节点3根据X i以及X min+1，确定P 1、P 2和P 3的端口属性，其中i＝1,2,3。
具体地，若X i＜X min+1，则可以确定X i对应的叶子节点3的端口为上联口；若X i＞X min+1，则可以确定X i对应的叶子节点3的端口为下联口。
750，在周期2中，将X min+1封装在PDU中作为叶子节点3的级数，并通过全部的下联口发送携带X min+1的PDU。
需要说明的是，上述周期2是周期1的下一个周期。叶子节点3在周期2中依然会收到其他节点通过下联口发送的PDU。叶子节点3可以重新执行上述步骤710至步骤750，确定各端口的端口属性。
经过预设的多个周期，网络中每个叶子节点的端口的端口属性趋于稳定，则可以停止发送PDU，此时，每个叶子节点确定的端口的端口属性较为准确。
下文以图1所示的网络架构为例，结合具体的例子，介绍本申请实施例提供的基于LLDP协议确定端口的端口属性的方法。图8所示的方法包括步骤810至步骤830。假设从根节点到服务器方向上，不同层级的节点的级数以步长1递减，且预先预定若网络设备与服务器相邻则该网络设备的级数为1。下文以叶子节点3发送LLDP请求为例，进行说明。假设叶子节点3的端口P 1的端口属性未知。
810，叶子节点3通过端口P 1向相邻的节点发送LLDP请求，以请求相邻的节点的级数以及端口属性。
当相邻节点为叶子节点时，叶子节点2通过端口Q 1接收该第一LLDP请求，第一LLDP请求用于请求叶子节点2的级数以及第二端口的端口属性。
若叶子节点2的级数以及端口Q 1的端口属性已知，则叶子节点2通过端口Q 1向叶子节点3发送第一LLDP报文，第一LLDP报文携带叶子节点2的级数，以及端口Q 1的端口属性。若叶子节点2的级数以及端口Q 1的端口属性未知，则叶子节点2被配置忽略上述第一LLDP请求。
当相邻节点为服务器时，叶子节点3通过P 2向服务器1发送第二LLDP请求，用于请求服务器1的级数以及服务器1的端口的端口属性。相应地，服务器向叶子节点2反馈第二LLDP报文。
820，叶子节点3通过端口P 1接收第一LLDP报文，或第二LLDP报文。
830，叶子节点3根据接收的LLDP报文，确定叶子节点3的级数以及发送LLDP报文的端口的端口属性。
上述LLDP报文为第一LLDP报文，若叶子节点3从第一LLDP报文中获取叶子节点2的级数为M，且端口Q 1的端口属性为下联口，则叶子节点3可以确定叶子节点3的级数为M+1，且端口P 1为上联口，其中，M为正整数。
若叶子节点3从第一LLDP报文中获取叶子节点2的级数为Z，且端口Q 1的端口属性为上联口，则叶子节点3可以确定叶子节点3的级数为Z-1，且端口P 1为下联口，其中，Z为大于或等于1的正整数。
上述LLDP报文为第二LLDP报文时，叶子节点3可以根据第二LLDP报文中端口ID的子类型确定相邻的节点为服务器，此时，叶子节点3可以确定端口P 1为下联口，且叶子节点3的级数为1。
需要说明的是，如上文所述，LLDP协议中规定，服务器适用的端口ID的子类型通常为MAC地址，即第二LLDP报文中携带的端口ID的子类型的取值为5。与交换机使用的端口ID的子类型不同。因此，叶子节点3可以基于第二LLDP报文中的端口ID的子类型，直接确定第二LLDP报文的发送端为服务器。
还应理解，相邻的节点为服务器时，由于叶子节点3可以直接基于端口ID的子类型，确定叶子节点3的级数以及端口P 1的端口属性，因此，上述第二LLDP报文中可以无需携带服务器的级别0以及服务器发送第二LLDP报文使用的端口的端口属性。当然，为了提高叶子节点3确定级数以及端口的端口属性的准确率，也可以在第二LLDP报文中携带服务器的级数，以及发送第二LLDP报文使用的端口的端口属性。
需要说明的是，在上述步骤810至步骤830描述的过程之前，叶子节点3可能会获得多个叶子节点3的级数。例如，叶子节点3在确定端口P 1的端口属性之前，已经获知了叶子节点3的级数为m，m为正整数，且与叶子节点3在上述步骤830中确定的级数不同。又或者，叶子节点3有多个端口的端口属性未知，则叶子节点3可能会从多个相邻节点处获取多个不同的相邻节点级数，导致叶子节点3确定了不同的多个叶子节点3的级数。在这种情况下，叶子节点3可以从多个叶子节点3的级数选择最大的级数，作为叶子节点3的级数。
下文以图1所示的网络架构为例，结合具体的例子，介绍本申请另一实施例提供的基于LLDP协议确定端口的端口属性的方法。图9所示的方法包括步骤910至步骤920。假设从根节点到服务器方向上，不同层级的节点的级数以步长1递减，且预先预定若网络设备与服务器相邻则该网络设备的级数为1。在预设时间段内，图9所述的网络中网络设备 通过全部的端口向相邻的网络设备发送LLDP报文。
下文以叶子节点3为例介绍确定端口的端口属性的方法。网络中的其他叶子节点确定端口的端口属性的方法与该方法类似，为了简洁，不再赘述。假设叶子节点3有三个端口分别用P 1、P 2和P 3表示。
910，叶子节点3通过端口P 1接收相邻节点发送的LLDP报文。
若LLDP报文中携带的端口ID的子类型为服务器使用的端口ID的子类型，叶子节点3可以直接确定端口P 1为下联口，且叶子节点3的级数为1。
需要说明的是，关于上述端口ID的子类型的介绍可以参见上文描述，为了简洁，在此不再赘述。
若LLDP报文中携带相邻节点的级数A`以及端口的端口属性为下联口，且叶子节点3记录的叶子节点3的级数为B`，其中，A`为大于1的正整数，B`为正整数。当A`-1＜B`时，叶子节点3将A`-1更新为叶子节点3的级数，并将端口P 1标记为上联口。当A`-1＞B`时，叶子节点3不更新叶子节点3的级数，并将端口P 1标记为上联口。
当然，在上述情况中，若叶子节点3未记录的叶子节点3的级数，则叶子节点3可以直接将A`-1作为叶子节点3的级数。
若LLDP报文中携带相邻节点的级数A以及端口的端口属性为上联口，且叶子节点3记录的叶子节点3的级数为B，其中，A为大于1的正整数，B为正整数。当A+1＜B时，叶子节点3将A+1更新为叶子节点3的级数，并将端口P 1标记为下联口。当A+1＞B时，叶子节点3不更新叶子节点3的级数，并将端口P 1标记为下联口。
当然，在上述情况中，若叶子节点3未记录的叶子节点3的级数，则叶子节点3可以直接将A+1作为叶子节点3的级数。
920，叶子节点3通过各个端口向相邻节点发送LLDP报文，该报文中携带叶子节点3的级数，以及发送LLDP报文使用的端口的端口属性。
上文中介绍的确定网络设备的级数，以及确定端口的端口属性的方法可以应用在各种场景中。下文以将确定端口的端口属性的方法应用于部署防PFC死锁规则的场景为例，介绍本申请实施例的方法。为了便于理解，下文先基于图1所示的网络拓扑，先介绍优先级流量控制(Priority-based flow control，PFC)策略以及PFC死锁的形成。
在图1所示的网络中，可以采用上述PFC策略传输数据流。PFC一种基于优先级的流量控制策略。PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟通道创建无丢包类别的服务，使其能够与同一接口上的其它流量共存。
下文结合图1所示数据流1、数据流2以及数据流3的传输路径为例，介绍PFC死锁的产生。其中，数据流1、数据流2以及数据流3的优先级相同，且在网络中通过队列5组成的虚拟通道进行传输。
在图1所示的网络中，每个根节点以全连接的方式连接至所有的叶子节点，且同层的网络设备之间不能直接通信，因此，网络中无链路故障时，数据流的流向通常是仅上行的方向，或者仅下行的方向。又或者是由上行(up)到下行(down)的方向，例如，图1中数据流2的传输路径以及数据流3的传输路径。其中，数据流2为需要从服务器c传输 至服务器d的数据流，数据流2的传输路径为服务器c-叶子节点2-根节点1-叶子节点3-服务器d。数据流3为需要从服务器e传输至服务器b的数据流，数据流3的传输路径为服务器e-叶子节点3-根节点2-叶子节点2-服务器c。
然而，当不同层的两个网络设备之间的链路故障后，网络中会产生由下行到上行流向的数据流。例如，根节点2与叶子节点4之间的链路故障后，需要从服务器a传输至服务器f的数据流1只能沿着图1所示的数据流1的传输路径进行传输，即服务器a-叶子节点1-根节点1-叶子节点3-根节点2-叶子节点4-服务器f。其中，数据流1在根节点1到叶子节点3之间为下行方向的数据流，数据流1在叶子节点3到根节点2之间为上行方向的数据流。
一旦网络中产生上述下行-上行流向的数据流后，该流向的数据流就可能与网络中相同优先级的其他通过正常流向传输数据流形成一个环路，该环路的形状类型数字8。例如，图1中数据流1、数据流2以及数据流3在根节点1、根节点2、叶子节点2以及叶子节点3之间形成的环路。
为了便于说明PFC死锁，图10仅示出了图1中的环路涉及的4个节点以及组成环路的3个数据流。在图10所示的环路中，当叶子节点3中队列5对应的缓存的容量的消耗超过阈值，即出现瞬时拥塞，则叶子节点3即向数据进入的方向发送反压信息(又称“PFC暂停帧”)，即叶子节点3沿着数据流1和数据流2流进的方向，将反压信息发送至根节点1。相应地，根节点1接收到反压信息后，会根据反压信息指示停止发送或延迟发送数据流1以及数据流2剩下的数据，并将剩下的数据缓存在本端队列5对应的缓存中。如果根节点1中队列5对应的缓存的消耗超过阈值，则沿着数据流2流进的方向，再将反压信息发送至叶子节点2。相应地，叶子节点2接收到反压信息后，会根据反压信息指示停止发送或延迟发送数据流2剩下的数据，并将剩下的数据缓存在本端队列5对应的缓存中。如果叶子节点2中队列5对应的缓存的消耗超过阈值，则继续沿着数据流3流进的方向，再将反压信息发送至根节点2。相应地，根节点2接收到反压信息后，会根据反压信息指示停止发送或延迟发送数据流3剩下的数据，并将剩下的数据缓存在本端队列5对应的缓存中。如果根节点2的队列5对应的缓存的消耗超过阈值，则继续沿着数据流3流进的方向，再将反压信息发送至叶子节点3。如此一级级反压，最终导致根节点1、根节点2、叶子节点2以及叶子节点3的队列5中都没有数据流进行传输，也就是说，上述4个节点之间队列5中缓存的流量不能发送，使得4个节点的缓存容量的消耗长久处于超过阈值的状态，即产生PFC死锁。
综上，可以看出，PFC死锁产生的根本原因是由于网络中产生了下行-上行流向的数据流。并且该下行-上行流向的数据流在一个网络设备被传输时，使用的是该网络设备中的两个上联口。例如，数据流1在流经叶子节点3时，入端口(inport)P r，以及出端口(outport)P r+1的端口属性都为上联口。因此，为了避免网络中产生下行-上行流向的数据流，从而预防PFC死锁产生，可以在网络中的每个叶子节点部署防PFC死锁规则。例如，可以在叶子节点3中部署防PFC死锁规则，该防PFC死锁规则可以包括：若{inport＝P r,outport＝P r+1,queue＝5}，动作：切换到队列6，且将数据流的优先级字段修改为队列6对应的优先级。该防PFC死锁规则表示，当数据流的入端口为P r，出端口为P r+1，且对应的队列为队列5时，叶子节点3需要将该数据流直接缓存在队列6中，并将该数据流的优先级从队列5对 应的优先级修改为队列6对应的优先级。即对流经一个网络设备的两个上联口的流量，执行切换优先级的操作，以防止产生PFC死锁。
如上文所述，下行-上行流向的数据流产生的原因通常是由于某一链路故障导致的，也就是说，下行-上行流向的数据流的产生具有一定的随机性。而这种随机性是不可预测的，因此，为了避免下行-上行流向的数据流产生，通常以预先部署的方式，在网络中有数据流被传输之前，由SDN控制器(例如，SDN控制器140)为网络中的每个网络设备的每两个上联口都部署防PFC死锁规则。如此一来，可能导致SDN控制器的负载过大。
为了减少SDN控制器部署防PFC死锁规则产生的压力，本申请还提供了一种新的防PFC死锁规则的部署方式，即由网络设备自己基于本端的上联口，自主生成防PFC死锁规则。下文结合图11介绍本申请实施例的防PFC死锁规则的部署方法的流程图。图11所示的方法可以由第一网络设备执行，第一网络设备可以是图1所示的网络设备中的任意一个叶子节点，第一网络设备包括多个发送队列，多个发送队列包括第一发送队列和第二发送队列，所述第一发送队列为第一数据流对应的原始发送队列。图11包括步骤1110至步骤1120。
1110，第一网络设备确定第一端口以及第一网络设备的第三端口为上联口。
需要说明的是，第一网络设备确定第一端口以及第三端口的方法可以参见上文中关于确定端口的端口属性的方法，为了简洁，在此不再赘述。当然，SDN控制器也可以向第一网络设备直接指示上述第一端口以及第三端口为上联口。
1120，第一网络设备生成防优先级流量控制PFC死锁规则，防PFC死锁规则用于指示将所述第一数据流缓存至第二发送队列，第一数据流的入端口为第一端口，第一数据流的出端口为所述第三端口。
可选地，上述第一发送队列对应的优先级与第二发送队列对应的优先级不同，但是在最终进行数据调度的过程中，可以将第一发送队列与第二发送队列视为对应相同优先级的队列，并按照预设的比例进行数据调度，以避免由切换队列导致的数据流乱序传输。
可选地，对于相同的一组上联口可以部署一条或多条防PFC死锁规则。
例如，可以针对两个上联口的不同数据流的流向部署多条防PFC死锁规则。对于上述叶子节点2中的上联口P r以及上联口P r+1可以部署的防PFC死锁规则包括：若{inport＝P r,outport＝P r+1,queue＝5}，动作：切换到队列6，且将数据流的优先级字段修改为队列6对应的优先级。以及若{inport＝P r+1,outport＝P r,queue＝5}，动作：切换到队列6，且将数据流的优先级字段修改为队列6对应的优先级。
又例如，可以针对不同的传输方式为两个上联口部署多条防PFC死锁规则。对于上述叶子节点2中的上联口P r以及上联口P r+1可以部署的防PFC死锁规则包括：若{inport＝P r,outport＝P r+1,queue＝5}，动作：切换到队列6，且将数据流的优先级字段修改为队列6对应的优先级。以及若{inport＝P r+1,outport＝P r,queue＝5}，动作：切换到队列3，且将数据流的优先级字段修改为队列3对应的优先级，其中队列5、队列6为无损列队，即用于传输无损流量。队列3为有损队列，即用于传输有损流量。
需要说明的是，上述流量可以基于预设的规则，确定切换无损流量传输模式还是有损流量传输模式，从而确定基于上述防PFC死锁规则确定切换至队列6还是队列3。
可选地，上述步骤1110以及步骤1120可以是由于网络中网络拓扑结构发生变化而触 发的，例如，新增部分网络设备，或者减少部分网络设备等。还可以是网络拓扑建立完成后，在传输数据流之前触发的。本申请实施例对此不作限定。
可选地，所述方法还包括：所述第一网络设备确定在预设时间段内，所述第一端口与所述第三端口为PFC死锁关联的端口的次数；上述步骤1120，包括：当所述次数高于预设阈值，所述第一网络设备确定生成所述防PFC死锁规则。
在本申请实施例中，根据次数确定生成防PFC死锁规则的上联口，无需为每组上联口都生成防PFC死锁规则，有利于减少网络设备生成防PFC死锁规则的数量，减少防PFC死锁规则占用的存储空间。
可选地，所述方法还包括：所述第一网络设备通过所述第一端口接收所述第二网络设备发送的指示信息，所述指示信息用于指示所述第二网络设备中的第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0，所述第三发送队列缓存的数据流的优先级与所述第一数据流的优先级相同；所述第一网络设备根据指示信息确定所述次数。
需要说明的是，上述根据指示信息确定所述次数的方式有很多种，例如指示信息可以指示在预设时间段内第三发送队列容量超过阈值且入流量为0产生的总次数。还可以当每次第三发送队列容量超过阈值且入流量为0时，第二网络设备都向第一网络设备发送指示信息，由第一网络设备统计预设时间段内，第三发送队列容量超过阈值且入流量为0产生的总次数。
例如，第一网络设备的控制面可以维护一张链表，其中一个表项为<第一端口，第三端口，优先级1，Z>，表示预设时间段内，第一端口作为入端口，第三端口作为出端口，且优先级1对应的次数为Z。当次数Z大于预设阈值时，第一网络设备为第一端口，第三端口生成防PFC死锁规则。
又例如，第一网络设备的控制面可以维护一张链表，其中一个表项为<第一端口，第三端口，优先级1，Z’>，表示预设时间段内，第一端口作为入端口，第三端口作为出端口，且优先级1对应的次数为Z。其中Z’为预先配置的初始次数，且大于0。每收到指示信息后，Z’都减少预设的次数(例如，1)，当次数Z’为0时，第一网络设备为第一端口，第三端口生成防PFC死锁规则。
可选地，上述指示信息可以通过携带第三发送队列缓存的数据流的优先级，指示所述第二网络设备中的第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0。
可选地，上述指示信息可以携带在PDU中，上述数据流的优先级可以通过PDU中的可选TLV承载，或通过新增TLV承载，具体的封装方式可以参见上文关于PDU的封装方式的介绍，为了简洁，在此不再赘述。
上文结合图1至图11详细地描述了本申请实施例的方法，下文结合图12至图14详细地描述本申请实施例的确定端口的端口属性的装置。需要说明的是，图12至图14所示的装置可以实现上述方法中各个步骤，为了简洁，在此不再赘述。
图12是本申请实施例的确定端口的端口属性的装置的示意性框图。图12所示的装置1200例如可以是上文中的第一网络设备，具体包括接收模块1210以及处理模块1220。可选地，接收模块1210用于执行上述步骤210，处理模块1220用于执行上述步骤220。可 选地，处理模块1220还用于执行上述步骤1110以及步骤1120。
即，接收模块1210，用于通过第一端口接收第二网络设备发送的协议数据单元PDU；
处理模块1220，用于根据所述接收模块接收的所述PDU，确定所述第一端口为上联口或下联口。
可选地，作为一个实施例，所述PDU携带网络中所述第二网络设备的级数，和/或所述PDU携带所述第二网络设备发送所述PDU使用的第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
可选地，作为一个实施例，所述处理模块，具体用于：根据所述PDU确定在所述网络中所述第一网络设备的级数；根据所述第一网络设备的级数，确定所述第一端口为上联口或下联口。
可选地，作为一个实施例，所述网络包括多个网络设备，所述多个网络设备包括所述第二网络设备，所述接收模块，还用于：通过多个端口接收所述多个网络设备发送的多个PDU，所述多个端口包括所述第一端口，所述多个PDU包括所述第二网络设备发送的所述PDU；所述处理模块还用于：根据所述多个PDU，确定在所述网络中所述多个网络设备的级数；从所述多个网络设备的级数中选择目标级数；根据所述目标级数以及预设规则确定所述第一网络设备的级数。
可选地，作为一个实施例，所述处理模块，具体用于：根据所述第一网络设备的级数，以及所述第二网络设备的级数确定所述第一端口为上联口或下联口。
可选地，作为一个实施例，所述处理模块，具体用于：根据所述PDU确定所述第二网络设备的级数；根据所述第二网络设备的级数确定所述第一端口为上联口或下联口。
可选地，作为一个实施例，所述第二网络设备为所述网络中的根节点，所述接收模块还用于：通过所述第一端口接收所述第二网络设备发送的所述PDU，所述PDU中携带的所述第二网络设备的级数为预设值；所述处理模块还用于：根据所述预设值确定所述第一端口为上联口。
可选地，作为一个实施例，所述处理模块，还用于：根据所述预设值，确定所述第一网络设备的级数，其中，在网络中，所述第一网络设备的级数表示的层级与所述根节点所在的层级相邻。
可选地，作为一个实施例，所述处理模块，还用于：根据所述PDU，确定所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器；确定所述第一端口为下联口。
可选地，作为一个实施例，所述PDU为LLDP PDU。
可选地，作为一个实施例，所述处理模块，还用于：根据所述LLDP PDU中端口ID的子类型，确定所述第二网络设备为服务器；确定所述第一端口为下联口。
可选地，作为一个实施例，所述处理模块，还用于：根据所述LLDP PDU中端口ID的子类型，确定所述第一网络设备的级数，其中，在网络中所述第一网络设备的级数表示的层级与所述服务器所在的层级相邻。
可选地，作为一个实施例，所述装置还包括发送模块，所述发送模块用于：向所述第二网络设备发送LLDP请求，所述LLDP请求用于请求所述第二网络设备的第二端口的端口属性，和/或所述第二网络设备在网络中的级数。
可选地，作为一个实施例，若所述第一端口的端口属性未知，所述发送模块还用于向所述第二网络设备发送所述LLDP请求。
可选地，作为一个实施例，所述LLDP PDU包括第二TLV，所述第二TLV用于指示所述第二网络设备的级数，和/或所述LLDP PDU包括第三TLV，所述第三TLV用于指示所述第二端口的端口属性。
可选地，作为一个实施例，所述第二TLV或所述第三TLV占用所述LLDP PDU中的保留位。
可选地，作为一个实施例，所述装置还包括多个发送队列，所述多个发送队列包括第一发送队列和第二发送队列，所述第一发送队列为第一数据流对应的原始发送队列，所述处理模块，还用于确定所述第一端口以及所述第一网络设备的第三端口为上联口；以及生成防优先级流量控制PFC死锁规则，所述防PFC死锁规则用于指示将所述第一数据流缓存至所述第二发送队列，所述第一数据流的入端口为所述第一端口，所述第一数据流的出端口为所述第三端口。
可选地，作为一个实施例，所述处理模块，还用于：确定在预设时间段内，所述第一端口与所述第三端口为PFC死锁关联的端口的次数；当所述次数高于预设阈值，确定生成所述防PFC死锁规则。
可选地，作为一个实施例，所述发送模块，还用于通过所述第一端口接收所述第二网络设备发送的指示信息，所述指示信息用于指示所述第二网络设备中的第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0，所述第三发送队列缓存的数据流的优先级与所述第一数据流的优先级相同；所述处理模块，用于根据指示信息确定所述次数。
图13是本申请另一实施例的确定端口属性的装置的示意性框图，图13所示的装置1300例如可以是上文中的第二网络设备，具体可以包括：处理模块1310以及发送模块1320。可选地，处理模块1310用于执行上述步骤200，发送模块1320用于执行上述步骤210中第二网络设备实现的功能。
即，处理模块1310，用于生成协议数据单元PDU，所述PDU用于确定第一网络设备的第一端口为上联口或下联口；
发送模块1320，用于通过第二端口向所述第一网络设备发送所述处理模块生成的所述PDU。
可选地，作为一个实施例，所述PDU携带网络中所述第二网络设备的级数，和/或所述PDU携带所述第二网络设备发送所述PDU使用的第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
可选地，作为一个实施例，所述第二网络设备为所述网络中的根节点，所述PDU中携带的所述第二网络设备的级数为预设值。
可选地，作为一个实施例，所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器。
可选地，作为一个实施例，所述PDU为LLDP PDU。
可选地，作为一个实施例，所述装置还包括接收模块，所述接收模块用于接收所述第一网络设备发送的LLDP请求，所述LLDP请求用于请求所述第二端口的端口属性，和/ 或所述第二网络设备的级数。
可选地，作为一个实施例，所述LLDP PDU包括第二TLV，所述第二TLV用于指示所述第二网络设备的级数，和/或所述LLDP PDU包括第三TLV，所述第三TLV用于指示所述第二端口的端口属性。
可选地，作为一个实施例，所述第二TLV或所述第三TLV占用所述LLDP PDU中的保留位。
可选地，作为一个实施例，所述发送模块，还用于向所述第一网络设备发送指示信息，所述指示信息用于指示所述装置中的第三发送队列对应的缓存的容量超过阈值，且所述第三发送队列的入流量为0，所述第三发送队列缓存的数据流的优先级与所述第一数据流的优先级相同。
在可选的实施例中，所述接收模块1210可以为入端口1430，所述处理模块620可以为处理器1420，所述网络设备还可以包括存储器1410以及出端口1440，具体如图14所示。
在可选的实施例中，所述发送模块1310可以为出端口1440，所述处理模块1320可以为处理器1420，所述网络设备还可以包括存储器1410以及入端口1430，具体如图14所示。
图14是本申请另一实施例的网络设备的示意性框图。图14所示的网络设备1400可以包括：存储器1410、处理器1420、入端口1430，以及出端口1440。其中，存储器1410、处理器1420，入端口1430，以及出端口1440通过内部连接通路相连，该存储器1410用于存储指令，该处理器1420用于执行该存储器1420存储的指令，以控制入端口1430接收输入的PDU或数据流，控制出端口1440转发待发送的PDU或者数据流。
需要说明的是，上述入端口1430可以是网络设备包括的多个端口中的一个。上述出端口1440可以网络设备包括的多个端口中的一个。上述入端口1430和出端口1440可以理解为两个逻辑端口，也就是说可以分别对应两个物理端口，也可以对应一个物理端口，本申请对此不作限定。
在实现过程中，上述方法的各步骤可以通过处理器1420中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1410，处理器1420读取存储器1410中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
应理解，本申请实施例中，该处理器可以为中央处理单元(central processing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中，该存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。处理器的一部分还可以包括非易失性随机存取存储器。例如，处 理器还可以存储设备类型的信息。
应理解，在本申请实施例中，“与A对应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (38)

  1. 一种确定端口属性的方法，其特征在于，包括：
    第一网络设备通过第一端口接收第二网络设备发送的协议数据单元PDU；
    所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口。
  2. 如权利要求1所述的方法，其特征在于，所述PDU携带网络中所述第二网络设备的级数，和/或
    所述PDU携带所述第二网络设备发送所述PDU使用的第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
  3. 如权利要求2所述的方法，其特征在于，所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口，包括：
    所述第一网络设备根据所述PDU确定在所述网络中所述第一网络设备的级数；
    所述第一网络设备根据所述第一网络设备的级数，确定所述第一端口为上联口或下联口。
  4. 如权利要求3所述的方法，其特征在于，所述网络包括多个网络设备，所述多个网络设备包括所述第二网络设备，
    所述第一网络设备通过第一端口接收第二网络设备发送的协议数据单元PDU，包括：
    所述第一网络设备通过多个端口接收所述多个网络设备发送的多个PDU，所述多个端口包括所述第一端口，所述多个PDU包括所述第二网络设备发送的所述PDU；
    所述第一网络设备根据所述PDU确定在所述网络中所述第一网络设备的级数，包括：
    所述第一网络设备根据所述多个PDU，确定在所述网络中所述多个网络设备的级数；
    所述第一网络设备从所述多个网络设备的级数中选择目标级数；
    所述第一网络设备根据所述目标级数以及预设规则确定所述第一网络设备的级数。
  5. 如权利要求3或4所述的方法，其特征在于，所述第一网络设备根据所述第一网络设备的级数，确定所述第一端口为所述上联口或所述下联口，包括：
    所述第一网络设备根据所述第一网络设备的级数，以及所述第二网络设备的级数确定所述第一端口为上联口或下联口。
  6. 如权利要求2所述的方法，其特征在于，所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口，包括：
    所述第一网络设备根据所述PDU确定所述第二网络设备的级数；
    所述第一网络设备根据所述第二网络设备的级数确定所述第一端口为上联口或下联口。
  7. 如权利要求6所述的方法，其特征在于，所述第二网络设备为所述网络中的根节点，所述第一网络设备通过第一端口接收第二网络设备发送的PDU，包括：
    所述第一网络设备通过所述第一端口接收所述第二网络设备发送的所述PDU，所述PDU中携带的所述第二网络设备的级数为预设值；
    所述第一网络设备根据所述第二网络设备的级数确定所述第一端口为上联口或下联口，包括：
    所述第一网络设备根据所述预设值确定所述第一端口为上联口。
  8. 如权利要求1所述的方法，其特征在于，所述第一网络设备根据所述PDU，确定所述第一端口为上联口或下联口，包括：
    所述第一网络设备根据所述PDU，确定所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器；
    所述第一网络设备确定所述第一端口为下联口。
  9. 权利要求1-8中任一项所述的方法，其特征在于，所述PDU为链路层发现协议LLDP PDU。
  10. 如权利要求9所述的方法，其特征在于，在所述第一网络设备接收第二网络设备发送的协议数据单元PDU之前，所述方法还包括：
    所述第一网络设备向所述第二网络设备发送LLDP请求，所述LLDP请求用于请求所述第二网络设备的第二端口的端口属性，和/或所述第二网络设备在网络中的级数。
  11. 如权利要求10所述的方法，其特征在于，所述第一网络设备向所述第二网络设备发送LLDP请求，包括：
    若所述第一端口的端口属性未知，所述第一网络设备向所述第二网络设备发送所述LLDP请求。
  12. 如权利要求1-11中任一项所述的方法，其特征在于，所述第一网络设备包括多个发送队列，所述多个发送队列包括第一发送队列和第二发送队列，所述第一发送队列为第一数据流对应的原始发送队列，
    所述方法还包括：
    所述第一网络设备确定所述第一端口以及所述第一网络设备的第三端口为上联口；
    所述第一网络设备生成防优先级流量控制PFC死锁规则，所述防PFC死锁规则用于指示将所述第一数据流缓存至所述第二发送队列，所述第一数据流的入端口为所述第一端口，所述第一数据流的出端口为所述第三端口。
  13. 一种确定端口属性的方法，其特征在于，包括：
    第二网络设备生成协议数据单元PDU，所述PDU用于确定第一网络设备的第一端口为上联口或下联口；
    所述第二网络设备通过第二端口向所述第一网络设备发送所述PDU。
  14. 如权利要求13所述的方法，其特征在于，所述PDU携带网络中所述第二网络设备的级数，和/或
    所述PDU携带所述第二网络设备的所述第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
  15. 权利要求14所述的方法，其特征在于，所述第二网络设备为所述网络中的根节点，所述PDU中携带的所述第二网络设备的级数为预设值。
  16. 权利要求13所述的方法，其特征在于，所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器。
  17. 权利要求13-16中任一项所述的方法，其特征在于，所述PDU为链路层发现协议LLDP PDU。
  18. 如权利要求17所述的方法，其特征在于，在所述第二网络设备向所述第一网络 设备发送所述PDU之前，所述方法还包括：
    所述第二网络设备接收所述第一网络设备发送的LLDP请求，所述LLDP请求用于请求所述第二端口的端口属性，和/或所述第二网络设备的级数。
  19. 一种第一网络设备，其特征在于，包括：
    接收模块，用于通过第一端口接收第二网络设备发送的协议数据单元PDU；
    处理模块，用于根据所述接收模块接收的所述PDU，确定所述第一端口为上联口或下联口。
  20. 如权利要求19所述的第一网络设备，其特征在于，所述PDU携带网络中所述第二网络设备的级数，和/或
    所述PDU携带所述第二网络设备发送所述PDU使用的第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
  21. 如权利要求20所述的第一网络设备，其特征在于，所述处理模块还用于：
    根据所述PDU确定在所述网络中所述第一网络设备的级数；
    根据所述第一网络设备的级数，确定所述第一端口为上联口或下联口。
  22. 如权利要求21所述的第一网络设备，其特征在于，所述网络包括多个网络设备，所述多个网络设备包括所述第二网络设备，
    所述接收模块，还用于通过多个端口接收所述多个网络设备发送的多个PDU，所述多个端口包括所述第一端口，所述多个PDU包括所述第二网络设备发送的所述PDU；
    所述处理模块，还用于根据所述多个PDU，确定在所述网络中所述多个网络设备的级数；
    所述处理模块，还用于从所述多个网络设备的级数中选择目标级数；
    所述处理模块，还用于根据所述目标级数以及预设规则确定所述第一网络设备的级数。
  23. 如权利要求21或22所述的第一网络设备，其特征在于，所述处理模块，还用于：
    根据所述第一网络设备的级数，以及所述第二网络设备的级数确定所述第一端口为上联口或下联口。
  24. 如权利要求20所述的第一网络设备，其特征在于，所述处理模块，还用于：
    根据所述PDU确定所述第二网络设备的级数；
    根据所述第二网络设备的级数确定所述第一端口为上联口或下联口。
  25. 如权利要求24所述的第一网络设备，其特征在于，所述第二网络设备为所述网络中的根节点，
    所述接收模块，还用于通过所述第一端口接收所述第二网络设备发送的所述PDU，所述PDU中携带的所述第二网络设备的级数为预设值；
    所述处理模块，还用于根据所述预设值确定所述第一端口为上联口。
  26. 如权利要求19所述的第一网络设备，其特征在于，所述处理模块，还用于：
    根据所述PDU，确定所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器；
    确定所述第一端口为下联口。
  27. 权利要求19-26中任一项所述的第一网络设备，其特征在于，所述PDU为链路 层发现协议LLDP PDU。
  28. 如权利要求27所述的第一网络设备，其特征在于，所述第一网络设备还包括：
    发送模块，用于向所述第二网络设备发送LLDP请求，所述LLDP请求用于请求所述第二网络设备的第二端口的端口属性，和/或所述第二网络设备在网络中的级数。
  29. 如权利要求28所述的第一网络设备，其特征在于，所述发送模块，还用于若所述第一端口的端口属性未知，向所述第二网络设备发送所述LLDP请求。
  30. 如权利要求19-29中任一项所述的第一网络设备，其特征在于，所述第一网络设备包括多个发送队列，所述多个发送队列包括第一发送队列和第二发送队列，所述第一发送队列为第一数据流对应的原始发送队列，
    所述处理模块还用于：
    确定所述第一端口以及所述第一网络设备的第三端口为上联口；
    生成防优先级流量控制PFC死锁规则，所述防PFC死锁规则用于指示将所述第一数据流缓存至所述第二发送队列，所述第一数据流的入端口为所述第一端口，所述第一数据流的出端口为所述第三端口。
  31. 一种第二网络设备，其特征在于，包括：
    处理模块，用于生成协议数据单元PDU，所述PDU用于确定第一网络设备的第一端口为上联口或下联口；
    发送模块，用于通过第二端口向所述第一网络设备发送所述处理模块生成的所述PDU。
  32. 如权利要求31所述的第二网络设备，其特征在于，所述PDU携带网络中所述第二网络设备的级数，和/或
    所述PDU携带所述第二网络设备的所述第二端口的端口属性，所述第二端口的端口属性包括所述第二端口为上联口或所述第二端口为下联口。
  33. 权利要求32所述的第二网络设备，其特征在于，所述第二网络设备为所述网络中的根节点，所述PDU中携带的所述第二网络设备的级数为预设值。
  34. 权利要求31所述的第二网络设备，其特征在于，所述第二网络设备为服务器，所述PDU携带第一TLV，所述第一TLV指示所述第二网络设备为服务器。
  35. 权利要求31-34中任一项所述的第二网络设备，其特征在于，所述PDU为链路层发现协议LLDP PDU。
  36. 如权利要求35所述的第二网络设备，其特征在于，所述第二网络设备还包括：
    接收模块，用于接收所述第一网络设备发送的LLDP请求，所述LLDP请求用于请求所述第二端口的端口属性，和/或所述第二网络设备的级数。
  37. 一种网络设备，其特征在于，包括处理器，所述处理器用于与存储器耦合，读取并执行所述存储器中的指令，以执行如权利要求1-18中任一项所述的方法。
  38. 一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行如权利要求1-18中任一项所述的方法。
PCT/CN2020/092209 2019-05-31 2020-05-26 确定端口属性的方法和装置 WO2020238875A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20815650.5A EP3968571A4 (en) 2019-05-31 2020-05-26 METHOD AND DEVICE FOR DETERMINING PORT ATTRIBUTES
US17/534,408 US20220086051A1 (en) 2019-05-31 2021-11-23 Method and apparatus for determining port orientation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910470325.9 2019-05-31
CN201910470325.9A CN112019365A (zh) 2019-05-31 2019-05-31 确定端口属性的方法和装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/534,408 Continuation US20220086051A1 (en) 2019-05-31 2021-11-23 Method and apparatus for determining port orientation

Publications (1)

Publication Number Publication Date
WO2020238875A1 true WO2020238875A1 (zh) 2020-12-03

Family

ID=73502109

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/092209 WO2020238875A1 (zh) 2019-05-31 2020-05-26 确定端口属性的方法和装置

Country Status (4)

Country Link
US (1) US20220086051A1 (zh)
EP (1) EP3968571A4 (zh)
CN (1) CN112019365A (zh)
WO (1) WO2020238875A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043422A (zh) * 2006-03-24 2007-09-26 上海贝尔阿尔卡特股份有限公司 一种接入网络中的组播业务保护方法及其系统、装置
CN101262412A (zh) * 2007-03-09 2008-09-10 上海贝尔阿尔卡特股份有限公司 一种具有最小时延的组播恢复的方法及其接入设备
CN102377679A (zh) * 2011-12-06 2012-03-14 烽火通信科技股份有限公司 一种在fttx接入系统中实现链路发现和管理的方法
WO2012171378A1 (zh) * 2011-06-15 2012-12-20 中兴通讯股份有限公司 解决vpls接入l3故障切换导致断流的方法及路由器

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7212534B2 (en) * 2001-07-23 2007-05-01 Broadcom Corporation Flow based congestion control
US8005013B2 (en) * 2007-06-12 2011-08-23 Hewlett-Packard Development Company, L.P. Managing connectivity in a virtual network
CN107196698A (zh) * 2011-04-05 2017-09-22 Lg 电子株式会社 在无线通信系统中用于调度的方法和设备
US9014201B2 (en) * 2011-11-09 2015-04-21 Oracle International Corporation System and method for providing deadlock free routing between switches in a fat-tree topology
US9100285B1 (en) * 2012-12-18 2015-08-04 Juniper Networks, Inc. Dynamic control channel establishment for software-defined networks having centralized control
US9979595B2 (en) * 2012-12-18 2018-05-22 Juniper Networks, Inc. Subscriber management and network service integration for software-defined networks having centralized control
CN104158747B (zh) * 2013-05-14 2019-09-24 中兴通讯股份有限公司 网络拓扑发现方法和系统
US9294385B2 (en) * 2014-03-03 2016-03-22 International Business Machines Corporation Deadlock-free routing in fat tree networks
CN104980302B (zh) * 2015-05-12 2018-06-19 上海斐讯数据通信技术有限公司 一种在sdn框架下基于stp消除冗余链路的方法
CN105337883B (zh) * 2015-08-20 2018-12-18 电子科技大学 一种支持多业务的网络交换装置及其实现方法
US10361948B2 (en) * 2017-03-02 2019-07-23 Dell Products, L.P. Communication loop prevention in an information handling system
CN108989069B (zh) * 2017-05-31 2022-11-15 中兴通讯股份有限公司 一种网络链接的检测方法、电子设备及计算机存储介质
CN109039788B (zh) * 2018-09-30 2022-02-25 锐捷网络股份有限公司 网络设备的端口配置方法、装置和存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043422A (zh) * 2006-03-24 2007-09-26 上海贝尔阿尔卡特股份有限公司 一种接入网络中的组播业务保护方法及其系统、装置
CN101262412A (zh) * 2007-03-09 2008-09-10 上海贝尔阿尔卡特股份有限公司 一种具有最小时延的组播恢复的方法及其接入设备
WO2012171378A1 (zh) * 2011-06-15 2012-12-20 中兴通讯股份有限公司 解决vpls接入l3故障切换导致断流的方法及路由器
CN102377679A (zh) * 2011-12-06 2012-03-14 烽火通信科技股份有限公司 一种在fttx接入系统中实现链路发现和管理的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3968571A4

Also Published As

Publication number Publication date
EP3968571A1 (en) 2022-03-16
CN112019365A (zh) 2020-12-01
US20220086051A1 (en) 2022-03-17
EP3968571A4 (en) 2022-06-22

Similar Documents

Publication Publication Date Title
US11646967B2 (en) Packet control method and network apparatus
US20220210092A1 (en) System and method for facilitating global fairness in a network
US8885488B2 (en) Reachability detection in trill networks
CN111800351B (zh) 由交换机进行的拥塞通知分组生成
WO2021185208A1 (zh) 报文处理方法、装置、设备及存储介质
US20140241345A1 (en) Source routing with fabric switches in an ethernet fabric network
US10999222B2 (en) Network device and method for selecting transmission of network device
WO2015014133A1 (zh) OPENFLOW网络中QoS的实现方法及装置
WO2022194023A1 (zh) 报文处理的方法、网络设备及控制器
CN113438182B (zh) 一种基于信用的流量控制系统和流量控制方法
US11646978B2 (en) Data communication method and apparatus
WO2016082436A1 (zh) 一种业务混合集中处理方法和装置、存储介质
WO2017008514A1 (zh) Clos网络中负载均衡的方法及装置
CN114095448A (zh) 一种拥塞流的处理方法及设备
WO2020238875A1 (zh) 确定端口属性的方法和装置
US20220166721A1 (en) Traffic balancing method, network device, and electronic device
WO2022247257A1 (zh) 一种pfc风暴的检测和处理方法
CN114500163A (zh) 一种通信调度方法、装置和存储介质
WO2023273788A1 (zh) 一种数据处理方法以及相关装置
WO2024016327A1 (zh) 报文传输
US11729099B2 (en) Scalable E2E network architecture and components to support low latency and high throughput
EP4311195A1 (en) Method and apparatus for ensuring deterministic latency of network slice, storage medium, and product
WO2024066555A1 (zh) 一种数据通信方法、交换芯片、通信节点及通信网络
WO2023123075A1 (zh) 一种数据交换的控制方法及装置
CN114501544A (zh) 一种数据传输方法、装置和存储介质

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: 20815650

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020815650

Country of ref document: EP

Effective date: 20211207