Internet DRAFT - draft-rfernando-irs-framework-requirement
draft-rfernando-irs-framework-requirement
INTERNET-DRAFT R. Fernando
Intended Status: Informational J. Medved
Expires: April 11, 2013 D. Ward
Cisco
A. Atlas
B. Rijsman
Juniper Networks
October 11, 2012
IRS Framework Requirements
draft-rfernando-irs-framework-requirement-00
Abstract
The Interface to Routing System (IRS) allows an application to
programmatically query and modify the state of the network. This
document defines the requirements for IRS with appropriate
reasoning where required.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
R. Fernando, et. al. Expires April 11, 2013 [Page 1]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IRS Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IRS Framework Terminology . . . . . . . . . . . . . . . . . . . 4
4. IRS Framework Design Objectives . . . . . . . . . . . . . . . . 7
5. IRS Framework Requirements . . . . . . . . . . . . . . . . . . 9
5.1 General Assumptions . . . . . . . . . . . . . . . . . . . . 9
5.2 Transport Requirements . . . . . . . . . . . . . . . . . . . 10
5.3 Identity Requirements . . . . . . . . . . . . . . . . . . . 11
5.4 Message Encoding Requirements . . . . . . . . . . . . . . . 12
5.5 Message Exchange Pattern Requirements . . . . . . . . . . . 13
5.6 API Method Requirements . . . . . . . . . . . . . . . . . . 15
5.7 Service and SDM Requirements . . . . . . . . . . . . . . . . 16
5.7 Security Requirements . . . . . . . . . . . . . . . . . . . 18
5.8 Performance and Scale Requirements . . . . . . . . . . . . . 19
5.9 Availability Requirements . . . . . . . . . . . . . . . . . 20
5.10 Application Programmability Requirements . . . . . . . . . 20
5.11 Operational Requirements . . . . . . . . . . . . . . . . . 21
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 21
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Normative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
R. Fernando, et. al. Expires April 11, 2013 [Page 2]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
1 Introduction
Routers, switches and network appliances that form today's network
infrastructure maintain state at various layers of detail and
function. For example, each router has a Routing Information Base
(RIB), and the routing protocols (OSPF, ISIS, BGP, etc.) each
maintain protocol state and information about the state of the
network.
IRS [IRS-FRMWK] defines a standard interface through well defined
APIs to access this information. The information collected by an
application could be used to influence the routing system in
conjunction with user defined policies in a feedback loop.
IRS enables this feedback loop so that applications can not only
collect information but also use them to influence the network. The
goal is to facilitate control and diagnosis of the routing
infrastructure, as well as enable sophisticated applications to be
built on top of today's network infrastructure.
Over time applications would evolve and with it their requirements
too. IRS MUST be extensible so that future requirements can be
easily factored in. IRS should be modular and extensible. It should
be simple to understand and friendly to application developers.
This document describes some of these requirements in detail taking
into consideration the use cases described in [2]. Particular
attention is paid to API and the application consumption model so
that it is developer friendly.
This document's scope is purely to collect and document requirements
for the IRS framework. This could serve three purposes:
a. To help the stakeholders (equipment vendors, application
programmers or interested IETF participants), to arrive at a common
understanding of the important elements of IRS.
b. To provide requirements to the designers of IRS framework on the
different aspects of the framework that needs consideration in the
design process.
c. To allow the stakeholders to evaluate technology choices that are
suitable for IRS, to identify gaps in them and to help evolve them to
suite IRS's needs.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
R. Fernando, et. al. Expires April 11, 2013 [Page 3]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. IRS Overview
IRS provides a standard interface for applications to read and
write state in a network device. Since the application and the
network device could reside in different physical nodes, IRS could
be viewed as a distributed client-server system.
IRS can also be viewed as a "framework" that helps reduce the
"start up" cost in developing network based applications. A
framework codifies a set of principles, patterns and software
artifacts that allow application developers to quickly develop new
applications.
Instead of designing each application from scratch, the IRS
framework provides a set of infrastructure that abstracts the
application indepedent mechanisms. This approach enhances software
agility, reusability and portability.
This document aims at making sure that the requirements of the IRS
framework are well articulated by describing its high level
objectives, the concepts and components involved, how they are
related and what their requirements are.
3. IRS Framework Terminology
Before we delve into the details of the IRS framework, it might
help to establish some basic terminology.
Service: For the purposes of IRS, a service refers to a set of
related state access functions together with the policies that
control its usage. For instance, 'RIB service' could be an example
of a service that gives access to state held in a device's RIB.
Server: Is a system that implements one or more services so that
other client systems can call them through well defined interfaces.
A server can export multiple services. A server is typically a
network device.
Client: Is a system that calls a service implemented by a server
through the well defined interface. A client can make use of
multiple services from many servers. A client is typically a
network application.
Participants: The server and client are collectively called the
R. Fernando, et. al. Expires April 11, 2013 [Page 4]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
participants of a service.
Transport: Is any mode of communication on an end-to-end basis
between the server and client that allows them to exchange data. In
principle, the transport hides the topology and other network
properties from the participants of a service.
Messages: Messages are logical chunks of data that are exchanged
between service participants.
Message Exchange Pattern: Is a categorization of different ways 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. MEPs are also sometimes referred to as the
session protocol.
Message Data Model: The schema representing the structure of
messages being exchanged between the service participants. The MDMs
can specify certain constraints such as the data type, length,
format and allowed 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.
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 the state.
Modeling Language: Is a language that defines schema for Message
Data Models and Service Data Models.
Namespaces: Allows a method for uniquely identifying and scoping of
schemas declared for messages and services. Namespace is an
important consideration when defining services and messages.
Service State or State: Is the general data held by the server for
a given service.
R. Fernando, et. al. Expires April 11, 2013 [Page 5]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
State Element: A programmable state present in the server. State
Element could vary in 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 Identifier can be viewed as the 'key'
for the state.
State Value or 'value: This is a value that is assigned to a
particular state identifier (key). The state is referred 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 up to which the state is maintained in
the server.
Datastore: This is 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: Mechanism that allows a server to recognize the
identity of a client.
Authorization: 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; they could become
effective only when certain conditions are met.
As can be seen, there are many aspects to be considered in designing
the IRS framework. The next section decribes the broad objectives of
the framework and breaks down the concerns so that each's
requirements can be individually examined.
R. Fernando, et. al. Expires April 11, 2013 [Page 6]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
4. IRS Framework Design Objectives
The goal is to provide a framework with the infrastructural
components needed to develop intelligent applications that control
the network. These are some of the core guiding principles and
objectives that should be kept in mind when designing that
framework.
a. Requirements Driven: The design of the framework should be
pragmatic and requirements driven. Having adequate provisions to
meet the needs of current applications yet making key aspects
extensible to meet future needs should be the goal.
b. Simple to Program: The success of any architectural framework
depends on the how simple it is to understand and implement
against. When presented with multiple choices to perform a
function, choosing one of them instead of supporting all of them
might lead to simpler design. In doing so, the design should
consider the most important requirements and the most common
deployment scenarios.
c. Standards Based: The need for a standards-based approach to
network programmability has been recognized by many standardization
groups including IETF. All aspects of IRS should be open standards
based. However, IRS should specify mechanisms to extend it in vendor
specific manner. The aspects of IRS that could be extended should
be identified in this document and should be supported by an
implementation.
d. Design for Scale and Performance: The design should meet current
and future performance and scale needs. It goes without saying that
scale and performance should be key criteria for making design
choices. There are well understood design patterns that allow us to
compose a scalable, high performing system.
e. Extensible: IRS will be deployed in environments whose
requirements evolve over time. Hence the system should be designed
with provisions that will allow significant enhancements to be added
to meet specified future goals and requirements. An extensible and
future-proof design will drive better adoption as it is a promise
against future technology churn.
f. 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.
R. Fernando, et. al. Expires April 11, 2013 [Page 7]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
g. 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 IRS is to achieve
predictive and consistent behavior when applications are migrated
from one platform or environment to another.
h. Security: IRS could 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 security aspects should be
carefully thought through when designing IRS.
i. 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.
j. 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 IRS framework are remote and
would be controlling the entire network, ensuring fault tolerance
is an important consideration.
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.
R. Fernando, et. al. Expires April 11, 2013 [Page 8]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
5. IRS Framework Requirements
This section is divided into multiple sub-sections, each dealing with
a specific consideration of IRS framework design. As we list the
requirements under each subsection, we'll annotate each requirement
with what high level objectives they meet. A reason for creating the
requirement is additionally provided where appropriate.
5.1 General Assumptions
This section captures the general, high level assumptions of the IRS
framework. Since the design choices for the IRS framework are many,
some simplifying assumptions could make the framework requirements
more tangible and useful.
+--------+ +--------+ +-----------+
| Client | ... | Client | .... .... | Client |
+--------+ +--------+ +-----------+
^ ^ ^ ^
| | | |
| | | |
| | | IRS |
| | +-------------+ |
| | | |
| | IRS | |
| +---+ | | IRS
| | | |
| IRS | | |
+------------------+ | | |
| | | |
V V V V
+-----------+ +-----------+
| Server | | Server |
+-----------+ +-----------+
G.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, IRS is a
client-server protocol/framework. IRS must provide mechanisms for the
client to discover services that a server provides.
G.2 The client can use the API's 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.
R. Fernando, et. al. Expires April 11, 2013 [Page 9]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
G.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.
G.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.
G.5 The IRS 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. IRS MUST specify the mapping from the
service data model to the message data model and subsequently to the
client API.
5.2 Transport Requirements
The transport layer provides connectivity between the client and the
server. This section details the transport requirements.
T.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 IRS setup will only have a
single transport session between the participants.
T.2 Depending on the data being exchanged, there could 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.
T.3 The transport connection between the client and server should
have mechanisms to support authentication, authorization and
optionally provide confidentiality of data exchanged between the
client and the server. See 'Security Requirements' for more details.
T.4 A client could connect to multiple servers. Similarly, a server
could accept connections from multiple clients.
T.5 The exact technology used for the transport layer should be
replaceable. There should be a single mandatory transport that
should be supported by all participants. This requirement will
ensure that there is always an interoperable transport mechanism
between any client and any server.
T.6 Clients and servers by default communicate using a point-to-point
transport connection.
R. Fernando, et. al. Expires April 11, 2013 [Page 10]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
T.7 Point-to-multipoint transport 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.
T.8 Once the transport connection is up, it is desirable to keep it
up and use it to perform multiple operations. This requirement
ensures that the system scales by amortizing the session setup
cost across multiple operations. Session down events do not have
an impact on the state maintained by the server.
T.9 After the transport connection comes up, the participants
exchange capabilities and other session parameters before exchanging
service related messages.
T.10 Messages pertaining to multiple services could be exchanged over
a single transport connection.
T.11 The "default" transport connection between the client and server
is purely for control plane message exchanges. Data plane packets
are not expected to be sent over this "default" connection. When
required, data plane 'punt' and 'inject' packets between
participants could be designed as a service in itself that sets
up a 'punt-inject-transport' that processes the right
characteristics.
T.12 For operational reasons, there MUST be a need to identify 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 IRS protocol level. For example, if TCP is used as a
transport, TCP keep-alives could be used to detect transport
session failures.
5.3 Identity Requirements
IRS 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.
I.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.
I.2 The server should use the client's identity to track state
R. Fernando, et. al. Expires April 11, 2013 [Page 11]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
provided by the client. State ownership enables the multiple
clients to edit their shared state. This is useful during client
death or disconnection when state owned by one client might be
delegated to another client that shares the same identity.
I.3 The client's 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.
I.4 A client that reboots or reconnects after a disconnection MUST
have the same identity if it wishes to continue to operate on the
state that it previously injected.
I.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.
I.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.
I.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.
I.8 When there is a single client and it dies, operational provisions
should be made to garbage collect its state by a client that
shares the original clients identity.
I.9 The server retains the client's identity till all of its state is
purged from the server.
5.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
R. Fernando, et. al. Expires April 11, 2013 [Page 12]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
transport independent frame format.
ME.2 Each message is serialized on the senders side and de-serialized
on the receivers 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 IRS 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 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 fields in messages
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 needs.
5.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
can be mapped to whether initiated by a client or the server. This
section provides the requirements for MEPS.
MEP.1 IRS defines three types of messages between the client and the
server. First, capabilities need to be exchanged on session
R. Fernando, et. al. Expires April 11, 2013 [Page 13]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
establishment. Second, API commands send down from client to server
to add, delete, modify and query state. And third, asynchronous
notifications from server to 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 IRS 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 The response message should 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). IRS framework should specify a
standard set of error codes.
MEP.7 The request-response messages should be asynchronous. That is,
the client should not stop-and-wait for one message to be
acknowledged before it transmits the next request.
MEP.8 To satisfy MEP.5, there needs to be a mechanism such as a
message-id, carried in the response that helps the sender correlate
the response message to its original request.
MEP.9 The response messages need not arrive in the order in which the
request was transmitted.
MEP.10 The request message should carry an application cookie that
should be returned back to it in the corresponding response.
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.
R. Fernando, et. al. Expires April 11, 2013 [Page 14]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
MEP.12 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.
5.6 API Method Requirements
API methods specify the exact operation that one participant intends
to perform. This section outlines the requirements for API methods.
A.1 The IRS 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.
A.2 The IRS framework should provide for two methods, subscribe and
unsubscribe, that the client can use to express its interest in
specific state changes in the server.
A.3 The API methods discussed in A.1 and A.2 should be transported
in a request-response MEP from the client to the server.
A.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.
A.5 The framework should define a set of base API methods for
manipulating state. These should be generic and should not service
specific.
A.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.
A.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. Notify method should also support a batched mode.
A.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.
R. Fernando, et. al. Expires April 11, 2013 [Page 15]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
A.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.
A.10 Besides the basic API methods that are common to all services,
a server could support proprietary methods or service specific
methods. The framework should devise a mechanism to express
these methods and their semantics through a modelling language
or otherwise. The ability to support additional API methods
should be conveyed to the client through the capability message.
A.11 Transactions allow a set of operations to be completed atom(all
or nothing) and that the end result is consistent. This might be a
requirement for some network applications and the framework designers
should keep this requirement in mind during the design phase.
5.7 Service and SDM Requirements
S.1 Each service is associated with a service data model that defines
the type and structure of the state pertaining to that service. IRS
should provide mechanisms to manage the state held in the server in
accordance to the SDM.
S.2 The data model should have the ability to express one-to-one,
one-to-many and hierarchical relationships between entities.
S.3 The base IRS API methods should allow a client to add, modify,
query and delete state information.
S.4 Neither the transport or the MEP should have any bearing on the
structure of the state being transferred. Each service module in
the server would be responsible for interpreting the structure of
the state being transferred corresponding to the SDM.
S.5 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 service. This is expressed by exchanging
capability information with the client.
S.6 The arrangement and structure of state (SDM) should be expressed
in a network friendly data modelling language.
S.7 Service data model once defined should be able to be extended.
Service data models should be able to express mandatory and optional
elements. If should also have the ability to express exceptions
R. Fernando, et. al. Expires April 11, 2013 [Page 16]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
for unsupported elements in the model. These are requirements for
the modelling language.
S.8 For every service that it wishes to expose to a client, the
server should send capabilities that indicate the service data model,
any exceptions to it and the optional features of the data model
that it supports.
S.9 A service data model could be dependent on another SDM and
should have the ability to refer to state elements in another
service data model.
S.10 A state element expressed in a data model could be writeable by
a client or purely readable. 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. The modelling language
should have the ability to express this constraint.
S.11 Query and notification API should be able to carry both read-
only as well as read-write state.
S.12 Besides specifying a SDM, a service should also specify the
interesting state changes that clients can subscribe to for
notifications.
S.13 A client which is authenticated to access a service (either
read-only or read-write) can subscribe to state change events.
S.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.
S.15 The base API operations should 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.
S.16 IRS 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.
S.17 The server should indicate to the client the availability of
infrastructure to manage the state that it maintains. This
includes but not limited to the availability of persistent store,
the availability of timer to clean up state after a specified
R. Fernando, et. al. Expires April 11, 2013 [Page 17]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
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.
S.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.
5.7 Security Requirements
Security requirements should be thought through up front to avoid
expensive rework to the framework. Adding security requirements once
the system is designed could be an expensive and painful process.
This section calls out some security concerns to be kept in mind
while designing the framework.
SEC.1 Every client should be authenticated and associated with an
identity. A secure mechanism to uniquely identify a client such
as certificates should be adopted.
SEC.2 Every client should have an authorized role whereby only
certain state can be accessed and only certain operations can be
performed by that client. To keep the model simple and
applications portable, authorization should be at a per service
level and not on individual state element level.
SEC.3 The framework should 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 The framework designers are strongly encouraged to provide
mechanisms to "hook" into third-party security infrastructure to
achieve these security goals whenever possible. This keeps
applications programmers free of security concerns and yet
provides a flexible, configurable and well integrated security
model.
R. Fernando, et. al. Expires April 11, 2013 [Page 18]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
5.8 Performance and Scale Requirements
Performance requirements are usually weaved 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 increases 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. The management of the cookie is
the applications responsibility.
PS.3 The framework should allow for bulk operations which amortizes
the communication and messaging costs.
PS.4 Provide for a binary encoding option for messages between the
participants.
PS.5 Provide for a non-encrypted transport between the service
participants.
PS.6 Provide for message prioritization.
PS.7 Multiple operations could be completed with one transport
session.
PS.8 Keep the server as stateless with respect to the number and
location of each client.
PS.9 For notifications, support filtered subscription.
PS.10 If a client requires to re-synchronize state with the server,
device a mechanism to do this efficiently without 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.
R. Fernando, et. al. Expires April 11, 2013 [Page 19]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
5.9 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,
A.1 Provide a 'superuser' identity that is capable of changing
security policies, clearing state and perform other actions that
override client initiated actions in the system.
A.2 Handle session disconnection and client deaths gracefully. These
should have the least impact on the system.
A.3 Log client connections and disconnections and provide this as a
well known service to authenticated users.
A.4 Notify clients of message processing and other errors through
error codes in messages.
A.5 Have a mechanism to gracefully terminate the session between the
client and the server.
A.6 Provide a mechanism for authenticated clients to query the load
attributes of the system, both instantaneous and running average.
Provide this as a service.
5.10 Application Programmability Requirements
The framework should pay particular attention the 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.
AP.1 A client programming framework should allow applications writers
to focus on the app functionality rather than mechanisms required to
communicate with the server.
AP.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.
AP.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
R. Fernando, et. al. Expires April 11, 2013 [Page 20]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
application programmers instead of dealing with the nitty-gritties of
the system.
AP.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.
AP.5 Provisions should be made for debugging & troubleshooting tools
that includes message trace, call traces, access to relevant
server traces and logs, packet decode tools to trace & decode
messages on the wire, consistency checkers of state inserted into
a server.
AP.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).
AP.7 The framework should define SDMs and MDMs in a language neutral
format so as to enable code generation in multiple programming
languages.
5.11 Operational Requirements
O.1 There is a need to identify operational performance parameters of
the system and provide mechanisms to retrieve them from a running
system.
O.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.
O.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.
O.4 Provide mechanisms and methodologies to test a new service before
deployment.
6 Security Considerations
See "Security Requirements", section 5.7 above.
R. Fernando, et. al. Expires April 11, 2013 [Page 21]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
7 Acknowledgements
Thanks to the following people for reviewing and providing feedback:
Alexander Clemm, John McDowell.
8. References
8.1 Normative References
[IRS-FRMWK] A. Atlas, T. Nadeau, D. Ward, "Interface to the Routing
System Framework", draft-ward-irs-framework-00
Authors' Addresses
Rex Fernando, Ed.
170 W Tasman Dr,
San Jose, CA 95134
EMail: rex@cisco.com
Jan Medved
Cisco Systems
170 W Tasman Dr,
San Jose, CA 95134
Email: jmedved@cisco.com
David Ward
Cisco Systems
170 W Tasman Dr,
San Jose, CA 95134
Email: wardd@cisco.com
Alia Atlas
Juniper Networks
10 Technology park Drive
Westford, MA 01886
Email: akatlas@juniper.net
Bruno Rijsman
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
Email: brijsman@juniper.net
R. Fernando, et. al. Expires April 11, 2013 [Page 22]
INTERNET DRAFT IRS Framework Requirements October 8, 2012
R. Fernando, et. al. Expires April 11, 2013 [Page 23]
