CN105162732B

CN105162732B - 创建扩展端口的方法、装置

Info

Publication number: CN105162732B
Application number: CN201510379869.6A
Authority: CN
Inventors: 张长君
Original assignee: New H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2015-06-30
Filing date: 2015-06-30
Publication date: 2018-09-04
Anticipated expiration: 2035-06-30
Also published as: CN105162732A

Abstract

本申请公开了一种创建扩展端口的方法、装置，该方法的步骤包括：与控制桥CB设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；如果所述PE设备和所述CB设备均具有所述批量创建端口能力，则向所述CB设备发送批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识，以使所述CB设备根据所述待创建端口的端口标识创建端口。本申请能够减轻PE设备在创建扩展端口时的报文转发压力。

Description

创建扩展端口的方法、装置

技术领域

本申请涉及虚拟化网络技术，尤其涉及创建扩展端口的方法、装置。

背景技术

PE(Port Extender，端口扩展器)技术是通过PE设备为CB(Control Bridge，控制桥)设备提供端口扩展的作用，使得网络实现多级的扩展。

PE设备在创建每个端口时均需要向CB设备发送Extended Port Create报文，每条Extended Port Create报文携带一个待创建端口的端口标识，CB设备通过端口标识来进行端口创建。由于当每次有新的PE加入或系统重启时均会发生端口创建的过程，因此创建端口的时机都很集中，于是容易出现某一时刻涌现大量的Extended Port Create报文。从而导致瞬间的大量交互报文给PE设备转发带来压力，并延长了CB设备端口创建时间、PE设备不可用的时间。

发明内容

本申请提供一种创建扩展端口的方法、装置，能够减轻PE设备在创建扩展端口时的报文转发压力。

根据本申请实施例的第一方面，提供一种创建扩展端口的方法，运行于端口扩展器PE设备，包括步骤：

与控制桥CB设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；

如果所述PE设备和所述CB设备均具有所述批量创建端口能力，则向所述CB设备发送批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识，以使所述CB设备根据所述待创建端口的端口标识创建端口。

根据本申请实施例的第二方面，提供一种创建扩展端口的方法，运行于控制桥CB设备，包括步骤：

与端口扩展器PE设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；

接收所述PE设备的批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识；

从所述BCP报文中获取至少一个待创建端口的端口标识并创建端口。

根据本申请实施例的第三方面，提供一种创建扩展端口的装置，位于端口扩展器PE设备，包括：

能力协商模块，用于与控制桥CB设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；

批处理模块，用于当所述PE设备和所述CB设备均具有所述批量创建端口能力时，向所述CB设备发送批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识，以使所述CB设备根据所述待创建端口的端口标识创建端口。

根据本申请实施例的第四方面，提供一种创建扩展端口的装置，运行于控制桥CB设备，包括：

能力协商模块，用于与端口扩展器PE设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；

扩展端口创建模块，用于接收所述PE设备的批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识；以及从所述BCP报文中获取至少一个待创建端口的端口标识并创建端口。

本申请通过BCP报文实现了多个待创建端口的端口标识的封装，通过一条BCP报文就可以将多个待创建端口的端口标识通知给CB设备，无需通过每条Extended Port Create报文携带一个端口标识的方式通知CB设备，因此对于PE设备而言，大大减轻了在端口创建过程中需要转发的报文压力。对于CB设备而言，由于可以通过一条BCP报文接收到多个待创建端口的端口标识，因此获取到所有待创建端口的端口标识的时间大大缩短，从而减少了端口创建的时间，并缩短了PE设备不可用的时间。

附图说明

图1为本申请实施例中虚拟化网络的结构图；

图2为本申请实施例中一个创建扩展端口的方法的流程图；

图2-1为本申请实施例中一种TLV格式的示意图；

图2-2为本申请实施例中另一种TLV格式的示意图；

图2-3为本申请实施例中另一种TLV格式的示意图；

图3为本申请实施例中另一个创建扩展端口的方法的流程图；

图4为本申请应用实例中创建扩展端口的方法的信令交互时序图；

图5为本申请实施例中创建扩展端口的装置的硬件架构图；

图6为本申请实施例中一个创建扩展端口的装置软件逻辑框图；

图7为本申请实施例中另一个创建扩展端口的装置软件逻辑框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请中所描述的创建扩展端口的方法的一个较常见的网络环境可以是802.1BR所定义的虚拟化系统中。IEEE802.1BR标准描述了扩展二层设备端口的方法，即将多台二层设备虚拟为一个EB(Extended Bridge，扩展桥)设备100。图1中的虚拟化网络主要包括EB设备100和终端103(End Station，也称为主机或服务器)，EB设备100中包括：CB设备101和外部PE(External Bridge PE)设备102(图1中以CB设备加上4个外部PE设备构成一个EB设备为例)，CB设备101通过CB设备内部的内部PE(Internal Bridge PE)与外部PE(ExternalBridge PE)设备102连接，外部PE设备102可以连接多个终端或与其他外部PE设备102级联。在虚拟化系统中，CB设备101是唯一具备网络交换功能的设备，而PE设备102并不具备独立网络功能。

本申请实现了待创建端口标识的批量发送，图2从虚拟化系统的PE设备侧描述创建扩展端口的方法的流程图。

S201，在能力协商阶段，PE设备与CB设备交互能力协商报文；PE设备和CB设备进行交互的能力协商报文中均携带有表示自身设备是否具有BCP(Batch Create Ports，批量创建端口)能力的标识；

作为一个例子，可以通过能力协商报文在原有协议中的保留位来定义这个表示设备是否具有批量创建端口能力的标识。例如，可以通过目前较常使用的LLDP(Link LayerDiscovery Protocol，链路层发现协议)所规定的CSP OPEN(Control and Status控制与状态协议打开)报文来作为能力协商报文，利用CSP OPEN报文格式中的R字段来作为描述BCP能力的标识，目前的CSP OPEN报文格式中的R字段占用6至8位，可以选择其中任一位来标识BCP能力，例如，R字段的第6位。容易理解，描述是否具有BCP能力的方式并不排除有其他途径，例如可以通过新增TLV(Type/Length/Value，类型/长度/值)类型的方式定义设备是否具有批量创建端口能力等。

S202，如果PE设备和CB设备均具有批量创建端口能力，则创建BCP报文，通过BCP报文封装至少一个待创建端口的端口标识；

在一个例子中，可以在封装BCP报文时，将该条BCP报文中所带的待创建端口的端口标识的数目信息也进行封装，以便CB设备在接收到BCP报文后根据端口标识的数目信息校验端口标识的数目是否有误。

在另一个例子中，还可以预先设置BCP报文的长度值，在封装待创建端口的端口标识时，如果超出所设置的BCP报文的长度值，则将尚未封装的端口标识在下一条BCP报文中进行封装。另外，为了使CB设备在接收到BCP报文时能够辨别是否已经接收到所有的待创建端口的端口标识，可以在BCP报文中添加一个标记，在本申请中称为第一分包标记，以标记该条BCP报文是否为发给CB设备的最后一条BCP报文。标记的方式在实现时可以选择多种方式，例如，可以定义第一分包标记为1时代表该条BCP报文发送完后，后续还有BCP报文待发送；第一分包标记为0时代表该条BCP报文后面已没有其他待发送的BGP报文。其他标记方式可以通过本领域技术人员的惯常做法进行变换，在此不再赘述。

对于分多条发送BCP报文的方式，使CB设备分辨是否已经接收到所有的待创建端口的端口标识的途径还有其他多种途径，例如，在BCP报文中也可以不携带第一分包标记，当发送完最后一条BCP报文后，再向CB设备发送一条结束报文来通知CB设备BCP报文已发送完毕；再例如，可以在CB设备侧设定一个定时器(为方便描述，称为第二定时器)，当第二定时器超时便认为BCP报文发送完成，该种方式可以结合其他的所列举的分多条发送BGP报文的方式实现，即，如果BCP报文中携带有第一分包标记，可以在第二定时器超时时，无论是否收到第一分包标记为0的BCP报文，CB设备均开始执行端口创建的操作等，各种方式结合的方案不再依次赘述。

S203，PE设备将BCP报文发送给CB设备，以使所述CB设备根据待创建端口的端口标识创建端口。

CB设备在接收到BCP报文后，解析出其中的待创建端口的端口标识，并针对多个端口标识一一创建端口，并将为每个端口所分配的ECID(E-Channel ID，扩展信道标识)发给PE设备。

发送ECID的方式之一是可以通过对每个已创建的扩展端口发送一条ExtendedPort Create响应报文，在每条Extended Port Create响应报文中携带一个与已创建的扩展端口相对应的ECID。

发送ECID给PE设备的第二种方式是，CB设备可以构建BCP响应报文，一条BCP响应报文中携带多个ECID，可以看出，CB设备通过BCP响应报文一次性发多个ECID的方式可以进一步减少PE设备和CB设备之间的报文交互压力，由于PE设备接收ECID的时间缩短，因此PE设备不可用的时间也会大大减少。

在本申请的一个实施例中，PE设备的工作流程还可以包括以下步骤：

如果PE设备已接收到CB设备所发送的全部ECID(可以是CB设备逐条发送的各个ECID，也可以是通过BCP响应报文打包发送的各个ECID)，则将各个待创建端口的ECID下发给驱动；为了明确端口标识与ECID的关系，可以在封装BCP响应报文时，将各个端口标识和对应的ECID成对封装。值得指出的是，作为一个实施例，BCP报文中的待创建端口标识中如果有部分待创建端口没有创建成功，则在返回各已创建的端口所对应的ECID时，可以仅将创建成功的端口标识及其所对应的ECID封装在BCP响应报文中发给PE设备。

在一个实施例中，PE设备判断是否已接收到CB设备所发送的全部ECID的方式可以存在多种途径。

其中一种途径是，在PE设备上设置第一定时器，根据第一定时器是否超时来判断；第二种途径是可以在BCP响应报文中携带第二分包标记，与第一分包标记的功能相类似，第二分包标记用于标记该条BCP响应报文是否为CB设备所发送的最后一条BCP响应报文。

另外的途径还可以是BCP响应报文中不必携带第二分包标记，在CB设备发送完毕所有的BCP响应报文后发送一条结束报文，来通知PE设备已发送完毕。除以上列举的几种途径之外，不排除有其他途径来使PE设备具有判断是否已接收到CB设备所发送的全部BCP响应报文的能力，在此不再赘述。

通过图2可以看出，PE设备与CB设备之间需要通过能力协商报文通知对方本设备是否具有BCP能力，在构建BCP报文时，需要具备将多个待创建的端口标识打包在一个BCP报文中的能力。为了简化设计难度，可以参照LLDP所定义的的TLV格式进行封装，TLV命令可以将设备的的主要能力、管理地址、设备标识、接口标识等信息组织成不同TLV报文。

在一个实施例中，能力协商报文和BCP报文可封装成两部分TLV格式的内容，其中一部分利用目前801.1BR标准中命令TLV(Command TLV)所定义的格式，具体格式参见图2-1，其中将Message Type用来作为所发送的报文类型，可以定义一个与目前已使用的值不同的值来表示BCP报文，例如，可以定义Message Type的值为15时表示设备所发送的报文为BCP报文。NTLV可以用来表示本条消息中所包含的端口数目信息，Index可以用来作为第一分包标识。图2-1中其他字段所代表的含义可参照801.1BR标准中各字段的定义，在此不予赘述。

可以看出，在交互能力协商报文时，根据Message Type的值即可判断出所发送的报文类型是否为BCP报文。CB设备在接收到BCP报文后，可以通过Index来判断是否已经接收到所有的待创建端口标识。

能力协商报文的另一部分可参照目前802.1BR标准中定义的资源限制能力TLV(Resource Limit Capability TLV)的格式，格式如图2-2；R字段占8至6位，在一个例子中，可以在扩展位R字段的第6位，即R字段的最低位写入表示是否具有BCP能力的值，写入的方式可以是R的最低位为1时表示具有BCP能力，R的最低位为0时表示不具有BCP能力；或者用0来表示不具有BCP能力，1表示具有BCP能力。图2-2中其他字段所代表的含义可参照801.1BR标准中各字段的定义，在此不予赘述。

BCP报文的另一部分用于封装各个待创建端口的端口标识，本例中同样参考TLV格式，将此部分自定义成图2-3所示的格式。为描述方便，本申请将此部分称为Port ArrayTLV，表中Port Entry的值即为待创建的PE设备本地端口标识的值。图2-3中其他字段所代表的含义可参照801.1BR标准中各字段的定义，在此不予赘述。

值得指出的是，图2-1、2-2、2-3为发明人在实现本申请的方案时，为了简化设计，借助目前802.1BR标准所作出的应用方案，设计者可以根据自身研发需要另行设计其他报文格式来实现本申请的设计构思。

图3从虚拟化系统的CB设备侧描述创建扩展端口的方法的流程图。

S301，CB设备与PE设备交互能力协商报文时，在自身所发送的能力协商报文中携带表示本端设备是否具有批量创建端口能力的标识；

CB设备实现在能力协商报文中携带BCP能力标识的方式可以参照上文S201步骤所描述的PE设备的作法，例如可以通过目前较常使用的LLDP所规定的CSP OPEN报文来作为能力协商报文，利用CSP OPEN报文格式中的R字段来作为描述BCP能力的标识等。

S302，接收PE设备的BCP报文；

从上文的S202步骤可以看出，BCP报文中可以携带一个或多个待创建的端口标识。

S303，CB设备从BCP报文中获取各个待创建端口的端口标识创建端口。

作为一个例子，创建扩展端口的具体过程可以利用现有技术中创建扩展端口的流程。

由于在某些实施例中，PE设备可能是分批发送多条BCP报文，BCP报文中可以携带第一分包标识，也可以不包含第一分包标识，CB设备为了能够分辨出是否已经发送完毕所有的BCP报文，还可以执行下述步骤：

根据预设的定时器(以下称为第二定时器)是否超时判断是否已接收完所有的BCP报文。在第二定时器超时后再执行S303步骤。

CB设备在批量创建端口后需要回复PE设备应答，以便将所创建的端口的ECID通知给PE设备。在一个例子中，CB设备回复PE设备的应答报文可以仍然参照现有技术的方式将各个已创建端口所对应的ECID逐条发送给PE设备；在另一个例子中，CB设备可以参照BCP报文类似的格式构造BCP响应报文，通过一条BCP响应报文将已创建的多个扩展端口封装，BCP响应报文中携带与各个所述待创建端口的端口标识对应的ECID，统一发给PE设备。

在创建BCP响应报文时，还可以包括本条BCP响应中封装的ECID的个数。另外，为了能够使得PE设备接收到BCP响应报文后分辨是否已经发送完所有的BCP响应报文，CB设备在构建BCP响应报文时还可以封装一个分包标记，称为第二分包标记，第二分包标记的标记方法可以参照第一分包标记的实现方式，标记的方式在实现时可以选择多种方式，例如，可以定义第二分包标记为1时代表该条BCP响应报文发送完后，后续还有BCP响应报文待发送，第二分包标记为0时代表该条BCP响应报文后面已没有其他待发送的响应报文BGP报文，其他标记方式不再一一列举。

在一个例子中，图2-1、图2-2和图2-3同样适用于CB设备的报文创建。能力协商报文和BCP报文可封装成两部分内容，其中一部分可以参照802.16BR标准中所定义的命令TLV，命令TLV所定义的格式，具体格式参见图2-1，其中Message Type为CB设备所发送的报文是否为BCP响应报文，NTLV可以用来表示本条消息中所包含的ECID的数目信息，Index为第二分包标识。能力协商报文的另一部分可参考图2-2，在R保留位携带代表是否具有BCP能力的值，例如1表示具有BCP能力，0表示不具有BCP能力；或者0表示具有BCP能力，1表示不具有BCP能力。

可以看出，在交互能力协商报文时，根据R字段的值即可判断出发送能力协商报文设备是否具有BCP能力。PE设备在接收到BCP响应报文后，可以通过Index来判断是否已经接收到所有的ECID标识。

BCP响应报文中封装的各个已创建端口的ECID同样参考TLV格式自定义成图2-3所示的格式。表中Port Entry即为已创建的扩展端口及所对应的ECID。

图4为本申请一个实际的应用场景下PE设备和CB设备通过报文交换创建扩展端口的详细流程。

