PMC volt v1.0 Getting started

Size: px

Start display at page:

Download "PMC volt v1.0 Getting started"

Darren Hunter
5 years ago
Views:

1 PMC volt v1.0 Getting started

2 Table of Contents 1. Introduction Setup Hardware Virtual machine In band management Package deployment and compilation Package usage Ports numbering and state OF controller Supported OF APIs Add/Remove flow: Add meter Packet In Packet Out Suggested use case Table of Figures Figure 1: PON system scheme... 4 Figure 2: Hypervisor vswitch... 5 Figure 3: In-band management DIP switch... 6 Figure 4: VID flows diagram

3 1. Introduction PMC_vOLT is a SW package which includes full PMC OLT API driver and management application for PMC OLT system. The package also includes support for open flow 1.3 protocol. This release will provide support for a subset of OF 1.3 APIs which will enable: Triple play traffic between OLT and ONUs (flows defined by VLAN ID) Forwarding a set of networking protocols to OF controller (DHCP, EAPOL and IGMP) QoS by providing rate limiting abilities. 3

4 2. Setup This section contains description of the environment that was used to develop and test volt package. 2.1 Hardware 1 x PAS5211 OLT 2 x PAS7401 ONU 1 x 1:8 PON splitter 1 x 10G traffic port (OLT side) 2 x 1G traffic ports (ONU side) VM running PMC_vOLT eth1 10G interface Figure 1: PON system scheme 4

5 2.2 Virtual machine Compilation and execution of PMC_vOLT binary was done on a Linux virtual machine running on a VMware hypervisor. This project can be deployed, compiled and run on every Linux computer with Ethernet connectivity. We choose to run it on a virtual machine on VMware hypervisor. However this project can be run using any hypervisor and using any Linux distribution. It might be simpler to initially deploy and compile the project on a Linux machine without a hypervisor, to rule out environment issues. Our virtual machine is running 32-bit Ubuntu Linux distribution (Linux version generic). GCC version is Note that VM must have 2 separate NICs, one for communication with the LAN and another one for communication with OLT. Below screenshot shows VM networking configuration, where ubuntu and ubuntu2 are 2 virtual machines each machine has 2 virtual ports connect to vswitch0 and vswitch1. vswitch0 is used for communication with LAN and vswitch1 is used for OLT management traffic. Figure 2: Hypervisor vswitch 5

2.3 In band management This delivery contains support for in-band OLT management, thus host interface should be connected to the OLT s CNI port (Xenpack).

6 2.3 In band management This delivery contains support for in-band OLT management, thus host interface should be connected to the OLT s CNI port (Xenpack). On our development setups we used a media converter, host management was connected to the VM s Ethernet NIC and converted to 10G fiber. Management traffic should be combined with traffic generator port traffic using a 10G optic switch. Enabling support of in-band management at PAS5211 OLT requires DIP switch DP2:4 to be modified to 1 (off), see below image: Figure 3: In-band management DIP switch 6

7 3. Package deployment and compilation Follow these steps to compile the package: 1. Unzip the attached zip file to your desired <release root> directory. 2. Navigate to <release root>/ivs_master 3. Enter make command Note: PMC_vOLT package compilation has dependencies on several linux libraries which should be present before first compilation. These dependencies can be easily resolve by installing the required packages using apt-get application. Command: apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev pkg-config python-tz libpcapdev openvswitch-datapath-dkms 7

8 4. Package usage Follow these steps to run PMC_vOLT application: 1. Compile PMC_vOLT package according to above instructions. 2. Navigate to <release root>/ivs_master/targets/ivs/build/gcc-local/bin 3. Before first run of the application, openvswitch kernel object must be loaded (modprobe openvswitch). 4. Execute./ PMC_vOLT c <OF controller address and port>. Notes: The application assumes that management port is connected to interface eth1 of the VM. For further detail about OF controller and port see controller chapter of this document. 8

