ESTABLISHING IPV6 CONNECTIVITY FOR A CABLE MODEM
Neel Jadia
B.E., Dharmsinh Desai University, India, 2008
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
COMPUTER SCIENCE
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
FALL
2010
ESTABLISHING IPV6 CONNECTIVITY FOR A CABLE MODEM
A Project
by
Neel Jadia
Approved by:
__________________________________, Committee Chair
Dr. Chung-E Wang
__________________________________, Second Reader
Dr. Ted Krovetz
____________________________
Date
ii
Student: Neel Jadia
I certify that this student has met the requirements for format contained in the University
format manual, and that this project is suitable for shelving in the Library and credit is to
be awarded for the Project.
__________________________, Graduate Coordinator
Dr. Nikrouz Faroughi
Department of Computer Science
iii
________________
Date
Abstract
of
ESTABLISHING IPV6 CONNECTIVITY FOR A CABLE MODEM
by
Neel Jadia
This project provides an overview into the lifecycle of a cable modem. It demonstrates
the initialization stages a cable modem would pass through. Once self-initialization of a
cable modem is complete, it comes online. This project discusses the state machine
transitions pursued by a cable modem. The focus of the project is to demonstrate how a
cable modem acquires an IPv6 address for its operation from the network. A dummy
process running on the other end would act as a very basic DHCPv6 server to provide
IPv6 address to the requesting host, which happens to be a cable modem in our case. The
cable modem logs the message received from the dummy process in a log file.
Docisis 3.0 specification from Cable Labs titled as, "MAC and Upper Layer Protocols
Interface Specification" is used as a strong guideline. Other sources of data include the
DHCPv6, IPv6 RFC’s from IETF.
_______________________, Committee Chair
Dr. Chung-E Wang
_______________________
Date
iv
ACKNOWLEDGMENTS
I wish to extend my sincere gratitude to my project advisor, Dr. Chung-E-Wang, for his
support, guidance and valuable inputs at every important stage of my project research and
implementation. Dr. Wang has always been an immensely supportive mentor. He has
been guiding me throughout my graduation. Without Dr. Wang’s support, it was an
impossible task for me to complete this project. His knowledge in the field of computer
networking and communications and teaching techniques helped me understand complex
topics very easily. I would take this opportunity and thank my committee member, Dr.
Ted Krovetz, for his valuable support as a second reader on the project. He has been very
helpful while drafting my project report and providing me his expertise, advice in the
form of his positive feedback.
I am highly grateful to Dr. Cui Zhang, Dr. Nikrouz Faroughi, other faculty members and
the entire staff of computer science department for their co-operation and guidance.
v
TABLE OF CONTENTS
Page
Acknowledgments......................................................................................................... v
List of Tables ............................................................................................................ viii
List of Figures ............................................................................................................. ix
Chapter
1. INTRODUCTION ……………. ………………………………………………… 1
1.1 Project Motivation ...................................................................................... 1
1.2 Project Background .................................................................................... 2
1.3 Goals ........................................................................................................... 2
1.4 Report Organization .................................................................................... 3
2. POWERING ON A CABLE MODEM .................................................................. 5
2.1 Scanning Downstream Channels ................................................................ 5
2.2 Scanning Upstream Channels ..................................................................... 6
2.3 Adjusting Timing Offset and Power Level ................................................. 7
2.4 Establish IP Connectivity............................................................................ 8
2.5 Establish Time of Day .............................................................................. 10
2.6 Transfer Operational Parameters .............................................................. 11
2.7 Register with the CMTS ........................................................................... 12
3. BACKGROUND AND LITERATURE REVIEW .............................................. 13
3.1 DHCP Protocol ......................................................................................... 13
3.2 IPv6 Protocol ............................................................................................ 15
3.2.1 IPv6 Protocol Introduction ............................................................... 15
3.2.2 Features Provided by IPv6 Protocol ................................................ 16
3.2.3 IPv6 Headers .................................................................................... 18
3.2.3.1 Extension Headers ............................................................... 20
vi
3.2.4 IPv6 Addressing ............................................................................... 21
3.2.4.1 Addresses without a Specific Prefix .................................... 22
3.3 Conclusion ................................................................................................ 26
4. THE ARCHITECTURE OF THE SIMULATOR SYSTEM ............................... 27
4.1 Connectivity .............................................................................................. 27
4.2 CMS Process and Architecture ................................................................. 28
4.2.1 CMS Threads ................................................................................... 29
4.2.2 CMS Signal Handlers ...................................................................... 31
4.2.3 CMS Libraries .................................................................................. 31
4.2.4 CMS State Machines........................................................................ 33
4.2.4.1 CMS State Machine Methods .............................................. 41
4.3 Source Tree Description ........................................................................... 44
4.4 Steps Required for Adding a New State Machine .................................... 46
5. CABLE MODEM ACQUIRING IPv6 ADDRESS .............................................. 50
5.1 IP Connectivity Phase ............................................................................... 53
5.2 Details for Implementing IPv6 Only Connectivity in CMS ..................... 54
6. CONCLUSION AND FUTURE DEVELOPMENT ............................................ 58
References ................................................................................................................... 59
vii
LIST OF TABLES
Page
1.
Table 3.1 IPv6 Header Elements...………...….…………….…………...……... 19
2.
Table 4.1 CMS Threads……...…………..………………….………...……....... 30
3.
Table 4.2 CMS Signals..……………….…………………………...…………... 31
5.
Table 4.3 CMS Libraries…………….………………………..….……………... 33
6.
Table 4.4 CMS State Machines...…………………………….…..…………….. 37
7.
Table 4.5 Modem State Machine Events and Actions ………..………………... 40
8.
Table 4.6 CMS State Machine Methods….......……………….………………... 43
9.
Table 4.7 Source Tree Description.….…….…………………..……………….. 45
10.
Table 4.8 New State Machine Files …………….………..…………………….. 47
viii
LIST OF FIGURES
Page
1.
Figure 3.1 IPv6 Header Format...…….……………...…………………………. 18
2.
Figure 3.2 Extension Headers……….……….…..……..………………………. 20
3.
Figure 4.1 Architecture of the System...………………………………..………. 28
4.
Figure 4.2 CMS State Machine Execution…………………..…………………. 35
5.
Figure 4.3 Independent Execution for each State Machine..……...……………. 38
6.
Figure 4.4 CMS State Machine Methods...…………………………..…………. 42
7.
Figure 5.1 State Machine for a Cable Modem....…………………….…………. 52
8.
Figure 5.2 IPv6 only Provisioning Mode….....…………………………………. 53
9.
Figure 5.3 Message Interaction for Establishing IPv6 Connectivity…....……… 54
ix
1
Chapter 1
INTRODUCTION
1.1 Project Motivation
It was a great learning experience working as an intern at Cisco Systems. During my
internship, I learned about Data-Over Cable Service Interface Specification (DOCSIS).
DOCSIS describes the ability to transfer IP data over a cable network. We all know, a
typical modem converts and transports a digital signal from a device like computer or
router into an analog signal and vice-versa. A Cable modem is a sophisticated device that
provides data, video and voice services over a hybrid fiber co-axial cable network (HFC)
via radio-frequency signals instead of a traditional analog telephone line. Cable Modem
uses DOCSIS protocol to transmit and receive packets from Cable Modem Termination
System (CMTS) head-end facility. I was interested in understanding the function of a
cable modem and the integration of services over a cable network. Cable modem
provides high bandwidth services as compared to a traditional analog modem.
IPv6 is becoming an important step towards sustaining internet. I was interested to learn
about IPv6 protocol. Therefore, I thought to develop a cable modem simulator to work on
IPv6 protocol connectivity. Thus, my interest in IPv6 protocol, experience in cable
communications with DOCSIS led me to choose this project.
2
1.2 Project Background
The objective of this project is to demonstrate the initialization sequence of a cable
modem when powered on. The project demonstrates various stages of a cable modem and
their corresponding events. The scope of this project is limited to few important stages
within the life cycle of a cable modem. Project focuses on the scenario where a cable
modem requests and receives an IPv6 address from the network Dynamic Host Control
Protocol (DHCP) server. Implementing every stage and event of a cable modem is not the
focus of this study due to limited resources.
DOCSIS Mulpi v3.0 specification is the main resource material for the project. Cable
Labs is responsible to maintain, draft and update the specification as it evolves. Services
such as voice, video and data deployed in the cable network are possible due to DOCSIS.
Major resources along with DOCSIS 3.0 include DHCPv6, IPv6 RFC’s from IETF.
1.3 Goals
The goal of the project is to demonstrate modem initialization process, to generate logs
for message transactions with dummy process and to establish IPv6 connectivity. Cable
modem supports various modes of IP connectivity. This project concentrates on ‘IPv6
only provisioning’ mode. A dummy process on the other end of the system acts as head-
3
end CMTS facility. It reports event like receiving messages from the cable modem
simulator and acts like a DHCPv6 server.
For IPv6 only connectivity, this project discusses how a Link Local Address (LLA) for a
cable modem is calculated. The DHCPv6 solicits, advertizes, requests and response
messages between cable modem and dummy process are demonstrated. The dummy
process acts as a DHCPv6 server.
The project logs the detailed description in a file and displays important message
interactions on the terminal window.
1.4 Report Organization
Chapter 2 discusses the background of a cable modem and individual initialization stages.
It explains every individual stage, its importance and their functions within the lifecycle
of a cable modem. In general, this chapter describes cable modem’s functioning and a
brief overview of DOCSIS protocol. Chapter 3 presents overview of DHCP and IPv6
protocol. Chapter 3 does not explain the working of protocols. This chapter reports only
the relevant topics from these protocols pertaining to the project. It is out of scope for this
project report to explain any of the particular protocols listed above in detail or its
functioning. In Chapter 4, we understand the overall architecture of the simulator system.
This chapter gives detailed emphasis on the framework adopted for making the project
4
highly scalable, flexible and open to future development. Chapter 5 gives detail on IP
Connectivity stage for a cable modem. This chapter demonstrates the implementation
detail of IP connectivity stage. Chapter 6 concludes the project details and gives the
direction for further research and development.
5
Chapter 2
POWERING ON A CABLE MODEM
This chapter describes a cable modem with subject to theory of operation when powered
on. It provides an overview of individual stages of a cable modem. In general, this
chapter equips audience with a better understanding of a cable modem and its
functionality. A Cable Modem Termination System (CMTS) router resides at service
provider’s head-end facility. In order to communicate with a Cable Modem Termination
System (CMTS) router, a cable modem establishes a communication link in-between
both entities. This communication link is in the form of a physical medium, it is either a
co-axial cable or a fiber optics cable. After powering on a cable modem, it follows a prespecified sequence of stages. Once the sequence is successfully completed, it comes
online and is capable to provide voice, video and data services to the customer. The
following section describes eight individual Data-Over Cable Service Interface
Specification (DOCSIS) operational stages. Successful completion of these stages is a
required condition for a cable modem to provide service to the customer. Stages are:
2.1 Scanning Downstream Channels
Once a cable modem powers on, it starts scanning the Hybrid Fiber Co-axial (HFC)
network for any of the available downstream CMTS channels. The downstream channels
originate from a CMTS head-end, propagates through the HFC and terminates at a cable
6
modem. The downstream frequency range is 60 Mhz to 990 Mhz approximately. CMTS
downstream channel is a unidirectional communication link through which a CMTS
router sitting at a head-end facility sends data to a cable modem. In general, it is a link to
send data from CMTS head-end to a cable modem. A cable modem populates all the
available downstream channels on the link. Simultaneously, a cable modem identifies a
valid downstream data channel on the basis of certain criteria’s such as QAM signal
timing, forward error correction (FEC), MPEG packets, and downstream media access
control (MAC) messages. A specific scanning algorithm helps cable modem to identify a
valid downstream channel as quickly as possible. Once a valid downstream channel is
available, cable modem terminates scanning downstream channels any further and moves
to the next stage.
2.2 Scanning Upstream Channels
Once a cable modem finds a valid downstream channel, it starts reviewing upstream
parameters available on that particular downstream channel. A cable modem verifies
upstream parameters in order to perform upstream ranging, automatic adjustments in
terms of required frequency, radio frequency power (RF-power), modulation, interleave
depth. This helps a cable modem to sustain communication over the link with head-end
CMTS. The upstream parameters enable a cable modem to send data towards the CMTS
head-end. Once a cable modem finds the correct upstream parameters on a particular
downstream channel, it communicates with the head-end CMTS router. If a particular
7
downstream channel were incapable to provide required upstream parameters for
communication, cable modem starts re-scanning of a valid downstream channel that
possibly provides required upstream parameters. Without receiving the required upstream
parameters, a cable modem cannot move to the next stage.
2.3 Adjusting Timing Offset and Power Level
A cable modem starts “Adjusting Timing Offset and Power Level” stage once it
completes the first two stages described above successfully. From “Scanning Upstream
Channels” stage, a cable modem receives the upstream parameters. CMTS head-end
facility sends these parameters to communicate with a cable modem. Before
communication is possible, a cable modem needs to adjust its timing offset and power
level with the head-end facility. Adjusting timing offset is required to keep in sync with
CMTS head-end while power level is required to have minimum required strength to
sustain the upstream channels.
A cable modem receives MAC messages regularly on a downstream channel from
CMTS. A cable modem determines the upstream channel frequency and adjusts the
timing offset parameters based on the MAC messages. These parameters help a cable
modem to synchronize timing with a CMTS head-end device. During this process, cable
modem determines the upstream signal transmit power required to communicate with the
CMTS.
8
Once this process is completed, a cable modem follows the next step and registers with
CMTS. On successful registration, a cable modem comes online and provides voice,
video and data services to the customer. A cable modem repeats the process of initial
adjustment and tuning regularly to fine-tune the settings established previously. As these
adjustments are performed at regular intervals of time, it is categorized under routine
maintenance and does not affect the normal operation of a cable modem.
2.4 Establish IP Connectivity
IP Connectivity is an important stage in the initialization lifecycle of a cable modem.
During this stage, a cable modem requests for an IP address. The IP connectivity starts
only if a cable modem has successfully completed the previous stages. In general, by this
stage a cable modem must have locked a primary downstream channel and an upstream
channel. Thus, a cable modem must have established a communication link to and from a
CMTS. Once again to make things clear, the downstream link is from a CMTS head-end
to a cable modem carrying control and data messages. The upstream link is for sending
control and data messages from a cable modem to a CMTS head-end. In this stage, a
cable modem obtains network connections information and an IP address from the
network devices such as provisioning servers within the network. Usually, there is a
Broadband Access Center for Cable and Cisco Network Registrar (BACC-CNR) server
located behind a CMTS router at the head-end facility. The sole purpose of this server is
to register all the cable modems attached to a CMTS router, authorize the services
9
demands from a cable modem. BACC-CNR provides combined services on behalf of a
Time of Day server, Trivial File Transfer Protocol (TFTP) server and Dynamic Host
Configuration Protocol (DHCP) server for the network devices connected to a head-end.
Due to limited resources, project implementation does not have any BACC-CNR support;
instead, we use a dummy process for the above services.
A cable modem achieves IP connectivity using DHCP. It can establish IP connectivity
following IPv4 protocol / IPv6 protocol for requesting an IPv4 address or an IPv6 address
from the DHCP server. Cable modem depending on its capabilities can establish IP
connectivity in either of the following modes:

IPv4 only provisioning mode: Supporting only IPv4 protocol and requesting an
IPv4 address.

IPv6 only provisioning mode: Supporting only IPv6 protocol and requesting an
IPv6 address.

Alternate provisioning mode: Supports either IPv4 protocol or IPv6 protocol at
one point of time.

Dual stack mode: Supports both IPv4 address and IPv6 address at the same time.
The focus of this project is to illustrate, “IPv6 only mode” described above. This project
does not cover any other IP connectivity modes of operation.
10
Note: If a cable modem fails to establish IP connectivity, it terminates the current session
and restarts the initialization lifecycle of a modem once again right from scanning
downstream channel stage.
2.5 Establish Time of Day
This stage is where a cable modem requests for the time of day from the Time Of Day
(TOD) server. BACC_CNR server as described before provides time of day service to a
requesting cable modem. This stage enables a cable modem with system time
synchronization with CMTS. With the help of this time, a cable modem logs an event
with a time stamp associated to it. For project implementation, the functionality of this
stage is by-passed. The state machine does accommodate TOD stage and its
corresponding events as per DOCSIS. Thus, it provides scope for future development and
extension.
Note: This is the only stage within a cable modem’s initialization life cycle without
which a cable modem can operate; however, it logs the failure, by generating an alert to
Simple Network Management Protocol (SNMP), and then moves to the next stage. If
unsuccessful at first attempt, a cable modem would try to establish the time of day at
regular intervals of time.
11
2.6 Transfer Operational Parameters
After completing the time of day stage, a cable modem requests to transfer the cable
modem configuration file. This file is located on a Trivial File Transfer Protocol (TFTP)
server handled by BACC-CNR. A cable modem requests for a TFTP file by a TFTP
request. The configuration file contains parameters for determining the services that a
cable modem should provide to the customer. A system operator or service provider such
as Comcast creates a separate file for each subscriber’s cable modem depending on the
services selected by that subscriber. For project implementation, the functionality of this
stage is by-passed. The state machine does accommodate TFTP stage and its
corresponding events as per DOCSIS. Thus, it provides scope for future development.
Not all but some typical parameters within a TFTP file for a cable modem includes the
following:

Upstream and downstream rate limits.

Specific operating frequencies for a cable modem.

Number of Customer Premises Equipment (CPE) devices allowed at the customer
site behind a cable modem.

IP filters.

Port filters.

MAC / LLC filters.
12

Vendor-specific settings.

Software version installed.
2.7 Register with the CMTS
A cable modem completes the transfer of a configuration file with the help of TFTP.
Once completed, it initiates the registration process with the CMTS head-end. Cable
modem would send a registration request to the CMTS and in response; CMTS confirms
the registration by sending a response. As soon as registration completes, cable modem is
allowed to forward network traffic from the Customer Premises Equipments (CPE’s)
sitting behind the cable modem. For project implementation, the functionality of this
stage is by-passed. The state machine does accommodate Registration stage and its
corresponding events as per DOCSIS. Thus, it provides scope for future development.
13
Chapter 3
BACKGROUND AND LITERATURE REVIEW
In this chapter, we understand the basics of DHCP and IPv6 protocol, as they are very
important aspects of this project. A general overview of these protocols helps us
understand the IP connectivity stage of a cable modem. This chapter does not intend to
explain the functioning of any of the listed protocols above. This chapter discusses the
relevant details attached with the goal of this project from these protocols.
3.1 DHCP Protocol
It is an auto configuration protocol used on IP networks. In a network, when two different
computers are interested in communicating with each other. They are required to have an
IP address assigned to them. This IP address acts as a unique identity for that computer
on the network as well as an address to reach that particular computer or device. IP
addresses on a given network for individual devices should be unique. As the network
expands and devices are added to the network, it is a tedious job for a network
administrator to assign unique IP addresses to all the devices within network. In order to
automate the process and make it effective, DHCP protocol is used. In this protocol
instead of configuring every computer on the network with a unique IP address manually,
the computer/device itself would request a DHCP server present within the network for a
unique IP address when required. Considering our project scenario, a cable modem in its
14
IP connectivity stage sends a DHCP Solicit request to the dummy process acting as a
server for us. The dummy process sends DHCP response with the assigned options as per
the request from a cable modem. Once a cable modem processes the received DHCP
options and parameters it sends a DHCP request for an IP address to the dummy process.
The dummy process will reply with an IP address assigned to the requesting cable
modem.
For further details on IP connectivity specific to cable modem device, refer chapter 5.
Thus, a DHCP server on network takes care of configuring all the devices within network
with a unique IP address. DHCP server checks the validity, lease new IP address to a new
device, renewal of old IP addresses from existing host, maintaining database of the
assigned IP addresses.
There are two versions of DHCP protocol one supports IPv4 protocol and other one
supports IPv6 protocol. DHCP protocol serves the same purpose for both IP protocols but
the details for IPv4 and IPv6 are different. Although IPv6 is capable of stateless address
configuration it eliminates the basic motivation for DHCP in IPv6, it uses stateless
address configuration to assign address statefully in the network if desired by network
administrator.
15
3.2 IPv6 Protocol
3.2.1 IPv6 Protocol Introduction
Introduction of IPv6 protocol is to overcome the shortage of IP addressing using IPv4
(Internet Protocol Version 4) protocol. IPv6 is designed to support continued internet
growth and scale as per the future needs. The increase in number of IP address enabled
devices and gadgets should not be a bottleneck for the growth of internet. Currently,
internet is in a revolutionary transition period where IPv4 and IPv6 protocol co-exist and
serve the need of unique IP addressing for all devices. Looking forward to the addition of
new devices that can be attached to internet such as consumer electronic gadgets, IP
enabled mobile devices, PDA’s etc definitely leads us to IPv6 addressing protocol. Thus,
IPv6 protocol is unavoidable in order to sustain the growth of internet.
IPv6 protocol is a layer 3 protocol out of the 7-layer OSI reference model. The major
revisions in IPv6 as compared to IPv4 protocol is the redesigning of IPv6 header. The
address size significantly increases to 128 bits in IPv6 protocol as compared to IPv4 with
32 bits. This means addressing more devices with the help of IPv6 protocol. In order to
follow the fundamental purpose of layer 3 end-to-end packet transport using IP address,
IPv6 addresses of the source and destination ends are necessary within IPv6 header.
16
3.2.2 Features Provided by IPv6 Protocol
IPv6 protocol designed to accommodate itself within the internet layer of OSI reference
model. As IPv4 protocol is a predecessor of IPv6 protocol, IPv6 protocol supports the
important functions within IPv4. The following are the significant changes present within
IPv6 as compared to IPv4.

Expanding Routing and Addressing Capabilities
IPv6 protocol increases the IP address size from 32 bits to 128 bits. This change
will support a large number of IP enabled devices, it supports more levels of
addressing hierarchy and simpler auto-configuration of addresses. The scalability
of multicast routing improves by adding a scope field to multicast addresses. With
no hidden networks and hosts, all hosts can be reachable and would indeed
increase global reach ability. The use of 64 bits out of 128 bits for link layer
addresses (LLA) provides the assurance of unique addresses to the nodes. The use
of anycast addresses in the IPv6 source route allows nodes to control the path
through which the traffic from one node to another node flows. As compared to
IPv4 protocol, there are no broadcast messages available in IPv6 protocol. The
reason to eliminate broadcast messages was providing efficient use of the network
bandwidth.
17

Header Format Simplification
IPv6 protocol eliminates certain header fields present in IPv4 protocol and are of
no use as per the new IPv6 protocol design. This trade off is implemented to
decrease processing cost of IPv6 header and bandwidth cost of IPv6 header. As
IPv6 header has significant use of bandwidth with the presence of source and
destination address, each being 128 bits this trade off was necessary to remove
unnecessary header fields. This change in the header field helps to keep the
header size twice that of IPv4, although the gain in terms of IP addressing with
128 bits is significant as compared to 32 bits in IPv4 protocol.
.

Options Improvement
Separate headers carry IPv6 options in IPv6 protocol. These headers are packed in
between the IPv6 header and the Transport layer header. Changes in the way IP
header options are encoded allow for efficient forwarding and less cumbersome
limits on the length of options, and provide greater flexibility for introducing new
options in the future. Due to elimination of fields such as checksum, it helps in
increasing the routing efficiency as well as usage of network bandwidth.

Quality-of-Service
18
A new flow label capability enables the labeling of packets belonging to particular
traffic flows for which the sender requests special handling, such as non-default
quality of service or real-time service.
3.2.3 IPv6 Headers
The following diagram helps us understand the IPv6 Header format:
Figure 3.1 IPv6 Header Format
19
The following table describes the IPv6 Header Elements:
Element
Description
Version
4-bit Internet Protocol version number, the value assigned is six.
Traffic Class
8-bit traffic class field. Identifies different classes or priorities.
Flow Label
A source node can label packets with a sequence number for giving
(20 bits)
real time application service.
Payload
It is a 16-bit field specifying the size of the payload in octets,
Length
including extension headers if any in the packet.
It is an 8-bit field. A specific value for transport layer protocols,
Next Header
extension headers help to identify the type of header following IPv6
header. The purpose of this field is same as that in IPv4 protocol.
It is a replacement for the time to live field in IPv4 protocol. The
value in this field would be decremented by value 1 at each node that
Hop Limit
forwards the packet. We will discard the packet if the hop limit
reaches a value 0.
Source
128-bits assigned for storing the originators IPv6 address within the
Address
packet.
Destination
129-bits assigned for storing the intended recipient of the packet.
Address
Table 3.1 IPv6 Header Elements
20
3.2.3.1 Extension Headers
These headers are placed in between the fixed IPv6 header and the upper layer protocol
header. Next header fields will help to maintain the link between the series of headers.
The next header field present in the fixed IPv6 header helps to determine the type of the
first extension header during packet processing. The next header field present within the
last extension header leads us to the type of the upper layer transport protocol. We could
say that extension headers follow daisy-chaining method in IPv6 protocol to link one
header to another. There can be zero, one or more than one extension headers within a
message. They all are distinguished with the help of next header field present within
preceding header.
The following figure helps us to visualize the concept:
Figure 3.2 Extension Headers
21
Every extension header is a multiple of eight octets; this design is to retain 8-octet
alignment for subsequent headers. Some extension header requires padding so that they
are octet in size. As indicated before, destination mode will process all the extension
headers. Every intermediate node, which includes sending and receiving node within
network path, will process some option fields such as hop-by-hop.
3.2.4 IPv6 Addressing
IPv6 addresses split into network and host parts using subnet masks. It is similar to IPv4
protocol. There is a limitation in IPv4 protocol, only one IP address per interface. In IPv6
protocol, we could assign more than one IPv6 addresses per interface. There are 128 bits
available for an IPv6 address. The first 64 bits is network part and the rest 64 bits is for
the host part. This helps in auto configuration. With 128 bits in use we have 2^128 -1
different addresses. This provides a much larger address space.
IPv6 addresses are represented in hexadecimal number system. To make it convenient, an
IPv6 address uses colon as a separator after each group of 16-bits. Colon(:) acts as a
period(.)
for
IPv4
address.
A
usable
IPv6
address
example
is:
2051:0112:0c88:9876:efc1:1200. For simplicity, leading zeroes for a 16-bit group can be
eliminated.
For
example,
the
above-specified
address
is
written
as
2051:112:c88:9876:efc1:1200. A sequence of 16-bit group containing all zeroes can be
replaced
with
“::”.
The
following
example
will
help
us
understand:
22
1234:0ab8:0:0:0:200:b123:1 is equivalent to 1234:ab8::b123:1. Thus, an IPv6 address
0000:0000:0000:0000:0000:0000:0000:0001 would eventually turn out to be ::1.
3.2.4.1 Addresses without a Specific Prefix
In IPv6 protocol, there are Unicast, Multicast and Anycast address types but no broadcast
as in IPv4. In Unicast, there are several categories such as:

Unspecified

Loopback

Scoped addresses:


Link-local

Site-local
Unspecified Address
The Unspecified is used when no address is available. It is used for initial DHCP
request and Duplicate Address Detection (DAD). It is analogous to 0.0.0.0 in
IPv4. Thus, in IPv6 we have 0:0:0:0:0:0:0:0 or ::. We cannot use unspecified
address destination address. For IPv6 it is:
23
0000:0000:0000:0000:0000:0000:0000:0000
Or can be compressed to ::

The Local-host Address
Loopback used to identify itself and it is used as a Local host IP address. For IPv4
we use 127.0.0.1, Similarly for IPv6 protocol the local-host address is:
0000:0000:0000:0000:0000:0000:0000:0001
It is compressed to ::1
Same as in IPv4, packets with the local-host address as source or destination
address should never leave the sending host and cannot be routed.

Network Part or Prefix
 Link Local Address Type
Link-locals are special addresses. They are scoped addresses – the scope is local
link such as Virtual Local Area Network, VLAN and subnets. These addresses are
new in IPv6, will only be valid on a link of an interface. They are automatically
24
configured for each interface by using the interface identifier based on Media
Access Control (MAC) address. If we use this address as destination address, the
packet never travels through a router. It provides every node an IPv6 address to
start basic communications. Link communications are possible with the help of
Link Local Address Type (LLA). The possible link communications are:
Anyone on this link, that is in the same subnet?
Anyone on this link here with a special address such as finding routers?
They begin with the following addresses as shown below. Normally the value in
place of ‘x’ is ‘0’. After every stateless auto-configuration, every IPv6-enable
interface would have and address with this prefix.
fe8x:
fe9x:
feax:
febx:
The format will look something like:
fe80:0:0:0:<interface identifier>
25
 Site Local Address Type
These addresses are similar to the RFC 1918 [11], scoped address in IPv4 today
(the scope is site or a network of link), with the added advantage that everyone
who use this address type has the capability to use the given 16 bits for a
maximum number of 65536 subnets, enabling an addressing plan for a full site. It
is comparable to the 10.0.0.0/8 in IPv4 today. Another advantage, it is possible to
assign more than one address to an interface with IPv6, you can also assign such a
site local address in addition to a global one. The addresses begin with:
fec0:
fed0:
fee0:
fef0:
These addresses cannot be used between nodes of the different site and thus
cannot be routed outside on Internet. It is quite similar to IPv4 private addresses.
The format is:
fec0:0:0:<subnet id>:<interface id>
26

Solicited Node Link-local Multicast Address
These addresses are the special addresses used as destination address in
neighborhood discovery. There is no Address Resolution Protocol (ARP) in IPv6
as compared to IPv4. An example of this address looks like:
ff02::1:ff00:1234
The used of prefix shows that this is a link-local multicast address. The suffix is
generated from the destination address. In this example, a packet should be sent to
address “fe80::1234”, but the network stack does not know the current layer 2
MAC address. It replaces the upper 104 bits with “ff02:0:0:0:0:1:ff00::/104”
leaving the lower 24 bits untouched. This address is now used on-link to find the
corresponding node which has to send a reply containing its layer 2 MAC address.
3.3 CONCLUSION
The basic overview of the protocols listed above is good enough to understand how a
cable modem requests and receives an IPv6 address from the head-end facility. This
chapter does not intend to describe any of the protocols listed above with all the working
details.
27
Chapter 4
THE ARCHITECTURE OF THE SIMULATOR SYSTEM
This chapter acts as a user guide and will describe many details of the framework for this
cable modem simulator (CMS) system. CMS is a Linux based application that is
responsible for simulating DOCSIS and IP protocol stacks for a cable modem. This
document will describe many details of simulator including the following subjects:

The overall architecture of simulator

The directory structure of the source code and its description
4.1 Connectivity
CMS resides on a Linux machine and is responsible for simulating both IP data traffic
generated by a cable modem. CMS on the other end communicates with a dummy
process that acts as head-end facility. The main functionality of this dummy process is to
acknowledge the receipt of valid IP messages, keep alive messages and provide an IPv6
address when requested by CMS. The simulation of a cable modem requires all IP
generated messages to be first encapsulated within a UDP message and then sent via a
datagram to the dummy process. As per the current design, all CMS UDP messages
terminates at the dummy process.
28
4.2 CMS Process and Architecture
CMS is a Linux based process that consists of multiple threads all sharing a common set
of libraries. The following illustration displays the basic architecture of CMS process.
State
Machine
Event Queue
Event Queue
event
State Machine
Library
Figure 4.1 Architecture of the System
Queue Library
List Library
Timer Library
Lock Library
event
DOCSIS Library
event
IP Library
Msg Library
Debug Library
Sockets
UDP
File I/O
Logging Details
Dummy Head-end
Process
State
Machine
29
The CMS process consists of the following building blocks (some of which are illustrated
above):

Threads

Signal Handlers

Generic Libraries

