本章介紹了由一組控制程序實現的葉脊交換結構。我們使用運行在ONOS上的SD-Fabric作為示例實現，在之前章節中我們已經介紹過了SD-Fabric的很多方面，所以在進入細節之前先總結一下這些內容。

• SD-Fabric支持葉脊拓撲，這種拓撲通常用于連接數據中心中的多個服務器機架(參見圖10)，但也支持多站點部署(參見圖17)。SD-Fabric基于裸金屬交換機，并配備前幾章介紹的軟件來構建網絡，可以混合使用固定功能流水線和可編程流水線，但在一般在生產中使用前者。
• SD-Fabric支持大部分L2/L3特性，所有這些特性都作為SDN控制程序重新實現(除了用于中繼DHCP請求的DHCP服務器和用于與外部對等實體交換BGP路由的Quagga BGP服務器)。SD-Fabric實現每個服務器機架內部的L2連接，以及機架之間的L3連接。
• SD-Fabric支持接入/邊緣網絡技術，如PON(見圖13)和RAN(見圖17)，包括支持(a)路由IP流量到/從連接到這些接入網絡的設備，以及(b)將接入網功能卸載到交換機上。

本章不會對所有這些特性進行全面介紹，重點關注的是數據中心架構用例，這足以說明使用SDN原則構建生產級網絡的方法。關于SD-Fabric設計決策的更多信息，請訪問SD-Fabric網站。

7.1 特性集

SDN提供了定制網絡的機會，但出于實用原因，采用SDN的第一個要求是重新實現現有功能，并以復制(或改進)傳統解決方案的彈性和可伸縮性的方式來實現。SD-Fabric滿足了這一要求，我們在這里總結一下。

首先，關于L2連接，SD-Fabric支持VLAN，包括基于VLAN id轉發流量的原生支持，以及基于外部/內部VLAN id對的Q-in-Q支持。對Q-in-Q的支持與訪問網絡特別相關，其中使用雙標記來隔離屬于不同服務類別的流量。此外，SD-Fabric支持跨L3網絡的L2隧道(包括單標簽和雙標簽)。

其次，關于L3連接，SD-Fabric支持單播和組播地址的IPv4和IPv6路由。對于后者，SD-Fabric實現了集中式組播樹構造(與運行像PIM這樣的協議相反)，包含了對希望加入/離開組播組的終端主機的IGMP支持。SD-Fabric還支持ARP(用于IPv4地址轉換)和NDP(用于IPv6鄰居發現)，同時支持DHCPv4和DHCPv6。

然后，SD-Fabric在面對鏈路或交換機故障時提供高可用性。它通過組合眾所周知的技術來實現這一點: dual-homing、鏈路綁定和ECMP鏈路組。如圖39所示，SD-Fabric集群中的每臺服務器都連接到一對ToR(或葉子)交換機上，運行在每個計算服務器上的操作系統實現active-active鏈路綁定。然后，每個葉交換機由一對連接到兩個或更多脊交換機的鏈接連接起來，ECMP組定義了將每個或每組葉交換機連接到給定脊交換機的鏈接對或者鏈接組。集群作為一個整體有多個到外部路由的連接，如圖中的葉交換機3和4所示。圖39中沒有顯示的事實是，SD-Fabric運行在ONOS之上，ONOS本身是為了可用性而構建的。在如下所示的配置中，ONOS(以及SD-Fabric控制應用程序)在3到5個服務器上都有副本。

圖39. 通過dual-homing、鏈路綁定和ECMP組的組合實現高可用性。

鏈路聚合和ECMP的用處很明顯，可以增強包轉發機制，在一組(如一對)鏈路(出口端口)之間實現負載均衡，而不只有一個"最佳"出口鏈路(出口端口)。這既提高了帶寬，又在發生單個鏈路故障時可以自動恢復。另一種情況是交換機轉發流水線支持端口組，因此一旦建立了等價鏈接，就可以一直為數據平面服務。

明確的說，ECMP是SD-Fabric在網絡中的所有交換機上統一應用的一種轉發策略。SD-Fabric控制程序感知拓撲，并相應的將端口組推送到每個網絡交換機上，然后交換機將這些端口組應用到其轉發流水線中，流水線通過端口組轉發數據包，不需要控制平面的額外參與。

