The functional architecture approach

Interoperability with other subsystems. 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 goals are typically as quantitative as possible, but if it is difficult or impossible to assign numbers to what the protocol is supposed to do, a qualitative description is acceptable. 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. After the goals are complete, an a

rchitecture is developed for the system. The architecture is often called a “framework,” and includes descriptions of the major network entities and how they interact at a high level. The protocol design on interfaces between network entities then follows. Not every IETF protocol design follows this process; however, it is often used when new system components are introduced.

Read the rest of this entry »