The functional architecture approach

A good compromise process for defining system requirements that trades off rigor against flexibility has been developed by the IETF. A set of lightweight requirements, called "goals," is developed for the system. The primary distinction between goals and requirements is that there is no intent to regress the final protocol design back onto the goals after the protocol design is complete. The goals are meant to be a set of flexible design guidelines. The same kinds of subjective, non-technical criteria that arise when developing formalized requirements also arise when developing goals. The difference is that because the intent of goals is not to rigidly structure the system/protocol design process, there is more room for flexibility during the design. The protocol design on interfaces between network entities then follows. While the frameworks developed during IETF protocol design are good at defining where interfaces between distributed network components need interoperable protocol design, such frameworks are often not very specific about what the different network entities do and what functions the protocol should perform. A functional architecture approach more accurately characterizes these points. The functional architectural approach is more formalized than the framework approach, while, at the same time, maintaining flexibility through the goals. Given a set of goals for a protocol or network system, the functional architecture approach for developing a new subsystem architecture from scratch consists of the following sequence of steps:

1. Using the requirements or goals, define a set of functions which the new subsystem must implement in order to achieve the goals.

2. Group the functions into a set of functional entities with communicating interfaces.

3. Decide which functional entities will be implemented together on a single network device and group these together; communication between the functions on the same device is handled through programmatic interfaces.

4. Define the interfaces between distributed functional entities where protocol design is required.

5. Decide which interfaces are open and require standardized protocols for interoper- ability purposes and which interfaces are closed and are therefore candidates for vendor-specific protocols.

Random Posts


Advertising



Comments are closed.

Advertising

Enter your email address:

Delivered by FeedBurner

Links