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]