Jeff,
I could add this to the wiki and we could keep updating it.
Next i will do something similar for the model.
Dean/Andy - Feel free to throw rotten tomatoes; at least that way we
have something to talk about.
cheers,
jamal
The I2RS protocol must satisfy the following requirements.
1) Model-Driven Programmatic Interfaces
The I2RS protocol MUST work in conjunction with I2RS data model
to facilitate programmatic interfaces
2) Extensibility
The I2RS protocol MUST be extensible
3) Protocol operations
The I2RS protocol, using the I2RS data model, MUST allow clients to:
a) determine the capabilities and capacities exposed by each agent.
b) control(adding/updating/deleting) and query the various I2RS objects
owned by an agent
c) subscribe to and receive agent-generated events
d) 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.
4) Support for Secure Communication between clients and agent.
I2RS protocol communications must allow for mutual message authentication,
and different levels of integrity, confidentiality, and replay protection
of packets.
5) Client Identity and Authentication
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.
6) Scalability
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)
b) Multiple pipelined Operations: A single client should be able
to send multiple operations via I2RS without being
required to wait for each to complete before sending the next. The
protocol SHALL provide such mechanisms (eg windowing etc)
c) High-Throughput: 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.
XXX: I think we need to throw in some numbers here ..
[achieving 10s to 100s of thousands of table updates/second should be
possible].
protocol requirement here would be allowing for batching.
d) 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.
e) 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.
7) Multi-Headed Control: Multiple clients may communicate to the
same I2RS agent. It is necessary that the I2RS agent can handle
requests from multiple clients to the same object within constraints of
the client access authorization.
8) Reliability
The I2RS protocol will be used to transport information that
requires varying levels of reliability. By strict or robust
reliability in this requirement we mean, no losses, no
corruption, no re-ordering of information being transported and
delivery in a timely fashion.
a) Some information or payloads, such as subscribed-to events
may not require robust reliability (can tolerate some degree of losses).
c) Payloads such as configuration information from clients
to the I2RS agent or responses from the I2RS agent
are mission critical and must be delivered in a robust
reliable fashion. Thus, for information of this sort, I2RS
MUST either provide built-in protocol mechanisms or use a
reliable transport protocol for achieving robust/strict
reliability.
9) Message Priority
The I2RS protocol MUST provide a means to express the protocol
message priorities. As various types of messages are expected,
their level of importance will be different depending on congestion.
10) Protection against node overload
based on CPU overload or queue overflow to either an agent resource
or client(s).
XXX: This may end up being an implementation issue/
Agents/clients utilizing the I2RS protocol can be subjected
CPU overload or queue overflow. The I2RS agent MUST be robust
under such conditions.
11) Transactions capability (section 7.9 of architecture doc)
The protocol must be able to express error handling for batched
operations. These are:
- Perform all or none
- Perform until error
- Perform all storing errors
12) Transport independence
Not sure how well this is a fit. It may complicate things.
If we were to separate the semantics of the I2RS protocol from the underlying
transport protocol then we could allow for more flexibility of different
characteristics.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
