Internet DRAFT - draft-rfernando-i2rs-protocol-requirements
draft-rfernando-i2rs-protocol-requirements
Network Working Group R. Fernando
Internet-Draft J. Medved
Intended status: Standards Track Cisco Systems
Expires: April 23, 2014 E. Crabbe
Google
K. Patel
Cisco Systems
October 20, 2013
I2RS Protocol Requirements
draft-rfernando-i2rs-protocol-requirements-00
Abstract
The Interface to Routing System (I2RS) allows an application to
programmatically query and modify the state of the network. This
document defines requirements for an I2RS protocol between
applications (clients) and network elements (servers).
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2014.
Fernando, et al. Expires April 23, 2014 [Page 1]
Internet-Draft I2RS Protocol Requirements October 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. I2RS Protocol High Level Design Objectives . . . . . . . . . 5
4. I2RS Protocol Requirements . . . . . . . . . . . . . . . . . 7
4.1. General Assumptions . . . . . . . . . . . . . . . . . . . 7
4.2. Transport Requirements . . . . . . . . . . . . . . . . . 8
4.3. Identity Requirements . . . . . . . . . . . . . . . . . . 10
4.4. Message Encoding Requirements . . . . . . . . . . . . . . 11
4.5. Message Exchange Pattern Requirements . . . . . . . . . . 11
4.6. API Method Requirements . . . . . . . . . . . . . . . . . 13
4.7. Service and SDM Requirements . . . . . . . . . . . . . . 14
4.8. Security Requirements . . . . . . . . . . . . . . . . . . 16
4.9. Performance and Scale Requirements . . . . . . . . . . . 17
4.10. High Availability Requirements . . . . . . . . . . . . . 18
4.11. Application Programmability Requirements . . . . . . . . 19
4.12. Operational Requirements . . . . . . . . . . . . . . . . 19
5. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Fernando, et al. Expires April 23, 2014 [Page 2]
Internet-Draft I2RS Protocol Requirements October 2013
I2RS defines a standard, programmatic interface for state transfer in
and out of the Internet's routing system. I2RS is intended to
automate network operations - it will allow applications to quickly
interact with routing systems and to implement more complex
operations, such as policy-based controls.
[I-D.ietf-i2rs-problem-statement] gives detailed problem statement
for I2RS, while [I-D.ietf-i2rs-architecture] defines its high-level
architecture.
This document expands on the required aspects of a protocol for I2RS,
described in Section 5 of [I-D.ietf-i2rs-problem-statement], and
refines I2RS protocol requirements formulated in Section 6 of
[I-D.ietf-i2rs-architecture]. The purpose of this document is as
follows:
1. To help stakeholders (equipment vendors, operators, application
programmers or interested IETF participants), to arrive at a
common understanding of the critical characteristics of the I2RS
protocol(s).
2. To provide requirements to designers of the I2RS framework and
protocols on aspects of the framework that warrant significant
consideration during the design process.
3. To allow the stakeholders to evaluate technology choices that are
suitable for I2RS, to identify gaps in these technologies and to
help evolve them to suite I2RS's needs.
2. Terminology
This document uses the following terminology definitions.
Service: For the purposes of I2RS, a service refers to a set of
related state access functions together with the policies that
control it's usage. For example, the 'RIB service' is a service
that provides access to state held in a device's RIB.
Server: Is a system that implements one or more services that can be
accessed by client systems via well defined interfaces (APIs). A
server can export multiple services. A server is typically a
network device. [ed: as an aside, I still find this usage to be
completely counterintuitive]
Client: A system that uses a service implemented by a server through
a well defined interface. A client can make use of multiple
services from multiple servers.
Fernando, et al. Expires April 23, 2014 [Page 3]
Internet-Draft I2RS Protocol Requirements October 2013
Participants: The server and client are collectively referred to as
the participants of a service.
Transport: Any end-to-end mode of communication between a server and
a client that allows exchange data the exchange of data. In
principle, the transport hides the topology and other network
properties from the participants of a service.
Messages: Messages are logical units of data that are exchanged
between service participants.
Message Exchange Pattern: A categorization of a way in which
messages could be exchanged between service participants. MEPs
specify the sequence, order, direction and cardinality of messages
exchanged. Request-response and asynchronous notifications are
examples of MEPs.
Message Data Model: The schema representing the structure of
messages being exchanged between the service participants. The
MDMs can specify certain constraints such as data type, length,
format and valid values of fields in messages.
Message Encoding: The "wire" representation of messages exchanged
between service participants.
API Method: Is an application level procedure or a function that is
invoked by the client to query or modify the state held in the
server.
Service Scope: Is the functional scope of a service. The service
scope is established during the service definition phase.
[definition needs work]
Service Data Model: The schema representing the conceptual structure
of the state held in the server for a given service. The SDMs can
specify certain constraints such as the data type, length, format
and allowed values for fields representing the state. They also
describe the relationship between various state elements that
constitute the state.
Modeling Language: A language that defines schema for Message Data
Models and Service Data Models.
Namespaces: A method for uniquely identifying and scoping of schemas
declared for messages and services. Namespace is an important
consideration when defining services and messages.
Fernando, et al. Expires April 23, 2014 [Page 4]
Internet-Draft I2RS Protocol Requirements October 2013
Service State or State: Is the general data held by the server for a
given service.
State Element: A readable or writable state present in the server.
The term 'State Element' may refer to states at different levels
of granularity.
State Identifier: A unique identity for the state element. The
identifier is derived from the SDM and uses the same naming
convention as the SDM. State Identifiers may be viewed as the
'key' for the state.
State Value or 'value': A value that is assigned to a particular
state identifier (key). The state is referred to using the State
Identifier or 'key' in operations that sets or transfers the value
of the state.
State Owner: Identity of the client that was the source of a state
held in the server.
State lifetime: The duration which the state is maintained in the
server.
Datastore: The physical mechanism used to store a service's state.
Capabilities: Capabilities represents the functionality supported
by a server including the services supported and exported to
clients.
Authentication: A mechanism that allows a server to recognize the
identity of a client.
Authorization: A mechanism that allows determination of what an
authenticated client is allowed to do.
Confidentiality: Specifies if data remains confidential while in
transit between service participants.
Policy: For the purposes of this document, a policy is an explicit
user configurable modification to the default behavior of the
system. The enforcement could be conditional; a given policy
could potentially become active only when certain conditions are
met.
3. I2RS Protocol High Level Design Objectives
The core guiding principles and objectives that should be used in
defining the specifics of the I2RS protocol(s) are as follows:
Fernando, et al. Expires April 23, 2014 [Page 5]
Internet-Draft I2RS Protocol Requirements October 2013
HLO-1. Design for Scale and Performance: is a key criteria for
making design choices. The design should meet current and future
performance and scale needs. Design patterns that allow us to
compose a scalable, high performing system are well understood and
should be utilized where possible.
HLO-2. Extensible: I2RS will be deployed in environments that will
evolve over time. Hence the system should be designed with
provisions that will allow significant modifications/extensions to
be added to existing mechanisms. An extensible and future-proof
design will drive better adoption as it is a promise against
future technology churn.
HLO-3. Promote Reuse: Reuse in this context refers to using existing
tools, technologies and mechanisms instead of inventing them from
scratch. It also refers to reusing a network device's current set
of capabilities that applications could harness without
reinventing them from scratch.
HLO-4. Promote Portability: Portability refers to the ease with
which software written for one device or environment can be moved
to work seamlessly with another device or environment to achieve
similar functionality. A fundamental requirement for I2RS is to
achieve predictive and consistent behavior when applications are
migrated from one platform or environment to another.
HLO-5. Security: I2RS may be deployed in environments where it might
be subjected to threats and denial-of-service attacks that might
cause intentional damage to the functioning of a network. This
could be in the form of loss of service, degradation of
performance, loss of confidentiality, etc. Therefore, the I2RS
protocol must provide basic security mechanisms including but not
limited to authentication, authorization, confidentiality along
with sufficiently expressive policy requirements for each.
HLO-6. Separation of concerns: The components of the system should
be decoupled from each other as much as possible to achieve clear
separation of concerns. This modularity would allow for
interchangeable design and implementation choices that address the
individual components requirements.
HLO-7. Robustness: Robustness is the ability of a system to operate
in the face of failures and errors. It is also its ability to
correctly and predictably recover from such errors and to settle
to a known state. Since applications that use the I2RS framework
are remote and would be controlling the entire network, ensuring
fault tolerance is an important consideration.
Fernando, et al. Expires April 23, 2014 [Page 6]
Internet-Draft I2RS Protocol Requirements October 2013
Most of these requirements cut across all the components of the
system and hence should be kept in mind while designing each
component and the system as a whole.
4. I2RS Protocol Requirements
This section is divided into multiple sub-sections, each dealing with
a specific consideration of I2RS protocol design. As we list the
requirements under each subsection, we'll annotate each requirement
with what high level objectives they meet. Additional reasoning is
additionally provided where appropriate.
4.1. General Assumptions
This section captures the general, high level assumptions of the I2RS
framework. The context for defining protocol requirements is shown
in the following figure.
+--------+ +--------+ +--------+
| Client | ... | Client | .... .... | Client |
+--------+ +--------+ +--------+
^ ^ ^
| | |
| | |
| | |
| | |
| | |
| | I2RS |
| +----+-------------+ |
| | | |
| I2RS | | I2RS |
+-----------|--------------+ | +-------+
| | | | |
V V V V V
+-----------+ +-----------+
| Server | | Server |
+-----------+ +-----------+
Figure 1: Protocol requirements context
Since the design choices for the I2RS framework are many, some
simplifying assumptions could make the framework requirements more
tangible and useful.
Fernando, et al. Expires April 23, 2014 [Page 7]
Internet-Draft I2RS Protocol Requirements October 2013
GEN-1: Programmatic access to the state held in a network device is
provided to an application by exposing a set of API's from the
device to the application. Due to this characteristic, I2RS is a
client-server protocol/framework. I2RS must provide mechanisms
for the client to discover services that a server provides.
GEN-2: The client can use the APIs provided by the server to
programmatically add, modify, delete and query state held in the
server. Additionally clients can register for certain events and
be notified when those events occur.
GEN-3: The client and the server communicate using a simple
transport connection. The client initiates the transport
connection to the server. The server does not know the number and
timing of the connections from its clients.
GEN-4: A service provides access to the state held in the server
structured according to the SDM of that service. A service allows
a client the ability to manipulate the service state.
GEN-5: The I2RS MUST define a data model to describe the SDMs
supported in the server and MUST define a data modeling language
to formally describe that data model. I2RS MUST specify the
mapping from the service data model to the message data model and
subsequently to the client API.
4.2. Transport Requirements
The transport layer provides connectivity between the client and the
server. This section details the transport requirements.
TR-1: There should exist a default transport connection between the
client and the server for communication. This control connection
is point-to-point and should provide in-order and reliable
delivery of data in both directions. The simplest I2RS setup
would only have a single transport session between the
participants.
TR-2: Depending on the data being exchanged, there may be
additional transport connections between the client and server
defined in future. The characteristics of these additional
transport connections will be dictated by the requirements that
create them.
TR-3: The transport connection between the client and server MUST
have mechanisms to support authentication, authorization and to
optionally provide confidentiality of data exchanged between the
client and the server. See Section 4.8 for more details.
Fernando, et al. Expires April 23, 2014 [Page 8]
Internet-Draft I2RS Protocol Requirements October 2013
TR-4: A client could connect to multiple servers. Similarly, a
server could accept connections from multiple clients. Any
participant may initiate the transport connection.
TR-5: The exact technology used for the transport layer should be
replaceable. There should be a single mandatory transport that
must be supported by all participants. This requirement will
ensure that there is always an interoperable transport mechanism
between any client and any server.
TR-6: Clients and servers by default communicate using a point-to-
point transport connection.
TR-7: Point-to-multipoint transports are mainly used to scale the
system by avoiding ingress replication when the same message has
to be delivered to multiple receivers. P2MP transport would work
hand-in-hand with a P2MP MEP. The subject of P2MP transport and
P2MP MEP is for future work.
TR-8: Once the transport connection is established, it is desirable
to reuse it to perform multiple operations. This requirement
ensures that the system scales by amortizing the session setup
cost across multiple operations. Session down events may not have
an impact on the state maintained by the server.
TR-9: After the transport is established, the participants exchange
capabilities and other session parameters before exchanging
service related messages.
TR-10: Messages pertaining to multiple services could be exchanged
over a single transport connection.
TR-11: The "default" transport connection between a client and a
server is purely for control plane message exchanges. Data plane
packets are not expected to be sent over this "default"
connection. When required, packets to be extracted from or
injected to the data plane could be designed as a service in
itself that sets up a separate packet injection/extraction channel
that provides the correct characteristics.
TR-12: For operational reasons, a participant MUST be able to detect
a transport connection failure. To satisfy this requirement,
transport level keep-alives could be used. If the underlying
transport connection does not provide a keep-alive mechanism, it
should be provided at the I2RS protocol level. For example, if
TCP is used as a transport, TCP keep-alives could be used to
detect transport session failures.
Fernando, et al. Expires April 23, 2014 [Page 9]
Internet-Draft I2RS Protocol Requirements October 2013
4.3. Identity Requirements
I2RS could be used in a multi-domain distributed environment.
Therefore a fool-proof way to ascertain the identity of clients is of
utmost importance. Identity provides authenticated access to clients
to state held by the server.
ID-1: Each client should have a unique identity that can be verified
by the server. The authentication could be direct or through an
identity broker.
ID-2: The server should use the client's identity to track state
provided by the client. State ownership enables multiple clients
to edit their shared state. This is useful for troubleshooting
and during client death or disconnection when the client's state
may have to be purged or delegated to another client that shares
the same identity.
ID-3: The client's I2RS identity should be independent of the
location or the network address of the physical node in which it
is hosted. This allows the client to move between physical nodes.
It also allows a standby client to take over when the primary
fails and allows shared state editing by multiple clients as
discussed in I.2.
ID-4: A client that reboots or reconnects after a disconnection MUST
have the same I2RS identity if it wishes to continue to operate on
the state that it previously injected.
ID-5: A clients ability to operate on a state held by the server is
expressed at the granularity of a service. A service could be
read-only or read-write by a client possessing a particular
identity.
ID-6: A policy on the server could dictate the services that could
be exposed to clients. Upon identity verification, the authorized
services are exported to the client by capability announcement.
ID-7: A client can edit (write, delete) only the state that was
injected by it or other clients with the same shared identity.
Therefore, two conditions must be met for a client to edit a state
through a session. First, the client should receive capability
from the server that it has 'edit' permissions for the service in
question, and, secondly, the state that it edits should be its own
state.
ID-8: The server retains the client's identity till all of that
client's state is purged from the server.
Fernando, et al. Expires April 23, 2014 [Page 10]
Internet-Draft I2RS Protocol Requirements October 2013
4.4. Message Encoding Requirements
Clients and servers communicate by exchanging messages between them.
Message encoding is the process of converting information content in
a message to a form that can be transferred between them.
ME-1: Every message between the client and the server is encoded in
a transport-independent frame format.
ME-2: Each message is serialized on the sender's side and de-
serialized on the receiver's side. The technology used for
encoding and decoding messages could be negotiated between the
client and the server.
ME-3: A mandatory default encoding standard should be specified and
implemented by all I2RS participants. This ensures that there is
an interoperable default encoding mechanism between any client and
any server.
ME-4: The mandatory encoding technology chosen should be well
supported by a developer community and should be standards based.
Availability of tools and language bindings should be one of the
criteria used in selecting the mandatory encoding technology.
ME-5: If multiple message encoding is supported in the framework,
the encoding used for the current session should be configured
using a policy on the server side and negotiated using
capabilities. Note that currently there is no requirement to
support multiple encoding schemes.
ME-6: The message encoding standard should be language and platform
neutral. It should provide tools to express individual fields in
a message in a platform independent IDL-based language.
ME-7: The encoding/decoding mechanism should be fast and efficient.
It should allow for operation on legacy equipment.
ME-8: The encoding scheme should allow for optional fields and
backward compatibility. It should be independent of the transport
and the message exchange pattern used.
ME-9: Human readability of messages exchanged on the wire might be a
goal but it is secondary to efficiency concerns.
4.5. Message Exchange Pattern Requirements
Message exchange patterns form the basis for all service level
activities. MEPs create a pattern of message exchanges that any task
Fernando, et al. Expires April 23, 2014 [Page 11]
Internet-Draft I2RS Protocol Requirements October 2013
can be mapped to whether initiated by a client or the server. This
section provides the requirements for MEPS.
MEP-1: I2RS defines three types of messages between the client and
the server. First, capabilities need to be exchanged on session
establishment. Second, API commands are sent from a client to a
server to add, delete, modify and query state. And third,
asynchronous notifications are sent from a server to a client when
interesting state changes occur.
MEP-2: The above message exchanges can be satisfied by two message
exchange patterns. Capabilities and asynchronous notifications
can be satisfied by one-way unsolicited fire and forget message.
API commands can be satisfied using a request-response message
exchange. The base I2RS framework should thus support at least
these two MEPs.
MEP-3: For a request-response MEP, the server SHOULD acknowledge
every request message from the client with a response message.
MEP-4: The response message in a request-response MEP SHOULD
indicate that the server has received the message, done some basic
sanity checking on its contents and has accepted the message. The
arrival of a response does not mean all post processing of the
message has completed.
MEP-5: If an error occurs with an API command, The response message
MUST indicate an error and carry error information if there was a
failure to process the request. The error code SHOULD be
accompanied by a descriptive reason for the failure.
MEP-6: Error codes SHOULD indicate to the client which layer
generated that error (transport, message parsing, schema
validation, application level failure, etc). The I2RS framework
should specify a standard set of error codes.
MEP-7: The request-response messages SHOULD be asynchronous. That
is, the client should not be required to stop-and-wait for one
message to be acknowledged before it transmits the next request.
[ed: there must be a method for dependency tracking in the
protocol. possibly negotiate as an optional capability?]
MEP-8: To satisfy asynchronous operations, a mechanism MUST exist
to correlate response messages to their respective original
requests. For example, a message-id could be carried in the
response that would help the sender to correlate the response
message to its original request.
Fernando, et al. Expires April 23, 2014 [Page 12]
Internet-Draft I2RS Protocol Requirements October 2013
MEP-9: The response messages need not arrive in the order in which
the request was transmitted. [ed: again, there must be a method
for providing an order of operations, and for receiving positive
ack on completion]
MEP-10: The request message SHOULD carry an application cookie that
should be returned back to it in the corresponding response. [ed:
provide further justification]
MEP-11: Besides the request-response MEP, there is a need for a fire
and forget MEP. Asynchronous notifications from the server to the
client could be carried using this MEP. Fire and forget MEPs can
be used in both client-to-server and server-to-client directions.
MEP-12: Fire-and-forget messages MAY optionally be acknowledged.
MEP-13: The fire-and-forget MEP does not carry a message-id but it
SHOULD carry a cookie that can be set by the sender and processed
by the receiver. The cookie could help the receiver of the
message to use the message for its intended purpose.
4.6. API Method Requirements
API methods specify the exact operation that one participant intends
to perform. This section outlines the requirements for API methods.
API-1: The I2RS framework SHOULD provide for a simple set of API
methods, invoked from the client to the server. These methods
should allow to add, modify, query and delete of state that the
server maintains.
API-2: The I2RS framework should provide for three query methods,
subscribe, unsubscribe, and one-time-query, that the client can
use to express an interest or collect specific state changes or
state from the server.
API-3: The API methods discussed in API-1 and API-2 should be
transported in a request-response MEP from the client to the
server.
API-4: The API framework SHOULD provide for a single notify method
from the server to the client when interested state changes occur.
The notification method SHOULD be transported in a fire-and-forget
MEP from the server to the client.
API-5: The framework SHOULD define a set of base API methods for
manipulating state. These SHOULD be generic and SHOULD not be
service specific.
Fernando, et al. Expires April 23, 2014 [Page 13]
Internet-Draft I2RS Protocol Requirements October 2013
API-6: All API methods that affect the state in the server SHOULD
be idempotent. That is, the final state on the server should be
independent of the number of times a state change method with the
same parameters was invoked by the client.
API-7: All API methods SHOULD support a batched mode for efficiency
purposes. In this mode multiple state entries are transmitted in
a single message with a single operation such as add, delete, etc.
For methods described in A.1 and A.2 which elicit a response, the
failure mechanism that is specific to a subset of state in the
batch should be devised. The Notify method SHOULD also support a
batched mode.
API-8: Since the API methods are primarily oriented towards state
transfer between the client and server, there SHOULD be a
identifier (or a key) to uniquely identify the state being
addressed.
API-9: API methods that refer to value of a particular state SHOULD
carry the state identifier (key) as well as the its value. For
instance, during a state add operation, both the identifier (key)
and the value SHOULD be passed down from the client to the server.
API-10: Besides basic API methods common to all services, a server
could support proprietary methods or service specific methods.
The framework SHOULD specify a mechanism to express these methods
and their semantics through a modeling language or otherwise. The
ability to support additional API methods SHOULD be conveyed to
the client through capability negotiation.
API-11: Transactions allow a set of operations to be completed
atomically (all or nothing) and that the end result is consistent.
Transactions MAY be required for some network applications. [ed:
i'd like to remove this for the the first version. it's a bit of
a canard']
4.7. Service and SDM Requirements
SVC-1: Each service is associated with a service data model that
defines the type and structure of the state (data) pertaining to
that service. I2RS MUST provide mechanisms to manage the state
held in the server in accordance to the SDM.
SVC-2: The base I2RS API methods MUST allow a client to add,
modify, query and delete state information.
SVC-3: Neither the transport or the MEP SHOULD have any bearing on
the structure of the state being transferred. Each service module
Fernando, et al. Expires April 23, 2014 [Page 14]
Internet-Draft I2RS Protocol Requirements October 2013
in the server would be responsible for interpreting the structure
of the state being transferred corresponding to the SDM.
SVC-4: A client, after proper identification, could operate on
multiple 'services' that are exported to it. A client could have
read-only or read-write access to a given service. The
availability of the service, valid entities and parameter ranges
associated with same are expressed via the exchange of capability
information with the client.
SVC-5: The arrangement and structure of state (SDM) SHOULD be
expressed in a network friendly data modeling language. [ed: I
have no idea what this means]
SVC-6: The data modeling language SHOULD have the ability to
express one-to-one, one-to-many and hierarchical relationships
between modelled entities.
SVC-7: The data modeling language MUST allow for a service data
model to be extended beyond its initial definition. The language
MUST be able to express mandatory and optional elements in SDMs.
It SHOULD also have the ability to express exceptions for
unsupported elements in the model.
SVC-8: For every service that it wishes to expose to a client, the
server SHOULD send capabilities that indicate the existence and
identity of the service data model, as well as valid states and
parameter ranges, any exceptions to it and the optional features
of the data model that it supports.
SVC-9: The data modeling language MUST be able to express a
dependence of service data model on another SDM. It SHOULD also
have the ability to express references to state elements in
another service data model.
SVC-10: The modeling language MUST have the ability to express read/
write and read-only constraints for state elements in an SDM.
Readable state elements are populated and managed by the server
and clients don't have the ability to write their value. Routing
next-hops added by a client is an example of read-write state.
Statistics associated with that next-hop is an example of read-
only state.
SVC-11: Query and notification APsI MUST be able to carry both read-
only as well as read-write state.
SVC-12: Besides specifying a SDM, a service SHOULD also specify the
interesting state changes that clients can subscribe to for
Fernando, et al. Expires April 23, 2014 [Page 15]
Internet-Draft I2RS Protocol Requirements October 2013
notifications. The absence of such a specification SHOULD be
interpreted as an implicit unavailability of any subscribable
entities. [ed: terminology to be worked out here]
SVC-13: A client which is authenticated to access a service (either
read-only or read-write) MAY subscribe to any subscribable state
change events.
SVC-14: A subscribe method SHOULD optionally have a filter
associated. This increases the efficiency by filtering out events
that the client is not interested in. The notification filter
should have the ability to express state identifiers and wildcards
for values.
SVC-15: The base API operations MUST be generic and allow a client
to operate on multiple services with the same set of methods.
Each service dictates its one schema or SDM.
SVC-16: I2RS protocol SHOULD allow a server to export standard
services as well as vendor proprietary services. A namespace
scheme should be devised to recognize standard and proprietary
services.
SVC-17: The server SHOULD indicate to the client the availability of
infrastructure to manage the state that it maintains. This
includes but is not limited to the availability of persistent
store, the availability of timer to clean up state after a
specified timeout, the ability to clean up state on the occurrence
of an event, etc. Equipped with this information, the client is
responsible for the lifetime of the state.
SVC-18: Each state SHOULD have a set of meta data associated with
it. This includes the state's owner, the state's lifetime
attributes, a creation and modification timestamp, etc. This
information would aid in the debugging of the system. An
authenticated client that is exposed to a service SHOULD also have
access to the meta data associated with that service's state.
4.8. Security Requirements
This section lists security requirements for the I2RS protocol.
SEC-1: Every client MUST be authenticated and associated with an
identity. A secure mechanism to uniquely identify a client such
as certificates MUST be adopted.
SEC-2: Every client MUST have an authorized role whereby only
certain state can be accessed and only certain operations can be
Fernando, et al. Expires April 23, 2014 [Page 16]
Internet-Draft I2RS Protocol Requirements October 2013
performed by that client. To keep the model simple and
applications portable, authorization MUST be at a per service
level and not on individual state element level.
SEC-3: The framework MUST provide for information confidentiality
and information integrity as options.
SEC-4: Every state maintained by the server SHOULD be tagged with
the client's identity as well as meta-data to indicate last access
and last modifications time-stamps. This ensures accountability
and helps auditing the system.
SEC-5: Mechanisms to "hook" into third-party security infrastructure
whenever possible SHOULD be provided in order to achieve security
goals. Applications programmers SHOULD be kept free of security
concerns and yet given a flexible, configurable and well
integrated security model.
4.9. Performance and Scale Requirements
Performance requirements are usually woven in with the functional
requirements of a system. They feature in every decision made to
fulfill the systems requirements. Performance and scale are a
complex function of many things. Hence performance requirements
cannot be precisely quantified by a single number. This section lays
out some common sense guidelines that should be kept in mind while
designing the system from a scale and performance standpoint.
PS-1: The request-response MEP SHOULD be asynchronous. This
ensures that a system is not stuck waiting for a response and
makes the entire system more responsive and enables concurrency
between operations.
PS-2: When applicable, messages SHOULD carry application level
cookies that enable an application to quickly lookup the context
necessary to process a message. Management of cookies is the
applications responsibility.
PS-3: The framework SHOULD allow for bulk operations which
amortizes the communication and messaging costs.
PS-4: The transport protocol SHOULD provide for a binary encoding
option for messages between the participants.
PS-5: The transport protocol MUST provide for both encrypted and
non-encrypted transport between participants.
Fernando, et al. Expires April 23, 2014 [Page 17]
Internet-Draft I2RS Protocol Requirements October 2013
PS-6: The transport protocol MUST provide for message
prioritization.
PS-7: Multiple operations should be completed using a single
transport session whenever possible.
PS-8: The server MUST be kept stateless with respect to the number
and location of each client.
PS-9: Filtered subscription MUST be supported for notifications.
PS-10: An efficient synchronization mechanism between a client and a
server SHOULD be provided that avoids transferring all the state
between them.
PS-11: Allow clients that perform infrequent operations to
disconnect their transport connection without cleaning up their
state.
PS-12: Create the basic necessary mechanisms in the framework and
build everything else as a service if possible.
4.10. High Availability Requirements
The ability of the system to withstand operational failures and
function in a predictable manner is called availability. A few
guidelines that are important are,
HA-1: A 'superuser' identity SHOULD be provided that is capable of
changing security policies, clearing state and perform actions
that override client initiated actions in the system.
HA-2: Session disconnection and client deaths MUST be handled
gracefully. They should have the least impact on the server
system.
HA-3: Client connections and disconnections MUST be logged and
provided as a well-known service to authenticated users.
HA-4: Clients MUST be notified of message processing and other
errors through error codes in messages.
HA-5: A mechanism to gracefully terminate the session between the
client and the server MUST be provided.
HA-6: A mechanism for authenticated clients to query the load
attributes of the system, both instantaneous and running average
MUST be provided as a service.
Fernando, et al. Expires April 23, 2014 [Page 18]
Internet-Draft I2RS Protocol Requirements October 2013
4.11. Application Programmability Requirements
The framework should pay particular attention the requirements of
application programmers. A well written framework should improve the
productivity of programmers and shorten the time to make an
application. This section has some issues to consider when devising
the framework from an applications standpoint.
PGM-1: A client programming framework SHOULD allow applications
writers to focus on the app functionality rather than mechanisms
required to communicate with the server.
PGM-2: The application once written to certain requirements should
be portable to other identical environments. The framework should
not have fine grained data access controls as this would lead to a
poorly written application with portability issues.
PGM-3: The framework should be devised in a manner that it is
possible to automate code generation and constraint checking in
popular programming languages. Generated code can then be used
readily by application programmers instead of dealing with the
nitty-gritties of the system.
PGM-4: Define a common repository for SDMs from which clients can
obtain the SDMs they are interested in and automatically generate
most of the boilerplate code.
PGM-5: Provisions SHOULD be made for debugging and troubleshooting
tools that includes message trace, call traces, access to relevant
server traces and logs, packet decode tools to trace and decode
messages on the wire, consistency checkers of state inserted into
a server.
PGM-6: The toolset should have a general portion (for common
functions, such as session management) and SDM-specific portions
(for example, a flag to control generation of debug code in code
generated for a particular SDM).
PGM-7: The framework SHOULD define SDMs and MDMs in a language
neutral format so as to enable code generation in multiple
programming languages.
4.12. Operational Requirements
OP-1: There is a need to identify operational performance parameters
of the system and provide mechanisms to retrieve them from a
running system.
Fernando, et al. Expires April 23, 2014 [Page 19]
Internet-Draft I2RS Protocol Requirements October 2013
OP-2: Provide a way to upgrade a service independently of the other
services. This modularity allows uninterrupted operation of the
all but one service which is being upgraded.
OP-3: Provide a detailed workflow for bringing about a new service.
This workflow will start with the need to introduce a new service
and address the following: How SDMs defined? Where are they
standardized? How are new entities (MEPs, transport, encoding)
introduced? What are the tools and workflow involved to develop
and operationalize a service. The intent is to introduce a level
of understanding about stakeholders responsibilities.
OP-4: Provide mechanisms and methodologies to test a new service
before deployment.
5. Contributing Authors
Thanks to the following people for reviewing and providing meaningful
contributions: Alia Atlas, Palani Chinnakannan, Alexander Clemm,
Muthumayan Mahdhayyan, John McDowell and Bruno Rijsman and David
Ward.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-00 (work in
progress), August 2013.
[I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-00 (work in progress), August 2013.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1995.
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1996.
Fernando, et al. Expires April 23, 2014 [Page 20]
Internet-Draft I2RS Protocol Requirements October 2013
Authors' Addresses
Rex Fernando
Cisco Systems
170 W Tasman Dr,
San Jose, CA 95134
US
Email: rex@cisco.com
Jan Medved
Cisco Systems
170 W Tasman Dr,
San Jose, CA 95134
US
Email: jmedved@cisco.com
Edward Crabbe
Google
1600 Amphitheater Parkway
Mountain View, CA 94043
US
Email: edward.crabbe@gmail.com
Keyur Patel
Cisco Systems
170 W Tasman Dr,
San Jose, CA 95134
US
Email: keyur@cisco.com
Fernando, et al. Expires April 23, 2014 [Page 21]
