Monday, August 19, 2013

[Floodlight] A simle note from Floodlight dev discussion

For some kind of the reasons, I stopped tracking what's going on Floodlight for a while. I post my previous notes about Floodlight and OpenFlow from Floodlight dev discussion, and hope it is beneficial for those who are still working on it.
  • Floodlight by default gets full packets from switch
    • OFPT_SET_CONFIG

  • GreenMST module for Floodlight
    • GreenMST is a module used to build the Minimum Spanning Tree of an OpenFlow network, thus avoiding brodcast storm, using looped topologies with the LearningSwitch module and switches not supporting the Spanning Tree Protocol.
    • http://github.com/LucaPrete/GreenMST

  • Wildcard Matching on network address
    • OFMatch mTo = new OFMatch();
      mTo.fromString("dl_type=0x800,nw_dst=224.128.0.0/9");
      System.out.println(mTo.toString()); // This prints nw_dst as 224.128.0.0/9
      System.out.println(mTo.getNetworkDestinationMaskLen()); //This prints destination mask length as 9
      But when I do dump-flows in the switch, it doesn't show any mask. It simply gives nw_dst as 224.128.0.0.
       
  • Push static flows based on ingress ports
    • your forwarding would not work any more.  Reason is any packet coming to that port is forced out the same port, making LLDP no longer workable.  LLDP is needed for floodlight to learn topology and route/forward packets.

  • BDDP Topology Discovery
    • In BSN BDDP and BSNPROBE types were defined.  BDDP is used in TopologyDiscovery to detect non-OpenFlow broadcast domains.  BSNPROBE is not used in Floodlight now.

  • Disabling Flooding for a Switch Port
    • OFPortMod p = (OFPortMod) floodlightprovider.
      getOFMessageFactory().getMessage(OFType.PORT_MOD);
      p.setPortNumber((short) 4); // or your port number
      p.setConfig(config); // you have to enter the proper Integer to disable the port (see OpenFlow doc)
    • The setting is related with OFPPC_NO_FLOOD

  • No NAT in Floodlight now
  • Creating static flows in Floodlight
  • Northbound API
    • Right now all the decisions are made logically (load balancer, firewall) so they will never have to travel to other computers. As far as the ordering in which these are executed you can enforce some special ordering by returning something in the isCallbackOrderingPostreq methods supplied by the IFloodlightmodule interface. For instance in the firewall module we have...

      @Override
      public boolean isCallbackOrderingPostreq(OFType type, String name) {
          return (type.equals(OFType.PACKET_IN) && name.equals("forwarding"));
      }

      This says that the module has a post requirement and forces Packet_IN messages to be passed on to the forwarding module. This is an example of how you would enforce an ordering. You can probably find something similar in the loadbalancing module.
  • Virtual Network
    • multiple links between two controller islands (which is the case for fat tree topologies) are not supported by Floodlight, at least for now. See Supported Topologies for details.

Monday, August 5, 2013

[SPC] SPC Demo

Here is a SPC System Demo Video that is related with the previous article: [SPC] A simple SPC system introduction

Check it out:
http://www.youtube.com/watch?v=XLRKj2mgnEA

[SPC] A simple SPC system introduction

SPC System
Introduction
  • Statistic Process Control (SPC) has adopted and widely used in many industries, such as, IC foundry, automobile, and so on. It provides the function to monitor the process(manufacturing) capacity and check if the monitor data violates SPC Rules. The following content explains how we build up the system architecture and what the basic items are inside this system.
SPC Chart Setting
  • Table: t1twsql1.mistw.dbo.SPC_CHART_SETTING
  • This table contains all the SPC Chart Setting Data and is critical for message sending and receiving.
  • Column definition:
    • 5 categories(Category1, Category2, Category3, Category4, Category5) are combined with comma, for instance, "T3,37XX,LINEA,N/A,N/A".
    • u_spec_limit: Upper SPEC Limit
    • l_spec_limit: Lower SPEC Limit
    • spc_rules: How many SPC Rules are adopted? For example => 20 + 21 + 2 2 + 23 = 1 + 2 + 4 + 8 = 15 = Rule1 + Rule2 + Rule3 + Rule4
    • sampling_rule: Only support SamplingRuleAvg?
    • sample_number: How many data will become a point value
    • data_type: Double or String
    • is_enabled: Y/N
    • need_to_reset: Y/N
    • xbar: Default X Bar.
    • dev: Default Std. Dev.
    • owner
    • memo
    • last_alarm_time
    • last_updated_time
SPC Rules
  • One point beyond the 3σ control limit
  • 2 out of 3 consecutive points plot outside of the 2σ control limit
  • 4 out of 5 consecutive points plot outside of the 1σ control limit
  • 9 consecutive points on the same side of the centerline
  • 6 consecutive points increase or decrease
  • consecutive points oscillate up and down
  • consecutive points inside of the 1σ control limit
So, when there is any applied SPC Rule that is violated, the SPC Server will send SPC Alarm Email to specific user directly. The following is the example of the email:

SPC Server
  • The main purpose of SPC Server is to monitor the process data and check the SPC Rules. Once it violates rules, the alarm email will send to related persons directly. But, before sending alarm email, there are a bunch of things that need to do. The following content will introduce the detail information about SPC Server.
  • What does the SPC Chart look like in our SPC system?
    • Our SPC Chart will display the latest 24 points data, 3σ control limit lines, and 2 SPEC limit lines as follows:

  • Multi-threading in SPC Server
    • For the purpose of showing dynamic SPC Chart image and updating the SPC info into database, there are several threads doing their jobs to keep SPC Server work well as follows:
      • GUI: This is the main thread. It controls the GUI drawing and event handling with JFrame application.
      • JMS Receiver: We adopt ActiveMQ as JMS Provider and its API to achieving the message receiving and sending. When SPC Server starts, it will generate a JMS Receiver that we have implemented for SPC purpose and this Receiver will listen and watch out if there is any message coming.
      • SPC Chart Drawer: This heavy loading job to draw SPC Chart image is done by the Class: SPCCanvas. It refreshes the current SPC Chart image that includes to draw upper and low SPEC limits, 3σ control limits, xbar line, 24 data points, and some data labels near lines and points in every 100 millisecond. Without it, the SPC Chart image won't show smoothly.
      • DB Sync: In order to know the current SPC info, for instance, xbar, std. dev., and the current 24 data points, last updated time, and last alarm time. The Class: SPCSync is to sync this information into database in every minute. And we can use the web application to query these information.

  • SPC Image Synchronization:
As mentioned below, SPC Server has multi-threads running when it starts so that it will encounter the resource that could be accessed or updated by 2 or more threads at the same time. It's the issue of resource synchronization. In our case, we have to avoid drawing image when SPC Server is adding a new point into its SPC Chart at the same time. In other words, we don't want to see that the SPC Chart image is not complete or not correct. This situation also will affect the correction of SPC Alarm Email. Our solution is to use Semaphore which is based on Lock object to achieve our goal. The more detail is in the following image: 
  • SPC Server Data Process Flow
    • When the number of the point in a SPC Chart reach 24, SPC Server will start to draw the Chart Image.
    • When data message comes, SPC Server will follow up this process flow to deal with SPC calculation and applying SPC Rules.

  • SPC Server Data Structure:
    • The data structure is very important because it controls and contains all the point data and SPC setting in the memory so that we can lookup and operate data quickly. The main data structure is as follows:

  • SPC Server Configuration
    • DataSource?_PROD.properties
      • This properties file is as same as we use in web application
    • activemq_PubSub.config
      • This config file is about the ActiveMQ (JMS Provider) setting
§  mq.url=tcp://localhost:61616
§  mq.messagetype=Topic
§  mq.subject=testtopic
§  mq.username=
§  mq.password=
    • log4j.properties
o    log4j.logger.SPCSERVER=ALL, SERVERFileAppender, consoleAppender
o     
o    #Console Log
o    log4j.appender.consoleAppender=org.apache.log4j.ConsoleAppender
o    log4j.appender.consoleAppender.layout=org.apache.log4j.PatternLayout
o    log4j.appender.consoleAppender.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %m%n
o     
o    #SPC Server File Log
o    log4j.appender.SERVERFileAppender=org.apache.log4j.DailyRollingFileAppender
o    log4j.appender.SERVERFileAppender.DatePattern='.'yyyy-MM-dd
o    log4j.appender.SERVERFileAppender.layout=org.apache.log4j.PatternLayout
o    log4j.appender.SERVERFileAppender.layout.ConversionPattern=%d{yy-MM-dd HH:mm:ss:SSS} [%c] %p :  %m%n
o    log4j.appender.SERVERFileAppender.File=C:\\log\\spc\\spcserver.log
SPC Client
  • SPC Server needs to be fed by data message and SPC Client is playing the role to provide the messaging source. So far we only implement a client program for fetching the columns in TblFinal? table. Different message source could need a different client to deal with because how to generate the data message and what the format of data message are key points. For this case, the the foramt of chart name has 4 categories and 1 data vlaue: Product Name, Test Type, Station, Column Name, and coming with a colon and a data value.
  • For instance, nuvi 3790 Software Version 2.60,A,T3_3001FT07,SNR:44.5
  • SPC Client program will query data from TblFinal? in SPC database(MySQL) and is based on chart name format to generate the data message and send to the topic in JMS Provider.
  • SPC Client Configuration
    • activemq_client.config
o    mq.url=tcp://localhost:61616
o    mq.messagetype=Topic
o    mq.subject=testtopic
o    mq.username=
o    mq.password=
    • spc_client_datasource.config
o    DS_MYSQL.SPC_URL=jdbc:mysql://10.124.0.132:3306/SPC
o    DS_MYSQL.SPC_USER=xxxx
o    DS_MYSQL.SPC_PASSWD=xxxx
o    DS_MYSQL.SPC_DRIVER=com.mysql.jdbc.Driver
o    DS_MYSQL.SPC_CHARENCODING=big5
o    DS_MYSQL.SPC_DBTYPE=MYSQL
    • spc_data_mapper.config
o    #Data Mapper
o    spc.client.main=TBLFINALDataMapper
o    tblfinal=SNR
SPC System Web Application
  • This web application provides all the parameter setting management and query function in SPC.
    • spc_client_query
      • Provide the basic qeury function of SPC setting and current SPC info.

      • Provide the SPC Chart setting for TblFinal?.

      • Provide the Alarm Email setting with SPC chart.


Friday, July 19, 2013

[TRILL] The keypoint for Appointed VLAN-x Forwarder

If you study a lot of TRILL related documents and still are not able to figure out what Appointed VLAN-x Forwarder is and what purpose it is for, please refer to the following excerpts about it.


Whether they run STP or not, the RBridges have to ensure there’s a single point of contact between a VLAN in the STP domain and the backbone, otherwise all the flooded packets would enter the backbone through multiple entry points, resulting in duplicate packets received by the remote hosts (which might break some odd fainthearted protocols running directly on top of L2). One of the RBridges therefore becomes an appointed forwarder for an edge VLAN.
The right-hand part of the figure illustrates the appointed forwarder concept: the RBridges don’t participate in the STP, none of their edge ports are blocked, but only one of the RBridges acts as a forwarder between the edge STP domain and the TRILL backbone (marked with A), all other RBridges ignore packets received through that VLAN (marked with B).

Having multiple RBridges active on a LAN segment could be an issue if they all start forwarding traffic over the TRILL network, as this would cause both traffic duplication and also confusion in terms of the appropriate return path with which to populate the MAC mapping tables. Consequently, RBridges on a VLAN see each other and elect a Designated RBridge (DRB) for the segment, which in turn normally becomes the Appointed Forwarder that is exclusively responsible for sending/receiving frames on that shared segment while all other RBridges effectively are in a kind of standby mode. Technically (i.e. in the protocol specifications) it is possible for a DRB to make other RBridges Appointed Forwarders, but I am not aware of this being implemented yet, and the likelihood is that the DRB will do the AF job itself.

