This document proposes enabling software-defined networking capabilities in wireless sensor networks. It discusses adapting the OpenFlow protocol by redefining flow tables to classify wireless sensor network addressing schemes and handle sensor data packet flows. It also addresses providing the software-defined network control channel, reducing control traffic, generating and processing sensor data, and ensuring backward and peer compatibility with OpenFlow. The goal is to provide programmable routing and flexible policy enforcement for wireless sensor networks.
This document describes the features of the operation of the OSPF routing protocol in general. In some subjects, theoretical information that was explained by establishing lab environments was reinforced by applications.
The purpose of this document is not to analyze OSPF from start to finish, but to create a simple quick learning booklet. For this reason, some topics are described only superficially, while some topics details are covered. Also, some concepts such as Sham Link or FRR are not included in the document.
This document describes the features of the operation of the OSPF routing protocol in general. In some subjects, theoretical information that was explained by establishing lab environments was reinforced by applications.
The purpose of this document is not to analyze OSPF from start to finish, but to create a simple quick learning booklet. For this reason, some topics are described only superficially, while some topics details are covered. Also, some concepts such as Sham Link or FRR are not included in the document.
The concept of the spanning tree protocol was devised to address broadcast storming. The spanning tree algorithm itself is defined by the IEEE standard 802.1D and its later revisions.
The IEEE Standard 802.1 uses the term bridge to define the spanning tree operation, and uses terms such as Bridge Protocol Data Units and Root Bridge when defining spanning tree protocol functions.
When a bridge receives a frame, it reads the source and destination address fields. The bridge then enters the frame’s source address in its forwarding database. In doing this the bridge associates the frame’s source address with the network attached to the por t on which the frame was received. The bridge also reads the destination address and if it can find this address in its forwarding database, it forwards the frame to the appropriate port. If the bridge does not recognize the destination address, it forwards the frame out from all its por ts except for the one on which the frame was received, and then waits for a reply. This process is known as “flooding”. Similarly, packets with broadcast or multicast destination MAC addresses will be flooded by a bridge.
A significant problem arises where bridges connect via multiple paths. A frame that arrives with an unknown or broadcast/multicast destination address is flooded over all available paths. The arrival of these frames at another network via different paths and bridges produces major problems. The bridges find the same source MAC address arriving on
multiple different por ts, making it impossible to maintain a reliable forwarding database. As a result, increasing numbers of packets will be forwarded to multiple paths. This process is selfperpetuating and produces a condition known as a packet storm, where the increase of circulating frames can eventually overload the network.
Basically it contains information about the OSPF routing protocol. As much as possible the information was tried to be summarized and a slideshow of visual weight was made.
In simple terms, detailed descriptions on how RSVP works in this document have been made. Some detail issues are not covered, such as CSPF or protection mechanisms. Purpose of this document is to create an idea of the working structure of the protocol and how to manage it in general.
This slide contains the basic and advanced concept of OSPF routing protocol, according to the latest version of Cisco books, and I presented it at IRAN TIC company. In the next slide, I will upload an attractive advanced feature about OSPF.
The concept of the spanning tree protocol was devised to address broadcast storming. The spanning tree algorithm itself is defined by the IEEE standard 802.1D and its later revisions.
The IEEE Standard 802.1 uses the term bridge to define the spanning tree operation, and uses terms such as Bridge Protocol Data Units and Root Bridge when defining spanning tree protocol functions.
When a bridge receives a frame, it reads the source and destination address fields. The bridge then enters the frame’s source address in its forwarding database. In doing this the bridge associates the frame’s source address with the network attached to the por t on which the frame was received. The bridge also reads the destination address and if it can find this address in its forwarding database, it forwards the frame to the appropriate port. If the bridge does not recognize the destination address, it forwards the frame out from all its por ts except for the one on which the frame was received, and then waits for a reply. This process is known as “flooding”. Similarly, packets with broadcast or multicast destination MAC addresses will be flooded by a bridge.
A significant problem arises where bridges connect via multiple paths. A frame that arrives with an unknown or broadcast/multicast destination address is flooded over all available paths. The arrival of these frames at another network via different paths and bridges produces major problems. The bridges find the same source MAC address arriving on
multiple different por ts, making it impossible to maintain a reliable forwarding database. As a result, increasing numbers of packets will be forwarded to multiple paths. This process is selfperpetuating and produces a condition known as a packet storm, where the increase of circulating frames can eventually overload the network.
Basically it contains information about the OSPF routing protocol. As much as possible the information was tried to be summarized and a slideshow of visual weight was made.
In simple terms, detailed descriptions on how RSVP works in this document have been made. Some detail issues are not covered, such as CSPF or protection mechanisms. Purpose of this document is to create an idea of the working structure of the protocol and how to manage it in general.
This slide contains the basic and advanced concept of OSPF routing protocol, according to the latest version of Cisco books, and I presented it at IRAN TIC company. In the next slide, I will upload an attractive advanced feature about OSPF.
John Donovan
Senior Executive VP
AT&T Inc.
Keynotes Session
ONS2015: http://bit.ly/ons2015sd
ONS Inspire! Webinars: http://bit.ly/oiw-sd
Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd
Internet Research Lab at NTU, Taiwan.
A survey of routing in data center networks and latest IEEE 802.1Qau - Congestion Notification standard in data center bridging task group.
Ming Xia
Ericsson Research Silicon Valley
Research Track Session Part 2
ONS2015: http://bit.ly/ons2015sd
ONS Inspire! Webinars: http://bit.ly/oiw-sd
Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd
Internet Research Lab at NTU, Taiwan.
SIGCOMM HotSDN 2012 is the first conference workshop focused on SDN. This presentation provides a survey of selected papers in HotSDN'12 and revisits concepts and frameworks of SDN. Example applications are also presented.
OPNFV Webinar – No Time to Wait: Accelerating NFV Time to Market Through Open...Open Networking Summits
This webinar presents a discussion on the 23+ ongoing OPNFV projects, the first OPNFV release (Arno), why it is significant and the use-cases / customer needs the OPNFV project aims to address.
Open Platform for NFV (OPNFV) is a carrier-grade, integrated, open source platform to accelerate the introduction of new NFV products and services, ensure the industry’s NFV needs are being met, and enable end user choice in specific technology components based on their use cases and deployment architectures.
Andrea Pinnola
Telecom Italia
NFV-SDN Synergy
Technology Track Session
ONS2015: http://bit.ly/ons2015sd
ONS Inspire! Webinars: http://bit.ly/oiw-sd
Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd
Deploying Hyperscale SDN and NFV in Next-Generation Data CentersRadisys Corporation
Check out this presentation that Radisys' Bryan Sadowski, VP, Product Management, presented at SDN & OpenFlow World Forum 2016 in The Hague, Netherlands. This presentation explores the carrier-grade integrated hardware and software SDN/NFV solution Radisys offers to deploy into next-generation data centers.
Relatore: Alessandro Legnani, Cisco CCIE e IP Network Architect di IT Global Consulting Srl
Sintesi e sinergia perfetta di un nuovo protocollo di routing (e non solo) con il caro vecchio e robusto IPsec (senza le problematiche ike). Perché inventarsi l’ennesima forma di tunnelig per il data plane?
Quanto sopra è la chiave del successo della soluzione sdwan Cisco/Viptela che la rende enormemente scalabile e unica sul mercato.
Provide a full explanation to the below question.1. Summarize the .pdfarihantmobileselepun
Provide a full explanation to the below question.
1. Summarize the 802.11 standard and describe the various flavors of the standard, its
architecture and how the standard is contributing to easing of congestion in cellular networks.
Solution
IEEE 802.11 is a standard that defines the physical and MAC layers of Wireless Local Area
Network (WLAN). Under this standard, the Mobile terminals (MTs) can communicate with a
Access Point (AP) in two modes. First mode is the Infrastructure Mode, in which the MTs
communicate with the APs which forward their data to the WLAN. Second mode is the Adhoc
mode, in which the MTs communicate directly with each other without the use of a AP. The
IEEE 802.11 has a very robust Medium Access Control (MAC) mechanism that helps in
alleviating te congestion in the LANs. The inherent working of MAC protocol employed by
802.11 standard is same as that of Carrier Sense Multiple Access/ Collision Aviodance
(CSMA/CA). However, in IEEE 802.11 the protocol is implemented in two different ways. First
way is called as the Distributed Coordination Function based Wireless MAC (DCFWMAC), and
the second way is Point Coordination Function based Wireless MAC (PCFWMAC).
In the DCFWMAC, every node tries to access the medium based on some fixed duration of time
defined in the standard. Normally there are three such time intervals defined based on which a
node attempts to access the channel and transmit its packets. The first interval is the Short Inter
frame Spacing (SIFS). It is the smallest duration of time between two frames and gives the node
higher priority for sending its data. Such a interval is employed only when the node has correctly
sent its data through the channel and the receiver node needs to send a Acknowlegement (ACK)
after waiting for SIFS period of time. The second most priority interval is PCF Inter Frame
Spacing (PIFS) used during Polling mechanism by the AP. Its duration is between SIFS and
DCF Inter frame Spacing (DIFS). The DIFS is the longest time duration and hence of least
priority, in which a AP has to wait between two successive channel accesses for the given
duration. Once the channel is sensed idle, the AP waits for DIFS period of time to transmit data
through the channel. If the channel is sensed busy, then it backs off for a period of time based on
the minimum and maximum value of a contention window. During the back off period, if the
node senses the channel as busy, then it freezes the backoff counter and starts the backoff(with
the remaining time left) once the channel is idle. In this manner, the nodes which have waited
longer get higher priority over others which accessing the channel. Once the node sends the data
after accessing the channel, the receiver waits for SIFS duration of time to finally send the
acknowledgement to the sender. In order to tackle the hidden terminal problem, the DCFWMAC
employs an additional mechanism called as the RTS-CTS mechanism, in which any node that
wants to transmit.
Research Inventy : International Journal of Engineering and Scienceinventy
Research Inventy : International Journal of Engineering and Science is published by the group of young academic and industrial researchers with 12 Issues per year. It is an online as well as print version open access journal that provides rapid publication (monthly) of articles in all areas of the subject such as: civil, mechanical, chemical, electronic and computer engineering as well as production and information technology. The Journal welcomes the submission of manuscripts that meet the general criteria of significance and scientific excellence. Papers will be published by rapid process within 20 days after acceptance and peer review process takes only 7 days. All articles published in Research Inventy will be peer-reviewed.
The Challenges of SDN/OpenFlow in an Operational and Large-scale NetworkOpen Networking Summits
Jun Bi
Professor & Director
Tsinghua University
Outline
• Intra-AS (campus level) IPv6 source address validation using OpenFlow (with extension)
– Good for introducing new IP services to network
• Planning next step if we run SDN as a common infrastructure for new services and architectures
– Some personal viewpoints and thoughts on design challenges
– Forwarding abstraction for Post-IP architectures
– Control abstraction for scalable NOS and programmable/manageable virtualization platform
– Inter-AS policies negotiation abstraction
ONS2015: http://bit.ly/ons2015sd
ONS Inspire! Webinars: http://bit.ly/oiw-sd
Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd
Router 1X3 – RTL Design and VerificationIJERD Editor
Routing is the process of moving a packet of data from source to destination and enables messages
to pass from one computer to another and eventually reach the target machine. A router is a networking device
that forwards data packets between computer networks. It is connected to two or more data lines from different
networks (as opposed to a network switch, which connects data lines from one single network). This paper,
mainly emphasizes upon the study of router device, it‟s top level architecture, and how various sub-modules of
router i.e. Register, FIFO, FSM and Synchronizer are synthesized, and simulated and finally connected to its top
module.
2. +
Data Plane: Creating Flows
Redefine flow tables to cater for the special addressing schemes in WSN
classify WSN addressing schemes into Class-1 , compact network-unique addresses such as the ZigBee 16-bit network
addresses (e.g., 0x796F as assigned by the CSkip algorithm [9]), and Class-2 , concatenated attribute-value pairs (CAV)
such as “30< temperature< 60” and “Zone-ID=7 AND x -coordinate> 150”
3. +
Control Plane: SOF Channel
If the network operator chooses the non-
IP solution, i.e., redefining flow
tables, then the SOF channel can be
supplied by overlaying a transport
protocol directly over WSN.
If, otherwise, the network operator
chooses to augment WSN with IP (and
use our recommended IP stacks), SOF
channels will be self-supplied because
uIP, uIPv6 and Blip are all shipped with
ready-to-use TCP implementations.
4. +
Curbing Control Traffic
Sensor only sends one packet-in for
the first table-miss and suppresses
subsequent packet-in whose associated
packets have the same destination
address (Class-1 or Class-2) as the first
packet, until the corresponding packet-
out or flow-mod is received or a
predefined timeout
Occurs.
1. the end-to end SOF channel is slow
(as it is in-band of WSN), the latency
between sending packet-in and
receiving packet-out or flow-mod is
much larger than in OpenFlow. - a large
number of incoming packets
2. major traffic in WSN is upstream –
use destination addresses to bundle
packets into flows
5. +
traf-gen module: interrupt routine
Sensory data generation consists of two very simple steps: reading data from the sensing
hardware, and converting the data if needed.
traf-gen module can run in a blocking
(synchronously awaiting sensory data to
become available), callback
(asynchronously triggered by a“data-
available” event), or round-robin
(periodically checking if data are
available) manner
6. +
traf-gen module: interrupt routine
Sensory data generation consists of two very simple steps: reading data from the sensing
hardware, and converting the data if needed.
traf-gen module can run in a blocking
(synchronously awaiting sensory data to
become available), callback
(asynchronously triggered by a“data-
available” event), or round-robin
(periodically checking if data are
available) manner
7. +
in-net proc module
If the processing is not needed by a packet, this module simply passes the packet intact to
the flow table.
future changes to the processing
algorithm - use over-the-air
programming (OTA) –
allows updating sensor
firmware&software wirelessly & remotely
(Libelium - offers a package that
features secured and interference-free
OTA programming)
data aggregation standard operations:
average, median, min, max, or removing
redundant data
absorbed into flow tables as a special
way of packet handling, which would
mitigate the compromise &enhance
network programmability
8. +
Backward and Peer Compatibility
SOF inherits backward compatibility from OpenFlow. An SOF-hybrid sensor will have a
NORMAL logical port defined similarly as by OpenFlow, which directs packets to traditional
sensor network forwarding.
SOF should enable OpenFlow to recognize SOF flow tables so
that OpenFlow can relegate Class-1 and Class-2 flow entries to
SOF
Making SOF peer compatible with OpenFlow
11. +
Intouch Mobile Client detects Gary is in
mobility state. There is no operator
policy set and the device defaults to in-
built policy without pulling any
connection policies from operator.
![+
Data Plane: Creating Flows
Redefine flow tables to cater for the special addressing schemes in WSN
classify WSN addressing schemes into Class-1 , compact network-unique addresses such as the ZigBee 16-bit network
addresses (e.g., 0x796F as assigned by the CSkip algorithm [9]), and Class-2 , concatenated attribute-value pairs (CAV)
such as “30< temperature< 60” and “Zone-ID=7 AND x -coordinate> 150”](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)