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]