draft-hadi-i2rs-forces-gap-analysis-00 provides an executive summary introduction to ForCES.
The requirements listed here were taken from various I2RS documents as well as perceived requirements.
We first list the protocol then model analysis.
The ForCES architecture provides (very) few simple protocol verbs which act upon a multitude of nouns as represented by the ForCES model. This allows powerful programmatic interfaces i.e the "API" construct boils down to a formulation of operations in the form of a "verb" acting on a "noun" followed by "optional arguements". From that perspective it is very similar to http (where the commands map to http commands and the htpp uris map to ForCES paths). In other words, the ForCES semantic allows composing of rich services on top of the basic grammar.
Extensibility
The I2RS protocol MUST be extensible
The ForCES protocol is extensible. New top Level TLVs can be introduced. New flags to extend paths and semantics of commands can be added.
*Protocol operations
The I2RS protocol, using the I2RS data model, MUST allow clients to:
a) connect to I2RS agents
The ForCES protocol does not meet this requirement as it stands today.
The relationship would be more the agent initiating the connection to the client (as opposed to the required reverse)
b) determine the capabilities and capacities exposed by each agent.
The ForCES protocol facilitates discovery of capabilities and capacities of a modelled Entity.
c) control(adding/updating/deleting) and query the various I2RS objects owned by an agent
The ForCES protocol does not fully meet this requirement.
For example, an update and a create/add operation are one and the same in the programmatic interfaces
d) subscribe to and receive agent-generated events
The ForCES protocol has very powerful publish-subscribe event model which meets this requirement.
e) analytics, audits and logging
*protocol requirements being ability to express time stamps and identity not sure if this calls out for "streaming" of data (as opposed to message based) and whether a requirement to call out here is separate "channel" for this kind of activity.
TBA
ForCES protocol is defined to work with IPSec and therefore meets these requirements. A transport module using TLS may be more friendly for I2RS (but would need to be defined)
Any client to agent object access must be subject to mutual authentication, authorization and resource accountability. The protocol MAY need to carry information to enable this requirement.
There is a gap that the ForCES protocol needs to address to properly meet this I2RS requirement.
Several proposals are made in section 4.6 of draft-hadi-i2rs-forces-gap-analysis
a) The I2RS protocol MUST be capable of supporting at least thousands of clients end points. i.e there should be no limitation in the protocol definition which restricts the agent from handling many clients (e.g in a header definition dont use an 8bit field to define a client id)
ForCES protocol meets this requirement
b) Multiple pipelined Operations: A single client should be able to send multiple independent operations via I2RS without being required to wait for each to complete before sending the next. The protocol SHALL allow for such mechanisms (eg using windowing etc)
ForCES protocol meets this requirement
c) High-Throughput (from RIB model draft) need
It should be possible to do bulking of table information in either direction (eg a single request to dump a RIB table or a single transaction to update large amounts of table rows).
The ForCES protocol is binary and supports command and data batching. A single get request allows the ForCES protocol to send in either client/agent direction a large number of table entries.
[achieving 100s of thousands of table updates/second should be possible].
d) High transaction rate: (from problem statement draft)
At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second above what basic Netconf or a propretiary CLI can.
The ForCES protocol is binary with design to have high transaction rates.
e) Low Latency: It MUST be possible to complete simple I2RS operations within a sub-second time-scale. It SHOULD be possible to to possible to process bulk data intensive operations (eg a table dump or update) with low latency.
The ForCES protocol is binary with very low operational overhead. The ForCES protocol achieves these goals.
f) Filterable Information Access: The protocol MUST allow to extract information in a scalable fashion that is more easily used by clients, the ability to specify filtering constructs in the I2RS protocol request MUST be possible.
The ForCES protocol does not have proper semantics to achieve this goal. It is not difficult to add it since the semantics already support definition of filter keys.
The ForCES architecture/protocol does not allow for this.
ForCES only allows a single master writer and multiple readers. This was done for the sake of simplicity of the HA mode. It is possible to meet some aspect of this requirement as was proposed in http://www.ietf.org/proceedings/86/slides/slides-86-forces-7.pdf
The ForCES protocol through the use of appropriate transport meets these requirements.
The ForCES protocol meets these requirements.
ForCES architecture was designed with this requirement in mind.
ForCES meets these requirements.
ForCES meets these requirements.
Various changes will be needed for the ForCES protocol to be compliant. These are:
The ForCES protocol meets most of the requirements for I2RS.
ForCES protocol is tied to the ForCES data model.
ForCES protocol could be made to meet requirements. Speak no speak evil of other proposals.
1) The data model MUST be able to describe the target objects
a) with formal constraints for validation purpose
b) basic read-write access permissions
c) class object capabilities and capacities
d) event object definitions with publish-subscribe semantics
The ForCES data model meets these requirements.
2) The model MUST be object oriented.
This allows it to extensible in the form of classes and sub-classing.
The ForCES data model meets these requirements.
3) The data model MUST be able to express semantics of instances.
The ForCES data model meets these requirements by being Object oriented.
4) The data model MUST be able to manage variation
a) Presence compliance of defined objects should be possible to express. (eg optional vs mandatory)
b) Default values MUST be possible to specify (facilitate templating)
c) Hierarchies MUST be possible to specify
The ForCES data model meets these requirements.
5) Data Model MUST be able to handle Object Life cycle management.
Typically this means:
a) Versioning support
b) being able to handle both backward and forward compatibility
The ForCES data model meets these requirements.
Data model definitions for various objects will need to be defined - but this is a given regardless of which data model used.
The ForCES data model meets all of the requirements for I2RS.
ForCES meets the requirements. Speak no evil of other proposals.
The content of this page was last updated on 2014-05-14. It was migrated from the old Trac wiki on 2023-01-21.