State Machines
We can think of CMS as a modem simulation operating system on top of Linux. The
following sections of this document will briefly cover all the building blocks that make
up the CMS.
4.2.1 CMS Threads
CMS contains a number of POSIX threads to allow multiple CMS actions for processing
them simultaneously. Several of these threads are responsible for the basic operation of
CMS, while we create other threads dynamically. As state machine is installed into CMS,
a new thread will be instantiated. This thread is responsible for receiving events from an
event queue and then executing the state machine dependent upon that event.
The following table describes all current CMS threads.
30
Thread
Description
Message TX Thread
This thread is responsible for transmitting simulation
messages to a dummy process. When a state machine wishes
to send messages to a dummy process, it will simply link the
message onto the end of a queue. The Message TX Thread
wakes up and sends all the messages on the queue via a
connectionless socket. When no messages are linked onto the
queue, the Message TX Thread will simply sleep.
Message RX Thread
This thread is responsible for receiving simulation messages
from a dummy process. It will simply block on the socket
waiting for an incoming message, if a message does not exist,
the Message RX Thread will simply sleep. Once a message
arrives, assuming that the message is valid, it will broadcast
to all state machines (which had previously subscribed to
receiving specific messages).
State Machine Threads When a state machine is installed within CMS we will create
a thread. Every State Machine thread will have an event
queue; this allows the State Machine thread to sleep when no
events need to be processed.
Table 4.1 CMS Threads
31
4.2.2 CMS Signal Handlers
In addition to the threads, CMS makes use of POSIX based signals for asynchronous
event processing. Signals to notify a CMS thread of a particular event such as timer
expiration. The following table describes all current CMS signals.
Signal
Description
Alarm Signal
This signal rises when the alarm timer expires. Upon receipt
of the alarm signal, alarm handler will execute the timer
wheel. Currently alarm is set to 10 milliseconds, thus the
smallest supported timer granularity in the system is 10
milliseconds. It provides keep alive messages.
Table 4.2 CMS Signals
4.2.3 CMS Libraries
The majority of the code in CMS lives in generic libraries. The following table describes
all current CMS libraries.
32
Library
Description
Msg Library
This library is responsible for providing the routines to
encapsulate IP messages as well as the routines required to
both send and receive messages to and from the dummy
process.
IP Msg Library
This library is responsible for providing the routines to create
all possible IP messages used by the modem.
Debug Library
This library is responsible for providing various debugging
facilities used to help in the logging of information to specific
logging files.
State Machine Library
This library is responsible for providing a mechanism to
execute various state machine methods. These methods
communicate between various state machines in CMS.
Constructor Method
Destructor Method
Parser Method
Statistics Method
Dumper Method
Start Machine Start Method
Logging Method
33
Reset Notification Method
Online Notification Method
Offline Notification Method
Timer Library
This library is responsible for providing timer wheel
implementation routines.
List Library
This
library
is
responsible
for
providing
link
list
implementation routines.
Queue Library
This library is responsible for providing the routines required
to enable intra-process and inter-process queuing.
Table 4.3 CMS Libraries
4.2.4 CMS State Machines
CMS state machines are composed of a finite number of states, events between those
states, and the event’s corresponding actions. In CMS, all state machines are encased
within a POSIX thread so that we can make sure that they operate on events in a
sequential fashion (no external interruptions are allowed). While installing a state
machine, an event queue is created and the state machine thread will simply pend on that
event queue; therefore, if there are no events to process, the thread simply will not wake
up.
34
State Machine can generate events internally only. The reason for this is to prevent other
State Machines from knowing the exact events for other State Machines. Therefore, if an
external event needs delivery to a State Machine, a callback from within the State
Machine executes and that will in turn generate an event back to the State Machine. A
good example of external events processing by State Machines is how a State Machines
notification takes place upon the receipt of CMS messages.
35
State Machine Storage
Message Queue
State Machine
Message
event
Event Queue
Message Callback
callback
Message RX
Thread
Call Back List Queue
Socket
Figure 4.2 CMS State Machine Execution
When a CMS receives message, the Message RX Thread will be responsible for
searching its callback notification list to see which State Machines previously registered
interest in receiving messages. When an interested State Machine is located, the Message
36
RX Thread will execute the State Machine’s message callback. This callback will be
responsible for enqueueing the message onto the State Machines message queue. After
successfully enqueueing the message, an event will be generated to the State Machine.
The State Machine will wake up at a later point in time, process the event and dequeue
the message.
There is no limit to the number of state machines installation within CMS; however, one
should understand that there would be system limits to the number of threads per process.
The following snippet of code shows an example of a CMS state machine.
static void *
state_machine_process( void * arg )
{
while ( TRUE ) {
event_message_t * message = NULL;
while (( message = dequeue_item_w_pend( queue )) != NULL ) {
while ( stop == FALSE ) {
o
o
execute state machine
o
o
}
free( message );
}
}
}
37
The following table describes all current by default enabled CMS state machines.
Thread
Modem-Online
Description
State The Modem-Online State Machine is responsible for
Machine
successfully bringing a modem online.
Modem-Station
The Modem- Station Maintenance State Machine is
Maintenance
State responsible for handling station maintenance responsibilities.
Machine
Table 4.4 CMS State Machines
When CMS installs a state machine, all appropriate modem instances will be able to
execute the state machine. In order for this to occur, each state machine needs to have its
own independent storage within the modem instance. This storage is actually allocated
when the modem is instantiated and to prevent one state machine from accessing other
state machine’s information. The following illustration shows how multiple state
machines use single modem instance for execution.
38
State Machine Storage
Modem Instance
State Machine Storage
State
Machine
State
Machine
Figure 4.3 Independent Execution for each State Machine
The following table contains an example of a CMS modem state machine events and
actions.
Event
Action
New State
STATE_MACHINE_START_EVENT
null_action
MAINT_STATE
39
MODEM_ONLINE_EVENT
modem_maint_modem_onli
MAINT_STATE
ne_action
MODEM_OFFLINE_EVENT
modem_maint_modem_offli
MAINT_STATE
ne_action
RNG_START_EVENT
modem_maint_rng_initializa
MAINT_STATE
tion_action
RNG_REQ_EVENT
modem_maint_rng_send_re
MAINT_STATE
q_action
RNG_RES_EVENT
modem_maint_rng_process_
MAINT_STATE
res_action
RNG_RES_VALID_EVENT
modem_maint_rng_res_vali
MAINT_STATE
d_action
RNG_RES_INVALID_EVENT
modem_maint_rng_res_inva
MAINT_STATE
lid_action
RNG_RES_TIMER_EXPIRED_EVENT
modem_maint_rng_timer_ex
MAINT_STATE
pired_action
RNG_POLL_TIMER_START_EVENT
null_action
MAINT_STATE
RNG_POLL_TIMER_EXPIRED_EVENT
modem_maint_poll_timer_e
MAINT_STATE
xpired_action
40
RETRY_EXHAUSTED_EVENT
modem_maint_rng_retry_ex
MAINT_STATE
hausted_action
STATE_DISABLED_EVENT
null_action
MAINT_STATE
Table 4.5 Modem State Machine Events and Actions
The best way to understand the flow of the above state machine is to view an output log.
Started ONLINE STATE MACHINE
Processing RNG_POLL_TIMER_EXPIRED_EVENT in MAINT_STATE
Processing RNG_START_EVENT in MAINT_STATE
Processing RNG_REQ_EVENT in MAINT_STATE
Sending RANGING REQUEST
000000: 03 05 00 01 01 00 00 22 c0 00 00 1c ff ff 01 02
000010: 03 04 05 06 00 00 00 00 00 00 00 0a 00 00 03 01
000020: 04 00 aa ee 79 00 00 00 00 00
Processing RNG_RES_EVENT in MAINT_STATE
Processing RANGING RESPONSE
000000: 03 05 00 01 01 00 00 22 c0 00 00 1c ff ff 00 00
000010: 00 00 00 00 01 02 03 04 05 06 00 0a 00 00 03 01
000020: 05 00 aa ee 79 00 00 00 00 00
41
Processing RNG_RES_VALID_EVENT in MAINT_STATE
Processing RNG_POLL_TIMER_START_EVENT in MAINT_STATE
Processing MODEM_OFFLINE_EVENT in MAINT_STATE
Processing MODEM_ONLINE_EVENT in MAINT_STATE
Processing RNG_START_EVENT in MAINT_STATE
4.2.4.1 CMS State Machine Methods
In order to provide a uniform mechanism to access information within any installed state
machine, a series of state machine methods are created. Every state machine in CMS
should support these state machine methods. When generic CMS functions or other state
machines want to communicate with each other, appropriate state machine method is
invoked. Depending upon the method, the State Machine’s information is accessible
directly or an event generated back to the State Machine. The following illustration
displays how state machine methods function in CMS.
42
Method Broadcast
Method Callback
Event Queue
State Machine
State Machine
Event Queue
Method Callback
Figure 4.4 CMS State Machine Methods
Method
Description
Constructor Method
This method will be invoked when a modem or CPE is
created
Destructor Method
This method will be invoked when a modem or CPE is
43
destroyed
Parser Method
This method will be invoked when an XML variable is
parsed
Start Machine Start Method
This method will be invoked after the configuration is
completely parsed and the state machine needs to be
started. Please note that this method should generate an
event into the State Machine and return immediately.
Logging Method
This method will be invoked in order to perform a
logging operation such as logging file creation, deletion
or write.
Reset Notification Method
This method will be invoked when a state machine
should be reset. Please note that this method should
generate an event into the State Machine and return
immediately.
Online Notification Method
This method will be invoked when a modem goes
online. Please note that this method should generate an
event into the State Machine and return immediately.
Offline Notification Method
This method will be invoked when a modem goes
offline. Please note that this method should generate an
event into the State Machine and return immediately.
Table 4.6 CMS State Machine Methods
44
4.3 Source Tree Description
All the CMS sources are located under /src directory. The following table briefly explains
the source code.
Directory
Description
src/
main.c
The main function for the CMS
executable. This is where the world
starts.
globals.h
Contains various global defines for the
CMS code base.
src/libraries
This directory contains all the shared CMS libraries and be used
by any and all state-machines
list_lib.[ch]
Basic link list implementation
lock_lib.[ch]
Basic POSIX locking implementation
queue_lib.[ch]
Basic POSIX queuing implementation
timer_lib.[ch]
Timer wheel implementation
debug_lib.[ch]
Contains various debugging utilities
ip_msg_lib.[ch]
Implement various IP messages
msg_lib.[ch]
Implements messaging between CMS
45
and the dummy process of simulator
state_machine_lib.[ch]
Contains
various
generic
state
machine utilities that focus on each
state machine’s default methods (the
methods
are
discussed
in
the
architecture portion of this document)
src/state-machines
This directory contains all the application state-machines.
Currently there are two state-machines executing; modemonline, station maintenance
modem-online
machine
state This state machine is responsible for
bringing DOCSIS, 1.0, 1.1, 2.0 and
3.0 modems online.
modem-station
maintenance
machine
src/utilities
This state machine is responsible for
state performing all station maintenance
duties for a modem.
This directory contains various CMS utilities such as CMSconfigure and CMS-simulator. CMS-configure is responsible for
generating the XML configuration files and CMS-simulator is
responsible for allowing the easy testing of the CMS by
supplying a dummy process.
Table 4.7 Source Tree Description
46
4.4 Steps Required for Adding a New State Machine
Since all state machines interface with the CMS system using only well defined State
Machine methods, the addition of another state machine is an extremely easy process. In
order to add a new state machine, please perform the following steps:

