息；
[0108] 第二配置模块，用于根据所述第二配置信息，配置第二状态；
[0109] 所述第二状态指示所述目标网络设备接收到PADI报文时，即时返回PAD0报文； [0110] 其中，所述第二配置信息是当所述控制器根据所述目标网络设备的负载参数确定 所述目标网络设备未处于负载超限的状态时所述控制器向所述目标网络设备发送的。
[0111] 第五方面，本发明实施例提供了一种负载分担的系统，所述系统包括控制器和网 络设备，所述控制器配置有前述第三方面任意一种实施方式的装置，所述网络设备配置有 前述第四方面任意一种实施方式的装置。
[0112] 与现有技术相比，本发明实施例至少具有以下优点：
[0113] 采用本发明实施例的技术方案，以目标网络设备表示网络内任意一个需要负载 控制的网络设备，控制器获取目标网络设备的负载参数，并根据该负载参数，确定目标网 络设备是否处于负载超限的状态，若目标网络设备处于负载超限的状态，控制器向目标网 络设备发送第一配置信息，目标网络设备当接收到第一配置信息时配置第一状态，在处 于第一状态的情况下，目标网络设备接收到的主动发现发起（PPPoE Active Discovery Initiation，简称PADI)报文时，延时或者不返回主动发现提供（PPPoE Active Discovery Offer Initiation，简称PAD0)报文。由此可见，在网络中，负载过大的网络设备会被配置成 第一状态，当接收到用户设备发送的PADI时，负载过大的网络设备不会立即向用户设备返 回PADO报文，负载空闲的网络设备则可以早于负载过大的网络设备向用户设备返回PADO 报文，因此，当用户设备向最早返回PAD0报文的网络设备请求建立PPP会话时，用户设备就 可以与负载空闲的网络设备建立PPP会话，从而实现了用户设备选择负载空闲的网络设备 接入网络，避免了用户设备选择负载过大的网络设备接入网络，使得网络中各网络设备的 负载更加均衡。
[0114] 此外，本发明实施例的技术方案，控制器可以通过向网络设备下发用于配置第一 状态的第一配置信息来实现对网络设备的负载控制，通过这种方式实现网络中各网络设备 的负载均衡，一方面网络设备的负载控制可以无需借助用户设备与网络设备之间额外增加 用于控制报文转发路径的交换设备，因而无需改造网络架构就可以实现负载均衡，另一方 面网络设备的负载控制可以无需预先在用户设备上配置报文转发路径的控制命令，因而无 需对大量的用户设备进行技术改造就可以实现负载均衡。由此可见，通过本发明实施例的 技术方案，网络负载均衡的实现难度小、成本低，从而使得网络负载均衡更容易实现。
【附图说明】
[0115] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现 有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本 申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他 的附图。
[0116] 图1为本发明实施例中一应用场景所涉及的网络系统框架示意图；
[0117] 图2为本发明中负载分担的方法一实施例的流程图；
[0118] 图3为本发明中负载分担的方法另一实施例的流程图；
[0119] 图4为本发明中负载分担的方法又一实施例的流程图；
[0120] 图5为本发明中负载分担的方法又一实施例的流程图；
[0121] 图6为本发明中负载分担的装置一实施例的结构示意图；
[0122] 图7为本发明中负载分担的装置另一实施例的结构示意图；
[0123] 图8为本发明中负载分担的系统一实施例的结构示意图；
[0124] 图9为本发明实施例中一种控制器的结构示意图；
[0125] 图10为本发明实施例中一种目标网络设备的结构示意图。
【具体实施方式】
[0126] 为了使本技术领域的人员更好地理解本发明中的方案，下面将结合本发明实施例 中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅 是本发明一部分实施例，而不是全部的实施例。
[0127] 发明人经过研究发现，现有技术中，用户设备接入网络进行网络访问的过程包括 两个阶段，即发现阶段和会话阶段。在发现阶段：当一个用户设备需要接入网络时，该用 户设备可以向网络中所有的网络设备发送PADI报文，该PADI报文用于向网络设备请求特 定类型的服务；每一个网络设备在接收到该PADI报文时，可以判断自身是否能够提供该 PADI报文请求的服务，如果能够提供，则可以向该用户设备返回PAD0报文；该用户设备在 发送PADI报文之后，往往会收到多个网络设备返回的PAD0报文，该用户设备选择向最早 返回PADO报文的网络设备请求建立PPP会话，该网络设备再向该用户设备提供会话标识 (Session ID)，这样，该用户设备与该网络设备之间就建立了 PPP会话。在会话阶段：用户 设备与网络设备可以基于会话标识实现PPP会话；基于PPP会话，用户设备可以与网络设备 进行各项协商及数据传输，从而实现用户设备对网络的访问。由此可见，由于用户设备选择 向最早返回PAD0报文的网络设备请求建立PPP会话，网络中的一些网络设备需要承载大量 用户设备进行PPP会话，从而造成负载超限，而网络中的另一些网络设备则仅需要承载少 量用户设备的PPP会话，从而导致负载空闲，因此，现有技术中，网络中各网络设备的负载 是不均衡的。
[0128] 在本发明实施例中，为了使得网络中各网络设备的负载更加均衡，提供了一种负 载分担的方法和设备。其中，负载过大的网络设备不会立即对接收到的PADI报文返回PAD0 报文，负载空闲的网络设备可以早于负载过大的网络设备向用户设备返回PAD0报文，因 此，用户设备可以通过负载空闲的网络设备而不是负载过大的网络设备来接入网络，网络 中各网络设备的负载得以更加均衡。
[0129] 参见图1，本发明实施例的应用场景之一，可以是应用到由控制器101与目标网络 设备102组成的网络系统中。在该网络系统中，控制器101获取目标网络设备102的负载 参数，并根据所述负载参数，确定所述目标网络设备102是否处于负载超限的状态。然后， 若所述目标网络设备102处于负载超限的状态，所述控制器101向所述目标网络设备102 发送第一配置信息。再后，所述目标网络设备102接收所述控制器101发送的第一配置信 息，并根据所述第一配置信息配置第一状态。所述第一状态指示所述目标网络设备102接 收到PADI报文时，延时或不返回PAD0报文。其中，目标网络设备102可以是网络系统中的 任意一个用于接入用户设备的网络设备。
[0130] 需要注意的是，上述应用场景仅是为了便于理解本发明实施例的原理而示出，本 发明实施例在此方面不受任何限制。相反，本发明实施例可以应用于适用的任何场景。
[0131] 下面结合附图，通过具体的实施例来详细说明本发明中负载分担的方法、装置和 系统的实现方式。
[0132] 参见图2,图2是本发明中负载分担的方法一实施例的流程图。在本实施例中，所 述方法例如具体可以包括如下步骤：
[0133] 步骤201、控制器获取目标网络设备的负载参数。
[0134] 当控制器需要对目标网络设备进行负载控制时，控制器获取目标网络设备的负载 参数。其中，所述目标网络设备可以是在所述控制器控制下的任意一个用于接入用户设备 的网络设备。例如，目标网络设备可以是在控制器控制下任意一个端口（port)对应的交换 设备。又如，目标网络设备可以是在控制器控制下任意一个槽位（slot)对应的交换设备。 所述负载参数是用于描述目标网络设备的负载状态的参数。例如，该负载参数可以是用户 利用率（user utilization radio)、带宽利用率（bandwidth utilization radio)、CPU 利 用率（CPU utilization radio)或剩余CPU处理能力。所述目标网络设备的用户利用率表 示所述目标网络设备上已接入用户设备的数量占总用户设备的数量的比例。所述目标网络 设备的带宽利用率表示所述目标网络设备上已占用的带宽占总带宽的比例。所述目标网络 设备的CPU利用率表示所述目标网络设备上已占用的CPU处理能力占总CPU处理能力的比 例。所述目标网络设备的剩余CPU处理能力可以根据所述目标网络设备的总CPU处理能力 与CPU利用率进行计算。
[0135] 在【具体实施方式】中，控制器可以采用多种不同的方式对负载参数进行获取。
[0136] 作为一种示例，控制器可以主动向目标网络设备请求负载参数，目标网络设备则 在接收到负载参数请求时返回自身的负载参数。具体地，步骤201包括：所述控制器向所述 目标网络设备发送负载参数请求；所述控制器接收所述目标网络设备对所述负载参数请求 而返回的负载参数。其中，对控制器向目标网络设备发送负载参数的时机，本实施例不作限 定。例如，控制器可以在需要对目标网络设备时向目标网络设备发送负载参数请求，此时， 控制器根据目标网络设备当前返回的负载参数对目标网络设备进行负载控制。或者，控制 器也可以定期地向目标网络设备发送负载参数请求并实时地保存目标网络设备最新返回 的负载参数，此时，控制器根据自身保存的目标网络设备的负载参数对目标网络设备进行 负载控制。
[0137] 作为另一种示例，目标网络设备可以主动向控制器发送负载参数。此时，步骤201 具体为：所述控制器接收所述目标网络设备主动发送的负载参数。其中，对于目标网络设备 向控制器发送负载参数的时机，本实施例不作限定。例如，目标网络设备可以定期地主动向 目标网络设备发送负载参数，控制器则实时地保存目标网络设备最新返回的负载参数，此 时，控制器根据自身保存的目标网络设备的负载参数对目标网络设备进行负载控制。
[0138] 在上述两种示例中，目标网络设备与控制器之间可以通过多种不同的协议来实现 负载参数的传输，如开放流（Openflow)协议、网络配置（Netconf)协议或简单网络管理协 议（Simple Network Management Protocol，简称 SNMP)协议。
[0139] 作为一种示例，在Openflow协议中，控制器向目标网络设备发送的负载参数请求 可以是扩展的多部分（Multipart)请求消息，目标网络设备向控制器发送的负载参数可以 通过Multipart应答消息发送。具体地，扩展的Multipart请求消息包括类型Type字段 和请求主体Body字段，所述Type字段携带指示负载均衡信息的类型值，所述请求Body字 段为空或者携带所述设备标识，此Muptipart请求消息即是一个负载参数请求。相应的， 扩展的Mulipart应答消息包括所述Type字段和应答主体Body字段，所述Type字段携带 指示负载均衡信息的类型值，所述应答Body字段携带所述目标网络设备的负载参数，此 Multipart应答消息即用于发送负载参数。
[0140] 在【具体实施方式】中，上述Multipart请求消息可以采用如下格式：
[0141] struct ofc multipart request { struct ofp header header; uintl6_t type; /* One of the OFPMP * constant*/ uintl6_t flags; /* OFPMPF REQ * flags */ uint8」pad[4]; iiint8_i: body[0]; Body of the request.*/
[0142] 上述Multipart应答消息可以采用如下格式：
[0143] s.triiet ofe-multipart-reply { struct ofp header header; uintl 6_t type; /* One of the OFPMP_>;: constant.*/
[0144] uintl 6 t flagi,; /* GFPMPF__REPLY__* fiags.*/ uintB 1: pad[4]; uint8_t body[0]; /* Body of the reply.*/ j 5：
[0145] 在上述Multipart请求消息和Multipart应答消息中，位于type字段的指示负载 均衡信息的类型值，可以是一个新定义的类型值。例如，该类型值可以定义为17, BP :
[0146] 0FPMP_BRAS_L0ADBALANCE_INF0 = 17
[0147] 在上述Multipart请求消息中，请求Body字段可以采用如下格式：
[0148] ./* Body for ot、c_multi part-request of type ()FPMP_BRAS」乂)ADBALANCE -腳〇.溱/ struct ofp bras loadbalance info req { uint32_t port_no; /* port numbering.*/ uint8._t slot-id; uM8_t pad[3]; /* Align to 64 bit*/ )，
[0149] 在发送给目标网络设备的Multipart请求消息的Body字段中，port_no字段携带 目标网络设备的端口号，sl〇t_id字段携带目标网络设备的槽位标识。
[0150] 在上述Multipart应答消息中，应答Body字段可以采用如下格式：
[0151] /* Body for reply ofOFPMP_BRAS_LOADBALANCE_INFO request. */ struct ofp-bras_loadbalance」nfo-reply { uint32_t banclwidtli; /* bandwidth of port,*/ uint32_t max user num; /* Total user num of slot.*/ uint32_t CPU capability; /*