ONF Atrium 분석

ONF Atrium 분석 - Atrium Apollo Project

2015. 07.06.㈜파이오링크

SDN개발실 정병화 [email protected]

© PIOLINK, Inc. SDN No.1

목차

●Atrium 개요 ○Atrium Apollo Project ○Atrium 실험

●Deep Dive○Flow Objective○Atrium Apollo Project in ODL

●Appendix○Atrium Apollo: BGP Peering 요구사항 ○OF-DPA○FPM

2


목차 설명

●Atrium 개요 ○Atrium Apollo Project

■Atrium의 첫번째 release target - BGP peering에 대한 설명

○Atrium 실험■Atrium ONOS의 설정 방법 및 Mininet과의 연동 설명

●Deep Dive○Flow Objective

■Atrium의 내부 동작 중 Flow install을 abstraction 한 것에 대한 설명

○Atrium Apollo Project in ODL ■ODL에 Atrium Apollo Project 적용 ■BGP Peering 구현에 대한 내부 구조 및 동작을 설명

●APPENDIX○Atrium Apollo: BGP Peering 요구사항 ○OF-DPA

■Broadcom chip의 TTP 설명

○FPM■Quagga의 Zebra와 연동하는 모듈 설명 ■SDN에 Legacy routing protocol을 연동하기 위한 연구라고 볼수 있음

3


Atrium 개요

4


▪ 현재, SDN 기술 도입의 2가지 어려움▪ Integration : 다양한 SDN stack과 application의 이식성 ▪ Interoperability : 다양한 Vendor의 스위치 사이의 호환성

Atrium’s 배경

5

User가 Application을 빠르고 유용하게 사용할 수 있도록 해줌

User가 동일한 사용목적으로 다른 Hardware switch를 선택 가능하게 해줌


Atrium’s 목적

● 목적○ Integration과 Interoperability 문제를 해결하기 위한 Project

● 정의○ Atrium은 하나의 완전한 SDN stack을 이루도록 open source

components를 수직적으로 통합한 set 임.

● 특징○ Network operator들이 원하는 deployable use-cases 이 target.

■ Deployment 시나리오, 요구사항 도출 ■ Appendix A. 참조

○ 첫번째 target - Apollo project.○ Atrium은 Linux distribution과 유사한 첫 full open source SDN distribution

6


Atrium Open SDN Stack

7


Atrium Apollo Project

Atrium 개요

8


Apollo Project

● Major Network operator들이 SDN 기술을 이용하여 BGP peering router를 deploy 하는 것을 희망함.

● "첫번째 Release는 BGP peering router를 이용한 대륙간의 연결이 Target"

9


Apollo Project’s Reference Stack

● Apollo release를 위해 다음의 components들이 reference stack으로 정함.○ The open source BGP implementation : Quagga○ The open source OpenFlow Controller : ONOS○ Two OpenFlow switch distribution:

■ Whitebox● Broadcom Trident+ silicon● ONL operation system● Indigo OpenFlow 1.3 agent● OF-DPA TTP for controller driver and switch agent

■ Corsa● FPGA based switching silicon● Linux operating system● OVS as an OF agent with Corsa extensions for supporting Corsa Hardware● Corsa TTP for controller driver and switch agent

10


Data Plane Switch Component

● A open source instance from the Apollo data plane○ Switching hardware from the Open Compute Project (OCP)○ Open Network Linux (ONL) as the open Operating System from OCP○ ONIE - an OS loading tool from the OCP○ Broadcom (BRCM) switching ASIC and it’s proprietary SDK○ OF-DPA 1.0 an open switch API exposed by Broadcom○ Indigo OpenFlow 1.3 client that provides OpenFlow based access to the TTP

exposed by OF-DPA 1.0

11


Data Plane Switch Plugin Architecture

● Atrium은 open-source component를 지양하지만, 동시에 open interface를 통해 proprietary component를 수용함.

● Open interface○ OpenFlow protocol v1.3○ Table Type Pattern (TTP)

12


SDN Controller Component

● Atrium Apollo project의 컨트롤러 요구사항○ OpenFlow 1.3○ Table Type Patterns (TTPs) as a SouthBound interface○ I-BGP as a NorthBound interface

13


Atrium TTP Driver 지원 현황

14

Driver 등록

Driver Source

1. CentecV350Pipeline.javaa. Centec's V350 switches

2. CpqdOFDPA1Pipeline.javaa. Corsa

3. CpqdOFDPA1Pipeline.javaa. software switch emulation of the OFDPA 1.0 pipeline.

4. DefaultSingleTablePipeline.javaa. Simple single table pipeline abstraction.

5. OFDPA1Pipeline.javaa. Broadcom's OF-DPA v1.0 TTP

6. OLTPipeline.javaa. Simple single table pipeline abstraction.

7. OVSCorsaPipeline.javaa. OpenvSwitch emulation of the Corsa pipeline handler.

8. PicaPipeline.javaa. Pica pipeline handler.

9. SoftRouterPipeline.javaa. Simple 2-Table Pipeline for Software/NPU based routers.

10. SpringOpenTTP.javaa. SPRING-OPEN pipeline.

11. SpringOpenTTPDell.javaa. Spring-open driver implementation for Dell hardware

switches.


Table Type Pattern : TTP

● 정의 ○ TTP는 컨트롤러가 OpenFlow-Switch protocol을 경유해서 specific switch forwarding behavior를 전송 할

수 있는 abstract switch model 임.

● TTP 기반의 approach’s motivation○ 기존의 다양한 hardware switch를 더 잘 수용하기 위해○ hardware switch의 future innovation 이 가능하도록 ○ app/controller 개발자와 switch vendor 사이의 정확한 communication을 위해○ app/controller 와 switch 사이의 automated communication을 위해

● 특성○ A TTP is a text file.

■ OpenFlow logical switch에서 지원되는 flow table, flow_mods, group_mods, meter_mods를 설명하는 text.

■ JSON style.○ TTP framework는 OpenFlow framework의 optional enhancement○ TTP는 더욱 복잡한 forwarding behavior를 가능하게 함 ○ TTP는 multiple table을 사용할 수 있는 환경에서 가장 유용할 것이라 기대됨, 특별히 forwarding device

가 ASIC 기반인 경우.○ TTP는 NDM (Negotiable Datapath Model) 의 first type.

■ TTP와 같은 Switch model의 구조는 OpenFlow protocol이 진화 함에 따라서 상당히 진화 할 것임.■ 미래 Switch model은 OpenFlow spec기반의 table-centric으로 진화 할 것임.■ 이러한 것을 NDM : Negotiable Datapath Model 이라고 부름

15


Table Type Pattern : TTP

▪ Example TTP Description: L2-L3-ACLs

16


TTP for Broadcom’s OF-DPA 1.0 Peering Router

17


TTP for Corsa’s Peering Router

18


Controller Routing Application

▪ I-BGP Speaker▪ Quagga BGP와 I-BGP 통신하기 위한 Lightweight implementation

▪ RIB▪ E-BGP로 부터 수신한 route

▪ FIB Listener▪ switch hardware에 flows를 install 하는 역할

▪ BGP-OF Encap/Decap▪ Quagga BGP의 E-BGP session을 위한 packet 제어

19


Controller Routing Application

20


Atrium 실험

Atrium 개요

21


Atrium 설치

● Atrium 설정정보 ○ git clone https://github.com/dtalayco/atrium-onos.git

●

22

onos + atrium package 설치


Atrium 설정

23

● address.json: router로서 동작할 수 있도록 port에 IP address, vlan 정보를 설정● sdnip.json: BGP connection을 설정

○ bgpSpeakers: Local interface address.○ bgpPeers: Remote bgp peer address.


Atrium 설정

24

● org.onosproject.openflow.controller.impl.OpenFlowControllerImpl.cfg○ OVS switch의 DPID와 Corsa driver와 Mapping 설정

● org.onosproject.provider.lldp.impl.LLDPLinkProvider.cfg○ Link discovery packet을 비활성화 시킴 - Static으로 port정보를 입력했기 때문.

● routerconfig.json○ Switch와 Corsa driver를 map 설정

● atriumbgp○ ONOS instance에서 실행되어야 하는 application들을 설정

root@atrium:~$ onos-topo-cfg localhost routerconfig.json - 적용


Atrium 실험

● mininet 이 실행되는 PC에 v2.3.1 버전의 ovs 설치 ○ corsa TTP 지원함

25

Mininet을 통해 switch-host를 만들고 onos 컨트롤로에 접속

ONOS 컨트롤러에서 실행되어 있는 Apps과 OpenFlow device를 확인

정상적으로 onos-atrium과 ovs가 연결이 되었다면, onos 컨트롤러는 ovs에 Corsa pipeline driver를 통해 23개의 pipeline 초기 flow rule을 내려야 함.


Atrium 설정 - 제약사항

● BGP control plane 트래픽을 Packet in 메시지를 통해서 Quagga instance와 통신하는 것은 현재 논의 중 ○ Data path -> Controller -> Packet-in -> internal OVS -> Quagga instance○ 이러한 Architecture는 미래에 Update 될 예정.

● 현재 공개자료에서는 Quagga instance를 생성하고 ONOS instance와 connection하는 것을 다루지 않음.

● 현재로서는 BGP Peering 시험하기에는 힘든 상황.

26


Flow Objective

Deep Dive

27


Flow Objective 개요

● �Flow Objective Service

○ SDN Application들이 다양한 종류의 TTP Driver를 인지하지 않고 general하게

flow rule을 install하기 위한 abstraction.

○ Switch chip마다 TTP에 대한 multiple table mapping이 다르기 때문에 동일한

route path에 대해서 flow rule의 형태가 다름.

● 특징

○ �이러한 abstraction은 flow rule을 install하는 Application을 제작시 더욱 편리함

○ Flow Objective Manager는 새로운 driver를 제작하여 적용하는데 편리함을 제공

○ �The first attempt at achieving interoperability between OF 1.3

implementations

○ Idea of {app/flow-obj/driver} may be portable to other controllers■ ODL에 적용 진행중

28


Why Are We Here?

29

© PIOLINK, Inc. SDN No.1 30


ONOS Architecture

31


Flow Objectives

● Flow Objectives는 3가지 모듈로 구성됨

○ 1. Filtering Objective

○ 2. Next Objective

○ 3. Forwarding Objective

● Flow objective는 flow를 스위치에 전달하는 SDN application의 objective(or

intention)을 나타냄.

○ 즉, routing entry라고 볼 수 있음.

32


1. Filtering Objective

● Filter는 특정 조건에 대한 Permit or Deny 을 구분함. ● match fields라고 할 수 있음.

33


2. Next Objective

34

● Next은 forwarding에 대한 nexthop임.● OpenFlow의 group이라 할 수 있음.


3. Forwarding Objective

● Forwarding: { S → T } or { Selector → Next Id }

● Forwarding type

○ Specific: MAC, IP, MPLS forwarding table

○ Versatile: ACL table

● Next Id get resolved to whatever the driver previously did with

corresponding Next Objective.

35


Flow Objective Manager

36


Atrium Apollo Project in ODL

Deep Dive

37


Proposed SDN Stack

38


Physical Topology View

39


Simple BGP Application Setup (Ref: SDN-IP)

40


BGP Peering Session Establishment

41


BGP Application - Controller System View for Route Update Handling

42


NIC alternative - How GBP can be enabled for BGP Application (Conceptual View)

43


How GBP can leverage DIDM (Conceptual View)

44


BGP Application Detailed View (Ref: ONOS SDN-IP, BGP Router) : Startup - ONOS Flow

45


BGP Application Detailed View (Ref: ONOS SDN-IP, BGP Router) : FIB Update - ONOS Flow

46


Atrium Apollo: BGP Peering 요구사항

Appendix A.

47


A.1 Atrium Apollo Deployment Scenario

48


A.2 Peering Router Requirements

● E-BGP peering with multiple BGP peers ● 25K routes in FIB ● Resolve next-hop IPs for routes received by BGP, and forward traffic based on IP

destination/prefix to the next hop. ● ARP & ICMP handling ● Vlan handling for vlan-ids assigned to switch interfaces ● Drop the following traffic

○ traffic with dst MAC that does not correspond to interface MAC addresses or router- loopback interface MAC address

○ traffic on VLANs other than ones configured for the interfaces ○ untagged traffic ○ all Ethernet traffic that is not ARP and not IPv4 (for example, this will drop IPv6 traffic) ○ all IPv4 traffic that does not match in the FIB and is not destined to the Router IP

addresses (interface or loopback) ○ Multicast traffic

49


A.32 Extensibility Scenarios

50


OF-DPA(OpenFlow Data Path Abstraction)

Appendix B.

51


OF-DPA 개요

● 목표○ Broadcom device들이 programmable가능한 OpenFlow protocol을 사용하여

OpenFlow Logical Switch로서 동작하는 것

● 특징 ○ OpenFlow Spec 기반으로 구현됨○ OpenFlow abstract switch model: OpenFlow Data Plane Abstraction (OF-DPA)○ ASIC을 multiple table에 mapping하도록 provisioning 함 ○ 이것은 ONF OpenFlow - Table Type Pattern (TTP)에 정의한 표기법을 사용함

■ TTP를 사용한 목적은 다양한 OpenFlow switch들의 개발 및 이용을 일반화시키는 것이 용이하도록 하기 위함.

○ OF-DPA 2.0 abstract switch는 공식적으로 TTP를 사용하여 정의 되어짐.

● 버전 ○ OF-DPA 1.0

■ OpenFlow 1.3.1 기반 ■ 2014.2

○ OF-DPA 2.0 ■ OpenFlow 1.3.4 기반 ■ 2014.11

52


OF-DPA Software Component

● OpenFlow와 Broadcom switch ASICs 사이에 hardware adaptation layer 를 제공

53


OF-DPA Software Component

54

● API Layer○ Northbound OF-DPA APIs을 제공.○ CLI는 없고, RPC를 통해 API를 call하는 구조. ○ hardware setting후 caller에게 결과값 리턴.

● OFDB Layer○ flow, group, port table에 대한 software database○ table을 manage할 수 있는 API 제공○ 다음의 layer들이 OFDB API를 사용함

■ API● 저장: the management state of the system.● flow add/delete 와 같은 설정을 위해 사용

■ Mapping/Driver● 저장: port link 상태와 같은 system 상태정보.● Mappling/Driver는 hardware로부터 port 상태를 수신

후, OFDB의 port table을 update함.■ Datapath

● flow aging과 같은 것을 수행하기 위해 OFDB의 flow table을 traverse 함.

● Datapath Layer○ 정기적으로 wake up 하여 flow table을 traverse 하면서 flow aging

operation을 수행. ○ aged flow를 발견시, client application에게 notification함.

● Mapping/Driver Layer○ system mapping과 driver 함수를 제공.○ 모든 system 초기화가 여기서 진행됨.○ system startup시 driver, OFDB, datapath layer 가 초기화됨 ○ driver function은 Broadcom SDK 에 대한 abstraction layer 를 제공.○ driver layer는 (platform에 따라) OF-DPA가 요구하는 interface를 정의

함.● Platform Layer

○ platform specific structure 와 functions을 제공함.○ 이러한 function은 system startup 할때, invoke 됨.


OF-DPA + OpenFlow 1.3 Vs OpenFlow 1.0

● OpenFlow 1.0○ single table 지원 ○ L2, L3, ACL, QoS 같은 flow entry는 모두 하나의 Table에 저장됨.○ 이것을 수용할 수 있는 것은 hardware의 IFP (Ingress Filter Processor)이고, 최대 4K flow entry까지 지원할 수 있음. (Trident 2기준)

○ ECMP, Multicast를 지원할 방법이 없음.

● OpenFlow 1.3○ multiple table 지원 ○ OF-DPA는 OpenFlow의 multiple table이 multiple XGS pipeline hardware table에 mapping됨.

○ L2 table : 32K flow entry 저장.○ L3 table : 16K flow entry 저장.○ ACL and QoS table: IFP 안에서 4K flow entry 저장. ○ OF-DPA는 Group을 정의하여 ECMP, Multicast를 지원 가능함.

55


OF-DPA Switching Architecture

● L2 bridging + L3 Routing을 하기 위한 OF-DPA abstract switch pipeline ○ Broadscale Switching Architecture 요소를 OpenFlow Table로 전환○ OF-DPA는 switching fabric을 OpenFlow data-plane으로 사용할 수 있도록 abstraction 한 구조

56


Trident 2 - Pipeline Blocks

57

● CAP (Content Aware Processor)

○ fast filter processor or FP로 알려져 있음.

○ CAP와 FP는 ingress, egress or vlan content와 함께 수행

■ ICAP(Ingress CAP ), IFP(Ingress FP)

■ ECAP(Egress CAP), EFP(Egress FP)

■ VCAP(Vlan CAP), VFP(Vlan FP)

○ ACL, DiffServ, QoS를 제공하기 위해 설계됨

○ Packet의 MAC, IP, L4Port를 식별할 수 있음.

○ user-defined fields

■ Programmable packet processing.

■ DoS attack detection

■ Access Control List (ACL)

■ Separate ingress and egress Processing


FPM (Forwarding Plane Manager)

Appendix C.

58


FPM : Forwarding Plane Manager

● FPM is a subscription based API within the Quagga stack that steams

routing update information

● FPM의 동작

○ Routing protocol은 best path를 zebra에게 전송.

zebra는 이것들 중에서 best path를 계산하여 FIB를 선정.

○ FPM은 zebra로부터 FIB를 가져와서 API를 통해서 전송.

○ FPM의 Client들은 API를 통해서 FIB 를 수신.

59


FPM Diagram

60


FPM의 한계

● FPM is unidirectional

○ zebra의 best route만을 제공할 수 있음

○ Enumerates interfaces using SNMP OIDs

○ Is incomplete and requires further definition and work

61

� Quagga-0.99.22 버전에 FPM interface 구현- 2013.02.10 추가됨 - “zebra FIB push interface”- FPM well known TCP port 2620- 10 초 주기로 변경된(add/delete/update) FIB를 check하여 FPM server로 update 함- Quagga/NEWS에 FPM에 대한 언급 - "OpenFlow"

zebraFPM client FPM


Next Steps for FPM

● FPM은 bi-directional 되어야 함.

○ Bi-directionality는 Quagga로부터 추가, 삭제할 수 있는 interface를 고려

○ Bi-directionality는 zebra에 보낼 수 있는 routing update를 고려

○ Both could be done outside of FPM with a different interface

● FPM은 표준이 될 수 있음(?).

○ By creating a standard around FPM, any routing protocol suite could use it

allowing for easy interoperability with other applications.

62


참고자료

▪ Apollo: Atrium 1.0. Overview ▪ Anchor Stack Introduction▪ Atrium Architecture and Integration Guide▪ ONF: OpenFlow Table Type Patterns▪ ONF Atrium Project▪ Forwarding Plane Manager (FPM)▪ Flow objectives

63

모든 자료는 다음의 사이트에서 가져옴:https://groups.opensourcesdn.org/wg/Atrium/document

감사합니다.㈜파이오링크

서울시 금천구 가산디지털2로 98

(가산동 550-1) IT캐슬 1동 401호TEL: 02-2025-6900FAX: 02-2025-6901www.PIOLINK.com

64

Technology

ONF Atrium 분석