Create a new directory under state-machines that will contain the new state
machine

Go to the new directory and at a minimum create the following files contained
within the table below:
File
Description
< state-machine-name>_state.[ch]
This will contain the actual state
action routines
< state-machine-name >_state_machine.c
This will contain the actual state
machine table, a state machine
installation routine as well as all
defined state machine methods.
< state-machine-name >_state_machine_private.h
This will contain private
47
prototypes of the state machine
for consumption by <new statemachine>_state.[ch].
< state-machine-name >_state_machine_public.h
This will contain public
prototypes of the state machine
for consumption by all other
CMS code
Table 4.8 New State Machine Files
CMS main( ) should be modified to call the <state machine> installation routine.

New State Machine Example
In order to properly interface a new state machine into the CMS system,
a <state-machine-name>_state_machine.c file must be created containing the state
machine’s methods.
static void state_machine_constructor( void * instance ) {}
static void state_machine_destructor( void * instance ) {}
static void state_machine_dumper(
FILE * fp, char * tab, void * instance, logging_level_t level ) {}
48
static void state_machine_start( void * instance ) {}
static void state_machine_logging_operation(
logging_operation_t operation, void * instance, va_list args ) {}
static void state_machine_process_online_notif( void * instance ) {}
static void state_machine_process_offline_notif( void * instance ) {}
void install_<state-machine-name>_state_machine( void )
{
method_info = calloc( sizeof( state_machine_methods_t ), 1 );
assert( method_info );
method_info->constructor_cb
= state_machine_constructor;
method_info->destructor_cb
= state_machine_destructor;
method_info->parser_cb
= state_machine_parser;
method_info->dumper_cb
= state_machine_dumper;
method_info->stats_cb
= state_machine_stats;
method_info->start_machine_cb = state_machine_start;
method_info->logging_operation_cb = state_machine_logging_operation;
49
method_info->reset_notif_cb
= NULL; // not required
method_info->online_notif_cb
= state_machine_process_online_notif;
method_info->offline_notif_cb
= state_machine_process_offline_notif;
state_machine_install( get_modem_method_handle(), method_info );
}
Then
in
CMS
main()
simply
call
the
install_<state-machine-
name>_state_machine() api:
printf( "Installing State Machines" );
printf( "\t* Modem Online State Machine Installed" );
printf( "\t* Modem Station Maintenance State Machine Installed" );
printf( "\t* Modem <state-machine> State Machine Installed" );
printf( "" );
install_modem_online_state_machine();
install_modem_station_maintenance_state_machine();
install_<state-machine-name>_state_machine( void )
50
Chapter 5
CABLE MODEM ACQUIRING IPv6 ADDRESS
This chapter describes the procedure by which a cable modem acquires an IPv6 address.
The following sequence gives an overview of the power on initialization:

Offline
Cable modem is considered to be in offline mode when it is either powered off /
unable to provide service to the user under any circumstances.

Initial Ranging Phase
Scans downstream channels coming from Cable Modem Termination System
(CMTS) head-end router, collects the corresponding upstream channel descriptor
(UCD) messages. Selects a suitable downstream channel and an upstream channel
for communicating with CMTS and completes the initial ranging process.

IP Connectivity
In order to obtain a layer-3 IPv4 address, Cable Modem is required to follow the
DHCPv4 protocol and acquire IP address from an external/internal DHCP server
via CMTS router.

Time of Day (TOD)
51
This phase has been bypassed in CMS implementation. A physical Cable Modem
follows this phase in order to obtain the current time from the external/internal
TOD server via CMTS router.

Trivial File Transfer Protocol (TFTP)
TFTP phase is required to provide a configuration file to the Cable Modem. The
configuration file normally resides on a TFTP server. A configuration file
determines the quality of service offered by a Cable Modem once it comes online.
The example of a service can be downloading and uploading bandwidths.
This phase has been by-passed in this project implementation but the framework
supports further development of this phase.

Online
Cable Modem is ready to cater configured services to the user.
52
Reset State
Init Range
State
Yes
V6 capable ?
No
Link Local
State
Dhcpv4
State
Dhcpv6
State
Time of Day
State
Yes
V6 capable ?
TFTPv6 State
No
TFTPv4 State
Registration
State
Online State
Figure 5.1 State Machine for a Cable Modem
53
5.1 IP Connectivity Phase
The following flow chart describes the IPv6 provisioning only mode. A cable modem
follows the illustrated sequence to obtain an IPv6 address.
IPv6 only
provisioning
mode
Acquire IPv6
Address
IPv6 Address Acquisition
Successful
Perform ToD &
TFTP phase
TFTP successful
IPv6 Connectivity
failed
IPv6 Connectivity
Successful
Establish Ip
Connectivity End
Figure 5.2 IPv6 only Provisioning Mode
54
5.2 Details for Implementing IPv6 Only Connectivity in CMS

DHCP support, to bring Cable Modem’s online with IPv6 only provisioning
mode.
The following flow diagram illustrates the interaction of messages between a
Cable Modem, CMTS head-end facility / dummy process in our case.
CM
DHCP
Server
CMTS
MLD Report (Solicited Node Multicast Address)
Link Local
Address
Assignment
NS (Duplicate Address Detection)
No response expected to DAD
Router Solicit (RS)
Router
Discovery
Router Advertise (RA)
DHCP Solicit
DHCP v6
DHCP Advertise
DHCP Request
DHCP Reply
Relay-Forward
Relay-Reply
Relay-Forward
Relay-Reply
Figure 5.3 Message Interaction for Establishing IPv6 Connectivity
55

In order to initiate IP connectivity phase, Cable Modem creates a unique Link
Local Address. The link local address is created according to the [13]. Usually, in
order to create a link local address the 48 bit MAC address of the Cable Modem is
used. The link local address for a Cable Modem MAC address 0025.2e2d.7262 is
calculated as : fe80::225:2eff:fe2d:7262/64.

Cable Modem must send a Network solicit message (NS) with the created link
local address as the destination address. If there were any other duplicate host on
the network using the same link local address, duplicate host sends the Network
Advertize message in response. Thus, a cable modem knows that it could not use
this link local address as it is already in use. Further, Duplicate Address Detection
(DAD) is used by CMTS router to determine uniqueness of the created link local
address.

Once the link local address is unique, the Cable Modem obtains the neighboring
routers information by sending Router Solicit (RS) message.

The neighboring and default router discovery is specified in [14].

If a cable modem is unable to receive a properly formatted response to the Router
Solicitation (RS) message. The response in the form of Router Advertise (RA)
message, cable modem should consider IPv6 Address acquisition as failed.

After creating a unique link local address, based on the received M bit value in the
Router Advertise message from a router, Cable Modem initiates DHCPv6
56
communication dialogue to obtain IP address from the DHCP server, and also the
TFTP parameters required to obtain the tftp config file from the TFTP server.

Cable Modem sends a DHCP solicit message with certain parameters required for
the TFTP stage as well as IP address acquisition. The message includes:
1) A client identifier option containing the DUID (DHCP Unique Identifier) for this
Cable Modem. For details refer section 9.1 of [1].
2) IA_NA to obtain its IPv6 management address.
3) A vendor class option containing 32-bit number “4491” and string “docsis3.0”.
This is mapped directly on the DHCP server. We configure the DHCPv6 options
on the server with these corresponding parameters in order to respond back with
the required parameters to perform DHCPv6 with requesting cable modem.
To make it simple, DHCP solicit message is a requesting query from the DHCP
server where we ask for all the required parameters to configure cable modem.
Therefore, a cable modem can perform the remaining phases successfully.
Note: For more details on all the required options on the vendor specific option
required in the DHCP solicit refer section 10.2.5.2.3 in [12].
4) Depending on the DHCP solicit message from Cable Modem, DHCP server
responds with the requested parameters in the form of DHCP advertize message.
5) Once the DHCP advertize message from all the available servers is obtained.
Thus, Cable Modem sends a DHCP request to the chosen DHCP server and wait
for the IP address allocation in the form of the DHCP response message.
57
6) Once it receives DHCP reply, it would have the assigned IP address for itself. By
this time, the IPv6 connectivity is established and a unique IPv6 address is
assigned to the Cable Modem.
58
Chapter 6
CONCLUSION AND FUTURE DEVELOPMENT
Cable Modem simulator follows the guidelines of Data-Over-Cable Interface
Specification. The original document on www.cablelabs.com focuses on the requirements
and expectations from a cable modem. I have implemented IP connectivity stage within
the lifecycle of a cable modem. However, the overall framework of the entire system
does support future development. Future development includes development of other
phases such as Initial Ranging, TOD, TFTP and applications built on top of it. The
framework of the simulator defines important events corresponding to the initialization
stages so adding a new state and implementing it in the future should not be an issue.
Currently, the state machine already accommodates all the initialization stages within the
lifecycle of cable modem. Thus, no change in the state machine is required in the future
until the overall initialization process is revised.
I learned key features of networking specifically in IPv6 protocol area during this project.
This project helped me gain important information over the functioning of a cable
modem, a product that we regularly use in our day-to-day life.
59
REFERENCES
[1]
R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. RFC 3315:
Dynamic Host Configuration Protocol for Ipv6 (DHCPv6), IETF, July 2003.
http://www.ietf.org/rfc/rfc3315.txt.
[2]
R. Hinden, S. Deering. RFC 4291: Internet Protocol Version 6 (Ipv6) Addressing
Architecture, IETF, July 2003. http://www.ietf.org/rfc/rfc4291.txt.
[3]
S. Deering, R. Hinden. RFC 2460: Internet Protocol Version 6 (Ipv6)
Specification, IETF, December 1998. http://www.ietf.org/rfc/rfc2460.txt.
[4]
R. Gilligan, E. Nordmark. RFC 2893: Transition Mechanisms for IPv6 Hosts and
Routers, IETF, August 2000. http://www.ietf.org/rfc/rfc2893.txt.
[5]
C. Huitema, B. Carpenter. RFC 3879: Deprecating Site Local Addresses, IETF,
September 2004. http://www.ietf.org/rfc/rfc3879.txt.
[6]
R. Hinden, B. Haberman. RFC 4193: Unique Local IPv6 Unicast Addresses,
IETF, October 2005. http://www.ietf.org/rfc/rfc4193.txt.
[7]
G. Hutson, A. Lord, P. Smith. RFC 3849: IPv6 Addresses Prefix Reserved for
Documentation, IETF, July 2004. http://www.ietf.org/rfc/rfc3849.txt.
[8]
Cisco Systems. DPC2203 and EPC 2203 VoIP Cable Modem Installation and
Operation Guide. 2008.
http://www.cisco.or.at/en/US/docs/video/at_home/Cable_Modems/2200_Series/4
011044_A.pdf
[9]
Simon Amor. Introduction to network functions in C. September 2008.
http://shoe.bocks.com/net/#intro
[10]
Douglas E. Comer, David L. Stevens. Internetworking with TCP/IP Volume III:
Client Server Programming and Applications. Prentice Hall, 1996.
[11]
Internet Protocol Version 6 (IPv6). January 2010,
http://www.tenouk.com/internetprotocolversionipv6.html
60
[12]
Cable Television Laboratories, Data-Over-Cable Service Interface Specification
DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification. July 2010.
http://www/cablelabs.com/specifications/CM-SP-MULPIv3.0-14-101008.pdf
[13]
S. Thomson, T. Narten, T. Jinmei. RFC 4862: IPv6 Stateless Address
Autoconfiguration, IETF, September 2007. http://www.ietf.org/rfc/rfc4862.txt.
[14]
T. Narten, E. Nordmark, W. Simpson, H. Soliman. RFC 4861: Neighbor
Discovery for IP Version 6 (IPv6), IETF, September 2007.
http://www.ietf.org/rfc/rfc4861.txt.