Internet DRAFT - draft-hadi-i2rs-forces-gap-analysis
draft-hadi-i2rs-forces-gap-analysis
Internet Engineering Task Force J. Hadi Salim
Internet-Draft Mojatatu Networks
Intended status: Informational November 11, 2013
Expires: May 15, 2014
ForCES For I2RS
draft-hadi-i2rs-forces-gap-analysis-00
Abstract
This document provide a gap-analysis on ForCES meeting the
requirements for I2RS.
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 May 15, 2014.
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.
Hadi Salim Expires May 15, 2014 [Page 1]
Internet-Draft ForCES For I2RS November 2013
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ForCES overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ForCES protocol . . . . . . . . . . . . . . . . . . . . . 4
3.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 6
4. Meeting I2RS requirements . . . . . . . . . . . . . . . . . . 7
4.1. Simplicity, Extensibility and Model-Driven
Programmatic Interfaces . . . . . . . . . . . . . . . . . 7
4.2. Protocol Structure . . . . . . . . . . . . . . . . . . . . 7
4.3. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Identity and Security Role . . . . . . . . . . . . . . . . 9
4.7. Multi-Headed Control . . . . . . . . . . . . . . . . . . . 10
4.8. Transactions . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Hadi Salim Expires May 15, 2014 [Page 2]
Internet-Draft ForCES For I2RS November 2013
1. Terminology and Conventions
1.1. 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].
1.2. Definitions
This document reiterates the terminology defined by the ForCES
architecture in various documents for the sake of clarity.
FE Model - The ForCES model used for describing resources to be
managed/controlled. This includes three components; the LFB
modeling of individual Logical Functional Block (LFB model), the
logical interconnection between LFBs (LFB topology), and the FE-
level attributes, including LFB components, capabilities and
events. The FE model provides the basis to define the information
elements exchanged between the CE and the FE in the ForCES
protocol [RFC5810].
LFB (Logical Functional Block) Class - A template that represents
a resource that is being modeled. Most LFBs relate to packet
processing in the data path; however, that is not always the case.
LFB classes are the basic building blocks of the FE model.
LFB Instance - A runtime instantiation of an LFB class.
ForCES Component - A ForCES Component is a well-defined, uniquely
identifiable and addressable ForCES model building block. A
component has a 32-bit ID, name, type, and an optional synopsis
description. These are often referred to simply as components.
ForCES Protocol - Protocol that runs in the Fp reference points in
the ForCES Framework [RFC3746].
ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol
architecture that defines the ForCES protocol messages, the
protocol state transfer scheme, and the ForCES protocol
architecture itself as defined in the ForCES Protocol
Specification [RFC5810].
ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
ForCES protocol architecture that uses the capabilities of
existing transport protocols to specifically address protocol
message transportation issues, such as how the protocol messages
are mapped to different transport media (like TCP, IP, ATM,
Hadi Salim Expires May 15, 2014 [Page 3]
Internet-Draft ForCES For I2RS November 2013
Ethernet, etc.), and how to achieve and implement reliability,
ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that
is mandated for ForCES.
2. Introduction
The ForCES architecture constitutes of:
1. Data model definition [RFC5812] serving as a basis for the
architecture constructs acted on by the protocol.
2. The ForCES protocol(PL) [RFC5810] which acts on the model
component constructs.
3. A transport mapping layer(TML) which takes the PL constructs and
maps them to underlying convinient transport(s) and delivers them
to the target end points. There is One TML currently defined
based on SCTP, [RFC5811].
This document presents the ForCES architecture as a basis for I2RS.
3. ForCES overview
In this section we do a quick overview of ForCEs. The reader is
encouraged to read the relevant documents (In particular RFC 5810,
5812 and 5811).
The origins of ForCES lie in desire to separate control and datapath;
where "datapath" was intended to be packet processing resources.
Over time, however, due to the convinience of ForCES architecture it
has been used for managing arbitrary (other than packet processing)
resources. As long as one can model the resources using the ForCES
model, the protocol semantics allows using ForCES protocol to control
and manage said resources. In the case of I2RS, for example, a RIB
is a resource (which is not to be confused with a datapath FIB). For
this reason we may refer interchangeably to datapath as "resource" to
avoid the confusion.
3.1. ForCES protocol
The ForCES protocol features can be summarized as:
1. Transport independence. The ForCEs protocol is intended to run
on a variety of chosen protocols. This was design intent to
separate the PL from the different transports for given
resources and environments. As an example, one of the original
Hadi Salim Expires May 15, 2014 [Page 4]
Internet-Draft ForCES For I2RS November 2013
desires was to directly run over PCI-Express.
2. Simplified ForCES layer when possible:
* Security is left up to the transport choice keeping the
ForCES layer simple. As an example, RFC 5811 defines running
ForCES on top of SCTP with IPSEC for security.
* Optional Controller high availability. FEs(resource owners)
when desired can connect to multiple controllers in both cold
or hot standby mode.
* Controller-controller connectivity could be taken care of by
other existing technologies.
3. Transport dependence. Experience with ForCES as depicted in the
SCTP TML (RFC 5811) has shown absolute need for a variety of
shades of reliability. Requests from the control to the
resource must be reliably delivered, pronto (think a FIB
update). So are the response back; however, items like
synchronous reports of statistics could afford to be lost once
in a while; and retransmitting such stats is not useful since
they are monotonically incrementing. This helps reduce noise in
situations of congestion. Likewise, packet redirects coming
from outside the box could afford to be lost since the end peer
will end up retransmiting anyways. (Think OSPF link state
updates for example or BGP on top of TCP).
4. Node overload. Experience has shown need to protect against
node overload in a work-conserving mode(thus optimal resource
usage). The SCTP TML prioritizes both compute and wire
resources to request to the controlled-resource and responses to
the controller over events; whereas, event are prioritized over
redirect packets. With this approach, there is no need to
provide hacks like non-work conserving approaches (such as rate
limiting redirects to the controller). Example, a SET to update
the FIB is way more important vs an incoming packet requiring
further policy processing or a link going down then back up.
5. Transactional capabilities in the form of 2 phase commits.
6. Transactional scalability, low latency and high throughput.
Given that the original desire of ForCES was to be able to
achieve very high throughput transactions for the purpose of
updating one or more datapath tables (depending on the table
contents, achieving 10s to 100s of thousands of table updates/
second is possible). The choice of making the underlying
protocol as binary, topped with allowing for command batching
Hadi Salim Expires May 15, 2014 [Page 5]
Internet-Draft ForCES For I2RS November 2013
allows the protocol achieve these goals.
7. Various execution modes for transactions {Execute-all-or-none,
Execute-until-error, Execute-all-despite-errors}. The default
mode of execution in ForCES is the atomic Execute-all-or-none
where the resource controller(CE) asks the resource owner(FE) to
run a transaction and abort if anything fails. The reader is
refered to look at RFC 5810 for more details.
8. Simple verbs in the form of {GET, SET, DELETE, REPORT and a few
helpers}
9. Traffic sensitive protocol level connectivity detection. ForCES
layer heartbeats could be sent in either or both directions.
Heartbeats, however are only sent when the link is idle.
10. Dynamic association of FEs to CEs. FEs register and unregister
to controllers and advertise their capabilities and capacities.
3.2. ForCES Model
The ForCES Model features can be summarized as:
1. Data model modularity through LFB class definition.
2. Data model type definitions via atomic types, complex/compound
types, grouping of compound types in the form of structures and
indexed/keyed tables which then end up composing addressable
components within an LFB class.
3. Hierarchical/tree definition of control/config/state components
which is acted on by a controller via the ForCES protocol.
4. Information-modeled metadata and expectations.
5. Built in LFB class resource capability definition/advertisement.
6. Publish/subscribe LFB event model with expressive trigger and
report definitions.
7. Data model flexibility/extensibility through augmentations, and
inheritance.
8. Backward and forward compatibility via LFB design and versioning
rules.
9. Formal constraints for validation of defined components.
Hadi Salim Expires May 15, 2014 [Page 6]
Internet-Draft ForCES For I2RS November 2013
4. Meeting I2RS requirements
This document assumes the floated RIB information model can be
described using the ForCES modelling language. Another document will
be published in the future to describe the RIB data model from a
ForCES point of view.
4.1. Simplicity, Extensibility and Model-Driven Programmatic Interfaces
If one was to provide an executive summary of the ForCES protocol
semantics, then it would be this:
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". In
other words, the ForCES semantic allows composing of rich services
on top of the basic grammar.
The expressive simplicity of the protocol is achieved due to the few
verbs (Refer to RFC 5810, section 7.1.6) which act on the agreed-to
modelled LFB components. The protocol is totaly agnostic of the
nature of the resource being controlled/managed. It is upto the
modeller to describe the resource in the manner that is fitting
(although frowned-upon, one could describe the resource model
_exactly_ as it is implemented and reduce the generalities and
therefore translation overhead). The model is highly extensible and
for this reason, the knowledge of the resource control is offloaded
to the service layer and a basic infrastructure is all that is
needed.
The author believes ForCES meets the requirements in these I2RS
prescribed needs.
4.2. Protocol Structure
The ForCES protocol using currently defined TML is binary for reasons
of conserving wire, memory and compute resources (needed for
scaling). The data model provides a _formal definition_ for
describing a variety of underlying structures (if you want to
describe /proc layout, then go ahead) and because the ForCES model
allows you to do this, the author believes it will be sufficient to
keep the transport encoding binary to maintain the efficiency desire.
However, given the ForCES architecture allows one to have different
transports (in the form of TML), if needed then one could for example
use XMPP to transport ForCES syntax.
Hadi Salim Expires May 15, 2014 [Page 7]
Internet-Draft ForCES For I2RS November 2013
The author believes ForCES meets the requirements in these I2RS-
prescribed needs.
4.3. Channel
ForCES leaves the decions on the number channels upto the underlying
TML. For example, the SCTP TML provides 3 channels which are used in
a strict priority. RFC 5811 provides guidelines for usage of these
channels. The High priority (HP) channel is isolated to carry
Requests from the Controller and responses from the resources and is
fully reliable and is always serviced first. The Medium priority is
for event updates from the resource and is partially reliable; and
last, the lowest priority is used for packet redirects and is less
reliable than the MP channel. IOW, during onsets of congestion MP
will be ignored over HP and LP will be ignored over MP.
The SCTP TML above is used for illustration, further study is needed
to pick one (or more) TMLs for I2RS.
The author believes ForCES meets the requirements in these I2RS
prescribed needs.
4.4. Negotiation
ForCES model definition allows a resource defined as an LFB to define
capabilities (Refer to RFC 5812, section 3.1 and section 4.7.5). It
also allows versioning of different LFBs(refer to RFC 5812 section
3.2.7).
The author believes ForCES meets the requirements in these I2RS
prescribed needs.
4.5. Notifications
The ForCES architecture exposes a pub-sub event model.
Event filtering is further defined. Filters include:
o Hysteresis - used to suppress generation of notifications for
oscillations around a condition value. Example, "generate an
event if the link laser goes below 10 or goes above 15".
o Count - used to suppress event generation around occurence count.
Example, "report the event to the client only after 5 consecutive
occurances".
o Time interval - used to suppress event generation around a time
limit. Example, "Generate an event if table foo row hasnt been
Hadi Salim Expires May 15, 2014 [Page 8]
Internet-Draft ForCES For I2RS November 2013
used in the last 10 minutes".
There could be multiple filters defined per event. Example of
compound filtering: "Generate an event when the count reaches 5 or
every 10 minutes when there is at least one event".
The events are published using the ForCES model on a per resource
level (refer to section 4.7.6 for more details on the semantics).
Event targets and what is to be reported is defined in the
definition.
Event subscription is achieved by using the protocol verb SET-
PROPERTY to the path of the published event.
The author believes ForCES meets the requirements in these I2RS
prescribed needs.
4.6. Identity and Security Role
The ForCES model defines basic ACLs to be used for components
(read,write,reset and access approach). The original intent was to
keep the resource/Datapath state very simple (refer to RFC 5812
section 4.7.6) and not need to store a lot of state.
The author believes there is a gap on ForCES to properly meet this
I2RS requirement that needs to be addressed.
The Identity and Security Role could be solved by adding TLS support
to the current SCTP TML(or any new one). This may be sufficient and
we let the controller to arbitrate on which client gets to write the
RIB. In case that turns out to be insufficient, then there are
several things that would need to be done:
1. Optionally, add userids and/or group ids to the ForCES component
ACL properties. These would be 32 bit IDs so not expensive to
store in the datapath. In addition to the existing ForCES ACLs,
the resulting changes would be equivalent to Unix file
permissions(which are well understood). The richness of details
of what a specific uid/gid means expected to sits in the
controller and at the resource level only the 32-bit ids are
used.
2. If we are to do the above, then we need to modify the protocol to
carry the uid/pid since the CE will be acting on behalf of the
different clients.
XXX: The outstanding question is whether we need to extend the ACLs
per LFB class or per LFB class Instance or per-component and whether
Hadi Salim Expires May 15, 2014 [Page 9]
Internet-Draft ForCES For I2RS November 2013
the controller can at runtime change permissions of the different
components. The challenge is to weigh-in usability vs efficiency..
(kinda like IETF 88 Hyatt Elevators).
4.7. Multi-Headed Control
ForCES only allows a single master writter and multiple readers.
This was done for the sake of simplicity of the HA mode. The author
believes this requirement is not met by ForCES.
During the re-charter of the WG a request was made for this feature
but was rejected because we needed to constrain the deliverables to
only a few that could be met within a short period. (refer to:
http://www.ietf.org/proceedings/86/slides/slides-86-forces-7.pdf).
We may need to revisit the requirement in order to use ForCES for
I2RS.
4.8. Transactions
I2RS requires a Perform all or none, Perform until error, and Perform
all storing errors capabilities.
The author believes this requirement is fully met by ForCES.
5. IANA Considerations
TBD
6. Security Considerations
TBD
7. References
7.1. Normative References
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010.
Hadi Salim Expires May 15, 2014 [Page 10]
Internet-Draft ForCES For I2RS November 2013
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", RFC 5811, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.
7.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Jamal Hadi Salim
Mojatatu Networks
Suite 400, 303 Moodie Dr.
Ottawa, Ontario K2H 9R4
Canada
Email: hadi@mojatatu.com
Hadi Salim Expires May 15, 2014 [Page 11]