本例中，能力协商报文采用CSP OPEN报文，通过TLV命令封装BCP报文和BCP响应报文，设定BCP报文及BCP响应报文的长度为511个字节，第一定时器及第二定时器为60s，第一分包标记和第二分包标记的值为0时表示后续没有BCP报文或BCP响应报文等待发送了。表4-1为与本例相关的交互报文中Message Type的参数定义。在本例中，Message Type为15时表示消息的类型为BCP报文或BCP响应报文；Request TLVs和Responts TLVs表示各种交互报文类型的载荷所需要TLV类型。可以看出，BCP报文和BCP响应报文的TLV格式均为PortArray TLV。表格中其他参数的具体含义可参考802.1BR中的相关定义。

表4-1

S401阶段为设备发现阶段，PE设备加入EB设备时，CB设备和PE设备先进行LLDP报文交互，发现对方设备，此过程可以参照现有技术的实现方式来实现，因此不予赘述。

S402阶段为能力协商阶段。

CB设备和PE设备各自构建CSP OPEN报文，本例中CSP OPEN报文的格式如图2-1和图2-2所定义，其中，Message Type选用一个目前802.1BR标准中未使用的数值，在本例中用15代表PE设备所发送的报文类型为BCP报文，CE设备所发送的为BCP响应报文；通过CSPOPEN报文协商能力，在CSP OPEN报文的R的第6位作为是否具有BCP能力的标识，。

S403阶段，CB设备向PE设备发送端口参数设置报文，初始化PE设备的上行流端口参数，PE设备在初始化完成后回复端口参数设置响应报文。

经过S402阶段交互CSP OPEN报文，如果PE设备和CB设备中的任一个不具有BCP能力，则仍然按照现有技术的扩展端口创建方式进行端口创建，如果二者均具有BCP能力，则按照S404阶段的方式创建扩展端口。

S404阶段，PE设备遍历本设备上所有的端口，将各个端口标识封装在BCP报文中，并发送给CB设备。

所构造的BCP报文包括两部分，一部分的报文格式为图2-1所定义的格式，在封装本条BCP报文时，如果BCP报文总长度超过511字节，且存在未被封装的待创建端口，则Index置为1，表示后续还有待发送的BCP报文，如果Index置为0，则表示本条BCP报文为向CB设备发送的最后一条BCP报文。

BCP报文的Port Array TLV部分的格式如图2-3所示。

如果该条BCP报文的长度超过了511字节，且还有部分端口标识没有被封装，则index字段置为1。并在发送该BCP报文后继续封装下个BCP报文。如果封装端口标识后没有剩余端口标识未被封装，则index字段置为0。

S405阶段是CB设备接收到BCP报文后创建扩展端口阶段。

CB设备接收到BCP报文后，解析其中的端口标识并保存。如BCP报文中index为1，那么继续等待接收。如果第二定时器超过了60秒仍没有接收到index为0的BCP报文或者接收到index为0的BCP报文，则CB设备根据BCP报文中的Port Array TLV部分的端口标识统一创建这些扩展端口。统一创建扩展端口参照现有技术中的相关流程。

S406阶段为返回BCP应答报文阶段。

CB设备创建BCP应答报文，为已创建的扩展端口分配ECID，并将各个ECID赋值给Port Entry。所构造的BCP响应报文包括两部分，一部分的报文格式为图2-1所定义的格式，在封装本条BCP响应报文时，如果BCP响应报文总长度超过511字节，且存在未被封装的ECID，则Index置为1，表示后续还有待发送的BCP响应报文，如果Index置为0，则表示本条BCP响应报文为向PE设备发送的最后一条BCP响应报文。

BCP响应报文的Port Array TLV部分的格式如图2-3所示。

如果该条BCP响应报文的长度超过了511字节，且还有部分ECID没有被封装，则index字段置为1。并在发送该BCP响应报文后继续封装下个BCP响应报文。如果封装端口标识后没有剩余ECID未被封装，则index字段置为0。

PE设备和CB设备通过报文交换创建扩展端口的流程还可以包括PE设备对BCP应答报文的处理阶段。

PE设备接收到BCP应答报文时，解析其中的PortEntry，将已创建的端口标识和ECID成对保存，如果第一定时器超过60秒没有接收到index为0的BCP响应报文，或者收到index为0的BCP响应报文，则PE设备将所有保存的ECID下发给驱动，使其用于转发。

值得指出的是，本申请所描述的创建扩展端口的方案在多级PE设备级联的虚拟化网络中效果尤为突出。例如，4个PE设备中，如果每个PE设备均具有48个待创建端口，那么依据现有技术需交互的Extended Port Create报文及Extended Port Create应答报文的总数量为4*48*2＝384个。而如果参照本申请所描述的方案，通过BCP报文及BCP响应报文来进行端口创建，则PE设备和CB设备交互的报文总数量仅为8个报文。

与前述创建扩展端口的方法的实施例相对应，本申请还提供了创建扩展端口的装置的实施例。

本申请创建扩展端口的装置的实施例可以应用在PE设备或CB设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在PE/CB设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请创建扩展端口的装置所在PE/CB设备的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的PE/CB设备通常根据该网络设备的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图6，为本申请创建扩展端口的装置600的逻辑框图，创建扩展端口的装置600位于端口扩展器PE设备。

能力协商模块601，用于与控制桥CB设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；

批处理模块602，用于当所述PE设备和所述CB设备均具有所述批量创建端口能力时，向所述CB设备发送批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识，以使所述CB设备根据所述待创建端口的端口标识创建端口。

其中，所述能力协商报文可以为CSP OPEN报文；表示所述CB设备或PE设备是否具有批量创建端口能力的标识为所述CSP OPEN报文的R字段。

其中，所述BCP报文中还可以封装有第一分包标记和/或待创建的端口的数目信息，所述第一分包标记用于标记该条BCP报文是否为发送给所述CB设备的最后一条BCP报文。

作为一个实施例，所述批处理模块602还用于接收所述CB设备所发送的BCP响应报文；所述BCP响应报文中封装有至少一个已创建端口的扩展信道标识ECID；以及如果已接收到所述CB设备所发送的全部BCP响应报文，则将各个所述ECID下发给驱动。

在一个实施例中，可以根据第一定时器是否超时判断是否已接收到所述CB设备所发送的全部BCP响应报文。

在另一个实施例中，所述BCP响应报文中还可以携带有第二分包标记，所述第二分包标记用于标记该条BCP响应报文是否为所述CB设备所发送的最后一条BCP响应报文。

请参考图7，为本申请创建扩展端口的装置700的逻辑框图，创建扩展端口的装置700位于端口扩展器CB设备。

能力协商模块701，用于与端口扩展器PE设备交互能力协商报文；所述能力协商报文中携带有表示所述CB设备或PE设备是否具有批量创建端口能力的标识；

扩展端口创建模块702，用于接收所述PE设备的批量创建端口BCP报文，所述BCP报文中封装有至少一个待创建端口的端口标识；以及从所述BCP报文中获取至少一个待创建端口的端口标识并创建端口。

作为一个实施例，在从所述BCP报文中获取至少一个待创建端口的端口标识并创建端口之前，所述扩展端口创建模块702还可以用于根据预设的第二定时器是否超时判断是否已接收完所有的所述BCP报文。

作为一个实施例，所述BCP报文中还封装有第一分包标记和/或待创建的端口的数目信息，所述第一分包标记用于标记该条BCP报文是否为发送给所述CB设备的最后一条BCP报文；

从所述BCP报文中获取至少一个待创建端口的端口标识创建端口之前，所述扩展端口创建模块702还用于根据所述第一分包标记判断所述BCP报文是否已接收完所有的所述BCP报文。

在一个实施例中，所述装置700还包括批处理模块(图中未示出)，用于向所述PE设备发送BCP响应报文，所述BCP响应报文中携带有已创建端口的扩展信道标识ECID。

在一个实施例中，所述BCP响应报文中携带有第二分包标记，所述第二分包标记用于标记该条BCP响应报文是否为所述CB设备所发送的最后一条BCP响应报文。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims

1.一种创建扩展端口的方法，运行于端口扩展器PE设备，其特征在于，包括步骤：

2.根据权利要求1所述的方法，其特征在于，所述能力协商报文为控制与状态协议打开CSP OPEN报文；表示所述CB设备或PE设备是否具有批量创建端口能力的标识为所述CSPOPEN报文的R字段。

3.根据权利要求1所述的方法，其特征在于，所述BCP报文中还封装有第一分包标记和/或待创建的端口的数目信息，所述第一分包标记用于标记该条BCP报文是否为发送给所述CB设备的最后一条BCP报文。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括步骤：

