Internet DRAFT - draft-djjhs-forces-lfbstate
draft-djjhs-forces-lfbstate
Internet Engineering Task Force D. Joachimpillai
Internet-Draft Verizon
Intended status: Informational Hadi Salim
Expires: April 16, 2013 Mojatatu Networks
October 13, 2012
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 16, 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
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 1]
Internet-Draft ForCES LFB Instance State October 2012
described in the Simplified BSD License.
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Changed XML . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 2]
Internet-Draft ForCES LFB Instance State October 2012
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
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 3]
Internet-Draft ForCES LFB Instance State October 2012
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:
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 4]
Internet-Draft ForCES LFB Instance State October 2012
o 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.
o 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.
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 5]
Internet-Draft ForCES LFB Instance State October 2012
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
[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.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 6]
Internet-Draft ForCES LFB Instance State October 2012
Authors' Addresses
Damascane M. Joachimpillai
Verizon
60 Sylvan Rd
Waltham, Mass. 02451
USA
Email: damascene.joachimpillai@verizon.com
Jamal Hadi Salim
Mojatatu Networks
Moodie Dr.
Ottawa, Ontario
Canada
Email: hadi@mojatatu.com
Joachimpillai & Hadi Salim Expires April 16, 2013 [Page 7]