最后，在可擴展性方面，SD-Fabric擁有支持多達120k路由和250k流表的能力。該配置包括兩個脊交換機和八個葉交換機，后者意味著支持多達四個機架的服務器。與可用性一樣，SD-Fabric的可擴展性直接得益于ONOS的擴展能力。

7.2 段路由(Segment Routing)

上一節重點介紹了SD-Fabric的功能，本節主要討論如何才能做到這一點。SD-Fabric的核心策略基于 段路由(Segment Routing, SR) 。"segment routing"一詞來源于這樣一種想法: 任意一對主機之間的端到端路徑可以由一組段序列構建，即使用標簽交換沿著一段端到端路徑遍歷一組段序列。Segment routing是一種通用源路由方法，可以通過多種方式實現。對于SD-Fabric，segment routing利用了MPLS(Multi-Protocol Label Switching) 轉發平面，細節可以參考網絡信息。

當應用于葉棘網絡時，總是涉及兩個部分: 從葉到棘和從棘到葉。SD-Fabric為交換機編寫程序，以匹配有標簽或無標簽數據包，并根據需要插入或彈出MPLS標簽。圖40說明了SR如何在SD-Fabric中工作，通過簡單的配置在一對主機(10.0.1.1和10.0.2.1)之間轉發流量。本例中，與Leaf 1相連的服務器在10.0.1/24子網中，與Leaf 2相連的服務器在10.0.2/24子網中，每個交換機都分配了一個MPLS id: 101、103、102和104。

圖40. 用于在一對主機之間轉發流量的Segment Routing示例。

當主機1發送目的地址為10.0.2.1的數據包時，默認情況下被轉發到服務器的ToR/葉交換機。Leaf 1匹配目的IP地址，了解到這個包需要穿過網絡并在Leaf 2出現以到達子網10.0.2/24，因此將MPLS標簽102壓到包上。因為有了ECMP, Leaf 1可以將產生的數據包轉發到任意一個脊交換機，此時交換機匹配MPLS標簽102，彈出標簽頭，并將其轉發到Leaf 2。最后，Leaf 2匹配目的IP地址并將數據包轉發給主機2。

從該示例中可以了解到，SR是高度格式化的。對于給定的葉脊交換機組合，SD-Fabric首先分配所有標識符，每個機架配置為共享一個IP前綴并在同一個VLAN上。SD-Fabric預計算可能的路徑，并在底層交換機中配置相應的match/action規則。ECMP負責處理多路徑負載均衡的復雜性，它同樣不感知任何端到端路徑。從實現角度來看，實現SR的SD-Fabric控制程序將這些match/action規則傳給ONOS, ONOS反過來將它們配置在底層交換機上。SD-Fabric還維護自己的Atomix map，以管理連接葉脊交換機的ECMP組。

7.3 路由和多播(Routes and Multicast)

除了在葉交換機之間建立數據路徑的Segment Routing之外，SD-Fabric還利用了第6章介紹的Route和Mcast服務，它們決定每個IP前綴都有哪些葉脊交換機為其服務，以及在哪里能找到連接到每個多播組的所有主機。

SD-Fabric不通過類似OSPF或者PIM這樣的分布式協議來學習路由以及構建組播樹。相反，它根據全局信息計算出正確答案，然后將映射推送到Route和Mcast服務。因為SD-Fabric強加了簡化約束，即每個機架恰好對應一個IP子網，因此這么做很簡單。

為了更具體討論問題，考慮到在第6章中描述的所有ONOS服務都可以通過RESTful API調用，或者通過封裝了REST的GET、POST和DELETE調用的CLI調用。下面通過CLI來舉例說明(因為更容易理解)，可以通過查詢Route Service了解現有路由，如下所示:

onos > routes

B: Best route, R: Resolved route

Table: ipv4
B R  Network            Next Hop        Source (Node)
     0.0.0.0/0          172.16.0.1      FPM (127.0.0.1)
> *  1.1.0.0/18         10.0.1.20       STATIC
> *  10.0.99.0/24       10.0.1.1        FPM (127.0.0.1)
  *  10.0.99.0/24       10.0.6.1        FPM (127.0.0.1)
   Total: 2

Table: ipv6
B R  Network                   Next Hop                  Source (Node)
> *  2000::7700/120            fe80::288:ff:fe00:1       FPM (127.0.0.1)
> *  2000::8800/120            fe80::288:ff:fe00:2       FPM (127.0.0.1)
> *  2000::9900/120            fe80::288:ff:fe00:1       FPM (127.0.0.1)
  *  2000::9900/120            fe80::288:ff:fe00:2       FPM (127.0.0.1)
   Total: 3

可以給Route Service添加一個類似的靜態路由:

onos > route-add < prefix > < nexthop >
onos > route-add 1.1.0.0/18 10.0.1.20 
onos > route-add 2020::101/120 2000::1

需要注意一點，路由有兩種可能的源，一種是STATIC，意味著SD-Fabric在插入路由時完全知道它分配給集群中每個機架的前綴。(運維人員也可以使用CLI添加STATIC路由，但這只是一個例外，而不是規則。)

第二種源是FPM。FPM(轉發平面管理器, Forwarding Plane Manager)是另一個ONOS服務，屬于SD-Fabric服務套件之一。它負責從外部源學習路由，輸入給被配置為BGP鄰區的本地Quagga進程。每當FPM學習到外部路由，就會向Route Service添加相應的基于前綴的下一跳映射，表明通過連接網絡和上游的葉交換機(例如圖39中的交換機3和4)，目的地前綴是可達的。

多播的情況與此類似，使用同樣的ONOS CLI可以創建新的多播路由并添加聚合器。例如:

onos > mcast-host-join -sAddr *
    -gAddr 224.0.0.1
    -srcs 00:AA:00:00:00:01/None
    -srcs 00:AA:00:00:00:05/None
    -sinks 00:AA:00:00:00:03/None
    -sinks 00:CC:00:00:00:01/None

該示例指定ASM (Any-Source Multicast) (sAddr *)、組播組地址(gAddr)、組源地址(srcs)和組聚合地址(sinks)。聚合地址可以通過如下指令移除:

onos > mcast-sink-delete -sAddr *
    -gAddr 224.0.0.1
    -h  00:AA:00:00:00:03/None

這里同樣沒有運行PIM，但是SD-Fabric為網絡運維人員提供了編程接口，通過一系列這樣的調用來定義多播樹。例如，當SD-Fabric作為向訂戶發送IPTV的接入網絡的一部分運行時，一種選擇是讓運營商機頂盒發出類似上面所示的調用(當然，使用RESTful API而不是CLI)。另一種選擇是讓機頂盒發送IGMP消息，SD-Fabric通過Packet Service(類似于攔截ARP和DHCP報文的Host Service)攔截IGMP消息。因此，當你下一次使用電視遙控器轉換頻道時，可能就在本書介紹的SDN軟件棧上觸發了過程調用!

7.4 定制轉發(Customized Forwarding)

SD-Fabric是SDN的典型用例，它是一組運行在網絡操作系統(Network OS)上控制程序，這些控制程序又運行在一組可編程交換機上，這些交換機以葉脊拓撲的架構連接，每個交換機運行本地交換機操作系統。通過這種方式，SD-Fabric位于自下而上的SDN軟件棧的頂點。

但如果我們從一開始就知道支持SD-Fabric特性集的葉脊網絡正是我們想要的，那么可能會回到較低的層級，并以此為目的進行調整。隨著時間的推移，這就是SD-Fabric所發生的情況，產生了一個名為fabric.p4的P4程序實現了定制轉發平面。我們通過對fabric.p4的概要總結來結束本章，重點介紹其設計如何與軟件棧的其他部分相結合。

在此之前，必須認識到，一開始就清楚知道想從網絡中獲得什么是非常高的標準。網絡的發展基于使用和運維的經驗，沒人從一開始就知道如何編寫fabric.p4，但在整個軟件棧的其他層實現了一系列迭代之后(包括引入Tofino作為可編程轉發流水線)，fabric.p4出現了。 關鍵點是，可編程平臺使我們能夠不斷、快速的實現網絡的演進 。

換句話說，我們在第4章中提到的forard.p4是"按照我們想要的方式定制轉發平面"的典型例子，但該章剩余部分都在討論無需重新實現特定網絡的功能使forward.p4成為可能的所有機制。簡言之，fabric.p4是forward.p4的一個具體例子，不過我們現在只介紹了它與控制平面的關系。

關于fabric.p4有三件事情值得注意。首先，雖然它基于Broadcom OF-DPA流水線，但是松耦合的。這很有意義，因為SD-Fabric最初是在一組基于Tomahawk的交換機上實現的。fabric.p4流水線比OF-DPA更簡單，消除了SD-Fabric不需要的表，從而使得fabric.p4更容易控制。

其次，fabric.p4被設計來模擬ONOS的FlowObjective API，從而簡化了將FlowObjective映射到P4Runtime的過程。圖41顯示了fabric.p4的入口流水線，雖然沒有顯示出口流水線，但在一般情況下，只是對頭字段的簡單重寫。

圖41. 由fabric.p4支持的邏輯流水線，用于對FlowObjective API的Filtering, Forwarding和Next階段的并行處理。

最后，fabric.p4被設計為可配置的，從而可以有選擇的包含額外的功能。在編寫基于ASIC的轉發流水線進行優化的代碼時，這并不容易，而且在實踐中會大量使用預處理條件(例如，#ifdefs)。下面顯示的代碼片段是fabric.p4的入口函數的主要控制塊。第9章將在較高層次上更深入討論下面這些可選擴展:

• UPF(用戶平面功能, User Plane Function): 增強IP功能，支持4G/5G移動網絡。
• BNG(寬帶網絡網關, Broadband Network Gateway): 增強IP功能，支持光纖到家。
• INT(帶內網絡遙測, Inband Network Telemetry): 增加度量收集和遙測輸出指令。

apply {
#ifdef UPF
    upf_normalizer.apply(hdr.gtpu.isValid(), hdr.gtpu_ipv4,
 hdr.gtpu_udp, hdr.ipv4, hdr.udp, hdr.inner_ipv4,
 hdr.inner_udp);
#endif // UPF

    // Filtering Objective
    pkt_io_ingress.apply(hdr, fabric_metadata, standard_metadata);
    filtering.apply(hdr, fabric_metadata, standard_metadata);
#ifdef UPF
    upf_ingress.apply(hdr.gtpu_ipv4, hdr.gtpu_udp, hdr.gtpu,
 hdr.ipv4, hdr.udp, fabric_metadata, standard_metadata);
#endif // UPF

    // Forwarding Objective
    if (fabric_metadata.skip_forwarding == _FALSE) {
        forwarding.apply(hdr, fabric_metadata, standard_metadata);
    }
    acl.apply(hdr, fabric_metadata, standard_metadata);

    // Next Objective
    if (fabric_metadata.skip_next == _FALSE) {
        next.apply(hdr, fabric_metadata, standard_metadata);
#if defined INT
        process_set_source_sink.apply(hdr, fabric_metadata,
     standard_metadata);
#endif // INT
    } 
#ifdef BNG
    bng_ingress.apply(hdr, fabric_metadata, standard_metadata);
#endif // BNG
}

例如，upf.p4(未顯示)實現了UPF擴展的轉發平面，支持包括3GPP蜂窩網絡標準要求的GTP隧道封裝/解封裝，將SD-Fabric網絡連接到無線接入網絡基站。同樣，bng.p4(未顯示)實現PPPoE終端，一些無源光網絡部署通過它將SD-Fabric網絡連接到家庭路由器。最后，這段沒什么實際意義的代碼片段介紹了fabric.p4核心功能的基本結構。首先應用 filtering對象 (filtering.apply)，然后應用 forwarding對象 (forwarding.apply和acl.apply)，最后應用 next對象 (next.apply)。

除了選擇包含哪些擴展之外，預處理器還定義了幾個常量，包括每個邏輯表的大小。顯然，這種實現是構建可配置轉發流水線的底層方法。設計更高級的語言結構，包括在運行時向流水線動態添加功能的能力，還是一個未完成的研究課題。

審核編輯：郭婷