业务路由器虚拟延伸接入系统技术要求

业务路由器虚拟延伸接入系统技术要求1范围本文件规定了业务路由器虚拟延伸接入系统技术要求，包括虚拟延伸系统结构基础架构本文件适用于业务路由器与汇聚接入交换机之间的虚拟延伸系统的研发、2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。IEEEStd802.1BR-2012局域网和城域网IEEE标准-虚拟桥接局域网-桥端口扩展(IEEEStandardforLocalandmetropolitanareanetworks-VirtualBridgedAreaNetworks-BridgePortExtension)3术语、定义及缩略语控制设备上连接端口扩展设备的端口。端口扩展设备上连接控制设备的端口。3.2缩略语下列缩略语适用于本文件。AddressResolutionPr扩展通道编号边缘控制协议LinkAggregationCont媒体访问控制NETCONF网络配置协议NetworkConfigurationProtocol2端口扩展端口扩展控制状态协议PortExtenderControlandStatus简单网络管理协议SimpleNetworkManagement生成树协议传输控制协议/网际协议TransmissionControlProtocolInterne远程登录协议TelecommunicationsNetwork虚拟网管口VirtualManagementEt虚拟专用网络VirtualPrivateNet4虚拟延伸系统结构4.1总体结构虚拟延伸接入系统是由控制设备CB(例如业务路由器或其集群)通过其级联口与PE设备(例如交换机或其集群)上行口连接起来形成的系统。整个虚拟延伸接入系统对外是一台虚拟的逻辑设备，PE设备是CB设备的扩展接口板。虚拟廷伸接入系统级联口图1虚拟延伸接入系统总体结构图如图1所示，CB设备和PE设备共同组成虚拟延伸接入系统，两者之间通过CB设备级联口和PE设备上行口互联，对外是同一系统。4.2管理模式CB设备统一管理PE设备上的接口，向用户提供接入服务，增加(B设备的接入能力。CB设备和PE设备之间是松耦合，版本独立管理，允许跨版本、跨分支、跨产品甚至跨平台对PE设备是CB设备的扩展接口板，CB设备下发到PE设备的全局配置主要包括：——PE设备的全局配置--PE槽位上板级的配置：--PE接口上的配置。对于CB设备和PE设备，在单独运行时，原有接口描述都为三维形式(接口类型槽号/3子卡号/端口号),如ten-gigabitethernet0/0/1;而创建虚拟延伸接入系统后，CB设备为了统一管理系统中数量庞大的PE设备，接口编号由三维变为四维(接口类型框号/槽号/子卡号/端口号),增加框号这一维，而框号由CB给PE分配，只在CB设备上有效。CB设备框号范围为1-99,而100到227分配给PE设备。框号只是在CB设备本地系统中起到对不同PE设备编号：而在PE设备本地系统中，仍为原三维描述(PE设备之间是独立、互不感知)。虚拟延仲接入系统统一在CB设备上运维，所以用户操作接口时，对于PE设备接口，变为四维，如ten-gigabitethernet100/0/0/1。CB设备和PE设备之间的通信以IEEE802.1BR协议为基础协议，PE设备通过802.1BR协议接入CB设备。CB设备通过IEEE802.1BR协议和NETCONF协议来完成对PE设备的控制和管理。IEFE802.1BR协议和NETCONF协议在CB设备主控板卡(Master)和PE设备Master之间进行，如果CB设备和PE设备非Master(如备用板卡Standby或者线卡接口板)之间有通信需求的特性，需要模块单独做分布式处理，例如PE和CB设备的Master进行通信交互，由Master上的进程再与Standby或者其他线卡接口板上的进程通信，完成最终的处理。CB设备运行业务路由器设备系统软件，CB设备板间通信(不含PE节点)基于设备商内部通信协议，可以是各厂商内部私有通信模型。PE设备运行接入交换机自身软件单台设备，可以是各厂商内部私有通信模型根据CB设备和PE设备之间通信情况，可以分为两种模型：CB集中处理模式和CB-PE协同处理模型CB集中处理模型：对于一些业务功能，如果所有状态控制、协议都在CB设备完成，PE设完全不参与任何处理，则可使用CB集中处理的通信模型。一般在网络层及以上的各层协议，都是由该模型处理，如路由协议报文集中由CB处理、计算路由等。如图2,假设A业务功能需使用CB集中处理模型，该模型应满足：——PE设备应将业务功能需要处理的协议报文送到CB设备处理；——业务处理过程不涉及E设备硬件处理的部分应全部由CB设备处理；——所有的配置数据、运行数据(如状态机)都应该由CB设备处理A4图2CB集中处理模型CB-PE协同处理模型：该模型下，业务功能的实现需要CB设备和PE设备协同完成。一般在数据链路层以及用户端口相关的处理，都需要使用该模型，例如链路聚合，所有的LACP报文由PE设备直接转发到CB设备，配置下发和协议计算由CB设备完成，计算结果(如端口状态设置)需通知到PE设备设置对应状态。如图3,假设A业务功能需使用CB-PE协同处理模型，该模型应满足：--CB设备将配置下发全局同步各板；——CB设备下发到硬件的配置数据，通过802.1BR通道下发到PE;-—PE设备下线后重新上线，CB设备负责恢复PE设备的配置，保证CB-PE的配置一——除了配置数据，CB设备将硬件上的状态数据也要下发到PE设备。CBCB-PE协作处理模型行口间的通道C”C图3CB-PE协同处理模型4.4虚拟三层通道模式4.4.1虚拟三层通道IEEE802.1BR协议在数据面对虚拟延伸系统做了阐明，但对管理通道未做过多规范。本标准设计虚拟管理网管口，建立了CB设备和PE设备之间的IP通信通道CB和PE之间各创建一个虚拟网管口WE,CB设备统一管理会并为每个VWIE口分配IP地址，且绑定到专有的VPN中，所有CB、PE设备之间的三层管理报文都通过VIE口收发。VE口物理承载在CB、PE设备之间的级联通道上，整个通道建立过程中所有的地址分配、ARP、路由学习都是系统自动进行的，无需用户进行任何配置和操作。基于该通道，CB设备可以通过各种基于IP的协议(如NETOONF、SNMP、T提高系统的可扩展性和CB设备对PE设备的管理控制能力。5PEPE管理通道示意图CBPE管理地址表级联链路：级联口与上行口间的数据通道间的管理通道图4PE管理通道4.4.2创建虚拟管理网口CB设备和PE设备启动后，各自创建虚拟三层网管口WE,各自为本设备的VME口分配MAC地址。CB设备只有一个网管口，每个PE设备有一个网管口4.4.3创建CB/PE管理网口VPNCB/PE设备启动后，各自创建一个用于CB、PE设备之间协议报文交互的管理VPN。CB设备上自动将WE口绑定管理VPN.并配置WE口IP地址，虚拟管理报文在专有VPN里传输，因此不会与用户业务IP地址配置冲突。该VPN是预留专用VPN,不能与其它业务共用。PE设备IP地址需要等PE上线后，由CB设备分配并同步到PE设备。4.4.4PE虚拟网管口分配ECIDCB设备的WEIP地址和分配给PE的VEIP地址都通过PECSP扩展消息通知给PE设备。PE设备向CB设备发送自己的VE口的端口创建(PORTCREATE)扩展消息，并请求自己的WE口BCID,CB收到PORTCREATE消息，对该虚拟网管口分配ECID,并通过PECSP响应消息发4.5控制协议PECSP交互模式4.5.1Request-Rosponso交互模式PECSP按照Request-Response形式进行交互，一般每个交互过程至少涉及4个PECSP报文。a)发起方发送请求(Request)报文给接收方；b)接收方收到后立即回复请求确认(Request-Ack)报文给发起方，表明Request报文已收到；该ACK报文只需要携带PEECSP头即可，无实际负载。PECSP头里包含有ACK报文以及对应的序列号(SequenceNum);c)接收方根据Request响应报文，d)发起方收到Response报文后，回复给接收方响应确认(Response-Ack)报文，表明Response报文已收到。整个交互过程如下图5所示，以CB发起协议交互为例执行命令图5Request-Responso交互模型该模型发起方只需要发送一个Request请求报文，中间过程的Ack和Response回复都是PECSP状态机来控制。目前系统设置类消息多采用该模型交互，例如CB设备对PE设备端口聚合和STP端口状态进行设置等。4.5.2Request-Raquest交互模式Request-Request形式的交互实际上是两次Request-Response模型，发起方在发起一次Request-Response交互后，如果对后续动作或状态等信息需要交互，则由接收方再发起整个交互过程如下图所示，以CB发起第一次协议交互为例。YD/TXXXX-XXXX请求结果返回Ack图6Request-Request交互模型该模型的典型特点是发起方需要发送一个Requst报文，接收方处理结果(或返回数据)也是通过Request报文返回。目前该模型主要应用在两种场景进行对端处理结果的设置类操作，以及获取对端返回数据的操作，例如CB设备需要从PE设备获取其所有接口的状态信5虚拟延伸系统建立过程5.1虚拟延伸系统建立主要的建立过程概括如下a)CB设备和PE设备各自独立启动；b)CB设备和PE设备之间的级联口/上行口UP时，交互LDP报文，协商各自能力集c)CB设备和PE设备之间聚合连接，通过LACP协商聚合状态，选择可选中成员口等d)聚合口UP后，即可交互PECSP协议，CB设备和PE设备互发PECSPOPEN报文，建立连接；e)WE接口创建，分配IP及ECID;0)PECPU口创建，分配ECID;g)PE扩展端口创建，分配ECID;h)其他配置下发，协议规定的其他标准字段。CB设备级联口和PE设备上行口UP时，即可交互LLDP来互相发现，使用标准协议。根据IEEE802.1BR协议规范，新增了TLV确认CB设备和PE设备各自能力集角色，如图7所IPriorityAddres-TLVInfornationString----按照协议的规范要求，当PE的上行口发送的报文中级联口优先级(CascadePortPriority)字段选填0~254,而CB的级联口发送的报文中级联口优先级字段设置为255。因此可根据级联口优先级(CascadePortPriority)来确认CB/PE角色，例如PE设备发出LDP报文，所带CascadePortPriority值为FF,即优先级最低；而CB设备发出的LLDP报文，所带CascadePortPriority值为00,为最高优先级，所以可选择优先做CB设备。标准LACP协议交互，参见IEEE802.3ad。回PECSPOPENRequest和Response报文，以及ECPACK报文。PECSP作为ECP的上层协议执行，所以有4字节ECP头，之后才是PECSP数据。设备分配虚拟网管口IP地址及VPN信息；同时PE设备向CB设备发送PECSP端口创建报文，CB设备也会为该虚拟网管口再分配ECID,协议标准的流程为PE设备发送ExtendedPort系统中会存在一些内部协议报文在CB设备和PE设备之间交互，因此对于PE的CPU也需要被认为是一个端口，要分配ECI0.PE设备向CB设备发送一个标准ExtendedPortCreat的报文，不带TLV,CB设备按照正常的ECID分配回复Response报文。虚拟网管口创建后，PE设备根据自身接口总数，循环发送ExtendedPortCreat消息CB设备在自身系统中按照接口创建流程添加接口，并分配EC10给PE设备端口；创建流程6.1PECSP总体报文格式PECSP扩展消息由CommandTLV和0rganizationallySpecificTLV组成.如图8所取值7。本CornandTLY的TLYlengthD消息类型，0表示roquest,1表示OrganizationallySpeeifieTLV定义如图10。各字段含义说明如表2、表3所示。127表示0nganizationally01IEEE802.1BRMBLSSocke2TEEE802,12RTLV数据扩展消息，详6.2标准消息扩展(MBUSsOCKET)6.2.1消息说明MBUSS0CKET是PE设备和CB设备之间交互管理类信息的消息，包括设备管理信息(如设备基础信息、制造信息、凤扇信息、温度信息等)以及接口管理类信息(如获取接口统计等),MBUSS0CXET消息是否需要对端业务应答需要看业务情况。另外，不保证消息一定被对端收到，所以发送方需要适当的超时处理机制。不同厂商之间实现形式可能不相同，属于各厂商内部实现，并不统一，建议后续都通过NETCONF形式来下发或查询。6.2.2消息格式之后是数据字段。IEEE802.1BRMBDSSocketTLV头定义如图11。<OrganizationallySpecificTLVH422源节点头见图12。222223图12源节点头MBUS协议分片头见图13。4422211图13MEUS协议分片头各字段含义说明如表4所示。序MBUS子协议号，802.1BRMBUSSocket固定MBUS分片编号，802.1BRMBUSSocket固定6.3标准消息扩展(TLV数据)6.3.1消息说明TLV数据是在PE设备和CB设备之间交互系统扩展接口相关信息，主要包括控制类和状态维护类消息6.3.2消息格式在PECSP协议报文的CommandTLV后面紧跟着802.1BR数据TLV头，再之后是相应消息类型的数据字