9 5. Ports numbering and state PMC_vOLT handles OLT+ONUs system as an OF switch with 130 ports as described in below table: Port number Description Notes ONU ports mapped to 4 channels of the device 1-32 Channel 0, ONUs Channel 1, ONUs Channel 2, ONUs Channel 3, ONUs 0-31 Flows between 2 ONU ports are not supported, only flows between OLT port and an ONU ports or between an ONU port and the controller s port are supported. 129 OLT port 0xfffffffd Controller port This port should be used as destination port for special protocols (DHCP, EAPOL and IGMP) forwarding flows. 9

10 6. OF controller PMC_vOLT s support for OF 1.3 was tested with several OF controllers (opendaylight, floodlight and RYU). Testing phase of the package was done using RYU controller. The controller s IP address and port should be specified on PMC_vOLT application launch by using c switch followed by the controller s IP address and port. During development controller was activated on the same VM as PMC_vOLT was running on, so we used :6633 as controller address. Running PMC-vOLT and OF controller on different VMs was also tested. 10

11 7. Supported OF APIs Below list of OFAPIs were implemented on PMC volt system, API usage was limited to below list. 7.1 Add/Remove flow: This API should be used for 2 purposes: 1. Creating VID based flows for triple play services traffic. These flows will only inspect packet s VLAN ID value, possible flow topologies are between OLT (#129) port and ONU (#1-#128) ports (DS traffic) or between an ONU port to OLT port (US traffic). 2. Creating protocols forwarding flows towards the controller. Four possible matches are supported for special protocols see below table, possible flow topology is between ONU (#1- #128) ports and the controller s port (0xfffffd). OF API name Required fields Valid values Notes FlowMod Cookie 64 bit value API structure cookie mask Only supported mask is ALL BITS (64 1 s). command 0x0 (Add) or 0x3 (Delete) out_port or 0xfffffffd Match See below table for possible options for this structure. Instruction See below table for possible options for this structure. 11

12 Match options (OXM TLV structure) OF structure Required fields Valid values Notes OXM TLV for VID flows in_port vlan_vid OXM TLV for DHCP flows in_port DHCP requests are expected eth_type 0x800 ip_proto 17 udp_dst OXM TLV for EAPOL flows in_port eth_type 0x800 OXM TLV for IGMP flows in_port eth_type 0x800 ip_proto 2 from ONUs to OLT so udp_dst 67 can only be used when src_port is DHCP replies are expected from OLT to an ONU so OLT so udp_dst 68 can only be used when src_port is 129. Instruction options (Instruction structure, action structure) OF structure Required fields Valid values Instruction for VID flows type 0x4 (ApplyActions) without a meter action.type 0 (output) action.output.port Instruction for VID flows type 0x4 (ApplyActions) including a meter (QoS action.type 0 (output) support) action.output.port type 0x6 (Meter) meter.meter_id Instruction for protocols flows type 0x4 (ApplyActions) action.type 0 (output) action.output.port 0xffffffd Note: Flow removal is still not stable, removal operations can be performed successfully but in some cases result may be unpredictable. 12

13 7.2 Add meter This API should be used to create meters (24 meters are currently supported in PMC_vOLT). This is a preliminary step to creation of QoS flows. Once a meter is created it can be bound to a VID flow and have the flow s traffic limited to the rate specified by the meter. A single meter can be used by different flows, meter id is used as a profile for the QoS, if a certain profile is used on two flows each one of them will get the rate specified by the meter id independently and will not share it. OF API name Required fields Valid values Notes MeterMod Command 0 (Add) API structure Flags 0x0001 (kbps) meter_id drop.rate 32 bit value indicating rate in kbps (kilo-bit) which above it traffic will be discarded. 7.3 Packet In Packet in is implemented in PMC_vOLT, in case a packet should be forwarded to the controller PacketIn API will be invoked towards the controller. OF API name Required fields Expected values Notes PacketIn Buffer No buffer API structure reason 0x1 (Action) tbl_id 0 in_port match Match structure according to packet type (identical to add protocol flow s match). In case the packet is tagged VLAN ID will also be updated. data The packet itself cookie Cookie of corresponding flow which forwarded the packet. 13

14 7.4 Packet Out Packet out is expected to be used by other external applications for management purposes (sending DHCP reply, IGMP queries etc.) OF API name Required fields Expected values Notes PacketOut Buffer No buffer API structure in_port 0xfffffffd action.type 0 (output) action.output.port Data The packet itself Important note for all APIs: Using OF APIs not specified in above list, or usage of APIs from above list with fields which are not specified in the list may result with unexpected results and is not advised. The value of API fields not specified in above tables is assumed to be 0. 14

15 8. Suggested use case A reference application for RYU controller (PON_topology.py) is attached to this release. This application performs several actions upon PON_vOLT switch connection to OF controller: Create 4 meters for QoS future use self.add_meter(datapath, 11, 1000) self.add_meter(datapath, 22, 2000) self.add_meter(datapath, 23, 3200) self.add_meter(datapath, 24, 8000) Define triple-play services PORT 1 services (VID 101 for provisioned service A, VID 201 for non-provisioned service B and VID 301 for non-provisioned service C) self.add_vid_flow(datapath,1000, 1, 129, 101, 11) self.add_vid_flow(datapath,1001, 129, 1, 101, 23) self.add_vid_flow(datapath,1002, 1, 129, 201) self.add_vid_flow(datapath,1003, 129, 1, 201) self.add_vid_flow(datapath,1004, 1, 129, 301) self.add_vid_flow(datapath,1005, 129, 1, 301) PORT 2 services (VID 102 for provisioned service A, VID 202 for non-provisioned service B and VID 302 for non-provisioned service C) self.add_vid_flow(datapath,1006, 2, 129, 102, 22) self.add_vid_flow(datapath,1007, 129, 2, 102, 24) self.add_vid_flow(datapath,1008, 2, 129, 202) self.add_vid_flow(datapath,1009, 129, 2, 202) self.add_vid_flow(datapath,1010, 2, 129, 302) self.add_vid_flow(datapath,1011, 129, 2, 302) 15

16 Below diagram shows 12 VID based flows configured to support triple play for 2 ONUs in both directions. VID 101 VID 101 VID 201 VID 201 VID 301 VID 301 VID 101 VID 101 VID 201 VID 201 VID 301 VID 301 ONU1 VID 101 VID 101 VID 201 VID 201 VID 301 VID 301 Traffic generator VID 102 VID 102 VID 202 VID 202 VID 302 VID 302 OLT VID 102 VID 102 VID 202 VID 202 VID 302 VID 302 ONU2 VID 102 VID 102 VID 202 VID 202 VID 302 VID 302 Traffic generator Figure 4: VID flows diagram Define special protocol handling PORT 1 DHCP self.add_dhcp_flow(datapath,1012, 1, 67) PORT 1 IGMP self.add_igmp_flow(datapath,1014, 1) PORT 1 EAPOL self.add_eapol_flow(datapath,1015, 1) PORT 2 DHCP self.add_dhcp_flow(datapath,1016, 2, 67) PORT 2 IGMP self.add_igmp_flow(datapath,1018, 2) PORT 2 EAPOL self.add_eapol_flow(datapath,1019, 1) 16

17 Server side DHCP self.add_dhcp_flow(datapath,1020, 129, 68) Server side IGMP self.add_igmp_flow(datapath,1021, 129) Server side EAPOL self.add_eapol_flow(datapath,1022, 129) Detailed implementation of the above functions can be found in reference application: <release root>/ryu apps/pon_topology.py 17

Outline. SDN Overview Mininet and Ryu Overview Mininet VM Setup Ryu Setup OpenFlow Protocol and Open vswitch Reference

Outline. SDN Overview Mininet and Ryu Overview Mininet VM Setup Ryu Setup OpenFlow Protocol and Open vswitch Reference 1 Mininet and Ryu 2 Outline SDN Overview Mininet and Ryu Overview Mininet VM Setup Ryu Setup OpenFlow Protocol and Open vswitch Reference 3 SDN Overview Decoupling of control and data planes Directly Programmable