IOT Module2
IOT Module2
• NOTE
We are going to design the subnets with the private IPs, not public
IPs, because if we use public IPs then it may conflict with the public
IPs provided by internet service provider.
IP addresses categories of IPv4..
• SOLUTION
• By looking at the subnet mask 255.255.255.0 we can see that first 3 octets are full.
• So, the entire IP address range will start from 192.168.1.0 to 192.168.1.255 in this
network.
• What is the first IP or network address in this network?
• First IP is also called network address and will be 192.168.1.0.
• What is the last IP or broadcast address in this network?
• Last IP is called broadcast address and will be 192.168.1.255.
• What is the gateway IP in this network?
• Next IP after First IP is assigned for the gateway and will be 192.168.1.1.
• Thus, the actual usable IP address range would be from 192.168.1.2 to 192.168.1.254 .
• Total Possible IP addresses in the network will be 0-255 = 256 IP addresses.
IPv4…
• IPv4 also has well-defined address spaces to be used as private
addresses (not routable on internet), and public addresses (provided
by ISPs and are routable on internet).
• Though IP is not reliable one; it provides ‘Best-Effort-Delivery’
mechanism.
Internet Protocol Version 6 (IPv6)
• The logic behind the development of the protocol was founded on the
traffic flow characteristics of such networks, where typical use cases
involve the collection of data from many (for example) sensing points,
nodes towards a sink, or alternatively, flooding information from a
sink to many nodes in the network.
• Thus, the well-known concept of a Directed Acyclic Graph (DAG)
structure was concentrated to a Destination Oriented DAG (DODAG)
for the purposes of initial development.
• The group defined a new ICMPv6 message, with three possible types,
specific for RPL networks.
Routing protocols…..
• The IETF Routing Over Low-power and Lossy networks (ROLL) Working
Group was formed in 2008 to create an IP level routing protocol
adapted to the requirements of mesh networking for the Internet of
Things: the first version of RPL (Routing Protocol for Low-power and
lossy networks) was finalized in April 2011.
• RPL specifies a routing protocol specially adapted for the needs of
IPv6 communication over “low-power and lossy networks” or LLNs,
supporting peer to peer traffic (point to point), communication from a
central server to multiple nodes on the LLN( point to multipoint
P2MP) and vice versa (multipoint to point MP2P).
• The base RPL specification is optimized only for MP2P traffic (upward
routing or convergecast used, e.g., in metering networks) or P2MP,
and P2P is optimized only through use of additional mechanisms such
as draft-ietf-roll-p2p-rpl.
RPL…..
• Such LLNs are a constrained environment, which imply specific
requirements explored by the IETF ROLL working group in RFC5867,
RFC5826, RFC5673, and RFC5548.
• RPL has been designed according to these LLN specific requirements
(typically on networks supporting 6LoWPAN), but is not limited to
operation over LLNs.
• Multiple concurrent instances of RPL may operate in a given network,
each RPL instance is characterized by a unique RPLinstanceID. The
following sections describe the behavior of an individual RPL instance.
RPL…..
• The RPL routing protocol builds one or more destination oriented
direct acyclic graphs (DODAG).
• Each DODAG is a directed graph with no cycles and with a single root
node (see Figure next slide).
• The graph is built according to optimization objectives specified by an
objective function (OF, defined by the OCP field of a DIO DODAG
configuration option).
• The objective function is not specified by RPL itself, but in other
companion documents according to domain-specific requirements
RPL…..
• for the available network metrics, the OF computes the “rank”
measuring the “distance” between the node and the DODAG root and
also defines the parent node selection policy, for instance an
objective function could seek to minimize the expected packet delay,
while another might want to avoid routing through any battery-
operated node.
• RPL requires bidirectional links. Bidirectional connectivity must be
verified before accepting a router as a parent, for example, by using
IPv6 neighbor unreachability detection(NUD), bidirectional
forwarding detection (RFC5881) and hints from lower layers via layer
2 triggers like RFC5184.
• RPL Control Messages
• RPL routers need to exchange information in order to build the
DODAG and populate routing tables.
• RPL defines a new ICMPv6 (RFC 4443) message, type 155, for this
purpose.
• RPL defines the following base objects:
• – The DODAG information solicitation (DIS) message;
• – The DODAG information object (DIO), see Figure next slide;
• – The destination advertisement object (DAO);
• – The DAO Ack object;
• – The consistency check (CC) object, which is used to check secure
message counters and to carry RPL challenges and responses, and is
always carried in a secure RPL message.
Construction of the DODAG and Upward
Routes
• The DODAG information object (DIO) is used to build the DODAG: it
carries general DODAG configuration parameters and information that
allows listening RPL routers to select a set of DODAG parents. Several
type-length-value encoded options in the same RPL control message may
specify:
• – The address of the sending RPL router, and prefixes that may be used for
IPv6 stateless
• auto configuration (0×08 prefix information option, or PIO). The PIO
contains the same fields as the IPv6 neighbor discovery prefix information
option defined in RFC4861,RFC4862 and RFC3775.
• A 1-bit “L flag” indicates that addresses derived from the prefix can be
considered “on-link”, a 1-bit “A flag” indicates that the prefix can be used
for stateless address auto configuration.
Construction of the DODAG…..
• Metrics allowing estimation of the cost to reach destinations starting
with each prefix (0×02 metric container option, formatted as specified
in ID. IETF-roll-routing-metrics),
• – One or more prefixes that are reachable by the advertising node
(0×03 routing information option, illustrated in Figure next slide and
containing the same fields as the IPv6 neighbor discovery route
information option defined in RFC4191).
• – Additional DODAG configuration information (0×04 DODAG
information option) such as the values of MaxRankIncrease and
MinHopRankIncrease used to constrain the rank a node can advertise
when reattaching to a DODAG, or the default lifetime of all RPL
routes.
Construction of the DODAG…..
• RPL nodes send DIOs periodically via link-local multicasts, and
joining nodes may request DIOs from their neighbors by multicasting
ICMPv6 control messages containing a DODAG information
solicitation Object (DIS).
• DIO parameters are explained in Figure slide 28, the DTSN is an 8-bit
unsigned integer number set by the issuer of the message.
• In the storing mode of operation, incrementing the DTSN is a way to
request updated DAO messages from child nodes.
Each DODAG, identified by a unique RPLInstanceID and DODAGID,
is built incrementally from the root to leaf nodes: