One document matched: draft-ietf-forces-protocol-17.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
-->
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3654 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3654.xml">
<!ENTITY RFC3746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3746.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc compact="no"?>
<?rfc strict="no"?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc notedraftinprogress="yes" ?>
<rfc category="std" docName="draft-ietf-forces-protocol-17.txt" ipr="full3978">
<front>
<title abbrev="ForCES">ForCES Protocol Specification</title>
<author fullname="Ligang Dong" initials="L." surname="Dong">
<organization>Zhejiang Gongshang University</organization>
<address>
<postal>
<street>149 Jiaogong Road</street>
<city>Hangzhou</city>
<code>310035</code>
<country>P.R.China</country>
</postal>
<phone>+86-571-88071024</phone>
<email>donglg@mail.zjgsu.edu.cn</email>
</address>
</author>
<author fullname="Avri Doria" initials="A." surname="Doria (Ed.)">
<organization>Lulea University of Technology</organization>
<address>
<postal>
<street>Rainbow Way</street>
<city>Lulea</city>
<code>SE-971 87</code>
<country>Sweden</country>
</postal>
<phone>+46 73 277 1788</phone>
<email>avri@ltu.se</email>
</address>
</author>
<author fullname="Ram Gopal" initials="R." surname="Gopal">
<organization>Nokia</organization>
<address>
<postal>
<street>5, Wayside Road</street>
<city>Burlington, MA</city>
<code>310035</code>
<country>USA</country>
</postal>
<phone>+1-781-993-3685</phone>
<email>ram.gopal@nokia.com</email>
</address>
</author>
<author fullname="Robert Haas" initials="R." surname="Haas (Ed.)">
<organization>IBM</organization>
<address>
<postal>
<street>Saumerstrasse 4</street>
<city>8803 Ruschlikon</city>
<code></code>
<country>Switzerland</country>
</postal>
<phone></phone>
<email>rha@zurich.ibm.com</email>
</address>
</author>
<author fullname="Jamal Hadi Salim" initials="J."
surname="Hadi Salim (Ed.)">
<organization>Znyx</organization>
<address>
<postal>
<street></street>
<city>Ottawa, Ontario</city>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>hadi@znyx.com</email>
</address>
</author>
<author fullname="Hormuzd M Khosravi" initials="H."
surname="Khosravi (Ed.)">
<organization>Intel</organization>
<address>
<postal>
<street>2111 NE 25th Avenue</street>
<city>Hillsboro, OR</city>
<code>97124</code>
<country>USA</country>
</postal>
<phone>+1 503 264 0334</phone>
<email>hormuzd.m.khosravi@intel.com</email>
</address>
</author>
<author fullname="Weiming Wang " initials="W. " surname="M. Wang (Ed.)">
<organization>Zhejiang Gongshang University</organization>
<address>
<postal>
<street>149 Jiaogong Road</street>
<city>Hangzhou</city>
<code>310035</code>
<country>P.R.China</country>
</postal>
<phone>+86-571-88057712</phone>
<email>wmwang@mail.zjgsu.edu.cn</email>
</address>
</author>
<date month="September" day="25" year="2008" />
<area>Routing</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>ForCES</keyword>
<keyword>Routing</keyword>
<keyword>Protocol</keyword>
<keyword></keyword>
<abstract>
<t>This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications between
Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network
Element (ForCES NE). This specification is intended to meet the ForCES
protocol requirements defined in RFC3654. Besides the ForCES protocol,
this specification also defines the requirements for
the Transport Mapping Layer (TML).
</t>
</abstract>
<note title="Authors">
<t>The participants in the ForCES Protocol Team, primary co-authors and
co-editors, of this protocol specification, are:
</t>
<t>Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea
University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal
Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang
(Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern
who has done extensive editing in support of congruence between the model
and
this protocol specification. Without his participation and persistence,
this specification might
never have been completed.
</t>
</note>
</front>
<!--
-->
<middle>
<section title="Terminology and Conventions">
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Other Notation">
<t>In <xref target="PMsgt" /> and
<xref target="FSt" /> the following notation is used to
indicate multiplicity:</t>
<t>
<list>
<t> (value)+ .... means "1 or more instance of value"</t>
<t> (value)* .... means "0 or more instance of value"</t>
</list>
</t>
</section>
<section title="Integers">
<t>
All integers are to be coded as unsigned binary integers of appropriate length.
</t>
</section>
</section>
<!-- introduction.xml -->
<section title="Introduction">
<t>Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding plane
in a ForCES Network Element (ForCES NE). RFC 3654 has defined the ForCES
requirements, and RFC 3746 has defined the ForCES framework. While there
may be multiple protocols used within the overall ForCES architecture,
the term "ForCES protocol" and "protocol" as used in this document
refers to the protocol used to standardize the information exchange
between Control Elements (CEs) and Forwarding Elements (FEs) only. </t>
<t>The ForCES FE model <xref target="FE-MODEL"></xref> presents
a formal way to define FE Logical Function Blocks (LFBs) using XML.
LFB configuration components, capabilities, and associated events are
defined when the LFB is formally created. The LFBs within the FE are
accordingly controlled in a standardized way by the ForCES protocol.</t>
<t>This document defines the ForCES protocol specifications. The ForCES
protocol works in a master-slave mode in which FEs are slaves and CEs
are masters. The protocol includes commands for transport of Logical
Function Block (LFB) configuration information, association setup,
status, and event notifications, etc.</t>
<!--
<t>This specification does not define a transport mechanism for protocol
messages. A discussion of service primitives that must be provided by
the underlying transport interface will be discussed in a future
document.</t>
-->
<t><xref target="Definitions"></xref> provides a glossary of terminology
used in the specification.</t>
<t><xref target="Overview"></xref> provides an overview of the protocol,
including a discussion on the protocol framework, descriptions of the
Protocol Layer (PL) and a Transport Mapping Layer (TML), as well as of
the ForCES protocol mechanisms.
<xref target="Proto_Scene"></xref> describes several Protocol
scenarios and includes message exchange descriptions.</t>
<t>While this document does not define the TML, <xref
target="TML_Req"></xref> details the services that a TML must provide
(TML requirements).</t>
<t>The ForCES protocol defines a common header for all protocol
messages. The header is defined in <xref target="Common_Header"></xref>,
while the protocol messages are defined in <xref
target="Proto_Msg"></xref>.</t>
<t><xref target="HA"></xref> describes the protocol support for
high availability mechanisms including redundancy and fail over.
</t>
<t>
<xref target="Security"></xref> defines the security mechanisms provided
by the PL and TML.</t>
</section>
<!-- &Definitions; -->
<section anchor="Definitions" title="Definitions">
<t>This document follows the terminology defined by the ForCES
Requirements in <xref target="RFC3654"></xref> and by the ForCES
framework in <xref target="RFC3746"></xref>. <!--
This document also uses the terminology
defined by ForCES the FE model in <xref target="FE-MODEL"/>.
--> The definitions below are repeated below for clarity.</t>
<t>Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on IP
networks, it is a device which can be reached using an IP address; and
on a switch fabric, it is a device which can be reached using a switch
fabric port number.</t>
<t>Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of control and
signaling protocols.</t>
<t>CE Manager (CEM) - A logical entity responsible for generic CE
management tasks. It is particularly used during the pre-association
phase to determine with which FE(s) a CE should communicate. This
process is called FE discovery and may involve the CE manager learning
the capabilities of available FEs. <cref source="WGLC"> A logical entity
that operates in the pre-association phase and is responsible for
determining to which FE(s) a CE should communicate. This process is
called FE discovery and may involve the CE manager learning the
capabilities of available FEs. A CE manager may use anything from a
static configuration to a pre-association phase protocol (see below) to
determine which FE(s) to use. Being a logical entity, a CE manager might
be physically combined with any of the other logical entities such as
CEs. </cref></t>
<t>Datapath - A conceptual path taken by packets within the forwarding
plane inside an FE.</t>
<t>Forwarding Element (FE) - A logical entity that implements the ForCES
protocol. FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by one or
more CEs via the ForCES
protocol.</t>
<t>FE Model - A model that describes the logical processing functions of
an FE. The FE model is defined using Logical Function Blocks (LFBs). </t>
<t>FE Manager (FEM) - A logical entity responsible for generic FE
management tasks. It is used during pre-association phase to determine
with which CE(s) an FE should communicate. This process is called CE
discovery and may involve the FE manager learning the capabilities of
available CEs. An FE manager may use anything from a static
configuration to a pre-association phase protocol (see below) to
determine which CE(s) to use. Being a logical entity, an FE manager
might be physically combined with any of the other logical entities such
as FEs.</t>
<t>ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside an NE, the NE represents a
single point of management. Similarly, an NE usually hides its internal
organization from external entities.</t>
<t>High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents or
headers of a packet based on content other than what is found in the IP
header. Examples of these capabilities include
quality of service policies, virtual private networks, firewall, and L7
content recognition.</t>
<t>Inter-FE Topology - See FE Topology.</t>
<t>Intra-FE Topology - See LFB Topology.</t>
<t>LFB (Logical Function Block) - The basic building block that is
operated on by the ForCES protocol. The LFB is a well defined, logically
separable functional block that resides in an FE and is controlled by
the CE via ForCES protocol. The LFB may reside at the FE's datapath and
process packets or may be purely an FE control or configuration entity
that is operated on by the CE. Note that the LFB is a functionally
accurate abstraction of the FE's processing capabilities, but not a
hardware-accurate representation of the FE implementation.</t>
<t>FE Topology - A representation of how the multiple FEs within a
single NE are interconnected. Sometimes this is called inter-FE
topology, to be distinguished from intra-FE topology (i.e., LFB
topology).</t>
<t>LFB Class and LFB Instance - LFBs are categorized
by LFB Classes. An LFB Instance represents an LFB Class (or
Type) existence. There may be multiple instances of the same LFB Class
(or Type) in an FE. An LFB Class is represented by an LFB Class ID, and
an LFB Instance is represented by an LFB Instance ID. As a result, an
LFB Class ID associated with an LFB Instance ID uniquely specifies an LFB
existence.</t>
<t>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. It defines the functionality but not how metadata is encoded
within an implementation.</t>
<t>LFB Attribute - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB
attributes. The LFB attributes include, for example, flags, single
parameter arguments, complex arguments, and tables that the CE can read
and/or write via the ForCES protocol (see below).</t>
<t>LFB Topology - Representation of how the LFB instances are logically
interconnected and placed along the datapath within one FE. Sometimes it
is also called intra-FE topology, to be distinguished from inter-FE
topology.</t>
<t>Pre-association Phase - The period of time during which an FE Manager
and a CE Manager are determining which FE(s) and
CE(s) should be part of the same network element.</t>
<t>Post-association Phase - The period of time during which an FE knows
which CE is to control it and vice versa. This includes the time during
which the CE and FE are establishing communication with one another.</t>
<!--
<t>The following terms are defined by this document:</t>
-->
<t>ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" and
"protocol" refer to the Fp reference points in the ForCES Framework in
<xref target="RFC3746"></xref>. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between FE
and CE managers. Basically, the ForCES protocol works in a master-slave
mode in which FEs are slaves and CEs are masters. This document defines
the specifications for this ForCES protocol.</t>
<t>ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol
architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML as shown below).
Specifications of ForCES PL are defined by this document.</t>
<t>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, Ethernet, etc), and how to
achieve and implement reliability, multicast, ordering, etc. The ForCES
TML specifications are detailed in separate ForCES documents, one for
each TML.</t>
</section>
<!-- &Overview; -->
<!-- x.0 Protocol Overview -->
<section anchor="Overview" title="Overview">
<t>The reader is referred to the Framework document <xref
target="RFC3746"></xref>, and in particular sections 3 and 4, for an
architectural overview and an explanation of how the ForCES protocol
fits in. There may be some content overlap between the framework
document and this section in order to provide clarity. This
document is authoritative on the protocol whereas <xref
target="RFC3746"></xref> is authoritative on the architecture.</t>
<!-- x.1 Protocol Framework -->
<section title="Protocol Framework">
<figure anchor="ne_arch" title="ForCES Architectural Diagram">
<preamble><xref target="ne_arch"></xref> below is reproduced from
the Framework document for clarity. It shows a NE with two CEs and
two FEs.</preamble>
<artwork><![CDATA[
---------------------------------------
| ForCES Network Element |
-------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | |
| | -------------- -------------- |
| Fl | | | Fp / |
| | Fp| |----------| / |
| | | |/ |
| | | | |
| | | Fp /|----| |
| | | /--------/ | |
-------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: CE-FE interface
Fi: FE-FE interface
Fr: CE-CE interface
Fc: Interface between the CE Manager and a CE
Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface
]]></artwork>
</figure>
<t>The ForCES protocol domain is found in the Fp Reference Points. The
Protocol Element configuration reference points, Fc and Ff also play a
role in the booting up of the ForCES Protocol. The protocol element
configuration (indicated by reference points Fc, Ff, and Fl in
<xref target="RFC3746" /> ) is out of
scope of the ForCES protocol but is touched on in this document in
discussion of FEM and CEM since it is an integral part of the protocol
pre-association phase.</t>
<figure anchor="Fp_if" title="Examples of CE and FE functions">
<preamble><xref target="Fp_if"></xref> below shows further breakdown
of the Fp interfaces by means of the example of an MPLS QoS
enabled Network Element.</preamble>
<artwork><![CDATA[
-------------------------------------------------
| | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | |
------------------------------------------------- CE
| ForCES Interface |
-------------------------------------------------
^ ^
| |
ForCES | |data
control | |packets
messages| |(e.g., routing packets)
| |
v v
-------------------------------------------------
| ForCES Interface |
------------------------------------------------- FE
| | | | | | |
|LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
| | | | |fier | |
-------------------------------------------------
]]></artwork>
</figure>
<!--
[Add more text referring to the figure above; probably customize
text from the Framework doc as well]
-->
<t>The ForCES Interface shown in <xref target="Fp_if"></xref>
constitutes two pieces: the PL and the TML.</t>
<figure anchor="PL_TML_if" title="ForCES Interface">
<preamble>This is depicted in <xref target="PL_TML_if"></xref>
below.</preamble>
<artwork><![CDATA[
+------------------------------------------------
| CE PL |
+------------------------------------------------
| CE TML |
+------------------------------------------------
^
|
ForCES | (i.e ForCES data + control
PL | packets )
messages |
over |
specific |
TML |
encaps |
and |
transport |
|
v
+------------------------------------------------
| FE TML |
+------------------------------------------------
| FE PL |
+------------------------------------------------
]]></artwork>
</figure>
<t>The PL is in fact the ForCES protocol. Its semantics and
message layout are defined in this document. The TML Layer is
necessary to connect two ForCES PLs as shown in <xref
target="PL_TML_if"></xref> above. The TML is out of scope for this
document but is within scope of ForCES. This document defines
requirements the PL needs the TML to meet.</t>
<t>Both the PL and the TML are standardized by the IETF. While
only one PL is defined, different TMLs are expected to be
standardized. To interoperate the TML at the CE and FE are
expected to conform to the same definition.</t>
<t>On transmit, the PL delivers its messages to the TML.
The local TML delivers the message to the destination TML. On
receive, the TML delivers the message to its destination PL.
</t>
<!--t>
[Add more text here on above later]
</t-->
<!-- x.1.1 The PL Layer -->
<section title="The PL ">
<t>The PL is common to all implementations of ForCES and is
standardized by the IETF as defined in this document. The PL
is responsible for associating an FE or CE to an NE. <!-- TBD: awkward phrase -->
It is also responsible for tearing down such associations. An FE
uses the PL to transmit various subscribed-to events to the CE
PL as well as to respond to various status requests issued
from the CE PL. The CE configures both the FE and associated LFBs'
operational parameters using the PL. In addition the CE may
send various requests to the FE to activate or deactivate it,
reconfigure its HA parameterization, subscribe to specific events
etc. More details can be found in <xref
target="Proto_Msg"></xref>.</t>
<!--
[Add more text here on above later]
-->
</section>
<!-- End PL -->
<!-- x.1.2 The TML Layer -->
<section title="The TML ">
<t>The TML transports the PL messages. The TML is where
the issues of how to achieve transport level reliability, congestion
control, multicast, ordering, etc. are handled. It is expected that
more than one TML will be standardized. The various possible
TMLs could
vary their implementations based on the capabilities of underlying
media and transport. However, since each TML is standardized,
interoperability is guaranteed as long as both endpoints support the
same TML. All ForCES Protocol Layer implementations MUST be portable
across all TMLs, because all TMLs MUST have the top edge semantics
defined in this document.</t>
<!--
[Update this later with more details once the messages are
well laid out; talk about implicit approach]
-->
</section>
<!-- end TML -->
<section title="The FEM/CEM Interface">
<t>The FEM and CEM components, although valuable in the setup and
configurations of both the PL and TML, are out of scope of
the ForCES protocol. The best way to think of them is as
configurations/parameterizations for the PL and TML before they
become active (or even at runtime based on implementation). In the
simplest case, the FE or CE reads a static configuration file. RFC
3746 has a more detailed description on how the FEM and CEM could
be used. The pre-association phase, where the CEM and FEM can be
used, are described briefly in <xref
target="Pre_Association" />.</t>
<t>An example of typical things the FEM/CEM could configure would
be TML specific parameterizations such as:</t>
<t>
<list style="letters">
<t>How the TML connection should happen (for example what IP
addresses to use, transport modes etc);</t>
<t>The ID for the FE (FEID) or CE (CEID) (which would
also be issued during the pre-association phase).</t>
<t>Security parameterization such as keys etc.</t>
<t>Connection association parameters</t>
</list>
</t>
<t>Example of connection association parameters this might be:
<list style="symbols">
<t>simple parameters: send up to 3 association messages every 1
second</t>
<t>complex parameters: send up to 4 association messages
with increasing exponential timeout</t>
</list>
</t>
</section>
<!-- FEM/CEM -->
</section>
<!-- Protocol Framework-->
<section anchor="FPP" title="ForCES Protocol Phases">
<t>ForCES, in relation to NEs, involves two phases: the
pre-association phase, where configuration/initialization/bootup
of the
TML and PL layer happens, and the post-association phase where
the ForCES protocol operates to manipulate the parameters of the
FEs.</t>
<figure anchor="FE_SM" title="The FE Protocol Phases">
<artwork><![CDATA[
CE sends Association Setup
+---->--->------------>---->---->---->------->----+
| Y
^ |
| Y
+---+-------+ +-------------+
|FE Pre- | | FE Post- |
|Association| CE sends Association Teardown | Association |
|Phase |<------- <------<-----<------<-------+ Phase |
| | | |
+-----------+ +-------------+
^ Y
| |
+-<---<------<-----<------<----<---------<------+
FE loses association
]]></artwork>
</figure>
<t>In the mandated case, once associated,
the FE may forward packets
depending on the configuration of its specific LFBs. An
FE which is associated to a CE
will continue sending packets until it receives an
Association teardown message or until it loses association.
An unassociated FE MAY continue sending packets when it has a
high availability capability. The extra details are
explained in <xref target="HA"></xref> and not discussed here
to allow for a clear explanation of the basics.
</t>
<t>The FE state transitions are controlled by means of the
FE Object LFB FEState component, which is defined in
<xref target="FE-MODEL"></xref> section 5.1 and also
explained in <xref target="FEO"></xref>.
<!-- FIX REFERENCE In the FE Object
LFB, FE state is defined as a component of the LFB, and CE
configuration of the FE state equals CE configuration of this
attribute.--></t>
<t>The FE initializes in the FEState OperDisable. When the
FE is ready to process packets in the data path it transitions
itself to the OperEnable state. </t>
<t>The CE may decide to pause the FE after it already came up
as OperEnable. It does this by setting the FEState to AdminDisable.
The FE stays in the AdminDisable state until it is explicitly
configured by the CE to transition to the OperEnable state.</t>
<!--
The FE transitions from the OperEnable to the DOWN state when explicitly
configured to do so by the CE or when FE loses its association with
CE.
Whether or not FE goes to DOWN state in this case depends on the
policy the CE sets for the FE for when such failover happens. See the
'CE failover policy' part in Section 7.2.1 for more details on this.
-->
<t>
When the FE loses its association with the CE it may go into
the pre-association phase depending on the programmed
policy. For the FE to properly complete the transition to the
AdminDisable state, it MUST stop Packet forwarding and this may impact
multiple LFBS. How this is achieved is outside the scope of this
specification.</t>
<!--
<t>
<list style="hanging">
<t hangText="Note:">in the case of loss of association, the FE can
also be configured to not go to the DOWN state.</t>
</list>
</t>
-->
<!-- FIX REFERENCES -->
<section anchor="Pre_Association" title="Pre-association">
<t>The ForCES interface is configured during the pre-association
phase. In a simple setup, the configuration is static and is
typically read
from a saved configuration file. All the parameters for the
association phase are well known after the pre-association phase is
complete. A protocol such as DHCP may be used to retrieve the
configuration parameters instead of reading them from a static
configuration file. Note, this will still be considered static
pre-association. Dynamic configuration may also happen using the Fc,
Ff and Fl reference points (refer to <xref target="RFC3746" />).
Vendors may use their own proprietary
service discovery protocol to pass the parameters. Essentially, only
guidelines are provided here and the details are left to the
implementation.</t>
<figure anchor="Ex_PreAssoc"
title="Examples of a message exchange over the Ff and Fc reference points">
<preamble>The following are scenarios reproduced from the
Framework Document to show a pre-association example.</preamble>
<artwork><![CDATA[
<----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication
| | | |
(FE ID, components) (CE ID, components)
2|<-------------| request 2|<------------|request
| | | |
3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID)
| | | |
| | | |
]]></artwork>
</figure>
<!--
[Add some text on the above]
Iam actually not quiet clear what corresponding FE ID is on the Fc ref point
thing
-->
<figure anchor="Ex_F1_msg"
title="An example of a message exchange over the Fl reference point">
<artwork><![CDATA[
<-----------Fl ref pt--------------> |
FE Manager FE CE Manager CE
| | | |
| | | |
(security exchange) | |
1|<------------------------------>| |
| | | |
(a list of CEs and their components) |
2|<-------------------------------| |
| | | |
(a list of FEs and their components) |
3|------------------------------->| |
| | | |
| | | |
]]></artwork>
</figure>
<t>Before the transition to the association phase, the FEM will have
established contact with a CEM component. Initialization of the
ForCES interface will have completed, and authentication as well as
capability discovery may be complete. Both the FE and CE would have
the necessary information for connecting to each other for
configuration, accounting, identification, and authentication
purposes. To summarize, at the completion of this stage both sides
have all the necessary protocol parameters such as timers, etc. The
Fl reference point may continue to operate during the association
phase and may be used to force a disassociation of an FE or CE.
The specific interactions of the CEM and the FEM that
are part of the pre-association phase are out of scope; for this
reason these details are
not discussed any further in this specification. The reader is
referred to the framework document <xref target="RFC3746" /> for a
slightly more detailed discussion.</t>
</section>
<!-- Pre-association -->
<section title="Post-association">
<t>In this phase, the FE and CE components communicate with each
other using the ForCES protocol (PL over TML) as defined in this
document. There are three sub-phases: <list style="symbols">
<t>Association Setup Stage</t>
<t>Established Stage</t>
<t>Association Lost Stage</t>
</list></t>
<!--
[do we need an INIT state?]
-->
<section title="Association Setup Stage">
<t>The FE attempts to join the NE. The FE may be rejected or
accepted. Once granted access into the NE, capabilities exchange
happens with the CE querying the FE. Once the CE has the FE
capability information, the CE can offer an initial configuration
(possibly to restore state) and can query certain components
within either an LFB or the FE itself.</t>
<t>More details are provided in <xref target="Proto_Scene" />.</t>
<t>On successful completion of this stage, the FE joins the NE and
is moved to the Established Stage.</t>
<!--
[Draw a state machine here]
-->
<!--
[update this section when the body message layout becomes clear]
-->
</section>
<section title="Established Stage">
<t>In this stage, the FE is continuously updated or queried. The FE
may also send asynchronous event notifications to the CE or
synchronous heartbeat notifications if programmed to do so. This
stage continues until a termination occurs, either due to loss of
connectivity or due to a termination initiated by either
the CE or the FE.</t>
<t>Refer to the section on protocol scenarios, <xref
target="Proto_Scene" />, for more details.</t>
</section>
<section anchor="ALS" title="Association Lost Stage">
<t>In this state, both or either the CE or FE declare the other
side is no longer associated. The disconnection could be
initiated by either party for administrative purposes
but may also be driven by operational reasons such as loss of
connectivity.</t>
<t>A core LFB known as FE Protocol Object (FEPO) is defined
(refer to <xref target="FPL_def" /> and
<xref target="FPL_sum" />). FEPO defines various timers
which can be used in conjunction with traffic sensitive
heartbeat mechanism (<xref target="HB_appr" />) to detect
loss of connectivity. </t>
<t>
The loss of connectivity between TMLs does not indicate a
loss of association between respective PL layers. If the
TML cannot repair the transport loss before the programmed
FEPO timer thresholds associated with the FE is exceeded,
then the association between the respective PL layers will
be lost.
</t>
<t>FEPO defines several policies that can be programmed
to define behavior upon a detected loss of association.
The FEPO's programmed CE failover policy (refer to
<xref target="HA" />, <xref target="FPL_sum" />,
<xref target="HB_appr" /> and <xref target="FPL_def" />)
defines what takes place upon loss of association.
<!-- <xref target= "Resp_def" />.
--></t>
<t>For this version of the protocol (as defined in this document),
the FE, upon re-association, MUST discard any state it has as
invalid and retrieve new state. This approach is motivated by a
desire for simplicity (as opposed to efficiency).
</t>
</section>
</section>
<!-- Post association -->
</section>
<!-- Phases -->
<section anchor="protmech" title="Protocol Mechanisms">
<t>Various semantics are exposed to the protocol users via the PL
header including: transaction capabilities, atomicity of transactions,
two phase commits, batching/parallelization, high availability and
failover as well as command pipelines.</t>
<t>The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP
(Transaction Phase) flag as defined in the Common Header
(<xref target="Common_Header"></xref>)
<!-- FIX REFERENCES --> are relevant to these mechanisms.</t>
<section anchor="taer"
title="Transactions, Atomicity, Execution and Responses">
<t>In the master-slave relationship the CE instructs one or more FEs
on how to execute operations and how to report the results.</t>
<t>This section details the different modes of execution that a CE
can order the FE(s) to perform, as defined in <xref
target="exec_def"></xref>. It also describes the different modes a
CE can ask the FE(s) to use for formatting the responses after
processing the operations as requested. These modes relate to the
transactional two phase commitment operations. <!-- in <xref target= "Resp_def" />. --></t>
<section anchor="exec_def" title="Execution">
<t>There are 3 execution modes that can be requested for a batch
of operations spanning one or more LFB selectors
(refer to <xref target="LFBselectTLV"></xref>)
in one protocol
message. The EM flag defined in the Common Header
<xref target="Common_Header"></xref>
selects <!-- FIX REFERENCES --> the execution mode for a
protocol message, as below:</t>
<t>
<list style="letters">
<t>execute-all-or-none</t>
<t>continue-execute-on-failure</t>
<t>execute-until-failure</t>
</list>
</t>
<section title="execute-all-or-none">
<t>When set to this mode of execution, independent operations
in a message MAY be targeted at one or more LFB selectors
within an FE. All these operations are executed serially
and the FE MUST have no execution failure for any of the
operations. If any operation fails to execute,
then all the previous ones that have been executed
prior to the failure will need to be undone.
I.e., there is rollback for this mode of operation.</t>
<t>Refer to <xref target="tp_def" /> for how this mode is used
in cases of transactions. In such a case, no operation is
executed unless a commit is issued by the CE.</t>
<t>Care should be taken on how this mode is used because
a mis-configuration could result in traffic losses. To
add certainty to the success of an operation, one should
use this mode in a transactional operation as described in
<xref target="tp_def" /> </t>
</section>
<section title="continue-execute-on-failure">
<t>If several independent operations are targeted at one or more
LFB selectors, execution continues for all operations at the FE
even if one or more operations fail.</t>
</section>
<section title="execute-until-failure">
<t>In this mode all operations are executed on the FE
sequentially until the first failure. The rest of the operations
are not executed but operations already completed are not
undone. I.e., there is no rollback in this mode of
operation.</t>
</section>
</section>
<!-- end execution -->
<section title="Transaction and Atomicity">
<section anchor="aorn_def" title="Transaction Definition">
<t>A transaction is defined as a collection of one or more
ForCES operations within one or more PL messages that MUST meet
the ACIDity properties <xref target="ACID" />, defined as:</t>
<t>
<list hangIndent="13" style="hanging">
<t hangText="Atomicity: ">In a transaction involving two or
more discrete pieces of information, either all of the pieces
are committed or none are.</t>
<t hangText="Consistency: ">A transaction either creates a new
and valid state of data, or, if any failure occurs, returns
all data to the state it was in before the transaction was
started.</t>
<t hangText="Isolation: ">A transaction in process and not yet
committed must remain isolated from any other transaction.</t>
<t hangText="Durability: ">Committed data is saved by the
system such that, even in the event of a failure and a system
restart, the data is available in its correct state.</t>
</list>
</t>
<t>There are cases where the CE knows exact memory and
implementation details of the FE such as in the case of an FE-CE
pair from the same vendor where the FE-CE pair is tightly
coupled. In such a case, the transactional operations may be
simplified further by extra computation at the CE. This view is
not discussed further other than to mention that it is not
disallowed.</t>
<t>As defined above, a transaction is always atomic and MAY be
<list style="letters">
<t>Within an FE alone<vspace /> Example: updating multiple
tables that are dependent on each other. If updating one
fails, then any that were already updated must be
undone.</t>
<t>Distributed across the NE<vspace /> Example: updating
table(s) that are inter-dependent across several FEs (such
as L3 forwarding related tables).</t>
</list></t>
</section>
<!-- end transaction defintion -->
<section anchor="tp_def" title="Transaction Protocol">
<t>By use of the execute mode, as defined in <xref
target="exec_def"></xref>, the protocol has provided a mechanism
for transactional operations within one stand-alone message. The
'execute-all-or-none' mode can meet the ACID requirements.</t>
<t>For transactional operations of multiple messages within one
FE or across FEs, a classical transactional protocol known as
Two Phase Commit (2PC) <xref target="2PCREF"></xref>
is supported by the protocol to achieve the transactional
operations utilizing Config messages
(<xref target="CfgMsg"></xref>).</t>
<t>The COMMIT and TRCOMP operations
in conjunction with the AT and the TP flags in
<xref target="Common_Header">Common Header</xref> are
provided for 2PC-based
transactional operations spanning multiple messages.</t>
<t>The AT flag, when set, indicates this message belongs to an
Atomic Transaction. All messages for a transaction operation
must have the AT flag set. If not set, it means the message is a
stand-alone message and does not participate in any transaction
operation that spans multiple messages.</t>
<t>The TP flag indicates the Transaction Phase this message
belongs to. There are four (4) possible phases for an
transactional operation known as: <list>
<t>SOT (Start of Transaction)</t>
<t>MOT (Middle of Transaction)</t>
<t>EOT (End of Transaction)</t>
<t>ABT (Abort)</t>
</list></t>
<t>The COMMIT operation is used by the CE to signal to the
FE(s) to commit a transaction. When used with an ABT TP flag,
the COMMIT operation signals the FE(s) to rollback (i.e
un-COMMIT) a previously committed transaction.</t>
<t>The TRCOMP operation is a small addition to the classical
2PC approach. TRCOMP is sent by the CE to signal the FE(s)
that the transaction they have COMMITed is now over. This
allows the FE(s) an opportunity to clear state they may
have kept around to perform a rollback (if it became necessary).
</t>
<t>A transaction operation is started with a message in which
the TP flag
is set to Start of Transaction (SOT). Multi-part messages, after
the first one, are indicated by the Middle of Transaction flag
(MOT). All messages from the CE MUST set the AlwaysACK flag
(<xref target="msg_encap"></xref>) to solicit responses
from the FE(s).
</t>
<t>Before the CE issues a commit (described further below)
the FE MUST only validate that the operation can be executed
but not execute it.
<list>
<t>Any failure notified by an FE causes the CE to abort
the transaction on all FEs involved in the
transaction. This is achieved by sending a Config message
with an ABT flag and a COMMIT operation.
</t>
<t>If there are no failures by any participating FE,
the transaction commitment phase is signaled from the CE
to the FE by an End of Transaction (EOT) configuration
message with a COMMIT operation.
</t>
</list>
</t>
<t>
The FE MUST respond to the CE's EOT message. There are
two possible failure scenarios in which the CE MUST
abort the transaction (as described above):
<list style="letters">
<t>
If any participating FE responds with a failure message
in relation to the transaction.
</t>
<t>
If no response is received from a participating FE within a
specified timeout.
</t>
</list>
If all participating FE(s) respond with a success indicator
within the expected time, then
the CE MUST issue a TRCOMP operation to all participating FEs.
An FE MUST NOT respond to a TRCOMP.
</t>
<t>Note that a transactional operation is generically atomic,
therefore it requires that the execute modes of all messages in
a transaction operation should always be kept the same and be
set to 'execute-all-or-none'. If the EM flag is set to other
execute modes, it will result in a transaction failure.</t>
<t>As noted above, a transaction may span multiple messages. It
is up to the CE to keep track of the different outstanding
messages making up a transaction. As an example, the correlator
field could be used to mark transactions and a sequence field to
label the different messages within the same atomic transaction,
but this is out of scope and up to implementations.</t>
</section>
<!-- Transaction protocol -->
<section anchor="roll_def" title="Recovery">
<t>Any of the participating FEs, or the CE, or the associations
between them, may fail after the EOT response message has been
sent by the FE but before the CE has received all the responses,
e.g. if the EOT response never reaches the CE.</t>
<t>In this protocol revision, as indicated in
<xref target="ALS"></xref>, an FE losing an association
would be required to get entirely new state from the
newly associated CE upon a re-association. Although this
approach is simplistic and provides likeliness of loosing datapath
traffic, it is a design choice to avoid the additional complexity of
managing graceful restarts. The HA mechanisms
(<xref target="HA"></xref>) are provided to allow for a
continuous operation in case of FE failures.
</t>
<t>
Flexibility is provided on how to react when an
FE looses association. This is dictated by the CE
Failover policy (refer to <xref target="HA"></xref> and <xref
target="LFB_def"></xref>).</t>
</section>
<!-- end recovery -->
<section title="Transaction Messaging Example">
<t> This section illustrates an example of how
a successful two phase commit between a CE and an FE would
look like in the simple case.
</t>
<figure anchor="twopc"
title="Example of a two phase commit">
<preamble></preamble>
<artwork><![CDATA[
FE PL CE PL
| |
| (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (2) ACKnowledge |
|----------------------------------------------------->|
| |
| (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (4) ACKnowledge |
|----------------------------------------------------->|
| |
| (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (6) ACKnowledge |
|----------------------------------------------------->|
. .
. .
. .
. .
| |
| (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT |
|<-----------------------------------------------------|
| |
| (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE|
|----------------------------------------------------->|
| |
| (N+2) Config, OP=TRCOMP |
|<-----------------------------------------------------|
]]></artwork>
</figure>
<t>
For the scenario illustrated above:
<list style="symbols">
<t>
In step #1, the CE issues a Config message with an
operation of choice like a DEL or SET. The transactional
flag are set to indicate a Start of Transaction (SOT),
Atomic Transaction (AT), execute-all-or-none.
</t>
<t>
The FE validates that it can execute the request
successfully and then issues an acknowledgment
back to the the CE in step #2.
</t>
<t>
In step #3, the same sort of construct as in
step #1 is repeated
by the CE with the transaction flag changed to
Middle of Transaction(MOT).
</t>
<t>
The FE validates that it can execute the request
successfully and then issues an acknowledgment
back to the the CE in step #4.
</t>
<t>
The CE-FE exchange continues in the same manner
until all the operations and their parameters are
transferred to the FE. This happens in step #(N-1).
</t>
<t>
In step #N, the CE issues a commit.
A commit is a config message with an
operation of type COMMIT. The transactional
flags are set to End of Transaction (EOT). Essentially,
this is an "empty" message asking the FE to execute
all the operations it has gathered since the
beginning of the transaction (message #1).
</t>
<t>
The FE at this point executes
the full transaction. It then issues an acknowledgment
back to the the CE in step #(N+1) which contains
a COMMIT-RESPONSE.
</t>
<t>
The CE in this case has the simple task of issuing
a TRCOMP operation the the FE in step #(N+2)
</t>
</list>
</t>
</section>
</section>
<!-- end transaction and atomicity -->
</section>
<!-- end Atomicity, Execution and Responses -->
<!-- 4.3.2. Scalability -->
<section title="Scalability">
<t>It is desirable that the PL not become the bottleneck when
larger bandwidth pipes become available. To pick a hypothetical
example in today's terms, if a 100Gbps pipe is available and there
is sufficient work then the PL should be able to take
advantage of this and use all of the 100Gbps pipe. Two mechanisms
have been provided to achieve this. The first one is batching and
the second one is a command pipeline.</t>
<t>Batching is the ability to send multiple commands (such as
Config) in one Protocol Data Unit (PDU). The size of the batch will
be affected by, amongst other things, the path MTU. The commands may
be part of the same transaction or may be part of unrelated
transactions that are independent of each other.</t>
<t>Command pipelining allows for pipelining of independent
transactions which do not affect each other. Each independent
transaction could consist of one or more batches.</t>
<section title="Batching">
<t>There are several batching levels at different protocol
hierarchies. <list style="symbols">
<t>multiple PL PDUs can be aggregated under one TML
message</t>
<t>multiple LFB classes and instances (as indicated in the LFB
selector) can be addressed within one PL PDU</t>
<t>Multiple operations can be addressed to a single LFB class
and instance</t>
</list></t>
</section>
<section title="Command Pipelining">
<t>The protocol allows any number of messages to be issued by the
CE before the corresponding acknowledgments (if requested) have
been returned by the FE. Hence pipelining is inherently supported
by the protocol. Matching responses with requests messages can be
done using the correlator field in the message header.</t>
</section>
</section>
<!-- end scalability -->
<section anchor="HB_appr" title="Heartbeat Mechanism">
<t>Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB
is sent only if no PL traffic is sent between the CE and FE within a
configured interval. This has the effect of reducing the amount of
HB traffic in the case of busy PL periods.</t>
<t>An HB can be sourced by either the CE or FE. When sourced by the
CE, a response can be requested (similar to the ICMP ping protocol).
The FE can only generate HBs in the case of being configured to do
so by the CE. Refer to <xref target="FPL_sum"></xref> and <xref
target="HBMsg"></xref> for details.</t>
</section>
<!-- HB -->
<section anchor="FE_Object" title="FE Object and FE Protocol LFBs">
<t>All PL messages operate on LFB constructs, as this provides more
flexibility for future enhancements. This means that maintenance and
configurability of FEs, NE, as well as the ForCES protocol itself
must be expressed in terms of this LFB architecture. For this reason
special LFBs are created to accommodate this need.</t>
<t>In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc.</t>
<t>To achieve this, the following specialized LFBs are introduced:
<list style="symbols">
<t>FE Protocol LFB which is used to control the ForCES
protocol.</t>
<t>FE Object LFB which is used to control attributes relative
to the FE itself. Such attributes include FEState <xref
target="FE-MODEL"></xref>, vendor, etc.</t>
</list> These LFBs are detailed in <xref
target="LFB_def"></xref>.</t>
</section>
<!-- FE Objects ... -->
</section>
<section anchor="Proto_Scene" title="Protocol Scenarios">
<!-- 7.1 Association Setup state -->
<t>
This section provides a very high level description
of sample message sequences between a CE and FE.
For protocol message encoding refer to
<xref target="Common_Header"></xref> and for the semantics of
the protocol refer to <xref target="protmech"></xref>.
</t>
<section title="Association Setup State">
<t>The associations among CEs and FEs are initiated via Association
setup message from the FE. If a setup request is granted by the CE, a
successful setup response message is sent to the FE. If CEs and FEs
are operating in an insecure environment then the security
associations have to be established between them before any
association messages can be exchanged. The TML will take care of
establishing any security associations.</t>
<t>This is typically followed by capability query, topology query,
etc.
When the FE is ready to start processing the data path, it sets
the FEO FEState component to OperEnable
(Refer to <xref
target="FE-MODEL"></xref> for details)
and reports it
to the CE as such when it is first queried.
Typically the FE is expected to be ready to process the data path
before it associates, but there maybe rare cases
where it needs time do some pre-processing - in such a case the FE
will start in the OperDisable state and when it is ready will
transition
to OperEnable state. An example of an FE starting in the OperDisable
then transitioning to OperEnable is illustrated in
<xref target="seq_Assoc_Setup"></xref>.
The CE could at any time also disable the FEs datapath operations by
setting the FEState to AdminDisable. The FE MUST NOT process packets
during this state unless the CE sets the state back to OperEnable.
These sequences of messages are illustrated
in <xref target="seq_Assoc_Setup"></xref> below.</t>
<figure anchor="seq_Assoc_Setup"
title="Message exchange between CE and FE to establish an NE association">
<preamble></preamble>
<artwork><![CDATA[
FE PL CE PL
| |
| Asso Setup Req |
|---------------------->|
| |
| Asso Setup Resp |
|<----------------------|
| |
| LFBx Query capability |
|<----------------------|
| |
| LFBx Query Resp |
|---------------------->|
| |
| FEO Query (Topology) |
|<----------------------|
| |
| FEO Query Resp |
|---------------------->|
| |
| FEO OperEnable Event |
|---------------------->|
| |
| Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->|
| |
]]></artwork>
</figure>
<t>On successful completion of this state, the FE joins the NE.</t>
</section>
<!-- 7.2 Association Established state or Steady State -->
<section title="Association Established state or Steady State">
<t>In this state, the FE is continuously updated or queried. The FE may
also send asynchronous event notifications to the CE, synchronous
heartbeat messages, or packet redirect message to the CE.
This continues until a termination (or
deactivation) is initiated by either the CE or FE.
<xref target="seq_Assoc_Estab"></xref> below,
helps illustrate this state.</t>
<figure anchor="seq_Assoc_Estab"
title="Message exchange between CE and FE during steady-state communication">
<preamble></preamble>
<artwork><![CDATA[
FE PL CE PL
| |
| Heart Beat |
|<---------------------------->|
| |
| Heart Beat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Attr |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Attr |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heart Beat |
|<-----------------------------|
. .
. .
| |
]]></artwork>
</figure>
<t>Note that the sequence of messages shown in the figure serve only
as examples and the message exchange sequences could be different
from what is shown in the figure. Also, note that the protocol
scenarios described in this section do not include all the different
message exchanges that would take place during failover. That is
described in the HA section (<xref target="HA" />) .</t>
</section>
</section>
<!-- Protocol Mechanisms -->
</section>
<!-- &TML; -->
<section anchor="TML_Req" title="TML Requirements">
<t>The requirements below are expected to be delivered by the TML. This
text does not define how such mechanisms are delivered. As an example
they could be defined to be delivered via hardware or between 2 or more
TML processes on different CEs or FEs in protocol level schemes.</t>
<t>Each TML must describe how it contributes to achieving the listed
ForCES requirements. If for any reason a TML does not provide a service
listed below a justification needs to be provided.</t>
<t>
<list style="numbers">
<t>Reliability<vspace /> As defined by RFC 3654, section 6 #6.</t>
<t>Security<vspace /> TML provides security services to the ForCES PL.
A TML layer should support
the following security services and describe how they are
achieved.
<list style="symbols">
<t>Endpoint authentication of FE and CE</t>
<t>Message authentication</t>
<t>Confidentiality service<vspace /></t>
<!--
<cref source="RAM">
[RAM i removed the example text to match the rest of the context;
if you
think it is needed here please let me know]
</cref>
-->
</list>
</t>
<t>Congestion control <vspace /> The congestion control scheme used
needs to be defined. The congestion control mechanism defined by the
TML should prevent the FE from being overloaded by the CE or the CE
from being overwhelmed by traffic from the FE. Additionally, the
circumstances under which notification is sent to the PL to notify it
of congestion must be defined.</t>
<t>Uni/multi/broadcast addressing/delivery, if any <vspace /> If there
is any mapping between PL and TML level uni/multi/broadcast addressing
it needs to be defined.</t>
<t>HA decisions <vspace /> It is expected that availability of
transport links is the TML's responsibility. However, based upon
its configuration, the PL may wish to participate in link
failover schemes and therefore the TML must support this
capability. <vspace /> Please
refer to <xref target="HA" /> for details.</t>
<t>Encapsulations used <vspace /> Different types of TMLs will
encapsulate the PL messages on different types of headers. The TML
needs to specify the encapsulation used. <vspace /></t>
<!--
[Do we wanna talk about PMTU, frags etc here?]
-->
<t>Prioritization<vspace /> It is expected that the TML will be able
to handle up to 8 priority levels needed by the PL and will
provide preferential treatment. <vspace blankLines="1" /> While the TML
needs to define how this is achieved, it should be noted that the
requirement for supporting up to 8 priority levels does not mean that
the underlying TML MUST be capable of providing up to 8 actual
priority levels. In the event that the underlying TML layer does not
have support for 8 priority levels, the supported priority levels
should be divided between the available TML priority levels. For
example, if the TML only supports 2 priority levels, the 0-3 could go
in one TML priority level, while 4-7 could go in the other.
<vspace blankLines="2" />
The TML MUST NOT reorder config packets with the
same priority.
</t>
<t>Protection against DoS attacks <vspace /> As described in
RFC 3654, section 6</t>
</list>
</t>
<section title="TML Parameterization">
<t>It is expected that it should be possible to use a configuration
reference point, such as the FEM or the CEM, to configure the TML.</t>
<t>Some of the configured parameters may include:</t>
<t>
<list style="symbols">
<t>PL ID</t>
<t>Connection Type and associated data. For example if a TML uses
IP/TCP/UDP, then parameters such as TCP and UDP port and IP
addresses need to be configured.</t>
<t>Number of transport connections</t>
<t>Connection capability, such as bandwidth, etc.</t>
<t>Allowed/supported connection QoS policy (or congestion control
policy)</t>
</list>
</t>
</section>
</section>
<!--&CommonHdr;-->
<section anchor="msg_encap" title="Message Encapsulation">
<t>All PL PDUs start with a common header
[<xref target="Common_Header"></xref>]
followed by a one or more TLVs
[<xref target="tlv_ref"></xref>] which may nest other TLVs
[<xref target="ntlv_ref"></xref>].
All fields are in network byte order.
</t>
<section anchor="Common_Header" title="Common Header">
<figure anchor="Com_Hdr" title="Common Header">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[63:32] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[31:0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The message is 32 bit aligned.
<vspace blankLines="1" /></t>
<t>
<list hangIndent="4" style="hanging">
<t hangText="Version (4 bit): "><vspace /> Version number. Current
version is 1.</t>
<t hangText="rsvd (4 bit): "><vspace /> Unused at this point. A
receiver should not interpret this field. Senders MUST set it to
zero and receivers MUST ignore this field.</t>
<t hangText="Message Type (8 bits): "><vspace /> Commands are
defined in <xref target="Proto_Msg" />.
</t>
<t hangText="Length (16 bits): "><vspace /> length of header + the
rest of the message in DWORDS (4 byte increments).</t>
<t hangText="Source ID (32 bit): " />
<t hangText="Dest ID (32 bit): " >
<vspace /> </t>
<t>
<list style="symbols">
<t>Each of the source and destination IDs
are 32 bit IDs which are unique
NE-wide and which identify the termination points of a ForCES PL
message.</t>
<t>IDs allow multi/broad/unicast addressing with the following
approach:
<list style="letters">
<t>A split address space is used to distinguish FEs from CEs.
Even though in a large NE there are typically two or more orders
of magnitude more FEs than CEs, the address space is split
uniformly for simplicity.</t>
<t>The address space allows up to 2^30 (over a billion) CEs and
the same amount of FEs.</t>
<figure anchor="sub-ID" title="ForCES ID Format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TS | sub-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The 2 most significant bits called Type Switch (TS) are used
to split the ID space as follows:</t>
<figure anchor="TS_ID" title="Type Switch ID Space">
<artwork><![CDATA[
TS Corresponding ID range Assignment
-- ---------------------- ----------
0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
0b10 0x80000000 to 0xBFFFFFFF reserved
0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16)
0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
0b11 0xFFFFFFFD all CEs broadcast
0b11 0xFFFFFFFE all FEs broadcast
0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
]]></artwork>
</figure>
</list>
<vspace blankLines="1" /></t>
<t>Multicast or broadcast IDs are used to group endpoints (such as
CEs and FES). As an example one could group FEs in some functional
group, by assigning a multicast ID. Likewise, subgroups of CEs
that act, for instance, in a back-up mode may be assigned a
multicast ID to hide them from the FE.
<list>
<t>
Multicast IDs can be used for both source or
destination IDs.
</t>
<t>
Broadcast IDs can be used only for destination
IDs.
</t>
</list>
</t>
<t>This document does not discuss how a particular multicast ID is
associated to a given group though it could be done via
configuration process. The list of IDs an FE owns or is part of
are listed on the FE Object LFB.</t>
</list>
</t>
<t hangText="Correlator (64 bits) "><vspace /> This field is set by
the CE to correlate ForCES Request Messages with the corresponding
Response messages from the FE. Essentially it is a cookie. The
correlator is handled transparently by the FE, i.e., for a
particular Request message the FE MUST assign the same
correlator value in the corresponding Response message. In
the case where the message from the CE does not elicit a
response, this field may not be useful.</t>
<t>The correlator field could be used in many implementations
specific ways by the CE. For example, the CE could split the
correlator into a 32-bit transactional identifier and 32-bit message
sequence identifier. Another example is a 64-bit pointer to a context
block. All such implementation specific use of the correlator is
outside the scope of this specification.</t>
<t>
It should be noted that the correlator is transmitted on the network
as if it were a 64 bit unsigned integer with the leftmost or most
significant octet (bits 63-56) transmitted first.
</t>
<t> Whenever the correlator field is not relevant, because no
message is expected, the correlator field is set to 0.</t>
<t hangText="Flags(32 bits): "><vspace /> Identified so far: <figure
anchor="Hdr_Flg" title="Header Flags">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
|ACK| Pri |Rsr |EM |A|TP | Reserved |
| | | vd. | |T| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>
<list style="hanging">
<t hangText="- ACK: ACK indicator (2 bit)"><vspace /> The ACK
indicator flag is only used by the CE when sending a Config
Message (<xref target="CfgMsg" />) or a HB message (<xref
target="HBMsg" />) to indicate to the message receiver whether or
not a response is required by the sender. Note that for all other
messages than the Config Message or the HB Message this flag MUST
be ignored.</t>
<t>The flag values are defined as below:
<list>
<t>'NoACK' (0b00) - to indicate that the message receiver MUST
NOT send any response message back to this message
sender.</t>
<t>'SuccessACK'(0b01) - to indicate the message receiver MUST
send a response message back only when the message has been
successfully processed by the receiver.</t>
<t>'FailureACK'(0b10) - to indicate the message receiver MUST
send a response message back only when there is failure by
the receiver in processing (executing) the message. In other
words, if the message can be processed successfully, the
sender will not expect any response from the receiver.</t>
<t>'AlwaysACK' (0b11) - to indicate the message receiver MUST
send a response message.</t>
</list>
</t>
<t> Note that in above definitions, the term success
implies a complete execution without any failure of the message.
Anything else than a complete successful execution is defined as a
failure for the message processing. As a result, for the execution
modes (defined in <xref target="exec_def" />) like
execute-all-or-none, execute-until-failure, and
continue-execute-on-failure, if any single operation among several
operations in the same message fails, it will be treated as a
failure and result in a response if the ACK indicator has been set
to 'FailureACK' or 'AlwaysACK'. </t>
<t> Also note that, other
than in Config and HB Messages, requirements for responses of
messages are all given in a default way rather than by ACK flags.
The default requirements of these messages and the expected
responses are summarized below. Detailed descriptions can be found
in the individual message definitions: </t>
<t>
<list style="symbols">
<t>Association Setup Message always expects a response.</t>
<t>Association Teardown Message, and Packet Redirect Message,
never expect responses.</t>
<t>Query Message always expects a response.</t>
<t>Response message never expects further responses.</t>
</list>
</t>
<t hangText="- Pri: Priority (3 bits) "><vspace /> ForCES protocol
defines 8 different levels of priority (0-7). The priority level
can be used to distinguish between different protocol message
types as well as between the same message type. The higher
the priority value, the more important the PDU is.
For example, the
REDIRECT packet message could have different priorities to
distinguish between routing protocols packets and ARP packets
being redirected from FE to CE. The Normal priority level is
1. The different priorities imply messages could be re-ordered;
however, re-ordering is undesirable when it comes to a set of
messages within a transaction and caution should be exercised
to avoid this from happening.</t>
<t hangText="- EM: Execution Mode (2 bits) "><vspace /> There are
3 execution modes refer to <xref target="exec_def" /> for details.
<list>
<t>Reserved..................... (0b00)</t>
<t>`execute-all-or-none` ....... (0b01)</t>
<t>`execute-until-failure` ..... (0b10)</t>
<t>`continue-execute-on-failure` (0b11)</t>
</list>
</t>
<t hangText="- AT: Atomic Transaction (1 bit) "><vspace /> This
flag indicates if the message is stand-alone message or one of
multiple messages that belongs to 2PC transaction operations. See
<xref target="tp_def" /> for details.
<list>
<t>Stand-alone message ......... (0b0)</t>
<t>2PC transaction message ..... (0b1)</t>
</list></t>
<t hangText="- TP: Transaction Phase (2 bits) "><vspace /> A
message from the CE to the FE within a transaction could be
indicative of the different phases the transaction is in. Refer to
<xref target="tp_def" /> for details. <list>
<t>SOT (start of transaction) ..... (0b00)</t>
<t>MOT (Middle of transaction) .... (0b01)</t>
<t>EOT (end of transaction) ........(0b10)</t>
<t>ABT (abort) .....................(0b11)</t>
</list>
</t>
</list>
</t>
</list>
</t>
<vspace blankLines="2" />
<!-- ISSUE 23
<list style="hanging" hangIndent="17">
<t hangText="Editorial Note: ">
There are several open issues, listed below,
in the header which still need to be settled:
</t>
<vspace blankLines="1" />
<list style = "numbers" hangIndent = "3">
<t>Parallelization of PL Windowing/subsequence
Someone to look into ISCSI
</t>
<t>events and replies and relation to peer to peer vs master slave
</t>
<t>[Need to choose one of the three alternatives above, or
identify others]
</t>
<t>[Discuss mapping to IPv6 link-local unicast and multicast
addresses,
unicast and multicast Ethernet addresses, etc]
</t>
<t>
We need to discuss whether some of the Flags such as those for
Atomicity, Batching
are needed in the common header or only belong to the PATH flags.
</t>
</list>
</list>
-->
</section>
<section anchor="tlv_ref" title="Type Length Value (TLV) Structuring ">
<t>
TLVs are extensively used by the ForCES protocol.
TLVs have some very nice properties which make them a good
candidate for encoding the XML definitions of
the LFB class model. These are:
<list style = "symbols">
<t> Providing for binary type-value encoding
that is close to the XML string tag-value scheme.
</t>
<t>Allowing for fast generalized binary-parsing functions.</t>
<t>Allowing for forward and backward tag compatibility.
This is equivalent to the XML approach i.e old applications
can ignore new TLVs and newer applications can
ignore older TLVs.
</t>
</list>
</t>
<t />
<figure anchor="tlv_fig" title="TLV Representation">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Essentially the TLV Data) |
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="17" style="hanging">
<t hangText="TLV Type (16):"><vspace /> The TLV type field is two
octets, and semantically
indicates the type of data encapsulated within the
TLV.</t>
<t hangText="TLV Length (16):"><vspace /> The TLV length field is
two octets, and includes the length of the TLV type (2 octets),
TLV Length (2 octets), and the length of the TLV data found
in the value field, in octets.
Note that this length is the actual
length of the value, before any padding for alignment is added.
</t>
<t hangText="TLV Value (variable):"><vspace /> The TLV value field
carries the data. For extensibility, the TLV value may in fact be a
TLV. Padding is required when the length is not a multiple of
32 bits, and is the minimum
number of octets required to bring the TLV to a multiple of 32
bits. The length of the value before padding is indicated by the TLV
Length field.
Note: The value field could be empty
which implies the minimal length a TLV could be is 4 (length of
"T" field and length of "L" field).
</t>
</list>
</t>
<section anchor="ntlv_ref" title="Nested TLVs ">
<t>TLV values can be other TLVs. This provides the benefits of
protocol flexibility (being able to add new extensions by
introducing new TLVs when needed). The nesting feature also allows
for a conceptual optimization with the XML LFB definitions to
binary PL representation (represented by nested TLVs).</t>
</section>
<section anchor="stlv_ref" title="Scope of the T in TLV ">
<t>The "Type" values in the TLV are global in scope. This means that
wherever TLVs occur in the PDU, a specific Type value refers to the
same Type of TLV. This is a design choice that was made to ease
debugging of the protocol.</t>
</section>
</section>
<section anchor="ilv_ref" title="ILV ">
<t>A slight variation of the TLV known as the ILV. This sets the type
("T") to be a 32-bit local index that refers to a ForCES component ID.
(refer to <xref target="paths"></xref>). </t>
<t>ILV length field is
4 octets, and includes the length of the ILV type (4 octets),
ILV Length (4 octets), and the length of the ILV data found
in the value field, in octets.
Note that, as in the case of the TLV, this length is the actual
length of the value, before any padding for alignment is added.
</t>
<figure anchor="ilv_ref_pic" title="ILV Representation">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>It should be noted that the "I" values are of local scope and are
defined by the data declarations from the LFB definition. Refer to
<xref target="DTLV"></xref> for discussions on usage of ILVs.</t>
</section>
<section anchor="Proto_cons" title="Important Protocol encapsulations">
<t>
In this section, we review a few encapsulation concepts
that are used by the ForCES protocol for its operations.
</t>
<t>
We briefly re-introduce two concepts, Paths and
Keys, from the model draft
<xref target="FE-MODEL"></xref> in order to
provide context. The reader is referred to
<xref target="FE-MODEL"></xref> for a lot of the finer
details.
</t>
<t>
For readability reasons, we introduce the encapsulation
schemes that are used to carry content in a protocol
message, namely FULLDATA-TLV, SPARSEDATA-TLV,
and RESULT-TLV.
</t>
<section anchor="paths" title="Paths">
<t>
The model draft <xref target="FE-MODEL"></xref> defines
an XML-based language that allows for a formal definition
of LFBs. This is similar to the relationship between ASN.1
and SNMP MIB definition (MIB being analogous to the LFB
and ASN.1 being analogous to the XML model language).
Any entity that the CE configures on an FE MUST be
formally defined in an LFB. These entities
could be scalars (e.g., a 32-bit IPv4 address) or vectors
(such as a nexthop table). Each entity within the LFB
is given a numeric 32-bit identifier known as an "component id".
This scheme allows the attribute
to be "addressed" in a protocol construct.
</t>
<t>These addressable
entities could be hierarchical (e.g., a table column or a cell
within a table row). In order to address hierarchical
data, the concept of a path is introduced by the
model <xref target="FE-MODEL"></xref>. A path is a series of
32-bit component IDs which are typically presented in a
dot-notation (e.g., 1.2.3.4). Section
(<xref target="Proto_Msg"></xref>) formally defines how paths
are used to reference data that is being encapsulated
within a protocol message.
</t>
</section>
<section anchor="Keys" title="Keys">
<t>
The model draft <xref target="FE-MODEL"></xref> defines
two ways to address table rows. The standard/common mechanism
is to allow table rows to be referenced by a 32-bit index.
The secondary mechanism is via Keys which allow for
content addressing. An example key is a multi-field
content key that uses the IP address and prefix length
to uniquely reference an IPv4 routing table row. In essence,
while the common scheme to address a table row is via
its table index, a table row's path could be derived
from a key. The KEYINFO-TLV (<xref target="Proto_Msg"></xref>)
is used to carry the data that is used to do the lookup.
</t>
</section>
<section anchor="pdata1" title="DATA TLVs">
<t>
Data from or to the FE is carried in two types of TLVs:
FULLDATA-TLV and SPARSEDATA-TLV. Responses to operations
executed by the FE are carried in RESULT-TLVs.
</t>
<t>In FULLDATA-TLV, the data is encoded in such a way
that a receiver of such data, by virtue of being armed
with knowledge of the path and the LFB definition, can
infer or correlate the TLV "Value" contents.
This is essentially an optimization that helps reduce the
amount of description required for the transported data in
the protocol grammar. Refer to
<xref target="DataencExam"></xref> for an example of
FULLDATA-TLVs.
</t>
<t>A number of operations in ForCES will need to
reference optional data within larger structures. The
SPARSEDATA-TLV encoding is provided to make it easier
to encapsulate optionally appearing data
components. Refer to <xref target="DataencExam"></xref> for
an example of SPARSEDATA-TLV.</t>
<t>
RESULT-TLVs carry responses back from the FE
based on a config issued by the CE.
Refer to <xref target="DataencExam"></xref> for examples
of RESULT-TLVs and <xref target="RTLV"></xref>
for layout.
</t>
</section>
<section anchor="addressing" title="Addressing LFB entities">
<t>
<xref target="paths"></xref> and <xref target="Keys"></xref>
discuss how to target an entity within an LFB. However,
the addressing mechanism used requires that an LFB type
and instance is selected first. The LFB Selector is used
to select an LFB type and instance being targeted.
Section (<xref target="Proto_Msg"></xref>)
goes into more details; for our purpose, we illustrate this
concept using <xref target="entadd"></xref> below.
More examples of layouts can be found reading further
into the text (Example: <xref target="Pathd_lay"></xref>).
<figure anchor="entadd" title="Entity Addressing ">
<artwork><![CDATA[
main hdr (Message type: example "config")
|
|
|
+- T = LFBselect
|
+-- LFBCLASSID (unique per LFB defined)
|
|
+-- LFBInstance (runtime configuration)
|
+-- T = An operation TLV describes what we do to an entity
| //Refer to the OPER-TLV values enumerated below
| //the TLVs that can be used for operations
|
|
+--+-- one or more path encodings to target an entity
| // Refer to the discussion on keys and paths
|
|
+-- The associated data, if any, for the entity
// Refer to discussion on FULL/SPARSE DATA TLVs
]]></artwork>
</figure>
</t>
</section>
</section>
</section>
<!--
-->
<section anchor="Proto_Msg" title="Protocol Construction">
<!-- &MessageIntro; -->
<!-- Message Intro -->
<!--
<section anchor="G_def" title="Protocol Grammar">
-->
<t>
A protocol layer PDU consists of a Common Header (defined in Section
<xref target="Common_Header"></xref> ) and
a message body. The Common Header is followed by a
message-type-specific message
body. Each message body is formed from one or more top-level TLVs.
A top-level
TLV may contain one or more sub-TLVs; these sub-TLVs are described in
this document as OPER-TLVs, because they describe an operation to be
done.
</t>
<t>
<texttable anchor="PMsgt">
<preamble></preamble>
<ttcol align="center">Message Name</ttcol>
<ttcol align="center">Top-Level TLV</ttcol>
<ttcol align="center">OPER-TLV(s)</ttcol>
<ttcol align="center">Reference</ttcol>
<c>Association Setup</c>
<c>(LFBselect)*</c>
<c>REPORT</c>
<c><xref target="Assoc_Setup_Resp" /></c>
<c>Association Setup Response</c>
<c>ASRresult-TLV</c>
<c>none</c>
<c><xref target="Assoc_Setup_Resp" /></c>
<c>Association Teardown</c>
<c>ASTreason-TLV</c>
<c>none</c>
<c><xref target="Assoc_Tear_Resp" /></c>
<c>Config</c>
<c>(LFBselect)+</c>
<c>(SET |
SET-PROP |
DEL |
COMMIT |
TRCOMP)+</c>
<c><xref target="CfgMsg" /></c>
<c>Config Response</c>
<c>(LFBselect)+</c>
<c>(SET-RESPONSE |
SET-PROP-RESPONSE |
DEL-RESPONSE |
COMMIT-RESPONSE)+</c>
<c><xref target="Config_Response" /></c>
<c>Query</c>
<c>(LFBselect)+</c>
<c>(GET |
GET-PROP)+</c>
<c><xref target="Query" /></c>
<c>Query Response</c>
<c>(LFBselect)+</c>
<c>(GET-RESPONSE |
GET-PROP-RESPONSE)+</c>
<c><xref target="QueryResponse" /></c>
<c>Event Notifi- cation</c>
<c>LFBselect</c>
<c>REPORT</c>
<c><xref target="EventMsg" /></c>
<c>Packet Redirect</c>
<c>REDIRECT-TLV</c>
<c>none</c>
<c><xref target="RedirectMsg" /></c>
<c>Heartbeat</c>
<c>none</c>
<c>none</c>
<c><xref target="HBMsg" /></c>
<postamble></postamble>
</texttable>
The different messages are illustrated in
<xref target="PMsgt"></xref>.
The different message type numerical values are defined in
<xref target="MSGt_Def"></xref>. All the TLVs values
are defined in <xref target="OPERt_Def"></xref>.
</t>
<!--
-->
<t>
An LFBselect TLV (refer to <xref target="LFBselectTLV" />)
contains the LFB Classid and LFB Instance being referenced
as well as the OPER-TLV(s) being applied to that reference.
</t>
<!--
-->
<t>
Each type of OPER-TLV is constrained as to how it describes
the paths and selectors of interest. The following BNF
describes the basic structure of an OPER-TLV and
<xref target="FSt" /> gives the details for each type
<figure anchor="OPER_BNF" title="BNF of OPER-TLV">
<artwork><![CDATA[
OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV
KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data component which may nest
further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally
appearing components
RESULT-TLV := Holds result code and optional FULLDATA-TLV
]]></artwork>
</figure>
</t>
<list style="symbols">
<t>PATH-DATA-TLV identifies the exact component targeted and may
have zero or more paths associated with it. The last PATH-DATA-TLV
in the case of nesting of paths via the DATA construct in the case
of SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE
is terminated
by encoded data or response in the form of either
FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV.
</t>
<!--
-->
<t>PATH provides the path to the data being referenced.
<list style="symbols">
<t>flags (16 bits) are used to further refine the operation to
be applied on the Path. More on these later.</t>
<t>IDcount(16 bit): count of 32 bit IDs</t>
<t>IDs: zero or more 32bit IDs (whose count is given by IDcount)
defining the main path. Depending on the flags, IDs could be
field IDs only or a mix of field and dynamic IDs. Zero is used
for the special case of using the entirety of the containing
context as the result of the path.</t>
</list>
</t>
<!-- End Path stuff -->
<t>SELECTOR is an optional construct that further defines the
PATH. Currently, the only defined selector is the KEYINFO-TLV,
used for selecting an array entry by the value of a key field. The
presence of a SELECTOR is correct only when the flags also
indicate its presence. A mismatch is a protocol format error.</t>
<t>A KEYINFO-TLV contains information used in content keying.
<list style="symbols">
<t>A KeyID is used in a KEYINFO-TLV. It indicates which key
for the current array is being used as the content key for
array entry selection.</t>
<t>The key's data is the data to look for in the array, in the
fields identified by the key field. The information is encoded
according to the rules for the contents of a FULLDATA-TLV, and
represent the field or fields which make up the key identified
by the KeyID.</t>
</list> <!-- End KEYINFO stuff --></t>
<t>DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV
or 1 or more further PATH-DATA selection. FULLDATA-TLV and
SPARSEDATA-TLV are only allowed on SET or SET-PROP requests, or on
responses which return
content information (GET-RESPONSE for example). PATH-DATA may be
included to extend the path on any request. <list style="symbols">
<t>Note: Nested PATH-DATA TLVs are supported as an efficiency
measure to permit common subexpression extraction.</t>
<t>FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path
has been selected by the PATH. Refer to <xref target="gd_def" />
for details.</t>
<t>
The following table summarizes the applicability and
restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV
to the OPER-TLVs.
<texttable anchor="FSt">
<preamble></preamble>
<ttcol align="center">OPER-TLV</ttcol>
<ttcol align="center">DATA TLV</ttcol>
<ttcol align="center">RESULT-TLV</ttcol>
<c>SET</c>
<c>(FULLDATA-TLV |
SPARSEDATA-TLV)+</c>
<c>none</c>
<c>SET-PROP</c>
<c>(FULLDATA-TLV |
SPARSEDATA-TLV)+</c>
<c>none</c>
<c>SET-RESPONSE</c>
<c>none</c>
<c>(RESULT-TLV)+</c>
<c>SET-PROP-RESPONSE</c>
<c>none</c>
<c>(RESULT-TLV)+</c>
<c>DEL</c>
<c>(FULLDATA-TLV |
SPARSEDATA-TLV)+</c>
<c>none</c>
<c>DEL-RESPONSE</c>
<c>none</c>
<c>(RESULT-TLV)+</c>
<c>GET</c>
<c>none</c>
<c>none</c>
<c>GET-PROP</c>
<c>none</c>
<c>none</c>
<c>GET-RESPONSE</c>
<c>(FULLDATA-TLV)+</c>
<c>(RESULT-TLV)*</c>
<c>GET-PROP-RESPONSE</c>
<c>(FULLDATA-TLV)+</c>
<c>(RESULT-TLV)*</c>
<c>REPORT</c>
<c>(FULLDATA-TLV)+</c>
<c>none</c>
<c>COMMIT</c>
<c>none</c>
<c>none</c>
<c>COMMIT-RESPONSE</c>
<c>none</c>
<c>(RESULT-TLV)+</c>
<c>TRCOMP</c>
<c>none</c>
<c>none</c>
<postamble></postamble>
</texttable>
<!--
-->
</t>
</list>
</t>
<t>RESULT-TLV contains the indication of whether the individual
SET or SET-PROP succeeded. RESULT-TLV is included on the
assumption that
individual parts of a SET request can succeed or fail separately.
</t>
</list>
<t>In summary this approach has the following characteristic:</t>
<t>
<list style="symbols">
<t>There can be one or more LFB class ID and instance ID
combination targeted in a message (batch)</t>
<t>There can one or more operations on an addressed LFB
class ID/instance ID combination (batch)</t>
<t>There can be one or more path targets per operation (batch)</t>
<t>Paths may have zero or more data values associated (flexibility
and operation specific)</t>
</list>
</t>
<t>It should be noted that the above is optimized for the case of a
single LFB class ID and instance ID targeting. To target multiple
instances
within the same class, multiple LFBselects are needed.</t>
<section anchor="gd_def" title="Discussion on encoding">
<t>
<xref target="pdata1" /> discusses the two types
of DATA encodings (FULLDATA-TLV and SPARSEDATA-TLV)
and the justifications for their existence. In this
section we explain how they are encoded.
</t>
<section anchor="pack_def" title="Data Packing Rules">
<t>The scheme for encoding data used in this doc adheres to the
following rules:
<list style="symbols">
<t>The Value ("V" of TLV) of FULLDATA-TLV will contain the
data being transported. This data will be as was described
in the LFB definition.</t>
<t>Variable sized data within a FULLDATA-TLV will be
encapsulated inside another FULLDATA-TLV inside the V of the
outer TLV. For example of such a setup refer to
<xref target="DataencExam" /> and
<xref target="use_cases" /> </t>
<t>In the case of FULLDATA-TLVs:</t>
<list style="symbols">
<t>When a table is referred to in the PATH (IDs) of a
PATH-DATA-TLV, then the FULLDATA-TLV's "V" will contain that
table's row content prefixed by its 32 bit
index/subscript. On the other hand, when PATH flags are 00,
the PATH may contain an index pointing to a row in table;
in such a case, the FULLDATA-TLV's "V" will only contain the content
with the index in order to avoid ambiguity.</t>
</list>
</list></t>
</section>
<section anchor="pat_flags" title="Path Flags">
<t>The following flags are currently defined: <list
hangIndent="4" style="symbols">
<t>SELECTOR Bit: F_SELKEY indicates that a KEY Selector is
present following this path information, and should be
considered in evaluating the path.</t>
<!--
<t>FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit
is set. This must only be used on a create operation. If
set, this indicates that although the path identifies an
array, the SET operation should be applied to the first
unused component in the array. The result of the operation
will not have this flag set, and will have the assigned
index in the path. <list style="hanging">
<t hangText="Example: ">For a given LFB class, the path
2.5 might select an array in a structure. If one wanted
to set component 6 in this array, then the path 2.5.6
would define that component. However if one wanted to
create an component in the first empty spot in the array,
the CE would then send the TLV with the FIND-EMPTY bit
set with the path set to 2.5. Essentially,this is an
optimization so as to not require the CE to fully
track all the tables.
</t>
</list>
</t>
-->
</list></t>
</section>
<section anchor="ret_flags"
title="Relation of operational flags with global message flags">
<t>Global flags, such as the execution mode and the atomicity
indicators defined in the header, apply to all operations in a
message. Global flags provide semantics that are orthogonal to
those provided by the operational flags, such as the flags
defined in Path Data. The scope of operational flags is
restricted to the operation.</t>
</section>
<section anchor="keys" title="Content Path Selection">
<t>The KEYINFO-TLV describes the KEY as well as associated KEY
data. KEYs, used for content searches, are restricted and
described in the LFB definition.</t>
</section>
<section anchor="LFBselectTLV" title="LFBselect-TLV">
<t>The LFBselect TLV is an instance of a TLV as defined in <xref
target="tlv_ref" />. The definition is as below:</t>
<figure anchor="LFB select TLV" title="PL PDU layout">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list hangIndent="4" style="hanging">
<t hangText="Type: "><vspace /> The type of the TLV is
"LFBselect"</t>
<t hangText="Length: "><vspace /> Length of the TLV including
the T and L fields, in octets.</t>
<t hangText="LFB Class ID: "><vspace /> This field uniquely
recognizes the LFB class/type.</t>
<t hangText="LFB Instance ID: "><vspace /> This field uniquely
identifies the LFB instance.</t>
<t hangText="OPER-TLV: "><vspace /> It describes an
operation nested in the LFBselect TLV. Note that usually
there SHOULD be at least one OPER-TLV present for an LFB
select TLV, but for the Association Setup Message defined
in <xref target="Asso_Setup" /> where the OPER-TLV is
optional.
</t>
</list>
</section>
<section anchor="OTLV" title="OPER-TLV">
<t>The OPER-TLV is a place holder in the grammar for
TLVs that define operations. The different types are
defined in <xref target="TLVt" />, below.
<texttable anchor="TLVt">
<preamble></preamble>
<ttcol align="center">OPER-TLV</ttcol>
<ttcol align="center">TLV "Type"</ttcol>
<ttcol align="center">Comments</ttcol>
<c>SET</c> <c>0x0001</c>
<c>From CE to FE. Used to create or add or update attributes</c>
<c>SET-PROP</c> <c>0x0002</c>
<c>From CE to FE. Used to create or add or update attribute
properties</c>
<c>SET-RESPONSE</c> <c>0x0003</c>
<c>From FE to CE. Used to carry response of a SET</c>
<c>SET-PROP-RESPONSE</c> <c>0x0004</c>
<c>From FE to CE. Used to carry response of a SET-PROP</c>
<c>DEL</c> <c>0x0005</c>
<c>From CE to FE. Used to delete or remove an attribute</c>
<c>DEL-RESPONSE</c> <c>0x0006</c>
<c>From FE to CE. Used to carry response of a DEL</c>
<c>GET</c> <c>0x0007</c>
<c>From CE to FE. Used to retrieve an attribute</c>
<c>GET-PROP</c> <c>0x0008</c>
<c>From CE to FE. Used to retrieve an attribute property</c>
<c>GET-RESPONSE</c> <c>0x0009</c>
<c>From FE to CE. Used to carry response of a GET</c>
<c>GET-PROP-RESPONSE</c> <c>0x000A</c>
<c>From FE to CE. Used to carry response of a GET-PROP</c>
<c>REPORT</c> <c>0x000B</c>
<c>From FE to CE. Used to carry an asynchronous event</c>
<c>COMMIT</c> <c>0x000C</c>
<c>From CE to FE. Used to issue a commit in a 2PC transaction</c>
<c>COMMIT-RESPONSE</c> <c>0x000D</c>
<c>From an FE to CE. Used to confirm a commit in a 2PC transaction</c>
<c>TRCOMP</c> <c>0x000E</c>
<c>From CE to FE. Used to indicate NE-wide success of 2PC transaction</c>
<postamble></postamble>
</texttable>
Different messages define OPER-TLV are valid and how they are
used (refer to <xref target="PMsgt" /> and <xref target="FSt" />).
</t>
<t>SET, SET-PROP, and GET/GET-PROP requests are issued
by the CE and
do not carry RESULT-TLVs. On the other hand, SET-RESPONSE,
SET-PROP-RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE
carry RESULT-TLVs.
</t>
<t>A GET-RESPONSE in response to a successful GET will have
FULLDATA-TLVs added to the leaf paths to carry the requested
data. For GET operations that fail, instead of the FULLDATA-TLV
there will be a RESULT-TLV.</t>
<t>For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV
or SPARSEDATA-TLV in the
original request will be replaced with a RESULT-TLV in the
response. If the request set the FailureACK flag, then only those items
which failed will appear in the response. If the request was for
AlwaysACK, then all components of the request will appear in the
response with RESULT-TLVs.</t>
<t>Note that if a SET/SET-PROP request with a structure
in a FULLDATA-TLV is
issued, and some field in the structure is invalid, the FE will
not attempt to indicate which field was invalid, but rather will
indicate that the operation failed. Note further that if there
are multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the
FE can select which error it chooses to return. So if a
FULLDATA-TLV
for a SET/SET-PROP of a structure attempts to write one
field which is
read only, and attempts to set another field to an invalid
value, the FE can return indication of either error.</t>
<t>A SET/SET-PROP operation on a variable length
component with a length of
0 for the item is not the same as deleting it. If the CE wishes
to delete then the DEL operation should be used whether the
path refers to an array component or an optional structure
component.</t>
</section>
<section anchor="RTLV" title="RESULT TLV">
<t>The RESULT-TLV is an instance of TLV defined in <xref
target="tlv_ref" />. The definition is as below:</t>
<figure anchor="Result_TLV" title="RESULT TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<!--
<t>The defined Result Values are</t>
<list hangIndent="5" style="hanging">
<t hangText="0x00 = ">Success</t>
<t hangText="0x01 = ">Unspecified error with header.</t>
<t hangText="0x02 = ">Header length field does not match
actual packet length.</t>
<t hangText="0x03 = ">Unresolvable mismatch in versions.</t>
<t hangText="0x04 = ">Destination PID is invalid for the
message receiver.</t>
<t hangText="0x05 = ">LFB Class ID is not known by
receiver.</t>
<t hangText="0x06 = ">LFB Class ID is known by receiver but
not currently in use.</t>
<t hangText="0x07 = ">LFB Class ID is known but the specified
instance of that class does not exist.</t>
<t hangText="0x08 = ">The specified path is impossible.</t>
<t hangText="0x09 = ">The specified path is possible but the
component does not exist (e.g., attempt to modify a table row
that has not been created).</t>
<t hangText="0x0A = ">The specified object exists but it
cannot exist for the operation to succeed (e.g., attempt to
add an existing LFB instance or array subscript).</t>
<t hangText="0x0B = ">The specified object does not exist but
it must exist for the operation to succeed (e.g.,
attempt to delete a non-existing LFB instance or
array subscript).</t>
<t hangText="0x0C = ">Attempt to modify a read-only value.</t>
<t hangText="0x0D = ">Attempt to create an array with an
unallowed subscript.</t>
<t hangText="0x0E = ">Attempt to set a parameter to a value
outside of its allowable range.</t>
<t hangText="0x0D = ">Attempt to write contents larger than
the target object space (i.e., exceeding a buffer).</t>
<t hangText="0x10 = "Any other error with data
parameters.</t>
<t hangText="0x11 = ">Message type is not acceptable.</t>
<t hangText="0x12 = ">Message flags are not acceptable for the
given message type.</t>
<t hangText="0x13 = ">A TLV is not acceptable for the given
message type.</t>
<t hangText="0x14 = ">Unspecified error while handling an
event.</t>
<t hangText="0x15 = ">Attempt to perform a valid ForCES
operation that is unsupported by the message receiver.</t>
<t hangText="0x16 = ">A memory error occurred while processing
a message (no error detected in the message itself)</t>
<t hangText="0x17 = "An unspecified error occured while
processing a message (no error detected in the message
itself).</t>
<t hangText="others = ">Reserved</t>
<t hangText="0xFF = ">unspecified error (for when the FE can
not decide what went wrong)</t>
</list>
-->
<texttable anchor="ErrorTbl">
<preamble>Defined Result Values</preamble>
<ttcol align="center">Result Value</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="center">Definition</ttcol>
<!--
<t hangText="0x00 = ">Success</t>
-->
<c>E_SUCCESS</c>
<c>0x00</c>
<c>Success</c>
<!--
<t hangText="0x01 = ">Unspecified error with header.</t>
-->
<c>E_INVALID_HEADER</c>
<c>0x01</c>
<c>Unspecified error with header.</c>
<!--
<t hangText="0x02 = ">Header length field does not match
actual packet length.</t>
-->
<c>E_LENGTH_MISMATCH</c>
<c>0x02</c>
<c>Header length field does not match
actual packet length.</c>
<!--
<t hangText="0x03 = ">Unresolvable mismatch in versions.</t>
-->
<c>E_VERSION_MISMATCH </c>
<c>0x03</c>
<c>Unresolvable mismatch in versions.</c>
<!--
<t hangText="0x04 = ">Destination PID is invalid for the
message receiver.</t>
-->
<c>E_INVALID_DESTINATION_PID</c>
<c>0x04</c>
<c>Destination PID is invalid for the
message receiver.</c>
<!--
<t hangText="0x05 = ">LFB Class ID is not known by
receiver.</t>
-->
<c>E_LFB_UNKNOWN</c>
<c>0x05</c>
<c>LFB Class ID is not known by
receiver.</c>
<!--
<t hangText="0x06 = ">LFB Class ID is known by receiver but
not currently in use.</t>
-->
<c>E_LFB_NOT_FOUND</c>
<c>0x06</c>
<c>LFB Class ID is known by receiver but
not currently in use.</c>
<!--
<t hangText="0x07 = ">LFB Class ID is known but the specified
instance of that class does not exist.</t>
-->
<c>E_LFB_INSTANCE_ID_NOT_FOUND</c>
<c>0x07</c>
<c>LFB Class ID is known but the specified
instance of that class does not exist.</c>
<!--
<t hangText="0x08 = ">The specified path is impossible.</t>
-->
<c>E_INVALID_PATH</c>
<c>0x08</c>
<c>The specified path is impossible.</c>
<!--
<t hangText="0x09 = ">The specified path is possible but the
component does not exist (e.g., attempt to modify a table row
that has not been created).</t>
-->
<c>E_COMPONENT_DOES_NOT_EXIST</c>
<c>0x09</c>
<c>The specified path is possible but the
component does not exist (e.g., attempt to modify a table row
that has not been created).</c>
<!--
<t hangText="0x0A = ">The specified object exists but it
cannot exist for the operation to succeed (e.g., attempt to
add an existing LFB instance or array subscript).</t>
-->
<c>E_EXISTS</c>
<c>0x0A</c>
<c>The specified object exists but it
cannot exist for the operation to succeed (e.g., attempt to
add an existing LFB instance or array subscript).</c>
<!--
<t hangText="0x0B = ">The specified object does not exist but
it must exist for the operation to succeed (e.g.,
attempt to delete a non-existing LFB instance or
array subscript).</t>
-->
<c>E_NOT_FOUND </c>
<c>0x0B</c>
<c>The specified object does not exist but
it must exist for the operation to succeed (e.g.,
attempt to delete a non-existing LFB instance or
array subscript).</c>
<!--
<t hangText="0x0C = ">Attempt to modify a read-only value.</t>
-->
<c>E_READ_ONLY</c>
<c>0x0C</c>
<c>Attempt to modify a read-only value.</c>
<!--
<t hangText="0x0D = ">Attempt to create an array with an
unallowed subscript.</t>
-->
<c>E_INVALID_ARRAY_CREATION </c>
<c>0x0D</c>
<c>Attempt to create an array with an
unallowed subscript.</c>
<!--
<t hangText="0x0E = ">Attempt to set a parameter to a value
outside of its allowable range.</t>
-->
<c>E_VALUE_OUT_OF_RANGE</c>
<c>0x0E</c>
<c>Attempt to set a parameter to a value
outside of its allowable range.</c>
<!--
<t hangText="0x0D = ">Attempt to write contents larger than
the target object space (i.e., exceeding a buffer).</t>
-->
<c>E_CONTENTS_TOO_LONG</c>
<c>0x0D</c>
<c>Attempt to write contents larger than
the target object space (i.e., exceeding a buffer).</c>
<!--
<t hangText="0x10 = ">Any other error with data
parameters.</t>
-->
<c>E_INVALID_PARAMETERS</c>
<c>0x10</c>
<c>Any other error with data parameters.</c>
<!--
<t hangText="0x11 = ">Message type is not acceptable.</t>
-->
<c>E_INVALID_MESSAGE_TYPE</c>
<c>0x11</c>
<c>Message type is not acceptable.</c>
<!--
<t hangText="0x12 = ">Message flags are not acceptable for the
given message type.</t>
-->
<c>E_INVALID_FLAGS</c>
<c>0x12</c>
<c>Message flags are not acceptable for the
given message type.</c>
<!--
<t hangText="0x13 = ">A TLV is not acceptable for the given
message type.</t>
-->
<c>E_INVALID_TLV</c>
<c>0x13</c>
<c>A TLV is not acceptable for the given
message type.</c>
<!--
<t hangText="0x14 = ">Unspecified error while handling an
event.</t>
-->
<c>E_EVENT_ERROR</c>
<c>0x14</c>
<c>Unspecified error while handling an
event.</c>
<!--
<t hangText="0x15 = ">Attempt to perform a valid ForCES
operation that is unsupported by the message receiver.</t>
-->
<c>E_NOT_SUPPORTED</c>
<c>0x15</c>
<c>Attempt to perform a valid ForCES
operation that is unsupported by the message receiver.</c>
<!--
<t hangText="0x16 = ">A memory error occurred while processing
a message (no error detected in the message itself)</t>
-->
<c>E_MEMORY_ERROR</c>
<c>0x16</c>
<c>A memory error occurred while processing
a message (no error detected in the message itself)</c>
<!--
<t hangText="0x17 = ">An unspecified error occured while
processing a message (no error detected in the message
itself).</t>
-->
<c>E_INTERNAL_ERROR</c>
<c>0x17</c>
<c>An unspecified error occurred while
processing a message (no error detected in the message
itself)</c>
<!--
<t hangText="others = ">Reserved</t>
-->
<c>-</c>
<c> 0x18-0xFE</c>
<c>Reserved</c>
<!--
<t hangText=")xFF = ">Unspecified error (for when the FE can
not decide what went wrong)</t>
-->
<c>E_UNSPECIFIED_ERROR</c>
<c>0xFF</c>
<c>Unspecified error (for when the FE can
not decide what went wrong)</c>
</texttable>
</section>
<section anchor="DTLV" title="DATA TLV">
<t>A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit Length
followed by the data value/contents. Likewise, a SPARSEDATA-TLV
has "T" = SPARSEDATA-TLV, a 16-bit Length, followed by the
data value/contents.
In the case of the SPARSEDATA-TLV, each component in the
Value part of the TLV will be further encapsulated in an ILV.</t>
<t> Below are the encoding rules for the FULLDATA-TLV and
SPARSEDATA-TLVs.
<xref target="DataencExam" /> is very useful in illustrating
these rules:
<list hangIndent="4" style="numbers">
<t>Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits
used for the alignment MUST be zero on transmission and MUST
be ignored upon reception.</t>
<t>FULLDATA-TLVs may be used at a particular path only if
every component at that path level is present. In example
1(c) of <xref target="DataencExam" /> this concept
is illustrated by
the presence of all components of the structure S in the
FULLDATA-TLV encoding. This requirement holds regardless
of whether the fields are fixed or variable
length, mandatory or optional.</t>
<list hangIndent="4" style="symbols">
<t>If a FULLDATA-TLV is used, the encoder MUST lay
out data for each component in the same order in which
the data was defined in the LFB specification.
This ensures the decoder is able to retrieve the data.
To use the example 1
again in <xref target="DataencExam" />, this implies
the encoder/decoder is assumed to have knowledge of how
structure S is laid out in the definition.</t>
<t>In the case of a SPARSEDATA-TLV, it does not need to
be ordered since the "I" in the ILV uniquely identifies
the component. Examples 1(a) and 1(b) in
<xref target="DataencExam" /> illustrate the power
of SPARSEDATA-TLV encoding.</t>
</list>
<t>Inside a FULLDATA-TLV <list hangIndent="4"
style="symbols">
<t>The values for atomic, fixed-length fields are given
without any TLV or ILV encapsulation.</t>
<t>The values for atomic, variable-length fields are
given inside FULLDATA-TLVs.</t>
</list></t>
<t>Inside a SPARSEDATA-TLV <list hangIndent="4" style="symbols">
<t>The values for atomic fields may be given with ILVs
(32-bit index, 32-bit length)</t>
</list></t>
<t>Any of the FULLDATA-TLVs can contain an ILV but an ILV
cannot contain a FULLDATA-TLV. This is because it is hard
to disambiguate the ILV since an I is 32 bits and a
T is 16 bits.</t>
<t>A FULLDATA-TLV can also contain a FULLDATA-TLV for
variable sized components. The decoding disambiguation is
assumed from rule
#3 above.</t>
</list></t>
</section>
<section anchor="SGR" title="SET and GET Relationship">
<t>It is expected that a GET-RESPONSE would satisfy the
following: <list hangIndent="4" style="symbols">
<t>It would have exactly the same path definitions as those
sent in the GET. The only difference being a GET-RESPONSE
will contain FULLDATA-TLVs.</t>
<t>It should be possible to take the same GET-RESPONSE and
convert it to a SET successfully by merely changing
the T in the operational TLV.</t>
<t>There are exceptions to this rule: <list hangIndent="4"
style="numbers">
<t>When a KEY selector is used with a path in a GET
operation, that selector is not returned in the
GET-RESPONSE; instead the cooked result is returned.
Refer to the examples using KEYS to see this.</t>
<t>When dumping a whole table in a GET, the GET-RESPONSE
that merely edits the T to be SET will end up
overwriting the table.</t>
</list></t>
</list></t>
</section>
<!--
</section>
-->
</section>
<section anchor="vis_def" title="Protocol Encoding Visualization">
<t>The figure below shows a general layout of the PL PDU. A main
header is followed by one or more LFB selections each of which may
contain one or more operation.</t>
<figure anchor="PDU_lay" title="PL PDU logical layout">
<artwork><![CDATA[
main hdr (Config in this case)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| +-- T = SET
| | |
| | +-- // one or more path targets
| | // with their data here to be added
| |
| +-- T = DEL
| . |
| . +-- // one or more path targets to be deleted
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| + -- T= SET
| | .
| | .
| + -- T= DEL
| | .
| | .
| |
| + -- T= SET
| | .
| | .
|
|
+--- T = LFBselect
|
+-- LFBCLASSID
|
+-- LFBInstance
.
.
.
]]></artwork>
</figure>
<t>The figure below shows a more detailed example of the
general layout
of the operation within a targeted LFB selection. The idea is to
show the different nesting levels a path could take to get to the
target path.</t>
<figure anchor="Pathd_lay" title="Sample operation layout">
<artwork><![CDATA[
T = SET
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| + -- T = KEYINFO-TLV
| | + -- KEY_ID
| | + -- KEY_DATA
| |
| + -- T = FULLDATA-TLV
| + -- data
|
|
T = SET
| |
| +- T = Path-data
| | |
| | + -- flags
| | + -- IDCount
| | + -- IDs
| | |
| | + -- T = FULLDATA-TLV
| | + -- data
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| + -- T = FULLDATA-TLV
| + -- data
T = DEL
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
+ -- T = KEYINFO-TLV
| + -- KEY_ID
| + -- KEY_DATA
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
]]></artwork>
</figure>
<t> <xref target="use_cases" /> shows a more concise set of use-cases
on how the data encoding is done.
</t>
</section>
<!--
</section>
-->
<section anchor="LFB_def" title="Core ForCES LFBs">
<t>There are two LFBs that are used to control the operation of the
ForCES protocol and to interact with FEs and CEs:
<list style="symbols">
<t>FE Protocol LFB</t>
<t>FE Object LFB</t>
</list></t>
<t>Although these LFBs have the same form and interface as other LFBs,
they are special in many respects. They have fixed well-known LFB
Class and Instance IDs. They are statically defined (no dynamic
instantiation allowed) and their status cannot be changed by the
protocol: any operation to change the state of such LFBs (for
instance, in order to disable the LFB) must result in an error.
Moreover, these LFBs must exist before the first ForCES message can be
sent or received. All attributes in these LFBs must have pre-defined
default values. Finally, these LFBs do not have input or output ports
and do not integrate into the intra-FE LFB topology.
<vspace blankLines="1" /></t>
<section anchor="FPL_sum" title="FE Protocol LFB">
<t>The FE Protocol LFB is a logical entity in each FE that is used
to control the ForCES protocol. The FE Protocol LFB Class ID is
assigned the value 0x2. The FE Protocol LFB Instance ID is assigned
the value 0x1. There MUST be one and only one instance of the FE
Protocol LFB in an FE. The values of the attributes in the FE
Protocol LFB have pre-defined default values that are specified
here. Unless explicit changes are made to these values using Config
messages from the CE, these default values MUST be used for correct
operation of the protocol.</t>
<t>The formal definition of the FE Protocol Object LFB can be
found in <xref target="FPL_def" />.</t>
<section title="FE Protocol capabilities">
<t>FE Protocol capabilities are read-only.</t>
<section title="SupportableVersions">
<t> ForCES protocol version(s) supported by the FE</t>
</section>
<section title="FE Protocol Attributes ">
<t>FE Protocol attributes (can be read and set).</t>
<section title="CurrentRunningVersion">
<t>Current running version of the ForCES protocol</t>
</section>
<section title="FEID">
<t>FE unicast ID</t>
</section>
<section title="MulticastFEIDs">
<t>FE multicast ID(s) list - this is a list of multicast IDs
that the FE belongs to. These IDs are configured by the CE.</t>
</section>
<section title="CEHBPolicy">
<t>CE heartbeat policy - This policy, along with the parameter
'CE Heartbeat Dead Interval (CE HDI)' as described below defines
the operating parameters for the FE to check the CE liveness.
The policy values with meanings are listed as below:</t>
<list style ="symbols">
<t>0 (default) - This policy specifies that the CE will send a
Heartbeat Message to the FE(s) whenever the CE reaches a time
interval within which no other PL messages were sent from the
CE to the FE(s); refer to <xref target="HB_appr" /> and
<xref target="HBMsg" /> for details. The CE HDI attribute
as described below is tied to this policy.
</t>
<!--
This info is redundant - remove for readability- JHS
If the FE has not received any PL messages within
a CE HDI period it declares the connectivity lost. The CE
independently chooses the time interval for sending the
Heartbeat messages to FE(s) - care must be exercised to ensure
the CE->FE HB interval is smaller than the assigned CE HDI.
<vspace blankLines="1" /> CE HDI SHOULD be at least 3 times as
long as the HB interval. Shorter rates MAY be appropriate in
implementations working across a reliable internal
interface.</t>
-->
<t>1 - The CE will not generate any HB messages. This actually
means CE does not want the FE to check the CE liveness.</t>
<t>Others - reserved.</t>
</list>
</section>
<section title="CEHDI">
<t>CE Heartbeat Dead Interval (CE HDI) - The time interval the
FE uses to check the CE liveness. If FE has not received any
messages from CE within this time interval, FE deduces lost
connectivity which implies that the CE is dead or the
association to the CE is lost. Default value 30 s.</t>
</section>
<section title="FEHBPolicy">
<t>FE heartbeat policy - This policy, along with the parameter
'FE Heartbeat Interval (FE HI)', defines the operating
parameters for how the FE should behave so that the CE can
deduce its liveness. The policy values and the meanings are:</t>
<list style ="symbols">
<t>0 (default) - The FE should not generate any Heartbeat
messages. In this scenario, the CE is responsible for checking
FE liveness by setting the PL header ACK flag of the message
it sends to AlwaysACK. The FE responds to CE whenever CE sends
such Heartbeat Request Message. Refer to <xref
target="HBMsg" /> and <xref target="HB_appr" /> for
details.</t>
<t>1 - This policy specifies that FE must actively send a
Heartbeat Message if it reaches the time interval assigned by
the FE HI as long as no other messages were sent from FE to CE
during that interval as described in <xref
target="HB_appr" />.</t>
<t>Others - Reserved.</t>
</list>
</section>
<section title="FEHI">
<t>FE Heartbeat Interval (FE HI) - The time interval the FE
should use to send HB as long as no other messages were sent
from FE to CE during that interval as described in <xref
target="HB_appr" />. The default value for an FE HI is
500ms.</t>
</section>
<section anchor="PCE" title="CEID">
<t>Primary CEID - The CEID that the FE is associated with.</t>
</section>
<section anchor="LPCE" title="LastCEID">
<t>Last Primary CEID - The CEID of the last CE that
that the FE associated with. This CE ID is reported
to the new Primary CEID.</t>
</section>
<section anchor="BCE" title="BackupCEs">
<t>The list of backup CEs an FE can use as backups.
Refer to <xref target="HA" /> for details.</t>
</section>
<section title="CEFailoverPolicy">
<t>CE failover policy - This specifies the behavior of the FE
when the association with the CE is lost.
There is a very tight relation between CE failover policy
and <xref target="PCE" />, <xref target="BCE" />,
<xref target="CEFTI" />, and <xref target="HA" />.
When an association is lost, depending on configuration,
one of the policies listed below is activated. </t>
<list style ="symbols">
<t>0 (default) - FE should stop functioning immediately
and transition to FE OperDisable.
</t>
<t>1 - The FE should continue running and do what it
can even without an associated CE. This basically requires
that the FE support CE Graceful restart (and defines
such support in its capabilities).
If the CEFTI expires before the FE re-associates with either
the primary (<xref target="PCE" />) or one of possibly
several backup CEs (<xref target="BCE" />), the FE will go
operationally down.</t>
<t>Others - Reserved</t>
</list>
</section>
<section anchor="CEFTI" title="CEFTI">
<t>CE Failover Timeout Interval (CEFTI) - The time interval
associated with the CE failover policy case '0' and '2'.
The default value is set to 300 seconds. Note that it is
advisable to set the CEFTI value much higher than the
CE Heartbeat Dead Interval (CE HDI) since the effect of
expiring this parameter is devastating
to the operation of the FE.</t>
</section>
<section title="FERestartPolicy">
<t>FE restart policy - This specifies the behavior of the FE
during an FE restart. The restart may be from an FE failure or
other reasons that have made FE down and then need to restart.
The values are defined as below:</t>
<list style ="symbols">
<t>0(default)- Restart the FE from scratch. In this case,
the FE should start from the pre-association phase.</t>
<t>others - Reserved for future use.</t>
</list>
</section>
<!-- ISSUE 37
<t hangText="TBD: ">
Define default values for each attribute where applicable.
</t>
</list>
-->
</section>
</section>
</section>
<section anchor="FEO" title="FE Object LFB">
<t>The FE Object LFB is a logical entity in each FE and contains
attributes relative to the FE itself, and not to the operation of
the ForCES protocol.</t>
<t>The formal definition of the FE Object LFB can be found in <xref
target="FE-MODEL" />. The model captures the high level properties
of the FE that the CE needs to know to begin working with the FE.
The class ID for this LFB Class is also assigned in <xref
target="FE-MODEL" />. The singular instance of this class will
always exist, and will always have instance ID 0x1 within its class.
It is common, although not mandatory, for a CE to fetch much of the
component and capability information from this LFB instance when the
CE begins controlling the operation of the FE.</t>
</section>
</section>
<section title="Semantics of Message Direction">
<t>Recall: The PL provides a master(CE)-Slave(FE)
relationship. The LFBs reside at the FE and are controlled by CE.</t>
<t>When messages go from the CE, the LFB Selector (Class and instance)
refers to the destination LFB selection which resides in the FE.</t>
<t>When messages go from the FE to the CE, the LFB Selector (Class and
instance) refers to the source LFB selection which resides in the
FE.</t>
</section>
<!-- &AssociationMsg; -->
<section title="Association Messages">
<t>The ForCES Association messages are used to establish and teardown
associations between FEs and CEs.</t>
<section anchor="Asso_Setup" title="Association Setup Message">
<t>This message is sent by the FE to the CE to setup a ForCES
association between them. <!--
<cref source="WGLC">
This message could also be used by CEs to join a ForCES
NE, however CE-to-CE communication is not covered by this protocol.
</cref>
-->
<vspace blankLines="1" /></t>
<list hangIndent="3" style="hanging">
<t hangText="Message transfer direction: "><vspace /> FE to CE</t>
<t hangText="Message header: "><vspace /> The Message Type in the
header is set MessageType= 'AssociationSetup'. The ACK flag in the
header MUST be ignored, and the association setup message always
expects to get a response from the message receiver (CE), whether
the setup is successful or not. The correlator field in the header
is set, so that FE can correlate the response coming back from
the CE correctly.
The FE may set the source ID to 0 in the header to request that
the CE should assign an FE ID for the FE
in the setup response message.</t>
<t hangText="Message body: "><vspace /> The association setup
message body optionally consists of zero, one or two LFBselect
TLVs, as described in <xref target="LFBselectTLV" />. The
Association Setup
message only operates on the FE Object and FE Protocol LFBs,
therefore, the LFB class ID in the LFBselect TLV only points to
these two kinds of LFBs. <cref source="WGLC"> There is only one FE
object LFB and one FE protocol LFB per FE, therefore, the LFB
instance IDs for the FE object LFB and the FE protocol LFB are
usually assigned to the value 0x1. </cref></t>
<t>The OPER-TLV in the LFBselect TLV is defined as a
'REPORT' operation. More than one component may be announced in
this message using REPORT operation to let the FE declare its
configuration parameters in an unsolicited manner. These may
contain components suggesting values such as the FE HB Interval,
or the FEID.
The OPER-TLV used is defined below.</t>
<t hangText="OPER-TLV for Association Setup: ">
<vspace />
</t>
<figure anchor="Oper_TLV" title="OPER-TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type:"><vspace /> Only one operation type is defined
for the association setup message: <list hangIndent="7"
style="hanging">
<t>Type = "REPORT" - this type of operation is for FE to
report something to CE.</t>
</list></t>
<t hangText="PATH-DATA-TLV for REPORT: "><vspace /> This is
generically a PATH-DATA-TLV format that has been defined in
section (<xref target="Proto_Msg" />) in the
PATH-DATA BNF definition. The PATH-DATA-TLV for REPORT operation
MAY contain FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV
in the data format. The RESULT-TLV is defined in <xref
target="RTLV" /> and the FULLDATA-TLV is defined in <xref
target="DTLV" />.</t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="Msg_Assoc"
title="PDU Format For Association Setup Message">
<artwork><![CDATA[
main hdr (type = Association Setup)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = LFBselect
|
+-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
|
+---OPER-TLV = REPORT
|
+-- Path-data to one or more components
]]></artwork>
</figure>
</section>
<section anchor="Assoc_Setup_Resp"
title="Association Setup Response Message">
<t>This message is sent by the CE to the FE in response to the Setup
message. It indicates to the FE whether the setup is successful or
not, i.e., whether an association is established.
<vspace blankLines="1" /></t>
<list hangIndent="4" style="hanging">
<t hangText="Message transfer direction: "><vspace /> CE to FE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
header is set MessageType= 'AssociationSetupResponse'. The ACK
flag in the header MUST be ignored, and the setup response message
never expects to get any more responses from the message receiver
(FE).
The destination ID in the header will be set to the source ID
in the corresponding association setup message, unless that
source ID was 0. If the corresponding source ID was 0, then
the CE will assign an FE ID value and use that value for the
destination ID.
</t>
<!--
<t hangText="Message body: "><vspace /> The Association Setup
Response message body only consists of one TLV, the Association
Result TLV, the format of which is as follows:</t>
-->
<figure anchor="ASR" title="ASResult OPER-TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Setup Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type (16 bits): "><vspace /> The type of the TLV is
"ASResult".</t>
<t hangText="Length (16 bits): "><vspace /> Length of the TLV
including the T and L fields, in octets.</t>
<t hangText="Association Setup Result (32 bits): "><vspace /> This
indicates whether the setup msg was successful or whether the FE
request was rejected by the CE. the defined values are: <list
hangIndent="7">
<t>0 = success</t>
<t>1 = FE ID invalid</t>
<t>2 = permission denied</t>
</list></t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="AssocSetupResp_tree"
title="PDU Format for Association Setup Repsonse Message">
<artwork><![CDATA[
main hdr (type = Association Setup Response)
|
|
+--- T = ASResult-TLV
]]></artwork>
</figure>
</section>
<section anchor="Assoc_Tear_Resp" title="Association Teardown Message">
<t>This message can be sent by the FE or CE to any ForCES element to
end its ForCES association with that element.
<vspace blankLines="1" /></t>
<list hangIndent="4" style="hanging">
<t hangText="Message transfer direction: "><vspace /> CE to FE, or
FE to CE (or CE to CE)</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
header is set MessageType= "AssociationTeardown". The ACK flag
MUST be ignored. The correlator field in the header MUST be set to
zero and MUST be ignored by the receiver.</t>
<!--
<t hangText="Message Body: "><vspace /> The association teardown
message body only consists of one TLV, the Association Teardown
Reason TLV, the format of which is as follows:</t>
-->
<!-- ISSUE 26
<list style="hanging" hangIndent="17">
<t hangText="Editorial Note: ">
Details of how Reason will be carried in the Teardown message
are still unclear. There is no such component at the FE Object at
the
moment. There is also no operation by the name of FEReason.
</t>
</list>
-->
<figure anchor="ASTreason_TLV" title="ASTreason-TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type (16 bits): "><vspace /> The type of the TLV is
"ASTreason".</t>
<t hangText="Length (16 bits): "><vspace /> Length of the TLV
including the T and L fields, in octets.</t>
<t hangText="Teardown Reason (32 bits): "><vspace /> This
indicates the reason why the association is being terminated.
Several reason codes are defined as follows. <list>
<t>0 - normal teardown by administrator</t>
<t>1 - error - loss of heartbeats</t>
<t>2 - error - out of bandwidth</t>
<t>3 - error - out of memory</t>
<t>4 - error - application crash</t>
<t>255 - error - other or unspecified</t>
</list></t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="AssocTeardown_tree"
title="PDU Format for Association Teardown Message">
<artwork><![CDATA[
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason-TLV
]]></artwork>
</figure>
</section>
</section>
<!-- &ConfigMsg; -->
<section title="Configuration Messages">
<t>The ForCES Configuration messages are used by CE to configure the
FEs in a ForCES NE and report the results back to the CE.</t>
<section anchor="CfgMsg" title="Config Message">
<t>This message is sent by the CE to the FE to configure LFB
components in the FE. This message is also used by the CE to
subscribe/unsubscribe to LFB events.</t>
<t>As usual, a config message is composed of a common header
followed by a message body that consists of one or more TLV data
format. Detailed description of the message is as below.
<vspace blankLines="1" /></t>
<list hangIndent="4" style="hanging">
<t hangText="Message transfer direction: "><vspace /> CE to FE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
header is set MessageType= 'Config'. The ACK flag in the header
can be set to any value defined in <xref
target="Common_Header" />, to indicate whether or not a response
from FE is expected by the message.
</t>
<!--
<t hangText="Message body: "><vspace /> The config message body
MUST consist of at least one LFBselect TLV as described in <xref
target="LFBselectTLV" />. The OPER-TLV in the LFBselect TLV
is defined below.</t>
-->
<t hangText="OPER-TLV for Config: ">
<vspace />
</t>
<figure anchor="Op_TLV-Config" title="OPER-TLV for Config">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type:"><vspace /> The operation type for config
message. two types of operations for the config message are
defined: <list hangIndent="7" style="hanging">
<t>Type = "SET" - this operation is to set LFB
components</t>
<t>Type = "SET-PROP" - this operation is to set LFB
component properties</t>
<t>Type = "DEL" - this operation to delete some LFB
components</t>
<t>Type = "COMMIT" - this operation is sent to the
FE to commit in a 2pc transaction. A COMMIT TLV is
an empty TLV i.e it has no "V"alue. In other words,
There is a Length of 4 (which is for the header only).
</t>
<t>Type = "TRCOMP" - this operation is sent to the
FE to mark the success from an NE perspective of
a 2pc transaction. A TRCOMP TLV is
an empty TLV i.e it has no "V"alue. In other words,
There is a Length of 4 (which is for the header only).
</t>
</list></t>
<t hangText="PATH-DATA-TLV:"><vspace /> This is generically a
PATH-DATA-TLV format that has been defined in section
(<xref target="Proto_Msg" />) in the PATH-DATA-TLV BNF definition.
The restriction on the use of PATH-DATA-TLV for SET/SET-PROP
operation is that
it MUST contain either a FULLDATA-TLV or SPARSEDATA-TLV(s), but
MUST NOT contain any RESULT-TLV. The restriction on the use of
PATH-DATA-TLV for DEL operation is it MAY contain FULLDATA-TLV or
SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The
RESULT-TLV is defined in <xref target="RTLV" /> and FULLDATA-TLV
and SPARSEDATA-TLVs is defined in <xref target="DTLV" />.</t>
<list hangIndent="7" style="hanging">
<t hangText="*Note:">For Event subscription, the events will be
defined by the individual LFBs.</t>
</list>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="PDU_format"
title="PDU Format for Configuration Message">
<artwork><![CDATA[
main hdr (type = Config)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET }
| |
| +-- // one or more path targets
| // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
.
.
]]></artwork>
</figure>
</section>
<section anchor="Config_Response" title="Config Response Message">
<t>This message is sent by the FE to the CE in response to the
Config message. It indicates whether the Config was successful or
not on the FE and also gives a detailed response regarding the
configuration result of each component.
<vspace blankLines="1" /></t>
<list hangIndent="4" style="hanging">
<t hangText="Message transfer direction: "><vspace /> FE to
CE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
header is set MessageType= 'Config Response'. The ACK flag in the
header is always ignored, and the Config Response message never
expects to get any further response from the message receiver
(CE).</t>
<!--
<t hangText="Message body: "><vspace /> The Config message body
MUST consist of at least one LFBselect TLV as described in <xref
target="LFBselectTLV" />. The OPER-TLV in the LFBselect TLV
is defined below.</t>
-->
<t hangText="OPER-TLV for Config Response: ">
<vspace />
</t>
<figure anchor="Op_TLV_Config_Resp"
title="OPER-TLV for Config Response">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type:"><vspace /> The operation type for Config
Response message. Two types of operations for the Config Response
message are defined: <list hangIndent="7" style="hanging">
<t>Type = "SET-RESPONSE" - this operation is for the
response of SET operation of LFB components</t>
<t>Type = "SET-PROP-RESPONSE" - this operation is
for the response of SET-PROP operation of LFB
component properties</t>
<t>Type = "DEL-RESPONSE" - this operation is for the
response of the DELETE operation of LFB components</t>
<t>Type = "COMMIT-RESPONSE" - this operation is sent to the
CE to confirm a commit success in a 2pc transaction.
A COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
success or failure.
</t>
</list></t>
<t hangText="PATH-DATA-TLV:"><vspace /> This is generically a
PATH-DATA-TLV format that has been defined in section
(<xref target="Proto_Msg" />) in the PATH-DATA-TLV BNF definition.
The restriction on the use of PATH-DATA-TLV for SET-RESPONSE
operation is that it MUST contain RESULT-TLV(s).
The restriction on the
use of PATH-DATA-TLV for DEL-RESPONSE operation is it also MUST
contain RESULT-TLV(s). The RESULT-TLV is defined in <xref
target="RTLV" />.</t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="ConfigResponse_tree"
title="PDU Format for Configuration Response message">
<artwork><![CDATA[
main hdr (type = ConfigResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET-RESPONSE }
| |
| +-- // one or more path targets
| // associated with FULL or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT-RESPONSE }
| |
| +-- RESULT-TLV
]]></artwork>
</figure>
</section>
</section>
<!-- &QueryMsg; -->
<section anchor="QueryMsg" title="Query Messages">
<t>The ForCES query messages are used by the CE to query LFBs in the
FE for informations like LFB components, capabilities, statistics,
etc. Query Messages include the Query Message and the Query Response
Message.</t>
<section anchor="Query" title="Query Message">
<t>A Query message is composed of a common header and a message body
that consists of one or more TLV data format. Detailed description
of the message is as below.
<vspace blankLines="1" /></t>
<list hangIndent="4" style="hanging">
<t hangText="Message transfer direction:"><vspace /> from CE to
FE</t>
<t hangText="Message Header:"><vspace /> The Message Type in the
header is set to MessageType= 'Query'. The ACK flag in the header
is always ignored, and a full response for a query message is
always expected. The Correlator field in the header is set, so
that the CE can locate the response back from FE correctly.
<vspace blankLines="1" /></t>
<!--
<t hangText="Message body: "><vspace /> The query message body
MUST consist of at least one LFBselect TLV as described in <xref
target="LFBselectTLV" />. The OPER-TLV in the LFBselect TLV
is defined below.</t>
-->
<!-- ISSUE 28
<list style= "hanging" hangIndent="17" >
<t hangText = "Editorial Note: ">
</t>
<list style="numbers" hangIndent="3">
<t>Under discussion is whether there is a need for explicit multiple
LFB instance
addressing here. One way to realize it is to define a specific
Instance select
TLV to substitute above 'LFB Instance ID' field. The TLV may have
following format:</t>
<figure><artwork>
INSselectTLV := Type Length Value
Type := INSselect
Value := InstanceID (RangeMark | Instance ID)+
</artwork></figure>
<t>An applicable RangeMark is '0xffffffff',
the value of which is the same as
Instance broadcast ID. Because there will be
no broadcast address applied
in this place, there will be no worry of ambiguity here.
This value indicates that all LFBs in that class
are addressed.</t>
</list>
</list>
-->
<t hangText="OPER-TLV for Query: ">
<vspace />
</t>
<figure anchor="tlv_Query" title="TLV for Query">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET/GET-PROP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type:"><vspace /> The operation type for query. Two
operation types are defined: <list hangIndent="7" style="hanging">
<t>Type = "GET" - this operation is to request to get LFB
components.</t>
<t>Type = "GET-PROP" - this operation is to
request to get LFB components.</t>
</list></t>
<t hangText="PATH-DATA-TLV for GET/GET-PROP: "><vspace />
This is
generically a PATH-DATA-TLV format that has been defined in
section (<xref target="Proto_Msg" />) in the
PATH-DATA-TLV BNF definition. The restriction on the use of
PATH-DATA-TLV for GET/GET-PROP operation is it MUST
NOT contain any
SPARSEDATA-TLV or FULLDATA-TLV and RESULT-TLV in the data
format.</t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="query_tree"
title="PDU Format for Query Message">
<artwork><![CDATA[
main hdr (type = Query)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET }
| |
| +-- // one or more path targets
|
+-- T = operation { GET }
. |
. +-- // one or more path targets
.
]]></artwork>
</figure>
</section>
<section anchor="QueryResponse" title="Query Response Message">
<t>When receiving a Query message, the receiver should process the
message and come up with a query result. The receiver sends the
query result back to the message sender by use of the Query Response
Message. The query result can be the information being queried if
the query operation is successful, or can also be error codes if the
query operation fails, indicating the reasons for the failure.</t>
<t>A Query Response message is also composed of a common header and
a message body consisting of one or more TLVs describing the query
result. Detailed description of the message is as below.
<vspace blankLines="1" /></t>
<list hangIndent="4" style="hanging">
<t hangText="Message transfer direction: "><vspace /> from FE to
CE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
header is set to MessageType= 'QueryResponse'. The ACK flag in the
header is ignored. As a response itself, the message does not
expect a further response.</t>
<!--
<t hangText="Message body: "><vspace /> The Query Response message
body MUST consist of at least one LFBselect TLV as described in
<xref target="LFBselectTLV" />. The OPER-TLV in the LFB
select TLV is defined below.</t>
-->
<t hangText="OPER-TLV for Query Response: ">
<vspace />
</t>
<figure anchor="msg_Query_Response" title="TLV for Query Response">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GET-RESPONSE/GET-PROP-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type:"><vspace /> The operation type for query
response. One operation type is defined: <list hangIndent="7"
style="hanging">
<t>Type = "GET-RESPONSE" - this operation is to response to
get operation of LFB components.</t>
<t>Type = "GET-PROP-RESPONSE" - this
operation is to response to GET-PROP operation
of LFB components.</t>
</list></t>
<t hangText="PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: ">
<vspace /> This is
generically a PATH-DATA-TLV format that has been defined in
section (<xref target="Proto_Msg" />) in the
PATH-DATA-TLV BNF definition. The PATH-DATA-TLV for GET-RESPONSE
operation MAY contain SPARSEDATA-TLV, FULLDATA-TLV and/or
RESULT-TLV(s) in the data encoding. The RESULT-TLV is defined in
<xref target="RTLV" /> and the SPARSEDATA-TLVs and FULLDATA-TLVs
are defined in <xref target="DTLV" />.</t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor= "QueryResp_tree"
title="PDU Format for Query Response Message">
<artwork><![CDATA[
main hdr (type = QueryResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { GET-PROP-RESPONSE }
. |
. +-- // one or more path targets
.
]]></artwork>
</figure>
</section>
</section>
<!-- &EventMsg; -->
<section anchor="EventMsg" title="Event Notification Message">
<t>Event Notification Message is used by FE to asynchronously notify
CE of events that happen in the FE.</t>
<t>All events that can be generated in an FE are subscribable by the CE.
The CE can subscribe to an event via a Config message with
SET-PROP operation, where the
included path specifies the event, as defined by the LFB Library
and described by the FE Model.
</t>
<t>As usual, an Event Notification Message is composed of a common
header and a message body that consists of one or more TLV data
format. Detailed description of the message is as below.</t>
<list hangIndent="1" style="hanging">
<t hangText="Message Transfer Direction: "><vspace /> FE to CE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
message header is set to <vspace /> MessageType =
'EventNotification'. The ACK flag in the header MUST be ignored by
the CE, and the event notification message does not expect any
response from the receiver.</t>
<!--
<t hangText="Message Body: "><vspace /> The event notification
message body MUST consist of at least one LFBselect TLV as
described in <xref target="LFBselectTLV" />. The OPER-TLV in
the LFBselect TLV is defined below.</t>
-->
<t hangText="OPER-TLV for Event Notification: ">
<vspace />
</t>
<figure anchor="TLV_Event_Notif" title="TLV for Event Notification">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Type:"><vspace /> Only one operation type is defined
for the event notification message: <list hangIndent="7"
style="hanging">
<t>Type = "REPORT" - this type of operation is for FE to
report something to CE.</t>
</list></t>
<t hangText="PATH-DATA-TLV for REPORT: "><vspace /> This is
generically a PATH-DATA-TLV format that has been defined in
section (<xref target="Proto_Msg" />) in the PATH-DATA-TLV
BNF definition. The PATH-DATA-TLV for REPORT operation MAY contain
FULLDATA-TLV or SPARSEDATA-TLV(s)
but MUST NOT contain any RESULT-TLV in the data format.</t>
</list>
<t>To better illustrate the above PDU format, a tree structure for the
format is shown below:</t>
<figure anchor="event_tree"
title="PDU Format for Event Notification Message">
<artwork><![CDATA[
main hdr (type = Event Notification)
|
|
+--- T = LFBselect
|
+-- LFBCLASSID = target LFB class
|
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { REPORT }
| |
| +-- // one or more path targets
| // associated with FULL/SPARSE DATA TLV(s)
+-- T = operation { REPORT }
. |
. +-- // one or more path targets
. // associated with FULL/SPARSE DATA TLV(s)
]]></artwork>
</figure>
</section>
<!-- &RedirectMsg; -->
<section anchor="RedirectMsg" title="Packet Redirect Message">
<t>A packet Redirect message is used to transfer data packets between CE
and FE. Usually these data packets are control packets but they
may be just data-path packets which need further (exception or
high-touch) processing. It is also feasible that this message
carries no data packets and rather just metadata.
</t>
<t>The Packet Redirect message data format is formated as follows:</t>
<list hangIndent="1" style="hanging">
<t hangText="Message Direction: "><vspace /> CE to FE or FE to
CE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
header is set to MessageType= 'PacketRedirect'.
</t>
<t hangText="Message Body: "><vspace /> This consists of one
or more TLVs that contain or describe the
packet being redirected. The TLV is
specifically a Redirect TLV (with the TLV Type="Redirect"). Detailed
data format of a Redirect TLV for packet redirect message is as
below:</t>
<figure anchor="tlv_Redirect_Data" title="Redirect_Data TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<!--
<t hangText="LFB class ID: "><vspace /> There are only two possible
LFB classes here, the 'RedirectSink' LFB or the 'RedirectSource'
LFB <xref target="FE-MODEL"></xref>. If the message is from FE to CE, the LFB class should
be 'RedirectSink'. If the message is from CE to FE, the LFB class
should be 'RedirectSource'.</t>
<t hangText="Instance ID: "><vspace /> Instance ID for the
'RedirectSink' LFB or 'RedirectSource' LFB.</t>
-->
<t hangText="Meta Data TLV: "><vspace /> This is a TLV that
specifies meta-data associated with followed redirected data. The
TLV is as follows:</t>
<figure anchor="Meta_Data" title="METADATA-TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = METADATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t hangText="Meta Data ILV: "><vspace /> This is an
Identifier-Length-Value format that is used to describe one meta
data. The ILV has the format as: <figure anchor="Meta_Data_ILV"
title="Meta Data ILV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> <vspace blankline="1" /> Where, Meta Data ID is an
identifier for the meta data, which is statically assigned by the
LFB definition.
</t>
<!--
<t>
This actually implies a Meta Data ID transcoding
mechanism may be necessary if a metadata traverses several LFBs
while these LFBs define the metadata with different Meta Data IDs.
<vspace blankLines="1" /> Usually there are two meta data that are
necessary for CE-FE redirect operation. One is the redirected data
type (e.g., IP packet, TCP packet, or UDP Packet). For an FE->CE
redirect operation, redirected packet type meta data is usually a
meta data specified by a Classifier LFB that filter out redirected
packets from packet stream and sends the packets to Redirect Sink
LFB. For an CE->FE redirect operation, the redirected packet type
meta data is usually directly generated by CE. <vspace
blankLines="1" /> Another meta data that should be associated with
redirected data is the port number in a redirect LFB. For a
RedirectSink LFB, the port number meta data tells CE from which port
in the lFB the redirected data come. For a RedirectSource LFB, via
the meta data, CE tells FE which port in the LFB the redirected data
should go out.</t>
-->
<t hangText="Redirect Data TLV"><vspace /> This is a TLV describing
one packet of data to be directed via the redirect operation. The
TLV format is as follows: <figure anchor="Refirect_Data_TLV"
title="Redirect Data TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REDIRECTDATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t hangText="Redirected Data: "><vspace /> This field contains
the packet that is to be redirected in network byte order.
The packet should be 32-bits aligned as is the data for all TLVs.
The metadata infers what kind of packet is carried in value
field and therefore allows for easy decoding of data
encapsulated </t>
</list>
<t>To better illustrate the above PDU format, a tree structure for
the format is shown below:</t>
<figure anchor="redirect_tree"
title="PDU Format for Packet Redirect Message">
<artwork><![CDATA[
main hdr (type = PacketRedirect)
|
|
+--- T = Redirect
. |
. +-- T = METADATA-TLV
| |
| +-- Meta Data ILV
| |
| +-- Meta Data ILV
| .
| .
|
+-- T = REDIRECTDATA-TLV
|
+-- // Redirected Data
]]></artwork>
</figure>
</section>
<!-- &HBMsg; -->
<section anchor="HBMsg" title="Heartbeat Message">
<t>The Heartbeat (HB) Message is used for one ForCES element (FE or
CE) to asynchronously notify one or more other ForCES elements in the
same ForCES NE on its liveness.
<xref target="HB_appr" /> describes the traffic-sensitive
approach used.
</t>
<t>A Heartbeat Message is sent by a ForCES element periodically. The
parameterization and policy definition for heartbeats for an FE is
managed as components of the FE Protocol Object LFB, and
can be set by CE via a Config message. The Heartbeat message
is a little different from
other protocol messages in that it is only composed of a common
header, with the message body left empty. A detailed description of the
message is as below.</t>
<list hangIndent="4" style="hanging">
<t hangText="Message Transfer Direction: "><vspace /> FE to CE or
CE to FE</t>
<t hangText="Message Header: "><vspace /> The Message Type in the
message header is set to MessageType = 'Heartbeat'. <xref
target="HB_appr" /> describes the HB mechanisms used. The ACK flag
in the header MUST be set to either 'NoACK' or 'AlwaysACK' when the
HB is sent.</t>
<list style="symbols">
<t>When set to 'NoACK', the HB is not soliciting for a
response.</t>
<t>When set to 'AlwaysACK', the HB Message sender is always
expecting a response from its receiver. According the HB policies
defined in <xref target="FPL_sum" />, only the CE can send such an
HB message to query FE liveness. For simplicity and because of the
minimal nature of the HB message, the response to a HB message is
another HB message, i.e., no specific HB response message is
defined. Whenever an FE receives a HB message marked with
'AlwaysACK' from the CE, the FE MUST send a HB message back
immediately. The HB message sent by the FE in response to the
'AlwasyACK' MUST modify the source and destination IDs so that the
ID of the FE is the source ID and the CE ID of the sender is the
destination ID, and MUST change the ACK information to 'NoACK'. A
CE MUST NOT respond to an HB message with 'AlwasyACK' set.</t>
<t> When set to anything else other than 'NoACK' or
'AlwaysACK', the HB Message is treated as if it was a 'NoACK'.</t>
</list>
<t>The correlator field in the HB message header SHOULD be set
accordingly when a response is expected so that a receiver can
correlate the response correctly. The correlator field MAY be
ignored if no response is expected.</t>
<t hangText="Message Body: "><vspace /> The message body is empty
for the Heartbeat Message.</t>
</list>
</section>
<!-- &CmdSum; -->
</section>
<!-- &ProtoScene; -->
<!-- &ProtoScene; -->
<!-- &HA; -->
<section anchor="HA" title="High Availability Support">
<t><vspace blankLines="1" />
The ForCES protocol provides mechanisms for CE redundancy and
failover, in order to support High Availability as defined in <xref
target="RFC3654" />. FE redundancy and FE to FE interaction is currently
out of scope of this document. There can be multiple redundant CEs and FEs
in a ForCES NE. However, at any one time only one primary CE can control
the FEs though there can be multiple secondary CEs. The FE and the CE PL
are aware of the primary and secondary CEs. This information (primary,
secondary CEs) is configured in the FE and in the CE PLs during
pre-association by the FEM and the CEM respectively. Only the primary CE
sends control messages to the FEs.</t>
<section anchor="FEPOHA" title="Relation with the FE Protocol ">
<t>High Availability parameterization in an FE is
driven by configuring the FE Protocol Object LFB (refer to
<xref target="FPL_def" /> and <xref target="FPL_sum" />). The
FE Heartbeat Interval, CE Heartbeat Dead Interval,
and CE Heartbeat policy help in detecting connectivity
problems between an FE and CE. The CE Failover policy defines
the reaction on a detected failure.
</t>
<t>
<xref target="FESM" /> extends the state
machine illustrated in <xref target="FE_SM" />
to allow for new states that facilitate connection
recovery.
<figure anchor="FESM"
title="FE State Machine considering HA">
<artwork><![CDATA[
(CE issues Teardown || +-----------------+
Lost association) && | Pre-Association |
CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+
| | progress) | |
| CE Issues +--------+--------+ |
| Association | | CFTI
| Setup V | timer
| ___________________+ | expires
| | |
| V ^
+-+-----------+ +-------+-----+
| | | Not |
| | (CE issues Teardown || | Associated |
| | Lost association) && | |
| Associated | CE Failover Policy = 1 | (May |
| | | Continue |
| |---------->------->------>| Forwarding)|
| | | |
+-------------+ +-------------+
^ V
| |
| CE Issues |
| Association |
| Setup |
+_________________________________________+
]]></artwork>
</figure>
<xref target="FPP" /> describes transitions between the
Pre-association, associated and not associated
states.
</t>
<t>When communication fails between the FE and CE (which can be caused
by either the CE or link failure but not FE related), either the TML on the
FE will trigger the FE PL regarding this failure or it will be detected
using the HB messages between FEs and CEs. The communication failure,
regardless of how it is detected, MUST be considered as a loss of
association between the CE and corresponding FE.
</t>
<t>If the FE's FEPO CE Failover Policy is configured to mode 0
(the default), it will immediately transition to the pre-association
phase. This means that if association is again established,
all FE
state will need to be re-established.
</t>
<t>If the FE's FEPO CE Failover Policy is configured to mode 1,
it indicates that the FE is capable of HA
restart recovery.
In such a case, the FE transitions to the not associated state and
the CEFTI timer is started. The FE MAY continue to forward
packets during this state. It MAY also recycle through any configured
secondary CEs in a round-robin fashion. It first adds its
primary CE to the tail of backup CEs and sets its primary CE to be
the first secondary. It then attempts to associate with
the CE designated as the new primary CE.
If it fails to re-associate with any CE and the
CEFTI expires, the FE then transitions to the pre-association state.
</t>
<t>
If the FE, while in the not associated state, manages to reconnect
to a new primary CE before CEFTI expires it transitions to the
Associated state. Once re-associated, the FE tries to recover any
state that may have been lost during the not associated state.
How the FE achieves re-synchronizes it state is out of scope for
this document.
<t>
<xref target="seq_HA_Report_Primary" /> below
illustrates the Forces message sequences that the FE
uses to recover the connection.
<figure anchor="seq_HA_Report_Primary"
title="CE Failover for Report Primary Mode">
<artwork><![CDATA[
FE CE Primary CE Secondary
| | |
| Asso Estb,Caps exchg | |
1 |<--------------------->| |
| | |
| All msgs | |
2 |<--------------------->| |
| | |
| | |
| FAILURE |
| |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) |
4 |------------------------------------------->|
| |
| All Msgs |
5 |<------------------------------------------>|
]]></artwork>
</figure>
</t>
A CE-to-CE
synchronization protocol would be needed to support fast failover as
well as to address some of the corner cases, however this will not be
defined by the ForCES protocol as it is out of scope for this
specification.</t>
<t>An explicit message (a Config message setting Primary CE component in
ForCES Protocol object) from the primary CE, can also be used to change
the Primary CE for an FE during normal protocol operation.</t>
<t>Also note that the FEs in a ForCES NE could also use a multicast
CE ID, i.e., they could be associated with a group of CEs (this
assumes the use of a CE-CE synchronization protocol, which is
out of scope for this specification). In this case, the loss of
association would mean that
communication with the entire multicast group of CEs has been lost. The
mechanisms described above will apply for this case as well during the
loss of association. If, however, the secondary CE was also using the
multicast CE ID that was lost, then the FE will need to form a new
association using a different CE ID. If the capability exists, the FE MAY
first attempt to form a new association with original primary CE using a
different non multicast CE ID.</t>
</section>
<!-- 8.1. Responsibilities for HA: -->
<section title="Responsibilities for HA">
<t>TML Level:</t>
<list style="numbers">
<t>The TML controls logical connection availability and
failover.</t>
<t>The TML also controls peer HA management.</t>
</list>
<t>At this level, control of all lower layers, for example transport
level (such as IP addresses, MAC addresses etc) and associated links
going down are the role of the TML.</t>
<t>PL Level: <vspace /> All other functionality, including
configuring the HA behavior during setup, the CE IDs used to
identify primary and secondary CEs, protocol messages used to report CE
failure (Event Report), Heartbeat messages used to detect association
failure, messages to change the primary CE (Config), and other HA
related operations described before, are the PL responsibility.</t>
<t>To put the two together, if a path to a primary CE is down, the TML
would take care of failing over to a backup path, if one is available.
If the CE is totally unreachable then the PL would be informed and it
would take the appropriate actions described before.</t>
</section>
</section>
<!-- &Security; -->
<section anchor="Security" title="Security Considerations">
<t>ForCES architecture identifies several levels of security in <xref
target="RFC3746" />. ForCES PL uses security services provided by the
ForCES TML. The TML provides security services such as endpoint
authentication service, message authentication service and
confidentiality service. Endpoint authentication service is invoked at
the time of the pre-association connection establishment phase and
message authentication is performed whenever the FE or CE receives a
packet from its peer.</t>
<t>The following are the general security mechanisms that need to be in
place for ForCES PL.</t>
<list style="symbols">
<t>Security mechanisms are session controlled - that is, once the
security is turned on depending upon the chosen security level (No
Security, Authentication, Confidentiality), it will be in effect
for the entire duration of the session.</t>
<t>An operator should configure the same security policies for both
primary and backup FEs and CEs (if available). This will ensure
uniform operations and avoid unnecessary complexity in policy
configuration.</t>
<!--
<t>ForCES PL endpoints SHOULD connections with both
primary and backup CE's. This will reduce the security messages and
enable rapid switchover operations for HA.</t>
-->
</list>
<!-- 10.1 No Security -->
<section title="No Security">
<t>When "No security" is chosen for ForCES protocol communication,
both endpoint authentication and message authentication service needs
to be performed by ForCES PL. Both these mechanism are weak and
do not involve cryptographic operation. An operator can choose "No
Security" level when the ForCES protocol endpoints are within a single
box, for example.</t>
<t>In order to have interoperable and uniform implementation across
various security levels, each CE and FE endpoint MUST implement this
level. </t>
<!--
The operations that are being performed for "No security" level
is required even if lower TML security services are being used.</t>
-->
<!-- 10.1.1 Endpoint Authentication -->
<section title="Endpoint Authentication">
<t>Each CE and FE PL maintains a list of associations as
part its of configuration. This is done via the CEM and
FEM interfaces. An FE MUST connect to only those CEs that
are configured via the FEM; similarly, a CE should accept
the connection and establish associations for the FEs which
are configured via the CEM. The CE should
validate the FE identifier before accepting the connections during
the pre-association phase.</t>
</section>
<!-- 10.1.2 Message authentication -->
<section title="Message Authentication">
<t>When a CE or FE initiates a message, the receiving
endpoint MUST validate the initiator of the message by checking the
common header CE or FE identifiers. This will ensure proper protocol
functioning. This extra processing step is recommended even when
the underlying TML layer security services exist.</t>
</section>
</section>
<!-- 10.2 ForCES PL and TML security service -->
<section title="ForCES PL and TML security service">
<t>This section is applicable if an operator wishes to use the TML
security services. A ForCES TML MUST support one or more security
services such as endpoint authentication service, message
authentication service, and confidentiality service, as part of TML
security layer functions. It is the responsibility of the operator to
select an appropriate security service and configure security policies
accordingly. The details of such configuration are outside the
scope of the ForCES PL and are dependent on the type of
transport protocol and the nature of the connection.</t>
<t>All these configurations should be done prior to starting the CE
and FE.</t>
<t>When certificates-based authentication is being used at the TML,
the certificate can use a ForCES-specific naming structure as
certificate names and, accordingly, the security policies can be
configured at the CE and FE.</t>
<!-- 10.2.1 Endpoint authentication service -->
<section title="Endpoint authentication service">
<t>When TML security services are enabled, the ForCES TML
performs endpoint authentication. Security association is
established between
CE and FE and is transparent to the ForCES PL.</t>
<!--
<t>It is recommended that an FE, after establishing the connection
with the primary CE, should establish the security association with
the backup CE (if available). During the switchover operation CE's
security state associated with each SA's are not transferred. SA
between primary CE and FE and backup CE and FE are treated as two
separate SA's.</t>
-->
</section>
<!-- 10.2.2 Message authentication service -->
<section title="Message authentication service">
<t>This is a TML specific operation and is transparent to the
ForCES PL. For details, refer to <xref target="TML_Req" />.</t>
</section>
<!-- 10.2.3 Confidentiality service -->
<section title="Confidentiality service">
<t>This is a TML specific operation and is transparent to the
ForCES PL. For details, refer to <xref target="TML_Req" />.</t>
</section>
</section>
</section>
<!--
<section title = "Contributors">
<t>
The participants in the ForCES Protocol Team, primary co-authors and co-editors,
of this protocol specification, are:
</t>
<t>
Ligang Dong (Zhejiang Gongshang University),
Avri Doria (ETRI),
Ram Gopal (Nokia),
Robert Haas (IBM),
Jamal Hadi Salim (Znyx),
Hormuzd M Khosravi (Intel), and
Weiming Wang (Zhejiang Gongshang University).
</t>
</section>
-->
<section title="Acknowledgements">
<t>The authors of this draft would like to acknowledge and thank the
ForCES Working Group and especially the following: Furquan
Ansari, Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen
M. Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel
M. Halpern (who should probably be listed among the authors), Zsolt
Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering,
T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their
contributions. We would also like to thank David Putzolu, and Patrick
Droz for their comments and suggestions on the protocol and for their
infinite patience. We would also like to thank Sue Hares and Alia
Atlas for extensive reviews of the
document.</t>
<t> Alia Atlas has done a wonderful job of shaping the draft to make
it more readable by providing the IESG feedback.</t>
<t>The editors have used the xml2rfc <xref target="RFC2629"></xref>
tools in creating this document and are very grateful for the existence
and quality of these tools. The editor is also grateful to Elwyn Davies
for his help in correcting the XML source of this document.</t>
</section>
</middle>
<back>
<!-- &NormRef; -->
<!-- normative references -->
<references title="Normative References">
&RFC2119;
&RFC5226;
<reference anchor="FE-MODEL">
<front>
<title>ForCES Forwarding Element Model</title>
<author fullname="L. Yang" initials="L." surname="Yang"></author>
<author fullname="J. Halpern" initials="J." surname="Halpern"></author>
<author fullname="R. Gopal" initials="R." surname="Gopal"></author>
<author fullname="A. DeKok" initials="A." surname="DeKok"></author>
<author fullname="Z. Haraszti" initials="Z." surname="Haraszti"></author>
<author fullname="S. Blake" initials="S." surname="Blake"></author>
<date month="Feb." year="2005" />
</front>
</reference>
</references>
<!-- &InfoRef; -->
<references title="Informational References">
&RFC2629;
&RFC3654;
&RFC3746;
<reference anchor="ACID">
<front>
<title>Principles of Transaction-Orientated Database
Recovery</title>
<author fullname="Harder T." initials="T." surname="Haerder"></author>
<author fullname="Reuter A." initials="A." surname="Reuter"></author>
<date year="1983" />
</front>
</reference>
<reference anchor="2PCREF">
<front>
<title>Notes on database operating systems. In Operating Systems: An
Advanced Course. Lecture Notes in Computer Science, Vol. 60, pp.
394-481, Springer-Verlag</title>
<author fullname="J. Gray" initials="J." surname="Gray"></author>
<date year="1978" />
</front>
</reference>
</references>
<!-- &IANA; -->
<!-- iana.xml -->
<section title="IANA Considerations">
<t>Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" (RFC 5226 <xref target="RFC5226" />),
the following name spaces are defined in ForCES.</t>
<list style="symbols">
<t>Message Type Name Space <xref target="Proto_Msg" /></t>
<t>Operation Type Name Space <xref target="OTLV" /></t>
<t>Header Flags <xref target="Common_Header" /></t>
<t>TLV Type <xref target="Proto_Msg" /></t>
<t>TLV Result Values <xref target="RTLV" /></t>
<t>LFB Class ID <xref target="LFBselectTLV" /></t>
<t>Result: Association Setup Response <xref
target="Assoc_Setup_Resp" /></t>
<t>Reason: Association Teardown Message <xref
target="Assoc_Tear_Resp" /></t>
<!--
<t>Configuration Request: Operation Result <xref
target="CfgMsg" /></t>
-->
</list>
<!-- B.1. -->
<section title="Message Type Name Space" anchor="MSGt_Def">
<t>The Message Type is an 8 bit value. The following is the guideline
for defining the Message Type namespace</t>
<list style="hanging">
<t hangText="Message Types 0x00 - 0x0F"><vspace /> Message Types in
this range are part of the base ForCES Protocol. Message Types in
this range are allocated through an IETF consensus action. <xref
target="RFC5226" /> <vspace blankLines="1" /> Values assigned by this
specification: <figure>
<artwork><![CDATA[
0x00 Reserved
0x01 AssociationSetup
0x02 AssociationTeardown
0x03 Config
0x04 Query
0x05 EventNotification
0x06 PacketRedirect
0x07 - 0x0E Reserved
0x0F Hearbeat
0x11 AssociationSetupRepsonse
0x12 Reserved
0x13 ConfigRepsonse
0x14 QueryResponse
]]></artwork>
</figure></t>
<t hangText="Message Types 0x20 - 0x7F"><vspace /> Message Types in
this range are Specification Required <xref target="RFC5226" />
Message Types using this range must be documented in an RFC or other
permanent and readily available reference.</t>
<t hangText="Message Types 0x80 - 0xFF"><vspace /> Message Types in
this range are reserved for vendor private extensions and are the
responsibility of individual vendors. IANA management of this range
of the Message Type Name Space is unnecessary.</t>
</list>
</section>
<section title="Operation Selection" anchor="OPERt_Def">
<t>The Operation Selection (OPER-TLV) name space is 16 bits long.
The following is the guideline for managing the OPER-TLV Name Space.</t>
<list style="hanging">
<t hangText="OPER-TLV Type 0x0000-0x00FF"><vspace /> OPER-TLV
Types in this range are allocated through an IETF consensus process.
<xref target="RFC5226" />. <vspace blankLines="1" /> Values assigned
by this specification: <figure>
<artwork><![CDATA[
0x0000 Reserved
0x0001 SET
0x0002 SET-PROP
0x0003 SET-RESPONSE
0x0004 SET-PROP-RESPONSE
0x0005 DEL
0x0006 DEL-RESPONSE
0x0007 GET
0x0008 GET-PROP
0x0009 GET-RESPONSE
0x000A GET-PROP-RESPONSE
0x000B REPORT
0x000C COMMIT
0x000D COMMIT-RESPONSE
0x000E TRCOMP
]]></artwork>
</figure></t>
<t hangText="OPER-TLV Type 0x0100-0x7FFF"><vspace /> OPER-TLV
Types using this range must be documented in an RFC or other
permanent and readily available reference. <xref
target="RFC5226" />.</t>
<t hangText="OPER-TLV Type 0x8000-0xFFFF"><vspace /> OPER-TLV
Types in this range are reserved for vendor private extensions and
are the responsibility of individual vendors. IANA management of
this range of the OPER-TLV Type Name Space is unnecessary.</t>
</list>
</section>
<section title="Header Flags">
<list style="hanging">
<t>The Header flag field is 32 bits long. Header flags are part of
the ForCES base protocol. Header flags are allocated through an IETF
consensus action <xref target="RFC5226" />.</t>
</list>
</section>
<section title="TLV Type Name Space">
<t>The TLV Type name space is 16 bits long. The following is the
guideline for managing the TLV Type Name Space.</t>
<list style="hanging">
<t hangText="TLV Type 0x0000-0x00FF"><vspace /> TLV Types in this
range are allocated through an IETF consensus process. <xref
target="RFC5226" />. <vspace blankLines="1" /> Values assigned by
this specification: <figure>
<artwork><![CDATA[
0x0000 Reserved
0x0001 REDIRECT-TLV
0x0010 ASResult-TLV
0x0011 ASTreason-TLV
0x1000 LFBselect-TLV
0x0110 PATH-DATA-TLV
0x0111 KEYINFO-TLV
0x0112 FULLDATA-TLV
0x0113 SPARSEDATA-TLV
0x0114 RESULT-TLV
0x0115 METADATA-TLV
0x0116 REDIRECTDATA-TLV
]]></artwork>
</figure></t>
<t hangText="TLV Type 0x0200-0x7FFF"><vspace /> TLV Types using this
range must be documented in an RFC or other permanent and readily
available reference <xref target="RFC5226" />.</t>
<t hangText="TLV Type 0x8000-0xFFFF"><vspace /> TLV Types in this
range are reserved for vendor private extensions and are the
responsibility of individual vendors. IANA management of this range
of the TLV Type Name Space is unnecessary.</t>
</list>
</section>
<!--
<section title="Result-TLV Result Values">
<t>The RESULT-TLV Result Value is an 8 bit value. <figure>
<artwork><![CDATA[
0x00 SUCCESS
0x01 INVALID_HEADER
0x02 LENGTH_MISMATCH
0x03 VERSION_MISMATCH
0x04 INVALID_DESTINATION_PID
0x05 LFB_UNKNOWN
0x06 LFB_NOT_FOUND
0x07 LFB_INSTANCE_ID_NOT_FOUND
0x08 INVALID_PATH
0x09 COMPONENT_DOES_NOT_EXIST
0x0A EXISTS
0x0B NOT_FOUND
0x0C READ_ONLY
0x0D INVALID_ARRAY_CREATION
0x0E VALUE_OUT_OF_RANGE
0x0F CONTENTS_TOO_LONG
0x10 INVALID_PARAMETERS
0x11 INVALID_MESSAGE_TYPE
0x12 INVALID_FLAGS
0x13 INVALID_TLV
0x14 EVENT_ERROR
0x15 NOT_SUPPORTED
0x16 MEMORY_ERROR
0x17 INTERNAL_ERROR
0x18-0xFE Reserved
0xFF UNSPECIFIED_ERROR
]]></artwork>
</figure> All values not assigned in this specification are
designated as Assignment by Expert review.</t>
</section>
-->
<section title="Result-TLV Result Values">
<t>The RESULT-TLV RTesult Value is an 8 bit value. <figure>
<artwork><![CDATA[
0x00 E_SUCCESS
0x01 E_INVALID_HEADER
0x02 E_LENGTH_MISMATCH
0x03 E_VERSION_MISMATCH
0x04 E_INVALID_DESTINATION_PID
0x05 E_LFB_UNKNOWN
0x06 E_LFB_NOT_FOUND
0x07 E_LFB_INSTANCE_ID_NOT_FOUND
0x08 E_INVALID_PATH
0x09 E_COMPONENT_DOES_NOT_EXIST
0x0A E_EXISTS
0x0B E_NOT_FOUND
0x0C E_READ_ONLY
0x0D E_INVALID_ARRAY_CREATION
0x0E E_VALUE_OUT_OF_RANGE
0x0F E_CONTENTS_TOO_LONG
0x10 E_INVALID_PARAMETERS
0x11 E_INVALID_MESSAGE_TYPE
0x12 E_E_INVALID_FLAGS
0x13 E_INVALID_TLV
0x14 E_EVENT_ERROR
0x15 E_NOT_SUPPORTED
0x16 E_MEMORY_ERROR
0x17 E_INTERNAL_ERROR
0x18-0xFE Reserved
0xFF E_UNSPECIFIED_ERROR
]]></artwork>
</figure> All values not assigned in this specification are
designated as Assignment by Expert review.</t>
</section>
<!--
<section title="LFB Class Id Name Space">
<t>The LFB Class ID name space is 32 bits long. The following is the
guideline for managing the LFB Class Id Name Space.</t>
<list style="hanging">
<t hangText="LFB Class ID 0x00000000-0x0000FFFF"><vspace /> LFB
Class IDs in this range are allocated through an IETF consensus
process. <xref target="RFC5226" />. <vspace blankline="1" /> Values
assigned by this specification: <figure>
<artwork><![CDATA[
0x00000000 Reserved
0x00000001 FE Protocol LFB
0x00000002 FE Object LFB
]]></artwork>
</figure></t>
<t hangText="LFB Class ID 0x00010000-0x7FFFFFFF"><vspace /> LFB
Class IDs in this range are Specification Required <xref
target="RFC5226" /> LFB Class ID using this range must be documented
in an RFC or other permanent and readily available references. <xref
target="RFC5226" />.</t>
<t hangText="LFB Class Id 0x80000000-0xFFFFFFFFF"><vspace /> LFB
Class IDs in this range are reserved for vendor private extensions
and are the responsibility of individual vendors. IANA management of
this range of the LFB Class ID Space is unnecessary.</t>
</list>
</section>
-->
<section title="Association Setup Response">
<t>The Association Setup Response name space is 32 bits long. The
following is the guideline for managing the Association Setup Response
Name Space.</t>
<list style="hanging">
<t hangText="Association Setup Response 0x0000-0x00FF"><vspace />
Association Setup Responses in this range are allocated through an
IETF consensus process <xref target="RFC5226" />. <vspace
blankLines="1" /> Values assigned by this specification: <figure>
<artwork><![CDATA[
0x0000 Success
0x0001 FE ID Invalid
0x0002 Permission Denied
]]></artwork>
</figure></t>
<t hangText="Association Setup Response 0x0100-0x0FFF"><vspace />
Association Setup Responses in this range are Specification Required
<xref target="RFC5226" /> Values using this range must be documented
in an RFC or other permanent and readily available reference <xref
target="RFC5226" />.</t>
<t
hangText="Association Setup Response 0x1000-0xFFFFFFFFF"><vspace />
Association Setup Responses in this range are reserved for vendor
private extensions and are the responsibility of individual vendors.
IANA management of this range of the Association Setup Responses
Name Space is unnecessary.</t>
</list>
</section>
<section title="Association Teardown Message">
<t>The Association Teardown Message name space is 32 bits long. The
following is the guideline for managing the Association Teardown
Message Name Space.</t>
<list style="hanging">
<t
hangText="Association Teardown Message 0x00000000-0x0000FFFF"><vspace />
Association Teardown Messages in this range are allocated through an
IETF consensus process <xref target="RFC5226" />. <vspace
blankLines="1" /> Values assigned by this specification: <figure>
<artwork><![CDATA[
0x00000000 Normal - Teardown by Administrator
0x00000001 Error - loss of heartbeats
0x00000002 Error - loss of bandwidth
0x00000003 Error - Out of Memory
0x00000004 Error - Application Crash
0x000000FF Error - Unspecified
]]></artwork>
</figure></t>
<t
hangText="Association Teardown Message 0x00010000-0x7FFFFFFF"><vspace />
Association Teardown Messages in this range are Specification
Required <xref target="RFC5226" /> Association Teardown Messages
using this range must be documented in an RFC or other
permanent and
readily available references. <xref target="RFC5226" />.</t>
<t hangText="Association Teardown Message 0x80000000-0xFFFFFFFFF"><vspace />
Association Teardown Messages in this range are reserved
for vendor private extensions and are the responsibility
of individual vendors.
IANA management of this range of the Association Teardown Message
Name Space is unnecessary.</t>
</list>
</section>
<!--
<section title="Configuration Request Result">
<t>The Configuration Request name space is 32 bits long. The following
is the guideline for managing the Configuration Request Name
Space.</t>
<list style="hanging">
<t hangText="Configuration Request 0x0000-0x00FF"><vspace />
Configuration Requests in this range are allocated through an IETF
consensus process. <xref target="RFC5226" />. <vspace
blankline="1" /> Values assigned by this specification: <figure>
<artwork><![CDATA[
0x0000 Success
0x0001 FE ID Invalid
0x0003 Permission Denied
]]></artwork>
</figure></t>
<t hangText="Configuration Request 0x0100-0x7FFF"><vspace />
Configuration Requests in this range are Specification Required
<xref target="RFC5226" /> Configuration Requests using this range
must be documented in an RFC or other permanent and readily
available references. <xref target="RFC5226" />.</t>
<t hangText=" 0x8000-0xFFFF"><vspace /> Configuration Requests in
this range are reserved for vendor private extensions and are the
responsibility of individual vendors. IANA management of this range
of the Configuration Request Name Space is unnecessary.</t>
</list>
</section>
-->
</section>
<!-- &ProtoLFB; -->
<section anchor="FPL_def" title="ForCES Protocol LFB schema">
<t>The schema described below conforms to the LFB schema <!--
(language?)
--> described in ForCES Model draft<xref target="FE-MODEL">.</xref></t>
<t>
<xref target="FPL_sum" /> describes the details of the different
components defined in this definition.
</t>
<figure>
<artwork><![CDATA[
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="FEPO">
<!-- XXX -->
<dataTypeDefs>
<dataTypeDef>
<name>CEHBPolicyValues</name>
<synopsis>
The possible values of CE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEHBPolicy0</name>
<synopsis>
The CE heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE heartbeat policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHBPolicyValues</name>
<synopsis>
The possible values of FE heartbeat policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FEHBPolicy0</name>
<synopsis>
The FE heartbeat policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE heartbeat policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<synopsis>
The possible values of FE restart policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restart policy 0
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<synopsis>
The possible values of CE failover policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The CE failover policy 0
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The CE failover policy 1
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHACapab</name>
<synopsis>
The supported HA features
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>GracefullRestart</name>
<synopsis>
The FE supports Graceful Restart
</synopsis>
</specialValue>
<specialValue value="1">
<name>HA</name>
<synopsis>
The FE supports HA
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object
</synopsis>
<version>1.0</version>
<components>
<component componentID="1" access="read-only">
<name>CurrentRunningVersion</name>
<synopsis>Currently running ForCES version</synopsis>
<typeRef>u8</typeRef>
</component>
<component componentID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>MulticastFEIDs</name>
<synopsis>
the table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEHBPolicy</name>
<synopsis>
The CE Heartbeat Policy
</synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</component>
<component componentID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat Policy
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The Primary CE this FE was last associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
the table of ForCES versions that FE supports
</synopsis>
<array type="variable-size">
<typeRef>u8</typeRef>
</array>
</capability>
<capability componentID="31">
<name>HACapabilities</name>
<synopsis>
the table of HA capabilities the FE supports
</synopsis>
<array type="variable-size">
<typeRef>FEHACapab</typeRef>
</array>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The pimary CE has changed
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
]]></artwork>
</figure>
<section title="Capabilities">
>
<t>Supportable Versions enumerates all ForCES versions that an FE
supports.</t>
<t>
FEHACapab enumerates the HA capabilities of the FE. If the
FE is not capable of Graceful restarts or
HA, then it will not be able to participate in
HA as described in <xref target="FEPOHA" />
</t>
</section>
<!-- end capabilities -->
<section title="Components">
>
<t>All Components are explained in <xref target="FPL_sum" />.</t>
</section>
<!-- end Components -->
</section>
<!-- end schema -->
<!-- &DatarawExam; -->
<section anchor="DataencExam" title="Data Encoding Examples">
<t>In this section a few examples of data encoding are discussed. these
example, however, do not show any padding.</t>
<figure>
<artwork><![CDATA[
==========
Example 1:
==========
]]></artwork>
</figure>
<t>Structure with three fixed-lengthof, mandatory fields.</t>
<figure>
<artwork><![CDATA[
struct S {
uint16 a
uint16 b
uint16 c
}
]]></artwork>
</figure>
<t>(a) Describing all fields using SPARSEDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path-Data TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>(b) Describing a subset of fields</t>
<figure>
<artwork><![CDATA[
Path-Data TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>Note: Even though there are non-optional components
in structure S, since one can uniquely identify components,
one can selectively send component of structure S (eg in
the case of an update from CE to FE).</t>
<t>(c) Describing all fields using a FULLDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path-Data TLV
Path to an instance of S ...
FULLDATA-TLV
valueof(a)
valueof(b)
valueof(c)
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
==========
Example 2:
==========
]]></artwork>
</figure>
<t>Structure with three fixed-lengthof fields, one mandatory, two
optional.</t>
<figure>
<artwork><![CDATA[
struct T {
uint16 a
uint16 b (optional)
uint16 c (optional)
}
]]></artwork>
</figure>
<t>This example is identical to Example 1, as illustrated below.</t>
<t>(a) Describing all fields using SPARSEDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path-Data TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>(b) Describing a subset of fields using SPARSEDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path-Data TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>(c) Describing all fields using a FULLDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path-Data TLV
Path to an instance of S ...
FULLDATA-TLV
valueof(a)
valueof(b)
valueof(c)
]]></artwork>
</figure>
<t>Note: FULLDATA-TLV _cannot_ be used unless all fields are being
described.</t>
<figure>
<artwork><![CDATA[
==========
Example 3:
==========
]]></artwork>
</figure>
<t>Structure with a mix of fixed-lengthof and variable-lengthof fields,
some mandatory, some optional. Note in this case, b is variable
sized </t>
<figure>
<artwork><![CDATA[
struct U {
uint16 a
string b (optional)
uint16 c (optional)
}
]]></artwork>
</figure>
<t>(a) Describing all fields using SPARSEDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>(b) Describing a subset of fields using SPARSEDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>(c) Describing all fields using FULLDATA-TLV</t>
<figure>
<artwork><![CDATA[
Path to an instance of U ...
FULLDATA-TLV
valueof(a)
FULLDATA-TLV
valueof(b)
valueof(c)
]]></artwork>
</figure>
<t>Note: The variable-length field requires the addition of a
FULLDATA-TLV within the outer FULLDATA-TLV as in the case of
component b above.</t>
<figure>
<artwork><![CDATA[
==========
Example 4:
==========
]]></artwork>
</figure>
<t>Structure containing an array of another structure type.</t>
<figure>
<artwork><![CDATA[
struct V {
uint32 x
uint32 y
struct U z[]
}
]]></artwork>
</figure>
<t>(a) Encoding using SPARSEDATA-TLV, with two instances of z[], also
described with SPARSEDATA-TLV, assuming only the 10th and 15th
subscript of z[] are encoded.</t>
<figure>
<artwork><![CDATA[
path to instance of V ...
SPARSEDATA-TLV
ComponentIDof(x), lengthof(x), valueof(x)
ComponentIDof(y), lengthof(y), valueof(y)
ComponentIDof(z), lengthof(all below)
ComponentID = 10 (i.e index 10 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b)
ComponentID = 15 (index 15 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)
]]></artwork>
</figure>
<t>Note the holes in the components of z (10 followed by 15).
Also note the gap in index 15 with only components a and c
appearing but not b.</t>
</section>
<!-- &Examples; -->
<section anchor="use_cases" title="Use Cases">
<t>Assume LFB with following components for the following use cases.</t>
<figure>
<artwork><![CDATA[
foo1, type u32, ID = 1
foo2, type u32, ID = 2
table1: type array, ID = 3
components are:
t1, type u32, ID = 1
t2, type u32, ID = 2 // index into table2
KEY: nhkey, ID = 1, V = t2
table2: type array, ID = 4
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
KEY: akey, ID = 1, V = { j1,j2 }
table3: type array, ID = 5
components are:
someid, type u32, ID = 1
name, type string variable sized, ID = 2
table4: type array, ID = 6
components are:
j1, type u32, ID = 1
j2, type u32, ID = 2
j3, type u32, ID = 3
j4, type u32, ID = 4
KEY: mykey, ID = 1, V = { j1}
table5: type array, ID = 7
components are:
p1, type u32, ID = 1
p2, type array, ID = 2, array components of type-X
Type-X:
x1, ID 1, type u32
x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1}
]]></artwork>
</figure>
<t>All examples will use valueof(x) to indicate
the value of the referenced component x.
In the case where F_SEL** are missing (bits equal to 00) then
the flags will not show any selection.</t>
<t>All the examples only show use of FULLDATA-TLV for data encoding;
although SPARSEDATA-TLV would make more sense in certain occasions,
the emphasis is on showing the message layout.
Refer to <xref target="DataencExam" /> for examples that show
usage of both FULLDATA-TLV and SPARSEDATA-TLV.</t>
<t />
<list style="numbers">
<t>To get foo1 <figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data TLV: IDCount = 1, IDs = 1
Result:
OPER = GET-RESPONSE-TLV
Path-data-TLV:
flags=0, IDCount = 1, IDs = 1
FULLDATA-TLV L = 4+4, V = valueof(foo1)
]]></artwork>
</figure></t>
<t>To set foo2 to 10 <figure>
<artwork><![CDATA[
OPER = SET-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV: L = 4+4, V=10
Result:
OPER = SET-RESPONSE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
]]></artwork>
</figure></t>
<t>To dump table2 <figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data-TLV:
IDCount = 1, IDs = 4
Result:
OPER = GET-RESPONSE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV: L = XXX, V=
a series of: index, valueof(j1), valueof(j2)
representing the entire table
]]></artwork>
</figure>
<list style="hanging">
<t hangText="Note: ">One should be able to take a GET-RESPONSE-TLV
and convert it to a SET-TLV. If the result in the above
example is sent back in a SET-TLV, (instead of a
GET-RESPONSE_TLV) then the entire contents of the table will be
replaced at that point.</t>
</list>
</t>
<t>Multiple operations Example. To create entry 0-5 of table2 (Error
conditions are ignored)</t>
<figure>
<artwork><![CDATA[
OPER = SET-TLV
Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV valueof(j1), valueof(j2) of entry 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV valueof(j1), valueof(j2) of entry 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV valueof(j1), valueof(j2) of entry 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV valueof(j1), valueof(j2) of entry 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV valueof(j1), valueof(j2) of entry 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV valueof(j1), valueof(j2) of entry 5
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Result:
OPER = SET-RESPONSE-TLV
Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
RESULT-TLV
]]></artwork>
</figure>
<t>Block operations (with holes) example. Replace entry 0,2 of
table2</t>
<figure>
<artwork><![CDATA[
OPER = SET-TLV
Path-data TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2) of 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2) of 2
Result:
OPER = SET-TLV
Path-data TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
]]></artwork>
</figure>
<t>Getting rows example. Get first entry of table2. <figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data TLV:
IDCount = 2, IDs=4.0
Result:
OPER = GET-RESPONSE-TLV
Path-data TLV:
IDCount = 2, IDs=4.0
FULLDATA-TLV containing valueof(j1), valueof(j2)
]]></artwork>
</figure></t>
<t>Get entry 0-5 of table2. <figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
Result:
OPER = GET-RESPONSE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV containing valueof(j1), valueof(j2)
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV containing valueof(j1), valueof(j2)
]]></artwork>
</figure></t>
<t>Create a row in table2, index 5.</t>
<figure>
<artwork><![CDATA[
OPER = SET-TLV
Path-data-TLV:
flags = 0, IDCount = 2, IDs=4.5
FULLDATA-TLV containing valueof(j1), valueof(j2)
Result:
OPER = SET-RESPONSE-TLV
Path-data TLV:
flags = 0, IDCount = 1, IDs=4.5
RESULT-TLV
]]></artwork>
</figure>
<!--
<t>An example of "create and give me an index" Assuming one asked for
verbose response back in the main message header.</t>
<figure>
<artwork><![CDATA[
OPER = SET-TLV
Path-data -TLV:
flags = FIND-EMPTY, IDCount = 1, IDs=4
FULLDATA-TLV containing valueof(j1), valueof(j2)
Result
If 7 were the first unused entry in the table:
OPER = SET-RESPONSE
Path-data TLV:
flags = 0, IDCount = 2, IDs=4.7
RESULT-TLV indicating success, and
FULLDATA-TLV containing valueof(j1), valueof(j2)
]]></artwork>
</figure>
-->
<t>Dump contents of table1.</t>
<figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data TLV:
flags = 0, IDCount = 1, IDs=3
Result:
OPER = GET-RESPONSE-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs=3
FULLDATA-TLV, Length = XXXX
(depending on size of table1)
index, valueof(t1),valueof(t2)
index, valueof(t1),valueof(t2)
.
.
.
]]></artwork>
</figure>
<t>Using Keys. Get row entry from table4 where j1=100. Recall, j1 is a
defined key for this table and its KeyID is 1.</t>
<!--
NOTE! NOTE!
There is still debate as to whether this must reference only
1 entry.
-->
<figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data-TLV:
flags = F_SELKEY IDCount = 1, IDs=6
KEYINFO-TLV = KeyID=1, KEY_DATA=100
Result:
If j1=100 was at index 10
OPER = GET-RESPONSE-TLV
Path-data TLV:
flags = 0, IDCount = 1, IDs=6.10
FULLDATA-TLV containing
valueof(j1), valueof(j2),valueof(j3),valueof(j4)
]]></artwork>
</figure>
<t>Delete row with KEY match (j1=100, j2=200) in table2. Note that
the j1,j2 pair are a defined key for the table2.</t>
<figure>
<artwork><![CDATA[
OPER = DEL-TLV
Path-data TLV:
flags = F_SELKEY IDCount = 1, IDs=4
KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200}
Result:
If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV
Path-data TLV:
flags = 0 IDCount = 2, IDs=4.15
RESULT-TLV
]]></artwork>
</figure>
<t>Dump contents of table3. It should be noted that this table has a
column with component name that is variable sized. The purpose of this
use case is to show how such an component is to be encoded.</t>
<figure>
<artwork><![CDATA[
OPER = GET-TLV
Path-data-TLV:
flags = 0 IDCount = 1, IDs=5
Result:
OPER = GET-RESPONSE-TLV
Path-data TLV:
flags = 0 IDCount = 1, IDs=5
FULLDATA-TLV, Length = XXXX
index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v)
index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v)
index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v)
index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v)
.
.
.
]]></artwork>
</figure>
<t>Multiple atomic operations.</t>
<list style="hanging">
<t hangText="Note 1: ">This emulates adding a new nexthop entry and
then atomically updating the L3 entries pointing to an old NH to
point to a new one. The assumption is both tables are in the same
LFB</t>
<t hangText="Note2: "> Observe the two operations on the LFB
instance, both are SET operations.</t>
</list>
<figure>
<artwork><![CDATA[
//Operation 1: Add a new entry to table2 index #20.
OPER = SET-TLV
Path-TLV:
flags = 0, IDCount = 2, IDs=4.20
FULLDATA-TLV, V= valueof(j1),valueof(j2)
// Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20
OPER = SET-TLV
Path-data-TLV:
flags = F_SELKEY, IDCount = 1, IDs=3
KEYINFO-TLV = KeyID=1 KEY_DATA=10
Path-data-TLV
flags = 0 IDCount = 1, IDs=2
FULLDATA-TLV, V= 20
Result:
//first operation, SET
OPER = SET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 3, IDs=4.20
RESULT-TLV code = success
FULLDATA-TLV, V = valueof(j1),valueof(j2)
// second operation SET - assuming entry 16 was updated
OPER = SET-RESPONSE-TLV
Path-data TLV
flags = 0 IDCount = 2, IDs=3.16
Path-Data TLV
flags = 0 IDCount = 1, IDs = 2
RESULT-TLV code = success
FULLDATA-TLV, Length = XXXX v=20
]]></artwork>
</figure>
<t>Selective setting. On table4 -- for indices 1, 3, 5, 7, and 9.
Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is.</t>
<figure>
<artwork><![CDATA[
PER = SET-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 6
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 5
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 7
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 9
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV, Length = XXXX, V = {300}
response:
OPER = SET-RESPONSE-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 6
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 5
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 7
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 9
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
]]></artwork>
</figure>
<t>Manipulation of table of table examples. Get x1 from table10 row
with index 4, inside table5 entry 10</t>
<figure>
<artwork><![CDATA[
operation = GET-TLV
Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
Results:
operation = GET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
FULLDATA-TLV: L=XXXX, V = valueof(x1)
]]></artwork>
</figure>
<t>From table5's row 10 table10, get X2s based on on the value of x1
equaling 10 (recall x1 is KeyID 1)</t>
<figure>
<artwork><![CDATA[
operation = GET-TLV
Path-data-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO-TLV, KeyID = 1, KEYDATA = 10
Path-data TLV
IDCount = 1, IDS = 2 //select x2
Results:
If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV
Path-data-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11
Path-data TLV
flags = 0 IDCount = 1, IDS = 2
FULLDATA-TLV: L=XXXX, V = valueof(x2)
]]></artwork>
</figure>
<t>Further example of manipulating a table of tables</t>
<!--
Weiming would like to update different items on a hierachy of data.
So this example is there to show how that can be done with the
current BNF.
-->
<figure>
<artwork><![CDATA[
Consider table6 which is defined as:
table6: type array, ID = 8
components are:
p1, type u32, ID = 1
p2, type array, ID = 2, array components of type type-A
type-A:
a1, type u32, ID 1,
a2, type array ID2 ,array components of type type-B
type-B:
b1, type u32, ID 1
b2, type u32, ID 2
If for example one wanted to set by replacing:
table6.10.p1 to 111
table6.10.p2.20.a1 to 222
table6.10.p2.20.a2.30.b1 to 333
in one message and one operation.
There are two ways to do this:
a) using nesting
b) using a flat path data
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
A. Method using nesting
in one message with a single operation
operation = SET-TLV
Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {111}
Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
FULLDATA-TLV: L=XXXX,
V = {222}
Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
B. Method using a flat path data in
one message with a single operation
operation = SET-TLV
Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1
FULLDATA-TLV: L=XXXX,
V = {111}
Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
FULLDATA-TLV: L=XXXX,
V = {222}
Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
FULLDATA-TLV: L=XXXX,
V = {333}
Result:
operation = SET-TLV
Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV
Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV
Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV
]]></artwork>
</figure>
<t>Get a whole LFB (all its components, etc.).</t>
<list style="hanging">
<t hangText="For example: ">at startup a CE might well want the
entire FE OBJECT LFB. So, in a request targeted at class 1, instance
1, one might find:</t>
</list>
<figure>
<artwork><![CDATA[
operation = GET-TLV
Path-data-TLV
flags = 0 IDCount = 0
result:
operation = GET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 0
FULLDATA-TLV encoding of the FE Object LFB
]]></artwork>
</figure>
</list>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:10 |