接收所述CB设备所发送的BCP响应报文；所述BCP响应报文中封装有至少一个已创建端口的扩展信道标识ECID；

如果已接收到所述CB设备所发送的全部BCP响应报文，则将各个所述ECID下发给驱动。

5.根据权利要求4所述的方法，其特征在于，根据第一定时器是否超时判断是否已接收到所述CB设备所发送的全部BCP响应报文。

6.根据权利要求4或5所述的方法，其特征在于，所述BCP响应报文中携带有第二分包标记，所述第二分包标记用于标记该条BCP响应报文是否为所述CB设备所发送的最后一条BCP响应报文。

7.一种创建扩展端口的方法，运行于控制桥CB设备，其特征在于，包括步骤：

8.根据权利要求7所述的方法，其特征在于，从所述BCP报文中获取至少一个待创建端口的端口标识并创建端口之前，所述方法还包括步骤：

根据预设的第二定时器是否超时判断是否已接收完所有的所述BCP报文。

9.根据权利要求7所述的方法，其特征在于，所述BCP报文中还封装有第一分包标记和/或待创建的端口的数目信息，所述第一分包标记用于标记该条BCP报文是否为发送给所述CB设备的最后一条BCP报文；

从所述BCP报文中获取至少一个待创建端口的端口标识创建端口之前，所述方法还包括步骤：

根据所述第一分包标记判断所述BCP报文是否已接收完所有的所述BCP报文。

10.根据权利要求7所述的方法，其特征在于，所述方法还包括步骤：向所述PE设备发送BCP响应报文，所述BCP响应报文中携带有已创建端口的扩展信道标识ECID。

11.根据权利要求10所述的方法，其特征在于，所述BCP响应报文中携带有第二分包标记，所述第二分包标记用于标记该条BCP响应报文是否为所述CB设备所发送的最后一条BCP响应报文。

12.一种创建扩展端口的装置，位于端口扩展器PE设备，其特征在于，包括：

13.根据权利要求12所述的装置，其特征在于，所述能力协商报文为控制与状态协议打开CSP OPEN报文；表示所述CB设备或PE设备是否具有批量创建端口能力的标识为所述CSPOPEN报文的R字段。

14.根据权利要求12所述的装置，其特征在于，所述BCP报文中还封装有第一分包标记和/或待创建的端口的数目信息，所述第一分包标记用于标记该条BCP报文是否为发送给所述CB设备的最后一条BCP报文。

15.根据权利要求12所述的装置，其特征在于，所述批处理模块还用于接收所述CB设备所发送的BCP响应报文；所述BCP响应报文中封装有至少一个已创建端口的扩展信道标识ECID；以及

16.根据权利要求15所述的装置，其特征在于，根据第一定时器是否超时判断是否已接收到所述CB设备所发送的全部BCP响应报文。

17.根据权利要求15或16所述的装置，其特征在于，所述BCP响应报文中携带有第二分包标记，所述第二分包标记用于标记该条BCP响应报文是否为所述CB设备所发送的最后一条BCP响应报文。

18.一种创建扩展端口的装置，运行于控制桥CB设备，其特征在于，包括：

19.根据权利要求18所述的装置，其特征在于，在从所述BCP报文中获取至少一个待创建端口的端口标识并创建端口之前，所述扩展端口创建模块还用于根据预设的第二定时器是否超时判断是否已接收完所有的所述BCP报文。

20.根据权利要求18或19所述的装置，其特征在于，所述BCP报文中还封装有第一分包标记和/或待创建的端口的数目信息，所述第一分包标记用于标记该条BCP报文是否为发送给所述CB设备的最后一条BCP报文；

从所述BCP报文中获取至少一个待创建端口的端口标识创建端口之前，所述扩展端口创建模块还用于根据所述第一分包标记判断所述BCP报文是否已接收完所有的所述BCP报文。

21.根据权利要求18所述的装置，其特征在于，所述装置还包括批处理模块，用于向所述PE设备发送BCP响应报文，所述BCP响应报文中携带有已创建端口的扩展信道标识ECID。

22.根据权利要求21所述的装置，其特征在于，所述BCP响应报文中携带有第二分包标记，所述第二分包标记用于标记该条BCP响应报文是否为所述CB设备所发送的最后一条BCP响应报文。