RFC 7391
Forwarding and Control Element Separation (ForCES) Protocol Extensions
RFC 7391 ✨ Forwarding and Control Element Separation (ForCES) Protocol Extensions
Okay bestie, this is RFC 7391 💖, a Standards Track doc from the IETF, dated October 2014. It was written by J. Hadi Salim at Mojatatu Networks, and its ISSN is 2070-1721. It updates RFC 5810 and RFC 7121 🎀. The header doesn't list anything it obsoletes.
Abstract 🌸
Okay so, people implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture kept running into the same needs 😭. They wanted a few small extensions to make programming easier and to make some transactions more efficient on the wire. So the ForCES protocol gets a table range operation and a new extension for error handling ✨. This doc updates the semantics in RFCs 5810 and 7121 to get there 💅.
Status of This Memo 🦋
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7391.
Copyright Notice 🌈
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction ....................................................2
1.1. Terminology and Conventions ................................3
1.1.1. Requirements Language ...............................3
1.1.2. Terminology .........................................3
2. Problem Overview ................................................4
2.1. Table Ranges ...............................................4
2.2. Error Codes ................................................4
3. Protocol Update .................................................5
3.1. Table Ranges ...............................................5
3.2. Error Codes ................................................6
3.2.1. New Codes ...........................................7
3.2.2. Private Vendor Codes ................................8
3.2.3. Extended Result TLV .................................8
3.2.3.1. Extended Result Backward Compatibility .....9
3.3. Large Table Dumping ........................................9
4. IANA Considerations ............................................11
5. Security Considerations ........................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
Appendix A. New FEPO Version ......................................13
Acknowledgments ...................................................23
Author's Address ..................................................231. Introduction 🍓
Okay, so the ForCES architecture folks have been implementing and deploying it, and they keep saying it needs a few small extensions. The goals are to ease programmability and to improve wire efficiency of some transactions 🫶. This doc describes a few extensions to the semantics in the ForCES protocol specification [RFC5810] to get that done ✨.
This document describes and justifies the need for two small extensions that are backward compatible 💜. It also clarifies how dumping a large table that lives on an FE (Forwarding Element) actually works 🔥. Here's the tea:
- A table range operation is introduced, so a controller or control application can request an arbitrary range of table rows 🌸.
- Additional error codes are introduced, which an FE returns to the controller (or control application). A new extension to carry details on error codes is introduced too. Because of this, the doc updates the definition of the FE Protocol Object (FEPO) Logical Functional Block (LFB) in [RFC7121] 👑.
- Even though it's already supported, an FE response to a GET request for a large table that doesn't fit in a single Protocol Layer (PL) message isn't described in [RFC5810]. This document clears that up 🙈.
1.1. Terminology and Conventions 💅
1.1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.1.2. Terminology 🧠
This document repeats the terminology defined in several ForCES documents ([RFC3746], [RFC5810], [RFC5811], and [RFC5812]) so everyone stays on the same page 📖.
- Control Element (CE)
- Forwarding Element (FE)
- FE Model
- LFB (Logical Functional Block) Class (or type)
- LFB Instance
- LFB Model
- LFB Metadata
- ForCES Component
- LFB Component
- ForCES Protocol Layer (ForCES PL)
- ForCES Protocol Transport Mapping Layer (ForCES TML)
2. Problem Overview 🔍
This section shows some sample use cases so you can see each challenge being addressed 👀.
2.1. Table Ranges 🎀
Let's imagine, just for illustration, an FE table with 1 million reasonably sized table rows that are sparsely populated. Let's also imagine there are 2000 table rows sparsely populated between the row indices 23-10023 ✨.
Implementation experience has shown that the existing ways of retrieving or deleting a sizable number of table rows are both programmatically tedious and inefficient when it comes to compute and wire resources 😩.
By definition, ForCES GET and DEL requests sent from a controller (or control application) are prepended with a path to a component and sent to the FE. For indexed tables, the component path can point to either a table or a table row index 🧚.
Say a control application wants to retrieve the first 2000 table rows appearing between row indices 23 and 10023. It can get there in one of these ways:
- Dump the whole table and filter for the needed 2000 table rows.
- Send up to 10000 ForCES PL requests, incrementing the index by one each time, and stop when the needed 2000 entries are retrieved.
- If the application knows which table rows exist (not unreasonable, since the controller is supposed to be aware of state within a Network Element (NE)), then it can use ForCES batching to send fewer large messages, each with different path entries for a total of 2000.
As argued, while those options exist, they're all tedious 😤.
2.2. Error Codes 🚨
[RFC5810] defined a generic set of error codes that an FE returns to the CE. Deployment experience has shown that more fine-grained error codes would be useful 💡. For example, the error code E_NOT_SUPPORTED could map to many possible FE error sources, which the caller then has to interpret based on what it knows about the nature of the request it sent. That makes debugging way more time consuming 💀.
3. Protocol Update 🦋
This section describes a normative update to the ForCES protocol to address the issues discussed in Section 2 💖.
3.1. Table Ranges 🎀
okay so we're introducing a brand new TLV called TABLERANGE-TLV (type ID 0x0117) 🦋 It gets attached to PATH-DATA-TLV the same way KEYINFO-TLV does, so if you already know that one you're basically there. Figure 1 shows how it's built:
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 (0x0117) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ForCES Table Range Request LayoutFigure 2 is a GET for rows 11 to 23 of a table sitting at component path "1/6" 💖
OPER = GET-TLV
PATH-DATA-TLV:
flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6}
TABLERANGE-TLV content = {11,23}
Figure 2: ForCES Table Range Request ExampleNow the path flag. F_SELTABRANGE is 0x2 (that's bit 1, and bit 0 is F_SELKEY from [RFC5810]) and it MUST be set to say the TABLERANGE-TLV is there 🫶 It can only be used in a GET or DEL, and it's mutually exclusive with F_SELKEY, so they can never be besties on the same request 🙈 The FE MUST enforce the path flag constraints and make sure the selected path belongs to a defined, indexed table component 👑 Any violation MUST be rejected with an error code of E_INVALID_TFLAGS, plus a description of what went wrong when extended error reporting is being used (see Section 3.2).
It should be noted that some combos should not hang out together, just to keep operations simple 🧚 That includes TABLERANGE-TLV with KEYINFO-TLV, and multiple nested TABLERANGE-TLVs.
The TABLERANGE-TLV contents are:
- A 32-bit start index. An index of 0 implies the beginning of the table row.
- A 32-bit end index. A value of 0xFFFFFFFF implies the last entry.
And the response to a table range query will either be:
- The requested table data returned (when at least one referenced row is available). In that case, a response with a path pointing to the table, whose data content contains the row(s), gets sent to the CE. The data content MUST be encapsulated in a SPARSEDATA-TLV. The SPARSEDATA-TLV content will have the "I" (in Index-Length-Value (ILV)) for each table row, indicating the table indices. 🍓
- An EXTENDEDRESULT-TLV (refer to Section 3.2.3) when:
- The response is to a range delete request. The result will either be:
- a success, if any of the rows that were requested are deleted; or
- a proper error code, if none of the rows that were requested can be deleted.
- Data is absent and an error code of E_EMPTY is used, with an optional content string describing the nature of the error (refer to Section 3.2).
- Both a path key and path table range were stated on the path flags of the original request. In that case, an error code of E_INVALID_TFLAGS is used, with an optional content string describing the nature of the error (refer to Section 3.2). not it! 💀
- Other standard ForCES errors occur, such as Access Control List (ACL) constraints trying to retrieve contents of an unreadable table, accessing unknown components, etc.
- The response is to a range delete request. The result will either be:
3.2. Error Codes 🌸
Here's what we're adding in this section:
- A new set of error codes.
- Allocation of some reserved codes for private use.
- A new TLV, EXTENDEDRESULT-TLV (0x0118), that carries a code (which will be a superset of what is currently specified in [RFC5810]) as well as an optional cause content. This is illustrated in Figure 3.
3.2.1. New Codes ✨
The EXTENDEDRESULT-TLV Result Value is 32 bits, and it's a superset of the RESULT-TLV Result Value defined in [RFC5810]. The new version code space is 32 bits, as opposed to the 8-bit code size in [RFC5810]. The first 8-bit values (256 codes) are common to both code spaces. 💅
+------------+-------------------------+----------------------------+
| Code | Mnemonic | Details |
+------------+-------------------------+----------------------------+
| 0x18 | E_TIMED_OUT | A timeout occurred while |
| | | processing the message |
| | | |
| 0x19 | E_INVALID_TFLAGS | Invalid table flags |
| | | |
| 0x1A | E_INVALID_OP | Requested operation is |
| | | invalid |
| | | |
| 0x1B | E_CONGEST_NT | Node congestion |
| | | notification |
| | | |
| 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table |
| | | |
| 0x1D | E_PERM | Operation not permitted |
| | | |
| 0x1E | E_BUSY | System is busy |
| | | |
| 0x1F | E_EMPTY | Table is empty |
| | | |
| 0x20 | E_UNKNOWN | A generic catch-all error |
| | | code. Carries a string to |
| | | further extrapolate what |
| | | the error implies. |
+------------+-------------------------+----------------------------+
Table 1: New Codes3.2.2. Private Vendor Codes 🦋
Codes 0x100-0x200 are reserved for use as private codes. Since these are freely available, it is expected that the FE and CE side implementations will both understand/interpret the semantics of any used codes and avoid any conflicts. 🫶
3.2.3. Extended Result TLV 👑
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 = EXTENDEDRESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Cause Content |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXTENDEDRESULT-TLVSome key facts about this TLV:
- Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to be 32-bit aligned.
- The EXTENDEDRESULT-TLV Result Value derives and extends from the same current namespace used by the RESULT-TLV Result Value, as specified in Section 7.1.7 of [RFC5810]. The main difference is that the Result Value is now 32 bits (instead of the old 8-bit one).
- The Optional Cause Content is there to further disambiguate the Result Value. It is expected that UTF-8 string values will be used. The content is meant to be read by the (human) operator, and implementations may choose to specify different content for the same error code. Future codes may also specify cause content of types other than string.
- It is recommended that the maximum size of the cause string should not exceed 32 bytes. The cause string is not standardized by this document. 📏
3.2.3.1. Extended Result Backward Compatibility 🌈
To support backward compatibility, we update the FEPO LFB (in Appendix A) to version 1.2. We also add a new component ID 16 (named EResultAdmin), and a capability component ID 32 (named EResultCapab).
An FE advertises its ability to support extended TLVs via the EResultCapab table. When an FE can respond with both extended results and older result TLVs, it has two table rows, one for each supported value. By default, an FE that supports both modes assumes the lowest common denominator (i.e., EResultAdmin will be EResultNotSupported) and issues responses using RESULT-TLVs. It should be noted that an FE advertising FEPO version 1.2 MUST support EXTENDEDRESULT-TLVs at minimum. 🧠
On an FE that supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a master CE can turn on extended results by setting the EResultAdmin value to 2. When that happens, the FE MUST switch over to sending only EXTENDEDRESULT-TLVs. Likewise, a master CE can turn extended result responses off by writing a 1 to the EResultAdmin. An FE that does not support one mode or the other MUST reject setting EResultAdmin to a value it doesn't support, by responding with an error code of E_NOT_SUPPORTED. 🙅♀️ It is expected that all CEs participating in a high availability (HA) mode be capable of supporting FEPO version 1.2 whenever EResultAdmin is set to strict support of EXTENDEDRESULT-TLVs. The consensus between CEs in an HA set up to set strict support of EXTENDEDRESULT-TLVs is out of scope for this document. 🤝
3.3. Large Table Dumping 🎀
Okay so imagine sending a GET request to a path that's a table, aka a table dump 🧚. That request goes to the FE with a specific correlator, let's call it X. Now picture that table having a massive number of entries at the FE. For the sake of illustration, let's say millions of rows 😭. That means the FE has to deliver the response over multiple messages, all using the same correlator X.
Bestie, the ForCES protocol document [RFC5810] doesn't really spell out how a large multi-part GET response gets delivered 🙈, so this section is here to clear that up. We're only talking about table objects here 💅.
Implementers who've dumped big tables already figured this out: you can use transaction flags to say whether a GET response is the beginning, middle, or end of a multi-part message 🔥. Basically, we copy the vibe of an atomic transaction that a CE sends to an FE 🦋.
CE PL FE PL
| |
| (0) Query, Path-to-a-large-table, OP=GET |
|----------------------------------------------------->|
| correlator = X |
| |
| (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
. .
. .
. .
. .
| |
| (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (N) Query-Response, EOT,AT, OP=GET-RESPONSE |
|<-----------------------------------------------------|
| correlator = X |
| RESULT-TLV (SUCCESS) |
| |
Figure 4: Large Table Dump Time SequenceThe very last message heading to the CE, the one carrying the End Of Transaction (EOT) flag, MUST NOT carry any data 🛑. That's how we mirror ForCES two-phase commit (2PC) messaging [RFC5810], where the final message is an empty commit message 🍓. And in that case, the GET response carries a RESULT-TLV ✨.
4. IANA Considerations 📝
This document updates <https://www.iana.org/assignments/forces> as follows:
Okay, the registry tea ☕: this document registers two new top-level TLVs and two new path flags, and it also updates an IANA-registered FE Protocol Object Logical Functional Block (LFB).
Appendix A defines an update to the FE Protocol Object LFB to version 1.2. An entry for FE Protocol Object LFB version 1.2 has been added to the "Logical Functional Block (LFB) Class Names and Class Identifiers" sub-registry 🌸.
The following new TLVs have been defined and added to the "TLV Types" sub-registry:
TABLERANGE-TLV (type ID 0x0117)EXTENDEDRESULT-TLV (type ID 0x0118)
The "RESULT-TLV Result Values" sub-registry has been updated as follows:
- Codes
0x21-0xFEare marked as Unassigned. - Codes
0x18-0x20are defined by this document in Section 3.2.1. - Codes
0x100-0x200are reserved for private use.
A new "EXTENDEDRESULT-TLV Result Values" sub-registry has been created 🎀. The codes 0x00-0xFF are mirrored from the "RESULT-TLV Result Values" sub-registry. Any future allocations of this code range (in the range 0x21-0xFE) must be made only in the new "EXTENDEDRESULT-TLV Result Values" sub-registry, and not in the "RESULT-TLV Result Values" sub-registry. The codes 0x100-0x200 are reserved for private use as described earlier, and the code ranges 0x21-0xFE and 0x201-0xFFFFFFFF are marked as Unassigned with the IANA allocation policy of Specification Required [RFC5226].
The Designated Expert (DE) needs to ensure that existing deployments are not broken by any specified request 🫶. The DE should post a given code request to the ForCES WG mailing list (or a successor designated by the Area Director) for comment and review. The DE should then either approve or deny the registration request, publish a notice of the decision to the ForCES WG mailing list or its successor, and inform IANA of his/her decision. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable. No rejections without receipts, bestie 💅.
5. Security Considerations 🚨
Okay, this part is SERIOUS, so pay attention 🔐. The security considerations described in the ForCES protocol [RFC5810] apply to this document as well. Do not skip this one 💀.
6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010,
<http://www.rfc-editor.org/info/rfc5810>.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", RFC 5811, March 2010,
<http://www.rfc-editor.org/info/rfc5811>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010, <http://www.rfc-editor.org/
info/rfc5812>.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
"High Availability within a Forwarding and Control Element
Separation (ForCES) Network Element", RFC 7121,
February 2014, <http://www.rfc-editor.org/info/rfc7121>.6.2. Informative References
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004,
<http://www.rfc-editor.org/info/rfc3746>.Appendix A. New FEPO Version ✨
Okay, the FEPO glow-up 💜. This version of FEPO updates the earlier one given in [RFC7121]. The XML has been validated against the schema defined in [RFC5812] 🦋.
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="lfb-schema.xsd" 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 will send heartbeats to the FE
every CEHDI timeout if no other messages
have been sent since.
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE will not send heartbeats to the FE.
</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 will not generate any heartbeats to the CE.
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE generates heartbeats to the CE every
FEHI if no other
messages have been sent to the CE.
</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 restarts its state from scratch.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>HAModeValues</name>
<synopsis>
The possible values of HA modes
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>NoHA</name>
<synopsis>
The FE is not running in HA mode.
</synopsis>
</specialValue>
<specialValue value="1">
<name>ColdStandby</name>
<synopsis>
The FE is running in HA mode cold standby.
</synopsis></specialValue> <specialValue value="2"> <name>HotStandby</name> <synopsis> The FE is running in HA mode hot standby. </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 FE should stop functioning immediately and transition to FE OperDisable state. </synopsis> </specialValue> <specialValue value="1"> <name>CEFailoverPolicy1</name> <synopsis> The FE should continue forwarding even without an associated CE for CEFTI. The FE goes to FE OperDisable when the CEFTI expires and there is no association. Requires graceful restart support. </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> <dataTypeDef> <name>CEStatusType</name> <synopsis>Status values. Status for each CE</synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>Disconnected</name> <synopsis>No connection attempt with the CE yet </synopsis> </specialValue> <specialValue value="1"> <name>Connected</name> <synopsis>The FE connection with the CE at the TML has been completed. </synopsis> </specialValue> <specialValue value="2"> <name>Associated</name> <synopsis>The FE has associated with the CE. </synopsis> </specialValue> <specialValue value="3"> <name>IsMaster</name> <synopsis>The CE is the master (and associated). </synopsis> </specialValue> <specialValue value="4"> <name>LostConnection</name> <synopsis>The FE was associated with the CE but lost the connection. </synopsis> </specialValue> <specialValue value="5"> <name>Unreachable</name> <synopsis>The CE is deemed as unreachable by the FE. </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>StatisticsType</name> <synopsis>Statistics Definition</synopsis> <struct> <component componentID="1"> <name>RecvPackets</name> <synopsis>Packets received</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="2"> <name>RecvErrPackets</name> <synopsis>Packets received from CE with errors </synopsis> <typeRef>uint64</typeRef> </component> <component componentID="3"> <name>RecvBytes</name> <synopsis>Bytes received from CE</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="4"> <name>RecvErrBytes</name> <synopsis>Bytes received from CE in error</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="5"> <name>TxmitPackets</name> <synopsis>Packets transmitted to CE</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="6"> <name>TxmitErrPackets</name> <synopsis> Packets transmitted to CE that incurred errors </synopsis> <typeRef>uint64</typeRef> </component> <component componentID="7"> <name>TxmitBytes</name> <synopsis>Bytes transmitted to CE</synopsis> <typeRef>uint64</typeRef>
</component> <component componentID="8"> <name>TxmitErrBytes</name> <synopsis>Bytes transmitted to CE incurring errors </synopsis> <typeRef>uint64</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>AllCEType</name> <synopsis>Table Type for AllCE component</synopsis> <struct> <component componentID="1"> <name>CEID</name> <synopsis>ID of the CE</synopsis> <typeRef>uint32</typeRef> </component> <component componentID="2"> <name>Statistics</name> <synopsis>Statistics per CE</synopsis> <typeRef>StatisticsType</typeRef> </component> <component componentID="3"> <name>CEStatus</name> <synopsis>Status of the CE</synopsis> <typeRef>CEStatusType</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>ExtendedResultType</name> <synopsis> Possible extended result support </synopsis> <atomic> <baseType>uchar</baseType> <rangeRestriction> <allowedRange min="1" max="2"/> </rangeRestriction> <specialValues> <specialValue value="1"> <name>EResultNotSupported</name> <synopsis> Extended results are not supported. </synopsis> </specialValue> <specialValue value="2">
<name>EResultSupported</name> <synopsis> Extended results are supported. </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> </dataTypeDefs> <LFBClassDefs> <LFBClassDef LFBClassID="2"> <name>FEPO</name> <synopsis> The FE Protocol Object, with extended result control </synopsis> <version>1.2</version> <components> <component componentID="1" access="read-only"> <name>CurrentRunningVersion</name> <synopsis>Currently running ForCES version</synopsis> <typeRef>uchar</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 milliseconds </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 milliseconds </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 milliseconds </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>
<component componentID="14" access="read-write">
<name>HAMode</name>
<synopsis>
The HA mode used
</synopsis>
<typeRef>HAModeValues</typeRef>
</component>
<component componentID="15" access="read-only">
<name>AllCEs</name>
<synopsis>The table of all CEs</synopsis>
<array type="variable-size">
<typeRef>AllCEType</typeRef>
</array>
</component>
<component componentID="16" access="read-write">
<name>EResultAdmin</name>
<synopsis>
Turn extended results off or on,
but default to off.
</synopsis>
<typeRef>ExtendedResultType</typeRef>
<defaultValue>1</defaultValue>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
The table of ForCES versions that FE supports
</synopsis>
<array type="variable-size">
<typeRef>uchar</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>
<capability componentID="32">
<name>EResultCapab</name>
<synopsis>
The table of supported result capabilities
</synopsis>
<array type="variable-size">
<typeRef>ExtendedResultType</typeRef>
</array>
</capability>
</capabilities>
<events baseID="61">
<event eventID="1">
<name>PrimaryCEDown</name>
<synopsis>
The primary CE has changed.
</synopsis>
<eventTarget>
<eventField>LastCEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>LastCEID</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>PrimaryCEChanged</name>
<synopsis>A new primary CE has been selected.
</synopsis>
<eventTarget>
<eventField>CEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>CEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>Acknowledgments 🫶
okay bestie, big thank-you-s go out to Evangelos Haleplidis and Joel Halpern, whose chats made this doc way better 💖 Adrian Farrel gave it an absolutely iconic AD review that leveled up the quality 🔥 Tobias Gondrom handled the Security Directorate review 🔐 Brian Carpenter did the Gen-ART review 🌸 Nevil Brownlee took care of the Operations Directorate review 🧚 S. Moonesamy (SM) put in the work reviewing our publication process 💅 and Pearl Liang caught issues in the IANA text 🎀
the author also wants to thank the IESG members who reviewed and improved this document: Alia Atlas, Barry Leiba, Brian Haberman, Kathleen Moriarty, Richard Barnes, and Spencer Dawkins ✨👑
Author's Address 🦋
here's where you can find the author ✨
Jamal Hadi Salim
Mojatatu Networks
Suite 400, 303 Moodie Dr.
Ottawa, Ontario K2H 9R4
Canada
EMail: hadi@mojatatu.com📦 where this page comes from
- ietf: rfc7391 2014-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms