ForCES LFB Instance State
draft-djjhs-forces-lfbstate-00

Abstract

The ForCES LFB Topology currently defines that once an instance of an LFB class is created it becomes immediately active in the datatapath. This document makes a slight extension to add state to an instantiated LFB class allowing the CE to decide when an LFB instance becomes operational on the datapath.

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 April 14, 2013.

Copyright Notice

Copyright (c) 2012 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.

Table of Contents

• 1. Terminology and Conventions
• 1.1. Requirements Language
• 1.2. Definitions
• 2. Introduction
• 3. Problem Scope
• 4. Proposal Overview
• 4.1. Changed XML
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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 follows the terminology defined by the ForCES Model in [RFC5812]. The required definitions are repeated below for clarity.

FE Model - The FE model is designed to model the logical processing functions of an FE. The FE model proposed in this document 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 FE capabilities. 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 (or type) - A template that represents a fine-grained, logically separable aspect of FE processing. Most LFBs relate to packet processing in the data path. LFB classes are the basic building blocks of the FE model.

LFB Instance - As a packet flows through an FE along a data path, it flows through one or multiple LFB instances, where each LFB is an instance of a specific LFB class. Multiple instances of the same LFB class can be present in an FE's data path. Note that we often refer to LFBs without distinguishing between an LFB class and LFB instance when we believe the implied reference is obvious for the given context.

LFB Model - The LFB model describes the content and structures in an LFB, plus the associated data definition. XML is used to provide a formal definition of the necessary structures for the modeling. Four types of information are defined in the LFB model. The core part of the LFB model is the LFB class definitions; the other three types of information define constructs associated with and used by the class definition. These are reusable data types, supported frame (packet) formats, and metadata.

LFB Metadata - Metadata is used to communicate per-packet state from one LFB to another, but is not sent across the network. The FE model defines how such metadata is identified, produced, and consumed by the LFBs, but not how the per-packet state is implemented within actual hardware. Metadata is sent between the FE and the CE on redirect packets.

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.

LFB Component - An LFB component is a ForCES component that defines the Operational parameters of the LFBs that must be visible to the CEs.

LFB Topology - LFB topology is a representation of the logical interconnection and the placement of LFB instances along the data path within one FE. Sometimes this representation is called intra-FE topology, to be distinguished from inter-FE topology. LFB topology is outside of the LFB model, but is part of the FE model.

FE Topology - FE topology is a representation of how multiple FEs within a single network element (NE) are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology). An individual FE might not have the global knowledge of the full FE topology, but the local view of its connectivity with other FEs is considered to be part of the FE model.

2. Introduction

In the ForCES architecture, a packet service can be modelled by composing a graph of one or more LFB instances. The reader is refered to the details in the ForCES Model [RFC5812]. The CE instantiates a class on the FE making it available for component update (eg table updates) as well as datapath processing.

If an FE is capable of dealing with modifiable LFB topology, then the CE may create a packet service when describing LFB instance graph connections by updating the FEOBject LFBTopology component.

3. Problem Scope

Sometimes it is prudent, after an LFB class is instantiated, to first populate an LFB instance with its configuration before activating it. There are various challenges we face which motivate this document:

• There are cases where an LFB instance may require some minimalist configuration before it can pass data. Any data received before the full configuration is updated may cause race conditions or corruptions.
• The LFB instance may require to receive configuration without being active in the datapath until a future determined time the CE deems. Such is the case when an LFB instance on an LFB is acting as backup of another instance running in another FE.

In both cases described above, we require ability for the CE to instantiate, populate the LFB instance with control data then later activate the populated LFB instance. We also need the ability to offline an LFB instance by having the CE deactivate it.

It should be noted that the FE Object LFB already allows the FE to be activated or offlined from the datapath. The CE may set the component FEState to be either administratively disabled or operationally disabled as well as operationally enabled. The new requirement in this document is to refine the granularity to be at the LFB instance level.

4. Proposal Overview

We propose a backward and forward compatible solution by extending the FEObject LFB.

We propose 3 changes:

1. Introduce a new FEObject Datatypedef which extends the LFBSelectorType. The newLFBSelectorType will have, in addition to the LFB class and instance identification, state definition in the form of a reference to FEStateValues.
2. Introduce a new component which is a table of newLFBSelectorType. This table will parallel the LFBSelectors(ID 2) but will additionally carry the LFB instance state. Old CE implementations can continue to update the LFBSelectors table and ignore the newLFBSelectors table. Such old CE implementations will not be able to use this new feature even if the FE was capable. New CE implementations can update newLFBSelectors table while ignoring the LFBSelectors table. To meet our stated goals, the default state in the newLFBSelectors state will be OperDisable. The CE will have to take the extra step of activating by setting it the state to OperDisable.
3. Introduce a capability advertised by the FE to announce its ability to handle the newLFBSelectors table. XXX: do we require a change to the FEO version?

4.1. Changed XML

TBA

5. Acknowledgements

TBA

6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

TBA

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses