業(yè)務(wù)路由器虛擬延伸接入系統(tǒng)技術(shù)要求

業(yè)務(wù)路由器虛擬延伸接入系統(tǒng)技術(shù)要求1范圍本文件規(guī)定了業(yè)務(wù)路由器虛擬延伸接入系統(tǒng)技術(shù)要求，包括虛擬延伸系統(tǒng)結(jié)構(gòu)基礎(chǔ)架構(gòu)本文件適用于業(yè)務(wù)路由器與匯聚接入交換機(jī)之間的虛擬延伸系統(tǒng)的研發(fā)、2規(guī)范性引用文件下列文件中的內(nèi)容通過(guò)文中的規(guī)范性引用而構(gòu)成本文件必不可少的的引用文件，僅該日期對(duì)應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。IEEEStd802.1BR-2012局域網(wǎng)和城域網(wǎng)IEEE標(biāo)準(zhǔn)-虛擬橋接局域網(wǎng)-橋端口擴(kuò)展(IEEEStandardforLocalandmetropolitanareanetworks-VirtualBridgedAreaNetworks-BridgePortExtension)3術(shù)語(yǔ)、定義及縮略語(yǔ)控制設(shè)備上連接端口擴(kuò)展設(shè)備的端口。端口擴(kuò)展設(shè)備上連接控制設(shè)備的端口。3.2縮略語(yǔ)下列縮略語(yǔ)適用于本文件。AddressResolutionPr擴(kuò)展通道編號(hào)邊緣控制協(xié)議LinkAggregationCont媒體訪問(wèn)控制NETCONF網(wǎng)絡(luò)配置協(xié)議NetworkConfigurationProtocol2端口擴(kuò)展端口擴(kuò)展控制狀態(tài)協(xié)議PortExtenderControlandStatus簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議SimpleNetworkManagement生成樹(shù)協(xié)議傳輸控制協(xié)議/網(wǎng)際協(xié)議TransmissionControlProtocolInterne遠(yuǎn)程登錄協(xié)議TelecommunicationsNetwork虛擬網(wǎng)管口VirtualManagementEt虛擬專用網(wǎng)絡(luò)VirtualPrivateNet4虛擬延伸系統(tǒng)結(jié)構(gòu)4.1總體結(jié)構(gòu)虛擬延伸接入系統(tǒng)是由控制設(shè)備CB(例如業(yè)務(wù)路由器或其集群)通過(guò)其級(jí)聯(lián)口與PE設(shè)備(例如交換機(jī)或其集群)上行口連接起來(lái)形成的系統(tǒng)。整個(gè)虛擬延伸接入系統(tǒng)對(duì)外是一臺(tái)虛擬的邏輯設(shè)備，PE設(shè)備是CB設(shè)備的擴(kuò)展接口板。虛擬廷伸接入系統(tǒng)級(jí)聯(lián)口圖1虛擬延伸接入系統(tǒng)總體結(jié)構(gòu)圖如圖1所示，CB設(shè)備和PE設(shè)備共同組成虛擬延伸接入系統(tǒng)，兩者之間通過(guò)CB設(shè)備級(jí)聯(lián)口和PE設(shè)備上行口互聯(lián)，對(duì)外是同一系統(tǒng)。4.2管理模式CB設(shè)備統(tǒng)一管理PE設(shè)備上的接口，向用戶提供接入服務(wù)，增加(B設(shè)備的接入能力。CB設(shè)備和PE設(shè)備之間是松耦合，版本獨(dú)立管理，允許跨版本、跨分支、跨產(chǎn)品甚至跨平臺(tái)對(duì)PE設(shè)備是CB設(shè)備的擴(kuò)展接口板，CB設(shè)備下發(fā)到PE設(shè)備的全局配置主要包括：——PE設(shè)備的全局配置--PE槽位上板級(jí)的配置：--PE接口上的配置。對(duì)于CB設(shè)備和PE設(shè)備，在單獨(dú)運(yùn)行時(shí)，原有接口描述都為三維形式(接口類型槽號(hào)/3子卡號(hào)/端口號(hào)),如ten-gigabitethernet0/0/1;而創(chuàng)建虛擬延伸接入系統(tǒng)后，CB設(shè)備為了統(tǒng)一管理系統(tǒng)中數(shù)量龐大的PE設(shè)備，接口編號(hào)由三維變?yōu)樗木S(接口類型框號(hào)/槽號(hào)/子卡號(hào)/端口號(hào)),增加框號(hào)這一維，而框號(hào)由CB給PE分配，只在CB設(shè)備上有效。CB設(shè)備框號(hào)范圍為1-99,而100到227分配給PE設(shè)備?？蛱?hào)只是在CB設(shè)備本地系統(tǒng)中起到對(duì)不同PE設(shè)備編號(hào)：而在PE設(shè)備本地系統(tǒng)中，仍為原三維描述(PE設(shè)備之間是獨(dú)立、互不感知)。虛擬延仲接入系統(tǒng)統(tǒng)一在CB設(shè)備上運(yùn)維，所以用戶操作接口時(shí)，對(duì)于PE設(shè)備接口，變?yōu)樗木S，如ten-gigabitethernet100/0/0/1。CB設(shè)備和PE設(shè)備之間的通信以IEEE802.1BR協(xié)議為基礎(chǔ)協(xié)議，PE設(shè)備通過(guò)802.1BR協(xié)議接入CB設(shè)備。CB設(shè)備通過(guò)IEEE802.1BR協(xié)議和NETCONF協(xié)議來(lái)完成對(duì)PE設(shè)備的控制和管理。IEFE802.1BR協(xié)議和NETCONF協(xié)議在CB設(shè)備主控板卡(Master)和PE設(shè)備Master之間進(jìn)行，如果CB設(shè)備和PE設(shè)備非Master(如備用板卡Standby或者線卡接口板)之間有通信需求的特性，需要模塊單獨(dú)做分布式處理，例如PE和CB設(shè)備的Master進(jìn)行通信交互，由Master上的進(jìn)程再與Standby或者其他線卡接口板上的進(jìn)程通信，完成最終的處理。CB設(shè)備運(yùn)行業(yè)務(wù)路由器設(shè)備系統(tǒng)軟件，CB設(shè)備板間通信(不含PE節(jié)點(diǎn))基于設(shè)備商內(nèi)部通信協(xié)議，可以是各廠商內(nèi)部私有通信模型。PE設(shè)備運(yùn)行接入交換機(jī)自身軟件單臺(tái)設(shè)備，可以是各廠商內(nèi)部私有通信模型根據(jù)CB設(shè)備和PE設(shè)備之間通信情況，可以分為兩種模型：CB集中處理模式和CB-PE協(xié)同處理模型CB集中處理模型：對(duì)于一些業(yè)務(wù)功能，如果所有狀態(tài)控制、協(xié)議都在CB設(shè)備完成，PE設(shè)完全不參與任何處理，則可使用CB集中處理的通信模型。一般在網(wǎng)絡(luò)層及以上的各層協(xié)議，都是由該模型處理，如路由協(xié)議報(bào)文集中由CB處理、計(jì)算路由等。如圖2,假設(shè)A業(yè)務(wù)功能需使用CB集中處理模型，該模型應(yīng)滿足：——PE設(shè)備應(yīng)將業(yè)務(wù)功能需要處理的協(xié)議報(bào)文送到CB設(shè)備處理；——業(yè)務(wù)處理過(guò)程不涉及E設(shè)備硬件處理的部分應(yīng)全部由CB設(shè)備處理；——所有的配置數(shù)據(jù)、運(yùn)行數(shù)據(jù)(如狀態(tài)機(jī))都應(yīng)該由CB設(shè)備處理A4圖2CB集中處理模型CB-PE協(xié)同處理模型：該模型下，業(yè)務(wù)功能的實(shí)現(xiàn)需要CB設(shè)備和PE設(shè)備協(xié)同完成。一般在數(shù)據(jù)鏈路層以及用戶端口相關(guān)的處理，都需要使用該模型，例如鏈路聚合，所有的LACP報(bào)文由PE設(shè)備直接轉(zhuǎn)發(fā)到CB設(shè)備，配置下發(fā)和協(xié)議計(jì)算由CB設(shè)備完成，計(jì)算結(jié)果(如端口狀態(tài)設(shè)置)需通知到PE設(shè)備設(shè)置對(duì)應(yīng)狀態(tài)。如圖3,假設(shè)A業(yè)務(wù)功能需使用CB-PE協(xié)同處理模型，該模型應(yīng)滿足：--CB設(shè)備將配置下發(fā)全局同步各板；——CB設(shè)備下發(fā)到硬件的配置數(shù)據(jù)，通過(guò)802.1BR通道下發(fā)到PE;-—PE設(shè)備下線后重新上線，CB設(shè)備負(fù)責(zé)恢復(fù)PE設(shè)備的配置，保證CB-PE的配置一——除了配置數(shù)據(jù)，CB設(shè)備將硬件上的狀態(tài)數(shù)據(jù)也要下發(fā)到PE設(shè)備。CBCB-PE協(xié)作處理模型行口間的通道C”C圖3CB-PE協(xié)同處理模型4.4虛擬三層通道模式4.4.1虛擬三層通道IEEE802.1BR協(xié)議在數(shù)據(jù)面對(duì)虛擬延伸系統(tǒng)做了闡明，但對(duì)管理通道未做過(guò)多規(guī)范。本標(biāo)準(zhǔn)設(shè)計(jì)虛擬管理網(wǎng)管口，建立了CB設(shè)備和PE設(shè)備之間的IP通信通道CB和PE之間各創(chuàng)建一個(gè)虛擬網(wǎng)管口WE,CB設(shè)備統(tǒng)一管理會(huì)并為每個(gè)VWIE口分配IP地址，且綁定到專有的VPN中，所有CB、PE設(shè)備之間的三層管理報(bào)文都通過(guò)VIE口收發(fā)。VE口物理承載在CB、PE設(shè)備之間的級(jí)聯(lián)通道上，整個(gè)通道建立過(guò)程中所有的地址分配、ARP、路由學(xué)習(xí)都是系統(tǒng)自動(dòng)進(jìn)行的，無(wú)需用戶進(jìn)行任何配置和操作?；谠撏ǖ溃珻B設(shè)備可以通過(guò)各種基于IP的協(xié)議(如NETOONF、SNMP、T提高系統(tǒng)的可擴(kuò)展性和CB設(shè)備對(duì)PE設(shè)備的管理控制能力。5PEPE管理通道示意圖CBPE管理地址表級(jí)聯(lián)鏈路：級(jí)聯(lián)口與上行口間的數(shù)據(jù)通道間的管理通道圖4PE管理通道4.4.2創(chuàng)建虛擬管理網(wǎng)口CB設(shè)備和PE設(shè)備啟動(dòng)后，各自創(chuàng)建虛擬三層網(wǎng)管口WE,各自為本設(shè)備的VME口分配MAC地址。CB設(shè)備只有一個(gè)網(wǎng)管口，每個(gè)PE設(shè)備有一個(gè)網(wǎng)管口4.4.3創(chuàng)建CB/PE管理網(wǎng)口VPNCB/PE設(shè)備啟動(dòng)后，各自創(chuàng)建一個(gè)用于CB、PE設(shè)備之間協(xié)議報(bào)文交互的管理VPN。CB設(shè)備上自動(dòng)將WE口綁定管理VPN.并配置WE口IP地址，虛擬管理報(bào)文在專有VPN里傳輸，因此不會(huì)與用戶業(yè)務(wù)IP地址配置沖突。該VPN是預(yù)留專用VPN,不能與其它業(yè)務(wù)共用。PE設(shè)備IP地址需要等PE上線后，由CB設(shè)備分配并同步到PE設(shè)備。4.4.4PE虛擬網(wǎng)管口分配ECIDCB設(shè)備的WEIP地址和分配給PE的VEIP地址都通過(guò)PECSP擴(kuò)展消息通知給PE設(shè)備。PE設(shè)備向CB設(shè)備發(fā)送自己的VE口的端口創(chuàng)建(PORTCREATE)擴(kuò)展消息，并請(qǐng)求自己的WE口BCID,CB收到PORTCREATE消息，對(duì)該虛擬網(wǎng)管口分配ECID,并通過(guò)PECSP響應(yīng)消息發(fā)4.5控制協(xié)議PECSP交互模式4.5.1Request-Rosponso交互模式PECSP按照Request-Response形式進(jìn)行交互，一般每個(gè)交互過(guò)程至少涉及4個(gè)PECSP報(bào)文。a)發(fā)起方發(fā)送請(qǐng)求(Request)報(bào)文給接收方；b)接收方收到后立即回復(fù)請(qǐng)求確認(rèn)(Request-Ack)報(bào)文給發(fā)起方，表明Request報(bào)文已收到；該ACK報(bào)文只需要攜帶PEECSP頭即可，無(wú)實(shí)際負(fù)載。PECSP頭里包含有ACK報(bào)文以及對(duì)應(yīng)的序列號(hào)(SequenceNum);c)接收方根據(jù)Request響應(yīng)報(bào)文，d)發(fā)起方收到Response報(bào)文后，回復(fù)給接收方響應(yīng)確認(rèn)(Response-Ack)報(bào)文，表明Response報(bào)文已收到。整個(gè)交互過(guò)程如下圖5所示，以CB發(fā)起協(xié)議交互為例執(zhí)行命令圖5Request-Responso交互模型該模型發(fā)起方只需要發(fā)送一個(gè)Request請(qǐng)求報(bào)文，中間過(guò)程的Ack和Response回復(fù)都是PECSP狀態(tài)機(jī)來(lái)控制。目前系統(tǒng)設(shè)置類消息多采用該模型交互，例如CB設(shè)備對(duì)PE設(shè)備端口聚合和STP端口狀態(tài)進(jìn)行設(shè)置等。4.5.2Request-Raquest交互模式Request-Request形式的交互實(shí)際上是兩次Request-Response模型，發(fā)起方在發(fā)起一次Request-Response交互后，如果對(duì)后續(xù)動(dòng)作或狀態(tài)等信息需要交互，則由接收方再發(fā)起整個(gè)交互過(guò)程如下圖所示，以CB發(fā)起第一次協(xié)議交互為例。YD/TXXXX-XXXX請(qǐng)求結(jié)果返回Ack圖6Request-Request交互模型該模型的典型特點(diǎn)是發(fā)起方需要發(fā)送一個(gè)Requst報(bào)文，接收方處理結(jié)果(或返回?cái)?shù)據(jù))也是通過(guò)Request報(bào)文返回。目前該模型主要應(yīng)用在兩種場(chǎng)景進(jìn)行對(duì)端處理結(jié)果的設(shè)置類操作，以及獲取對(duì)端返回?cái)?shù)據(jù)的操作，例如CB設(shè)備需要從PE設(shè)備獲取其所有接口的狀態(tài)信5虛擬延伸系統(tǒng)建立過(guò)程5.1虛擬延伸系統(tǒng)建立主要的建立過(guò)程概括如下a)CB設(shè)備和PE設(shè)備各自獨(dú)立啟動(dòng)；b)CB設(shè)備和PE設(shè)備之間的級(jí)聯(lián)口/上行口UP時(shí)，交互LDP報(bào)文，協(xié)商各自能力集c)CB設(shè)備和PE設(shè)備之間聚合連接，通過(guò)LACP協(xié)商聚合狀態(tài)，選擇可選中成員口等d)聚合口UP后，即可交互PECSP協(xié)議，CB設(shè)備和PE設(shè)備互發(fā)PECSPOPEN報(bào)文，建立連接；e)WE接口創(chuàng)建，分配IP及ECID;0)PECPU口創(chuàng)建，分配ECID;g)PE擴(kuò)展端口創(chuàng)建，分配ECID;h)其他配置下發(fā)，協(xié)議規(guī)定的其他標(biāo)準(zhǔn)字段。CB設(shè)備級(jí)聯(lián)口和PE設(shè)備上行口UP時(shí)，即可交互LLDP來(lái)互相發(fā)現(xiàn)，使用標(biāo)準(zhǔn)協(xié)議。根據(jù)IEEE802.1BR協(xié)議規(guī)范，新增了TLV確認(rèn)CB設(shè)備和PE設(shè)備各自能力集角色，如圖7所IPriorityAddres-TLVInfornationString----按照協(xié)議的規(guī)范要求，當(dāng)PE的上行口發(fā)送的報(bào)文中級(jí)聯(lián)口優(yōu)先級(jí)(CascadePortPriority)字段選填0~254,而CB的級(jí)聯(lián)口發(fā)送的報(bào)文中級(jí)聯(lián)口優(yōu)先級(jí)字段設(shè)置為255。因此可根據(jù)級(jí)聯(lián)口優(yōu)先級(jí)(CascadePortPriority)來(lái)確認(rèn)CB/PE角色，例如PE設(shè)備發(fā)出LDP報(bào)文，所帶CascadePortPriority值為FF,即優(yōu)先級(jí)最低；而CB設(shè)備發(fā)出的LLDP報(bào)文，所帶CascadePortPriority值為00,為最高優(yōu)先級(jí)，所以可選擇優(yōu)先做CB設(shè)備。標(biāo)準(zhǔn)LACP協(xié)議交互，參見(jiàn)IEEE802.3ad?；豍ECSPOPENRequest和Response報(bào)文，以及ECPACK報(bào)文。PECSP作為ECP的上層協(xié)議執(zhí)行，所以有4字節(jié)ECP頭，之后才是PECSP數(shù)據(jù)。設(shè)備分配虛擬網(wǎng)管口IP地址及VPN信息；同時(shí)PE設(shè)備向CB設(shè)備發(fā)送PECSP端口創(chuàng)建報(bào)文，CB設(shè)備也會(huì)為該虛擬網(wǎng)管口再分配ECID,協(xié)議標(biāo)準(zhǔn)的流程為PE設(shè)備發(fā)送ExtendedPort系統(tǒng)中會(huì)存在一些內(nèi)部協(xié)議報(bào)文在CB設(shè)備和PE設(shè)備之間交互，因此對(duì)于PE的CPU也需要被認(rèn)為是一個(gè)端口，要分配ECI0.PE設(shè)備向CB設(shè)備發(fā)送一個(gè)標(biāo)準(zhǔn)ExtendedPortCreat的報(bào)文，不帶TLV,CB設(shè)備按照正常的ECID分配回復(fù)Response報(bào)文。虛擬網(wǎng)管口創(chuàng)建后，PE設(shè)備根據(jù)自身接口總數(shù)，循環(huán)發(fā)送ExtendedPortCreat消息CB設(shè)備在自身系統(tǒng)中按照接口創(chuàng)建流程添加接口，并分配EC10給PE設(shè)備端口；創(chuàng)建流程6.1PECSP總體報(bào)文格式PECSP擴(kuò)展消息由CommandTLV和0rganizationallySpecificTLV組成.如圖8所取值7。本CornandTLY的TLYlengthD消息類型，0表示roquest,1表示OrganizationallySpeeifieTLV定義如圖10。各字段含義說(shuō)明如表2、表3所示。127表示0nganizationally01IEEE802.1BRMBLSSocke2TEEE802,12RTLV數(shù)據(jù)擴(kuò)展消息，詳6.2標(biāo)準(zhǔn)消息擴(kuò)展(MBUSsOCKET)6.2.1消息說(shuō)明MBUSS0CKET是PE設(shè)備和CB設(shè)備之間交互管理類信息的消息，包括設(shè)備管理信息(如設(shè)備基礎(chǔ)信息、制造信息、鳳扇信息、溫度信息等)以及接口管理類信息(如獲取接口統(tǒng)計(jì)等),MBUSS0CXET消息是否需要對(duì)端業(yè)務(wù)應(yīng)答需要看業(yè)務(wù)情況。另外，不保證消息一定被對(duì)端收到，所以發(fā)送方需要適當(dāng)?shù)某瑫r(shí)處理機(jī)制。不同廠商之間實(shí)現(xiàn)形式可能不相同，屬于各廠商內(nèi)部實(shí)現(xiàn)，并不統(tǒng)一，建議后續(xù)都通過(guò)NETCONF形式來(lái)下發(fā)或查詢。6.2.2消息格式之后是數(shù)據(jù)字段。IEEE802.1BRMBDSSocketTLV頭定義如圖11。<OrganizationallySpecificTLVH422源節(jié)點(diǎn)頭見(jiàn)圖12。222223圖12源節(jié)點(diǎn)頭MBUS協(xié)議分片頭見(jiàn)圖13。4422211圖13MEUS協(xié)議分片頭各字段含義說(shuō)明如表4所示。序MBUS子協(xié)議號(hào)，802.1BRMBUSSocket固定MBUS分片編號(hào)，802.1BRMBUSSocket固定6.3標(biāo)準(zhǔn)消息擴(kuò)展(TLV數(shù)據(jù))6.3.1消息說(shuō)明TLV數(shù)據(jù)是在PE設(shè)備和CB設(shè)備之間交互系統(tǒng)擴(kuò)展接口相關(guān)信息，主要包括控制類和狀態(tài)維護(hù)類消息6.3.2消息格式在PECSP協(xié)議報(bào)文的CommandTLV后面緊跟著802.1BR數(shù)據(jù)TLV頭，再之后是相應(yīng)消息類型的數(shù)據(jù)字