If there are multiple RBridges on the same link, together with end nodes, it is important that only one of them encapsulate a packet from an end node. As illustrated in Figure 9, if both R1 and R2 were to encapsulate a unicast packet from S, two copies would be delivered to the destination. However, if S were to transmit a multidestination packet (such as a multicast, or an unknown destination), then the copy that R1 encapsulates would be forwarded through the campus, received by R2 (which likely would not know that the packet originated on its port to R1), and R2 would decapsulate it. Then R1 would see a native packet from S, exactly as the first copy, and again encapsulate it and send it into the campus.
The hop count in the TRILL header would not solve this loop, because the hop count does not exist while the packet is not encapsulated with a TRILL header.
IS-IS has an election protocol in which one of the RBridges is elected as the Designated RBridge (DRB). In order to allow load-splitting the task of encapsulating and decapsulating traffic, the DRB may delegate the job of encapsulation/decapsulation based on VLAN. In other words, if R1 is DRB, R1 can delegate to R2 the task of encapsulating/decapsulating traffic for a set of VLANs, say VLANs x, y, and z, and delegate to R3 a different set of VLANs, and R1 might handle the rest.
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-3/143_trill.html


By the way, in this blog the author mentions the concept of Designated VLANs. I excerpt from it as follows:
Some background points that will help to explain things:
1) When RBridges see other RBridges on a multi-access link, they will determine between them which is to be the Designated RBridge (DRB). I should note that this on Point-to-Point (P2P) links, no DRB is elected.
2) When an RBridge receives a native (i.e. non-TRILL) frame that it’s going to forward as TRILL-encapsulated, it first adds a 802.1q header to the frame so that the origin VLAN will be known when the frame is decapsulated at the egress RBridge. Thus when the frame format shows the “original Ethernet frame”, it’s really the original frame plus an 802.1q header. You could, if you wanted to make the Shortest Path Bridging folks laugh quietly, liken this a little to QinQ – you’re sending TRILL-encapsulated frames sourced from multiple VLANS over a single VLAN, and inside the TRILL data frame the 802.1q header in the “original” packet means it can be ‘demuxed’ correctly at the other end. Ugh, horrible analogy :)
3) The reality is that links between RBridges are unlikely to be carrying a single VLAN, but rather they’re likely to be 802.1q trunk links with many VLANs on them. You don’t want to send out TRILL-IS-IS Hellos and run an instance of IS-IS on every VLAN, as that wouldn’t be scalable. It would also be pointless, as TRILL encapsulated frames are not forwarded on the VLAN on which the frame ingressed; rather the TRILL data frames are forwarded on a common VLAN – the Designated VLAN.
So, if we put all that together:
- On any given link, there must be a single VLAN that the RBridges agree to use for the exchange of TRILL-IS-IS and TRILL data.
- On a multi-access link, the DRB dictates what the Designated VLAN will be; other (non-DRB) RBridges on that link MUST use whatever VLAN the DRB dictates.
- On a point-to-point link, the RBridges use tie-break mechanisms to determine whose Designated VLAN should reign supreme (since there’s no DRB)
- The best design obviously would be that you configure all RBridges to prefer the SAME Designated VLAN, so that if the DRB changes, you don’t change Designated VLAN as well.
- You also need to ensure that all RBridges on a link have connectivity to that Designated VLAN. Common sense, really.
So in summary, the Designated VLAN is the VLAN where TRILL-IS-IS really runs, and over which TRILL data forwarding between RBridges occurs. Make sure all RBridges on a link have the same preferred Designated VLAN configured, and ensure they all have connectivity to that VLAN.
 http://lamejournal.com/2011/05/16/layer-2-routing-sort-of-and-trill/




Wednesday, July 17, 2013

[OpenFlow] OpenFlow 1.3 Spec Summary

Compared with OF1.0, OF1.3 is more tables and complex design than 1.0. Here I try to summarize the main items in OF1.3 spec included the table, message, and so on for me to review it more quick in the future.

OpenFlow Table

Flow Table
+-----------------------------------------------------------------------------------------+
 | Match Fields | Priority | Counters | Instructions | Timeouts | Cookie |
