The next steps in protocol initialization deal with the registration of modules and callback routines and initialization of interfaces at the higher and lower layers. Subsequently, more protocol tasks may also need to be created. In a router, there could be a root task for TCP/IP subsystem which is responsible for all the protocols in the suite. The root task would initialize and spawn off the additional tasks (IP,
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.
Table of Contents
Designing Embedded Communications Software Foreword
Preface
Chapter 1 - Introduction
Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning
Chapter 4 - Protocol Software
Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software
Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development
Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References
Index List of Figures List of Tables List of Listings List of Sidebars
TCP, UDP). Each of the tasks can perform its own initialization using the sequence outlined.
4.1.6 Protocol Upgrades
Communications equipment is critical to the functioning of the network. This means that it should not taken out of commission during upgrades, but this is not always possible. In certain environments like the core of the Internet, routers cannot go down for system upgrades. There are several schemes for handling this, including redundancy, protocol task isolation, and control and data plane separation. In particular, protocol task isolation is becoming common in new designs.
Instead of a monolithic design, in which all protocol tasks are linked in with the RTOS and provided as a single image, some vendors are using a user mode—kernel mode design to isolate tasks. The key enablers for this approach are:
Memory protection between tasks or processes Ability to start and stop tasks or processes Plane separation between forwarding and routing
Consider a case where an IS–IS routing task runs as a user mode process in UNIX with the actual IP forwarding done in the kernel (with hardware support, as appropriate). If the IS–IS task needs to be upgraded, we can configure the current IS–IS task to save its configuration in a common area (say as a file on the same UNIX system), kill the task and start the “new” (upgraded version) IS–IS task. This upgrade task picks up the configuration from the file and establishes a connection with the IP
forwarding in the kernel. Forwarding will continue uninterrupted, and so will the other protocol tasks in the system.
UNIX, Linux, and BSD variants are being used as the operating systems of choice in some of the new communications equipment. In multi-board configurations, several equipment vendors run modified versions of Linux or BSD UNIX on the control blade. These modifications are usually in the area of process scheduling and code optimization in the kernel.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.
Table of Contents
Designing Embedded Communications Software Foreword
Preface
Chapter 1 - Introduction
Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning
Chapter 4 - Protocol Software
Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software
Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development
Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References
Index List of Figures List of Tables List of Listings List of Sidebars
4.2 Summary
Protocols in a system may be standards based or proprietary. They may be stateful or stateless.
Stateful protocols are realized using state machines, which may be implemented via switch–case constructs or state event tables. More than one state machine may be present in a protocol implementation.
PDUs are preprocessed and provided as inputs to the state machine. Protocol interfaces can include drivers, buffers, timers, and events along with various forms of IPC. Protocol management includes configuration and control of its management parameters, including saving and restoring of
configuration. Upon initialization, protocols will need to use settable sizing variables to avoid recompilation.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.
Table of Contents
Designing Embedded Communications Software Foreword
Preface
Chapter 1 - Introduction
Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning
Chapter 4 - Protocol Software
Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software
Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development
Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References
Index List of Figures List of Tables List of Listings List of Sidebars
4.3 For Further Study
State machines are used in several areas, including hardware design, object modeling, and so on.
Martin (1998) provides a good introduction to state machines using UML. Perlman (1999) and
Tanenbaum (2002) provide detail about protocol operation, including routing protocols. Stevens (1998) discusses several aspects of networking under UNIX.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.
Table of Contents
Designing Embedded Communications Software Foreword
Preface
Chapter 1 - Introduction
Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning
Chapter 4 - Protocol Software
Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software
Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development
Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References
Index List of Figures List of Tables List of Listings List of Sidebars
4.4 Exercises
A hardware port can have two administrative states—disabled and enabled. Operationally, it has two states—up and down, based on the physical connectivity. If the port is disabled, the operational status is designated down. Devise a simple state machine to demonstrate the administrative and operational status of the port.
1.
Show the SET and Switch–Case implementation for Problem 1.
2.
Outline the steps in PDU preprocessing of an IP packet.
3.
A controller supporting 4 Ethernet ports has been replaced by another controller supporting 8 ports. List the device-independent adaptation layer and device-specific layer functions, for applications to migrate to the new driver in a transparent manner.
4.
The text discusses use of a UNIX-like environment for protocol restarts. Discuss alternate methods.
5.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.
Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning
Chapter 4 - Protocol Software
Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software
Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development
Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References
Chapter 5: Tables and Other Data Structures
Earlier chapters specified that communications software modules use several tables for their operation.
One of the functions of control plane software is building tables for data plane operations. This chapter details some of the tables and other data structures typically used in communications systems and discusses the related design aspects. While the term “table” implies a data structure involving
contiguous memory, this chapter uses the term to also signify data structures with multiple entries, each of the same base type.
5.1 Tables
Tables are used for storing information referenced by the communications system. In a router, a forwarding table is used by the forwarding software/hardware to forward packets. In a frame relay switch, a connection table can provide the switch map from one Permanent Virtual Circuit (PVC) to another. Global configuration and port-related configuration for a device can be stored in tables. The key issues with tables are:
Tables are referenced for both reading and writing. So, both storage and access methods should be optimized for frequent references.
1.
Tables can be stored in different parts of memory depending upon their application. For
example, forwarding tables can be located in fast SRAM (Static Random Access Memory), while other tables such as configuration and statistics are stored in slower DRAM (Dynamic Random Access Memory).
2.
Tables can also be organized according to the access method. For example, an IP forwarding table can be organized in the form of a PATRICIA tree. This structure is commonly used to optimize the access of the entries using the variable-length IP address prefix as an index into the table. A MAC filtering/forwarding table used in a Layer 2 switch often uses a hashing mechanism to store and access the entries. Hashing yields a fixed-length index into the table and is
commonly performed by a bit-level operation on the six-byte destination MAC address in a frame.
3.
5.1.1 Using Tables for Management
Configuration, control, status, and statistics information are four different types of management information that can be represented via tables.
Configuration—refers to the read–write (or read-only) information used to set the parameters and boundaries for the operation. For example, a password is a configuration parameter.
Control—indicates read–write information used to change the behavior of the communications software module. For example, enabling or disabling a protocol is treated as control.
Status—specifies read-only information that provides details about the current state of operation.
For example, the operational status of an interface is considered a status variable.
Statistics—refers to read-only information that the module counts or monitors. For example, a variable that counts the number of packets received by the module is a statistics variable.
In the following discussion, the term “Configuration variables” represents both Configuration and Control variables.
The following sections outline some tables (using illustrative data structures) with information about their allocation, organization, and use.