[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

ForCES                                                        J. Halpern
Internet-Draft                                                      Self
Expires: September 6, 2006                                 March 5, 2006


       A base Library for use with the ForCES Protocol and Model
                draft-halpern-forces-lfblibrary-base-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Forwarding and Control Element Separation (ForCES) working group
   is defining a protocol to allow a Control Element (CE) to control the
   behavior of a Forwarding Element (FE).  The manipulations used by
   this protocol operate in terms of adjustments to Logical Function
   Blocks (LFBs) whose structure is defined my a model RFC produced by
   the working group.  In order to build an actual solution using this
   protocol, there needs to be a set of Logical Function Block
   definitions that can be instantiated by FEs and controlled by CEs.
   This document provides an initial set of such definitions.  It is



Halpern                 Expires September 6, 2006               [Page 1]


Internet-Draft           Forces LFB Base Library              March 2006


   anticipated that additional defining documents will be produced over
   time.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   3.  Base Definitions . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Connectivity LFBs  . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Generic Connectivity LFB . . . . . . . . . . . . . . . . .  4
     4.2.  Redirect LFB . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  taggedInterface  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Packet Validation and Manipulation LFBs  . . . . . . . . . . .  8
     5.1.  IPv4 Validator LFB . . . . . . . . . . . . . . . . . . . .  8
     5.2.  IPv6 Validator LFB . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Meta-Data marker . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Packet Trimmer . . . . . . . . . . . . . . . . . . . . . . 12
     5.5.  IPv4 outbound updater  . . . . . . . . . . . . . . . . . . 13
     5.6.  IPv6 outbound updater  . . . . . . . . . . . . . . . . . . 13
     5.7.  Duplicator . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Classifer LFBs . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  Classifier Data Types  . . . . . . . . . . . . . . . . . . 15
     6.2.  ArbitraryClassifierLfb . . . . . . . . . . . . . . . . . . 21
     6.3.  LPMClassifier  . . . . . . . . . . . . . . . . . . . . . . 24
     6.4.  Next Hop Applicator  . . . . . . . . . . . . . . . . . . . 24
   7.  Packet Control LFBs  . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  ARPOutRequestLFB . . . . . . . . . . . . . . . . . . . . . 25
     7.2.  ARPInMessageLFB  . . . . . . . . . . . . . . . . . . . . . 25
     7.3.  ICMPLFB  . . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  Queue and Scheduler LFBs . . . . . . . . . . . . . . . . . . . 25
     8.1.  Scheduler  . . . . . . . . . . . . . . . . . . . . . . . . 26
     8.2.  Queue  . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     13.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 29









Halpern                 Expires September 6, 2006               [Page 2]


Internet-Draft           Forces LFB Base Library              March 2006


1.  Introduction

   The ForCES protocol Protocol [2] defines a protocol by whcih Control
   Elements (CEs) communicated with and control the behavior of
   Forwarding Elements (FEs).  That control is expressed in terms of
   manipulations of attributes of Logical Function Blocks (LFBs).  The
   structure and abstract semantics of LFBs is defined in Model [3].
   That document also defines a single LFB Class for gaining access to
   FE properties including the set of LFBs and their interconnection.
   The Protocol [2] document defines an LFB class for manipulating the
   protocol properties of the FE.

   In order for the protocol to be useful to control any behavior, there
   must be a set of LFB class definitions for the LFBs which provide
   that behavior.  This document provides an initial set of such
   definitions.  While this document is intended to provide an initially
   sufficient set of such classes, it is expected that other definitions
   will be developed over time, and documented in other RFCs.

   Section 3 provides a set of definitions, in an LFBLibrary wrapper
   that does not provide any classes.  These are then used in each
   subsequent definition by the statement:


   <load library="Base"/>


   Following that are sections containing definitions of LFB classes.
   They are group for convenience.  While there is some explanatory text
   in each section, the primary semantics are explain in description
   clauses in the LFB Class definition so as to ensure the description
   is available in any context that uses the definition.

   [Editor's note: Most of these class definitions are completely blank.
   A few have been filled in to provide starting ideas to contributors.]


2.  Requirements notation

   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 [1].


3.  Base Definitions

   This section povides a base set of LFB frame, data type, and meta
   data definitions for use by all any LFB Class definitions (in this or



Halpern                 Expires September 6, 2006               [Page 3]


Internet-Draft           Forces LFB Base Library              March 2006


   other documents.  This section provides no actual LFB Class
   definitions.


   <LFBLibrary>
     <frameDefs>
       <frameDef>
         <name>IPv4Frame</name>
         <synopsis>A frame containing an IPv4 packet.</synopsis>
       </frameDef>
       <frameDef>
         <name>IPv6Frame</name>
         <synopsis>A frame containing an IPv6 packet.</synopsis>
       </framedef>
       <frameDef>
         <name>taggedFrame</name>
         <synopsis>A frame of any type with associated metadata.</synopsis>
       </frameDef>
       <frameDef>
         <name>metaDataFrame</name>
         <synopsis>
           A frame consisting only of meta data, with no packet.
         </synopsis>
       </frameDef>
     </frameDefs>
     <dataTypeDefs>
     </dataTypeDefs>
     <metadataDefs>
     </metadataDefs>
   </LFBLibrary>



4.  Connectivity LFBs

   This section provides LFB class definitions for LFBs which provide
   connectivity between the FE and the rest of the world.

4.1.  Generic Connectivity LFB

   This section provides the LFB Class definition for the generic
   connectivity LFB.  This LFB is intended to provide media and
   encapsulation oriented capabilities such as one might associated with
   an interface.  It only captures those properties which relate to its
   function in the data flow.  (So, for example, it does not provide for
   the IP address associated with this interface, or even an indication
   as to whether there is such an address.)




Halpern                 Expires September 6, 2006               [Page 4]


Internet-Draft           Forces LFB Base Library              March 2006


   <LFBLibrary provides="GenericConnectivityLFB">
     <load library="Base"/>
     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010001">
         <name>GenericConnectivityLFB</name>
         <synopsis>
           An LFB Class for providing connectivity between an FE and
           communications media.
         </synopsis>
         <version>0.0</version>
         <description>
           This LFB Class provides a generic basis for representing
           connectivity between the FE and the outside world.

           The LFB has one or more ports for packets that the FE
           processing logic is forwrding for transmission by this
           Connectivity LFB.  It has one or more ports for packets
           that the Connectivity LFB has received and is handing to
           the FE processing logic.

           Multiple ports for handline packets are supported so that
           protocol specific encapsulation and demultiplexing can be
           provided by this LFB.

           This LFB also has ports for sending packets to lower layer
           Connectivity LFBs and receiving packets from such lower
           layer Connectivity LFBs.  This enables support for the
           processing components of interface stacks, such as PPP over
           Ethernet or Ethernet over MPLS.

           For packets arriving from Media or lower layer connectivity,
           this LFB will perform appropriate media validation, then
           remove media specific headers, and place the relevant
           information in meta-data.  For ethernet, the Source MAC would
           be in meta-data.  For Frame Relay or ATM, a circuit identifier
           would be in meta-data.  For Ethernet with VLANs, this
           meta-data would indicate which VLAN the packet came from.

           For packets to be transmitted, meta-data indicating the
           destination (destination MAC or outgoing circuit, etc.) is
           required.

           This LFB will also include statistical attributes such as the
           number of octets and packets sent and received, the number of
           various input and output errors, etc.
         </description>
       </LFBClassDef>
     </LFBClassDefs>



Halpern                 Expires September 6, 2006               [Page 5]


Internet-Draft           Forces LFB Base Library              March 2006


   </LFBLibrary>


4.2.  Redirect LFB

   This class definition provides for the function of sending and
   receiving data packets between the CE and the FE.  Such data packets
   are accompanied by meta-data which assists the receiver processing of
   the packet.  This LFB is implicitly tied to the protocol machinery
   for redirecting packets.

   There may be multiple Redirect LFBs in the LFB topology.  For packets
   from the CE to the FE, as described in Protocol [2] the correct LFB
   to handle the packet is determined by the instance ID in the redirect
   message.  In the direction from the FE to the CE, the source instance
   ID indicates which LFB is sending the packet.  Redirect Source or
   Sink LFBs may be instantiated by simply not connecting the input or
   output ports of the LFB instance to any other portion of the
   topology.
































Halpern                 Expires September 6, 2006               [Page 6]


Internet-Draft           Forces LFB Base Library              March 2006


   <LFBLibrary provides="RedirectLFB">
     <load library="Base"/>
     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010002">
         <name>RedirectLFB</name>
         <synopsis>
           An LFB Class definition for exchanging data packets
           between the FE and the CE.
         </synopsis>
         <version>0.0</version>
         <inputPorts>
           <inputPort>
             <name>RedirectToCE</name>
             <synopsis>
               Port for frames to send to the CE.
             </synopsis>
             <expectation>
               <frameExpected>
                 <name>taggedFrame<name>
               </frameExpected>
             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort>
             <name>RedirectFromCE</name>
             <synopsis>
               Port for frames to send to the CE
             </synopsis>
             <product>
               <frameProduced>taggedFrame</frameProduced>
             </product>
           </outputPort>
         </outputPorts>
         <description>
           This LFB represents a point of exchagne of data packets
           between the CE and the FE.  Packets with meta-data are
           exchanged.  It is expected that the output port of a
           RedirectLFB, if it is connected at all, will be connected
           to a meta-data redirector.
         </description>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>







Halpern                 Expires September 6, 2006               [Page 7]


Internet-Draft           Forces LFB Base Library              March 2006


4.3.  taggedInterface

   This LFB is for use instead of a GenericConnectivity LFB for use in
   conjunction with media interfaces which can carry meta-data.  It is
   in some ways similar to the RedirectLFB.  It is expected that it will
   be used with media that are used to interconnect FEs, such as modern
   chassis fabrics, which can carry meta-data with packets.  Unlike the
   Redirect LFB, it is expected that for a given fabric an FE will have
   only one taggedInterface LFB instance.


5.  Packet Validation and Manipulation LFBs

   This section provides LFBs that verify or adjust contents of packets.
   While one could consider the classifiers a subset of this, they are
   sufficiently significant that they are dealt with separately.

5.1.  IPv4 Validator LFB

   This LFB validates the IP version and header length fields, including
   verifying that the packet length is at least as long as the header
   indicates.

   This may be placed in the data path following a Connectivity LFB, or
   it may be placed in the data path for packets directed towards the
   CE, as some routers choose not to perform extensive validation on
   data packets to be forwarded.


   <LFBLibrary provides="IPv4ValidatorLFB">
     <load library="Base"/>
     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010003">
         <name>IPv4Validator</name>
         <synopsis>
           An LFB Class definition for validates the IPv4 packet.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
           <inputPort>
             <name>ValidatorIn</name>
             <synopsis>
               Normal packet input.
             </synopsis>
             <expectation>
               <frameExpected>
                 <ref>IPv4</ref>
               </frameExpected>



Halpern                 Expires September 6, 2006               [Page 8]


Internet-Draft           Forces LFB Base Library              March 2006


             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort>
             <name>ValidatorOut</name>
             <synopsis>
               Normal packet Output.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>IPv4packet</ref>
               </frameProduced>
             </product>
           </outputPort>
           <outputPort>
             <name>FailOutput</name>
             <synopsis>
               The port to send packets that do not match any entries.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>taggedFrame</ref>
               </frameProduced>
               <metadataProduced>
                 <ref>errorid</ref>
               </metadataProduced>
             </product>
           </outputPort>
         </outputPorts>
         <description>
           This LFB validates the IP version and header length
           fields, including verifying that the packet length
           is at least as long as the header indicates.
         </description>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>


5.2.  IPv6 Validator LFB

   This LFB validates the IP version and header length fields, including
   verifying that the packet length is at least as long as the header
   indicates.

   This may be placed in the data path following a Connectivity LFB, or
   it may be placed in the data path for packets directed towards the



Halpern                 Expires September 6, 2006               [Page 9]


Internet-Draft           Forces LFB Base Library              March 2006


   CE, as some routers choose not to perform extensive validation on
   data packets to be forwarded.


   <LFBLibrary provides="IPv6ValidLFB">
     <load library="Base"/>
     <metadataDefs>
       <metadataDef>
         <name>ErrorId</name>
         <synopsis>Error Type.</synopsis>
         <metadataID>11</metadataID>
         <atomic>
           <baseType>int32</baseType>
           <specialValues>
             <specialValue value="0x00030001">
               <name>WrongIpVersion</name>
               <synopsis>the IP version wrong</synopsis>
             </specialValue>
             <specialValue value="0x00030002">
               <name>WrongLength</name>
               <synopsis>
                 the packet length is not as long as
                 the header indicates
               </synopsis>
             </specialValue>
             <specialValue value="0x000300FF">
               <name>otherError</name>
               <synopsis>The errors we not defined now</synopsis>
             </specialValue>
           </specialValues>
         </atomic>
       </metadataDef>
     </metadataDefs>
     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010004">
         <name>IPv6Validator</name>
         <synopsis>
           An LFB Class definition for validates the IPv6 packet.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
           <inputPort>
             <name>ValidatorIn</name>
             <synopsis>
               Normal packet input.
             </synopsis>
             <expectation>
               <frameExpected>



Halpern                 Expires September 6, 2006              [Page 10]


Internet-Draft           Forces LFB Base Library              March 2006


                 <ref>IPv6</ref>
               </frameExpected>
             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort>
             <name>ValidatorOut</name>
             <synopsis>
               Normal packet Output.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>IPv6packet</ref>
               </frameProduced>
             </product>
           </outputPort>
           <outputPort>
             <name>FailOutput</name>
             <synopsis>
               The port to send packets that do not match any entries.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>taggedFrame</ref>
               </frameProduced>
               <metadataProduced>
                 <ref>errorid</ref>
               </metadataProduced>
             </product>
           </outputPort>
         </outputPorts>
         <description>
           This LFB validates the IP version and header length
           fields, including verifying that the packet length
           is at least as long as the header indicates.
         </description>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>


5.3.  Meta-Data marker

   It is sometimes necessary to move information from the packet to
   meta-data, or from one meta-data field to another.  This LFB class
   provides that capability.  It consists of a series of processing
   instructions.  Each instruction identifes either a meta-data element,



Halpern                 Expires September 6, 2006              [Page 11]


Internet-Draft           Forces LFB Base Library              March 2006


   a named packet field, or a portion of the packet identified by offset
   and length.  The instruction also indicates what meta-data element to
   copy the selected data into.  The target field is identified using
   the same data types used for the matcher target identification.

5.4.  Packet Trimmer

   It is sometimes necessary to remove data from the front of a packet.
   This LFB class provides that capability.


   <LFBLibrary provides="PacketTrimmer">
     <load library="Base"/>
     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010004">
         <name>PacketTrimmer</name>
         <synopsis>
           LFB removes data from the front of a packet.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
           <inputPort>
             <name>PacketIn</name>
             <synopsis>
               Normal packet input.
             </synopsis>
             <expectation>
               <frameExpected>
                 <ref>Packet</ref>
               </frameExpected>
             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort>
             <name>PacketOut</name>
             <synopsis>
               Normal packet Output.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>Packet</ref>
               </frameProduced>
             </product>
           </outputPort>
           <outputPort>
             <name>FailOut</name>
             <synopsis>



Halpern                 Expires September 6, 2006              [Page 12]


Internet-Draft           Forces LFB Base Library              March 2006


               For packets without enough bytes to remove
             </synopsis>
             <product>
               <frameProduced>
                 <ref>Packet</ref>
               </frameProduced>
             </product>
           </outputPort>
         </outputPorts>
         <attributes>
           <attribute access="read-write" elementID="1">
             <name>TrimLength</name>
             <synopsis>amount to trim from each packet</synopsis>
             <typeRef>uint32</typeRef>
           </attribute>
         </attributes>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>


5.5.  IPv4 outbound updater

   This LFB updates the TTL and header checksum in a packet to be sent
   by the FE.  The header checksum update is performed by modification,
   so that erroneous checksums are still erroneous.




5.6.  IPv6 outbound updater

   This LFB updates the TTL and header checksum in a packet to be sent
   by the FE.  The header checksum update is performed by modification,
   so that erroneous checksums are still erroneous.




5.7.  Duplicator

   A duplicator LFB has one input port and multiple output ports.  Any
   packet arriving on an input port is copied so as to be sent on all
   output ports.







Halpern                 Expires September 6, 2006              [Page 13]


Internet-Draft           Forces LFB Base Library              March 2006


   <LFBLibrary provides="Duplicator">
        <load library="Base"/>
        <LFBClassDefs>
          <LFBClassDef LFBClassID="0x00010007">
            <name>Duplicator</name>
            <synopsis>
              An LFB Class definition for packet duplicator LFB.
              Any packet received on an input port is
              loigcally  copied and sent to all output ports.
            </synopsis>
            <version>1.0</version>
            <inputPorts>
              <inputPort>
                <name>PacketIn</name>
                <synopsis>
                  Normal packet input.
                </synopsis>
                <expectation>
                  <frameExpected>
                    <ref>IPv4</ref>
                    <ref>IPv6</ref>
                  </frameExpected>
                </expectation>
              </inputPort>
            </inputPorts>
            <outputPorts>
              <outputPort group="yes">
               <name>PacketOut</name>
               <synopsis>Normal packet output port group</synopsis>
               <product>
                 <frameProduced>
                   <ref>IPv4</ref>
                   <ref>IPv6</ref>
                 </frameProduced>
               </product>
             </outputPort>
            </outputPorts>
          </LFBClassDef>
        </LFBClassDefs>
      </LFBLibrary>



6.  Classifer LFBs

   This section provides the classifer LFBs.  It also includes a set of
   data type definitions for use by classifiers.




Halpern                 Expires September 6, 2006              [Page 14]


Internet-Draft           Forces LFB Base Library              March 2006


   Currently, two classifiers are defined here.  One has the ability to
   classify a packet based on combinations of meta data and packet
   contents.  It has the ability to add meta-data, and to select an
   egress port.  It may be useful to define classes with only a subset
   of these capabilities.  The other does an longest prefix match (LPM)
   lookup of the value provided in the "target" meta-data item.

6.1.  Classifier Data Types

   These data definitions belong in a dataTypeDefs element in some
   LFBLibrary.

   These data definitions are built around a simplistic classifier
   model.  The classifier consists of a sequence of test-action pairs.
   The each test consists of an optional input port number condition
   followed by a sequence of match conditions.  A test is considered
   passed if all of the match conditions succeed.  The classifier
   conceptually functions by applying success tests until one succeeds.

   First, there is the definition of the scalar for the target of a
   match.






























Halpern                 Expires September 6, 2006              [Page 15]


Internet-Draft           Forces LFB Base Library              March 2006


     <dataTypeDef>
       <name>MatchTargetType</name>
       <synopsis>
         Indicator for the kind of field to be matched by this
         entry in a classifier.
       </synopsis>
       <atomic>
         <baseType>uint8</baseType>
         <specialValues>
           <specialValue value="0">
             <name>MatchNone</name>
             <synopsis>A matcher against no field</synopsis>
           </specialValue>
           <specialValue value="1">
             <name>MatchMetaData</name>
             <synopsis>A matcher against a metadata item</synopsis>
           </specialValue>
           <specialValue value="2">
             <name>MatchPacketField</name>
             <synopsis>
               A matcher that works against an identified packet field.
             </synopsis>
           </specialValue value="3">
             <name>MatchOffsetLength</name>
             <synposis>
               The match target is a specified portion of the packet.
             </synopsis>
           </specialValue>
         </specialValues>
       </atomic>
     </dataTypeDef>



   Then there is the data type definition for the identifier of the
   target of the match.















Halpern                 Expires September 6, 2006              [Page 16]


Internet-Draft           Forces LFB Base Library              March 2006


     <dataTypeDef>
       <name>MatchTargetIdentifier</name>
       <synopsis>
         Identify the specific target of a match condition.
       </synopsis>
       <union>
         <element elementID="1">
           <name>MetaDataID</name>
           <synopsis>The ID of a metadata item</synopsis>
           <typeRef>uint32</typeRef>
         </element>
         <element elementID="2">
           <name>packetFieldID</name>
           <synopsis>
             The identifier for a packet Field, such as SA, DA,
             Protocol, SPort, DPort, etc.  These identifiers allow
             references to fields with varialbe amounts before them.
           </synopsis>
           <typeRef>uint32</typeRef>
         </element>
         <element elementID="3">
           <name>OffSetLengthPacketField</name>
           <synopsis>
             A field in the packet identified by its offset and
             length in bits.  This does not allow for matching fields
             whose position depends upon earlier field sizes.
           </synopsis>
           <struct>
             <element elementId="1">
               <name>fieldOffset</name>
               <synopsis>
                 The offset in bits from the start of the packet to the
                 start of the field.
               </synopsis>
               <typeRef>uint32</typeRef>
             </element>
             <element elementID="2">
               <name>fieldLength</name>
               <synopsis>The length of the field, in bits</synopsis>
               <typeRef>uint32</typeRef>
             </element>
           </struct>
         </element>
       </union>
     </dataTypeDefs>


   Then there is the representation of the match condition.  First we



Halpern                 Expires September 6, 2006              [Page 17]


Internet-Draft           Forces LFB Base Library              March 2006


   provide the structure definition for a match condition, and then the
   enumeration that defines the various conditions.  This ordering is
   for readability.

   The conditions use bitfields, which are represented as octet strings
   of length up to 16 bytes, along with a length providing the actual
   meaningful length in bits.  The model could be enhanced to provide a
   base type for variable length bit strings.


     <dataTypeDef>
       <name>MatchBitString</name>
       <synopsis>A bit string for use in a match condition.</synopsis>
       <struct>
         <element elementID="1">
           <name>MatchBits</name>
           <synopsis>The bits to match</synopsis>
           <typeRef>OctetString[16]</typeRef>
         </element>
         <element elementID="2">
           <name>MatchLength</name>
           <synopsis>The number of bits to match</synopsis>
           <typeRef>uint8</typeRef>
         </element>
       </struct>
     </dataTypeDef>

     <dataTypeDef>
       <name>MatchCondition</name>
       <synopsis>
         structure for a single condition to be applied.
       <synopsis>
       <struct>
         <element elementID="1">
           <name>TargetType</name>
           <synopsis>The category of target to match</synopsis>
           <typeRef>MatchTargetType</typeRef>
         </element>
         <element elementID="2">
           <name>TargetID</name>
           <synopsis>The specific target to compare</synopsis>
           <typeRef>MatchTargetIdentifier</typeRef>
         </element>
         <element elementID="3">
           <name>MatchType</name>
           <synopsis>The kind of match to apply.</synopsis>
           <typeRef>MatchConditionType</typeRef>
         </element>



Halpern                 Expires September 6, 2006              [Page 18]


Internet-Draft           Forces LFB Base Library              March 2006


         <element elementID="4">
           <name>MatchParamOne</name>
           <synopsis>The first parameter for the match</synopsis>
           <optional/>
           <typeRef>MatchBitString</typeRef>
         <element elementID="5">
           <name>MatchParamTwo</name>
           <synopsis>The second parameter for the match</synopsis>
           <optional/>
           <typeRef>MatchBitString</typeRef>
         </element>
       </struct>
     </dataTypeDef>


   The enumeration describes the match types, and how it interacts with
   the structure of a match condition.  There may be more conditions
   here than we need.


     <dataTypeDef>
       <name>MatchConditiontType</name>
       <synopsis>
         Indicator for the kind of match condition to be applied.
       </synopsis>
       <atomic>
         <baseType>uint8</baseType>
         <specialValues>
           <specialValue value="0">
             <name>MatchNone</name>
             <synopsis>A matcher which always fails</synopsis>
           </specialValue>
           <specialValue value="1">
             <name>MatchExact</name>
             <synopsis>
               The target and the match value must be the same, with no
               padding. Only the first value of the match condition is
               used.  The first match value must be occur.
             </synopsis>
           </specialValue>
           <specialValue value="2">
             <name>MatchLeft</name>
             <synopsis>
               The target must begin with the first match value.
               If there is a second match value, the remainder of the
               target must match repeated occurrances of the second
               value.  Thus, this can be used to allow any terminal
               content, or specific ending pad. The first match value



Halpern                 Expires September 6, 2006              [Page 19]


Internet-Draft           Forces LFB Base Library              March 2006


               must occur.
             </synopsis>
           </specialValue>
           <specialValue value="3">
             <name>MatchRight</name>
             <synopsis>
               The target must end with the first match value.
               If there is a second match value, the preceding part
               of the target must match repeated occurrances of the
               second value.  Thus, this can be used to allow any
               leading content, or specific leading fill.  The first
               match value must occur.
             </synopsis>
           </specialValue>
           <specialValue value="4">
             <name>MatchRange</name>
             <synopsis>
               The match values will be considered as numbers, and
               the target must be greater than or equal to the
               first match value, and less than or equal to the
               second match value.  An omitted match value means
               that end of the range is unlimitted.
             </synopsis>
           </specialValue>
           <specialValue value="5">
             <name>MatchMaskedValue</name>
             <synopsis>
               The target the the first value are each anded with the
               second value.  The match succeeds if the results of these
               and operations are identical.  Both values are required.
             </synopsis>
           </specialValue>
           <specialValue value="6">
             <name>MatchSucceed</name>
             <synopsis>A Match which always succeeds</synopsis>
           </specialValue>
         </specialValues>
       </atomic>
     </dataTypeDef>


   The MatchMetaData Action represents setting a piece of metadata when
   all of the match conditions are met.  The action can set the meta-
   data to a specific value, or can set it to a value used by a match
   condition.

   The two kinds of values are used, without a union, for simplicity.




Halpern                 Expires September 6, 2006              [Page 20]


Internet-Draft           Forces LFB Base Library              March 2006


   The match condition value is used as that avoids the question of
   whether a specific field exists in the packet.  It must exist for it
   to have matched.


     <dataTypeDef>
       <name>MatchMetaDataAction</name>
       <synopsis>
         An action to set a metadata item to either a specific value
         or a field from the incoming meta data or packet.
       </synopsis>
       <struct>
         <element elementID="1">
           <name>MetaDataToSet</name>
           <synopsis>The Meta Data Item to set</synopsis>
           <typeRef>uint32</typeRef>
         </element>
         <element elementID="2">
           <name>ExplicitValueToSet</name>
           <synopsis>A value to set the metadata to</synopsis>
           <optional/>
           <typeRef>OctetString[16]</typeRef>
         </element>
         <element elementID="3">
           <name>ValueFromCondition</name>
           <synopsis>
             This is an index into the corresponding match conditions,
             and the meta data will be set to the value that was tested
             by that condition.
           </synopsis>
           <optional/>
           <typeRef>uint32</typeRef>
         </element>
       </struct>
     </dataTypeDef>


6.2.  ArbitraryClassifierLfb

   This is a class definition that makes use of the above types.  The
   input is a port group, and the match conditions can include the port
   in their test.  This allows the topology to carry some information if
   desired.  The match conditions can select an output from the
   SuccessOuput output port group.  If no condition matches, the packet
   will be sesnt to the FailOutput port.


   <LFBLibrary provides="RedirectLFB">



Halpern                 Expires September 6, 2006              [Page 21]


Internet-Draft           Forces LFB Base Library              March 2006


     <load library="Base"/>
     <LFBClassDefs>
       <LFBClassDef LFBClassId="0x00010004">
         <name>ArbitraryClassifierLfb</name>
         <synopsis>
           A classifier which can test packet or metadata, and on that
           basis set meta-data a pick an output port.
         </synopsis>
         <version>0.0</version>
         <inputPorts>
           <inputPort group="yes">
             <name>PacketsToClassify</name>
             <synopsis>
               The group of ports to received packets over
             </synopsis>
             <expectation>
               <frameExpected>
                 <ref>taggedFrame</ref>
               </frameExpected>
   <! no metadataExpected item as any and all meta data is allowed >
             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort group="yes">
             <name>SuccessOutput</name>
             <synopsis>
               The group of ports used by the classifer for output
               when a successful match is found.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>taggedFrame</ref>
               </frameProduced>
   <! no metaDataProduced as anything can be produced >
             </product>
           </outputPort>
           <outputPort group="no">
             <name>FailOutput</name>
             <synopsis>
               The port to send packets that do not match any entries.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>taggedFrame</ref>
               </frameProduced>
   <! no metaDataProduced as anything can be produced >
             </product>



Halpern                 Expires September 6, 2006              [Page 22]


Internet-Draft           Forces LFB Base Library              March 2006


           </outputPort>
         </outputPorts>
         <attributes>
           <attribute access="read-write" elementID="1">
             <name>ClassifierTable</name>
             <synopsis>
               The table of classifier entries
               Each entry is tested until one succeeds.
               Each entry contains an optional port test, an array of
               packet and meta data tests, an array of metadata actions,
               and an exit selection.
             </synopsis>
             <array type="variable-size">
               <struct>
                 <element elementID="1">
                   <name>InputPortTest</name>
                   <synopsis>
                      If present, this match will only match packets
                      arriving over the specified port.
                   <synopsis>
                   <optional/>
                   <typeRef>uint32</typeRef>
                 </element>
                 <element elementID="2">
                   <name>TestConditions</name>
                   <synopsis>The array of conditions to test</synopsis>
                   <array type="variable-size">
                     <typeRef>MatchCondition</typeRef>
                   </array>
                 </element>
                 <element elementID="3">
                   <name>MetaDataActions</name>
                   <synopsis>
                     The array of meta data modifications to make when the
                     match succeeds.
                   </synopsis>
                   <array type="variable-size">
                     <typeRef>MatchMetaDataAction</typeRef>
                   </array>
                 </element>
                 <element elementID="4">
                   <name>MatchOutputPort</name>
                   <synopsis>
                     The port within the success group to send packets
                     which match these tests.
                   </synopsis>
                   <typeRef>uint32</typeRef>
                 </element>



Halpern                 Expires September 6, 2006              [Page 23]


Internet-Draft           Forces LFB Base Library              March 2006


               </struct>
             </array>
           </attribute>
         </attributes>
         <capabilities>
         </capabilities>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>


6.3.  LPMClassifier

   This takes the information in the "target" metadata item, and looks
   it up in its longest prefix match table.  It sets the "LPMresult"
   meta-data item to the value associated with the best match entry.
   For example, the result might be a next-hop identifier.

6.4.  Next Hop Applicator

   This LFB class is used to apply a next hop to a packet.  The next hop
   is identified by the NextHop meta-data.  The value of that meta-data
   is used as an index into the next-hop table owned by this instance of
   this class.  The table indicates a series of new meta-data items to
   add to the packet, and an exit port from the Success port group.  If
   no valid next hop is found, the packet is sent to the MissingEntry
   port.  If a valid next hop is found, but it needs resolution, the
   packet is sent to the NeedsResolution port, which will typically lead
   to a suitable ARPOutRequest LFB instance.

   As part of the functioning of this LFB, one of the next hop
   identifiers would indicate packets to be sent to the CE.  One of the
   outputs of this Next Hop applicator would be connected to a path
   leading to a Redirect LFB to handle those packets.

   Note that some FEs will have restrictions in their actual
   implementation such that the LPM always goes against certain packet
   fields, and always produces a block of information rather than an
   identifier.  Some of those restrictions can be represented by the FE
   Object LFB Support LFB Attribute CanOccurBefores and CanOccurAfters
   information.


7.  Packet Control LFBs

   These LFBs are related to control functions for data packets.





Halpern                 Expires September 6, 2006              [Page 24]


Internet-Draft           Forces LFB Base Library              March 2006


7.1.  ARPOutRequestLFB

   Given a data packet and a next hop identifier, this LFB builds an ARP
   request and hands it off.  It has an alias to point to the next hop
   table that is shared with the output encapsulor in the connectivity
   LFB and with other packet processors.

7.2.  ARPInMessageLFB

   This LFB is handed received ARP messges, both requests and responses.
   It performs table updating (using alias entries) and when necessary
   generates ARP responses.

7.3.  ICMPLFB

   This is handed a packet with meta-data indicating a problem.  It
   determines if an ICMP message should be generated, and if so to whom
   it should be sent.


8.  Queue and Scheduler LFBs

   To build an actual forwarder, one must include some limitted for of
   queueing and scheduling.  Queues are entities which store packets.
   Schedulers are entities which react to the state of queues and cause
   packets to be emitted from queues.

   The actual interaction between queues and schedulers (and their real
   world degree of separation) is quite complex.  A very complex LFB
   model would be required to represent all the complexity.
   Additionally, there is the issue of representing the relationship
   between the queue and the scheduler.  A simple approach has been
   taken in these class definitions.

   A queue element consists of an input port (called InData) on which it
   receives data packets, and output port (called OutData) on which it
   will send packets when permitted by its definition or the scheduler.
   Its relationship to scheduluers is represented by a set of output
   ports (the group OutCountrol) and an input port (called InControl).
   These ports are defined to carry packets consisting only of meta-
   data.  In fact, these ports are an abstraction, and what one might
   call a legal fiction.  An element of the OutControl group represents
   the fact that a scheduler is aware of the state of that queue
   element.  The InControl port represents the fact that one or more
   schedulers connected to that port are controlling that queue.  There
   is no meta-data defined for actual exchange on these ports, as their
   real world realization is highly implementation dependent.  To
   complete this picture, a schedule has a group of input ports



Halpern                 Expires September 6, 2006              [Page 25]


Internet-Draft           Forces LFB Base Library              March 2006


   (Watchers) representing the connectivity to queues it is aware of,
   and a group of output ports (Controllers) representing control over
   queues.  This allows for the simple case of a controller who monitors
   and controls a single set of queues, and more interesting cases where
   the control of certain queues may depend upon the state of queues
   whihc are not under the control of the scheduler.

8.1.  Scheduler

   This defines a base LFB class for schedulers.  Scheulers have an
   Input Port group called Watchers for representing the queues they
   watch, and an Output Port group called Controllers fro representing
   the queues they control.

8.2.  Queue

   Queues have a packet input, a packet output, a control input, and a
   group of control outputs.  The control ports represent the control
   relationships with scheduluers.


9.  Acknowledgements

   The ideas here are based on proposals from many people.  In
   particular, Xiaoyi Guo has provided some of the LFB definitions
   included herein.


10.  Contributors

   The following people contributed significant portions of text to this
   document.


11.  IANA Considerations

   The ForCES working group needs to determine how LFB Class IDs will be
   registered.  It seems likely that an IANA registry will be needed.
   Once that registry is established by the Model draft, this document
   will need to register values for the LFB classes it defines.


12.  Security Considerations

   These definitions if used by an FE to support ForCES create
   manipulable entities on the FE.  Manipulation of such objects can
   produce almost unlimited effects on the FE.  FEs should ensure that
   only properly authenticated ForCES protocol participants are



Halpern                 Expires September 6, 2006              [Page 26]


Internet-Draft           Forces LFB Base Library              March 2006


   performing such manipulations.  Thus, largely, the security issues
   with this protocol are defined in Protocol [2].


13.  References

13.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Doria, A., "I-D.ietf-forces-protocol-04.txt", 2005.

   [3]  Deleganes, E., "I-D.ietf-forces-model-05.txt", 2005.

13.2.  Informative References



































Halpern                 Expires September 6, 2006              [Page 27]


Internet-Draft           Forces LFB Base Library              March 2006


Author's Address

   Joel M. Halpern
   Self
   P. O. Box 6049
   Leesburg, VA  20178
   US

   Email: jmh@joelhalpern.com










































Halpern                 Expires September 6, 2006              [Page 28]


Internet-Draft           Forces LFB Base Library              March 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Halpern                 Expires September 6, 2006              [Page 29]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/