+-----------------------------------------------------------------------------------------+

Group Table
+-----------------------------------------------------------------------------+
 | Group Identifier | Group Type | Counters | Action Buckets |
+-----------------------------------------------------------------------------+
  •   Group Types
    • Required: all: Execute all buckets in the group
    • Optional: select: Execute one bucket in the group.
    • Required: indirect: Execute the one defines bucket in this group.
    • Optional: fast failover: Execute the first live bucket.
Meter Table
+-------------------------------------------------------+
 | Meter Identifier | Meter Bands | Counters |
+-------------------------------------------------------+
  • Meter Bands 
               +--------------------------------------------------------------------------+
                 | Band Type | Rate | Counters | Type specific arguments |
                +-------------------------------------------------------------------------+
    • Band Type
      • Drop
      • Remark DSCP

New Data Structure in Pipeline
+-------------------------------------------------------+
 | media data | packet header | Action Set   |
+-------------------------------------------------------+

 Instructions
Each flow entry contains a set of instructions that are executed when a packet matches the entry.
  • Optional Instruction: Meter meter id: Direct packet to the specified ed meter.
  • Optional Instruction: Apply-Actions action(s): Applies the specified ed action(s) immediately, without any change to the Action Set.
  • Optional Instruction: Clear-Actions: Clears all the actions in the action set immediately.
  • Required Instruction: Write-Actions action(s): Merges the specified ed action(s) into the current action set. 
  • Optional Instruction: Write-Metadata metadata / mask: Writes the masked metadata value into the metadata field. 
  • Required Instruction: Goto-Table next-table-id: Indicates the next table in the processing pipeline.
Action Set
The actions in an action set are applied in the order specifi ed below, regardless of the order that
they were added to the set.
  • copy TTL inwards: apply copy TTL inward actions to the packet
  • pop: apply all tag pop actions to the packet
  • push-MPLS: apply MPLS tag push action to the packet
  • push-PBB: apply PBB tag push action to the packet
  • push-VLAN: apply VLAN tag push action to the packet
  • copy TTL outwards: apply copy TTL outwards action to the packet
  • decrement TTL: apply decrement TTL action to the packet
  • set: apply all set-eld actions to the packet
  • qos: apply all QoS actions, such as set queue to the packet
  • group: if a group action is specied, apply the actions of the relevant group bucket(s) in the order specied by this list
  • output: if no group action is specied, forward the packet on the port specied by the output action
Action List
  • The Apply-Actions instruction and the Packet-out message include an action list.
Actions
  • Required Action: Output. The Output action forwards a packet to a speci ed OpenFlow port
  • Optional Action: Set-Queue. The set-queue action sets the queue id for a packet.
  • Required Action: Drop. There is no explicit action to represent drops.
  • Required Action: Group. Process the packet through the speci ed group.
  • Optional Action: Push-Tag/Pop-Tag. Switches may support the ability to push/pop tags
    • Push / Pop VLAN header
    • Push  / Pop MPLS header
    • Push  / Pop PBB header
  • Optional Action: Set-Field. The various Set-Field actions are identified by their field type and modify the values of respective header fields in the packet.
  • Optional Action: Change-TTL. The various Change-TTL actions modify the values of the IPv4 TTL, IPv6 Hop Limit or MPLS TTL in the packet.
    • Set MPLS TTL
      • 8 bits: New MPLS TTL
    • Decrement MPLS TTL
    • Set IP TTL
      • 8 bits: New IP TTL
    • Decrement IP TTL
    • Copy TTL outwards
    • Copy TTL inwards

OpenFlow Channel
Controller-to-Switch Message
Handshake:
Features:
Switch-Configuration:

Flow Table Configuration:
Modify-State message:
Multipart message:
Queue-Configuration message:
Read-State:
Packet-out message:
Barrier message:
Role-Request message:
Set-Asynchronous-Configuration message:


Asynchronous Message
Packet-in:
Flow-Removed:
Port-status:
Error:

Symmetric Message
Hello:
Echo Request/Reply:
Experimenter:



Flow Table Modification Messages

Group Table Modification Messages

Meter Modification Messages