RFC 5810
Forwarding and Control Element Separation (ForCES) Protocol Specification
Forwarding and Control Element Separation (ForCES) Protocol Specification ✨
Part 1 of 22 🎀
okay bestie, this one is the ForCES protocol spec, RFC 5810, and it's a Standards Track doc, so it's the real deal 💅. It came out in March 2010 and its status is ISSN 2070-1721 🌸. The authors are A. Doria (Ed.) from Lulea University of Technology, J. Hadi Salim (Ed.) from Znyx, R. Haas (Ed.) from IBM, H. Khosravi (Ed.) from Intel, W. Wang (Ed.) plus L. Dong from Zhejiang Gongshang University, R. Gopal from Nokia, and J. Halpern 🧚. This header doesn't list anything it obsoletes or updates, so there's no older RFC it's replacing.
Abstract 💜
so this doc specifies the ForCES protocol, which handles the chats between Control Elements (CEs) and Forwarding Elements (FEs) inside a ForCES Network Element (ForCES NE) 🦋. It's designed to meet the ForCES protocol requirements from RFC 3654. And on top of the protocol, it also lays out the requirements for the Transport Mapping Layer (TML) ✨.
Status of This Memo 🍓
this is an Internet Standards Track document 🔥.
it's a product of the Internet Engineering Task Force (IETF), so it reflects consensus across the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 👑.
info on the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5810 🌈.
Copyright Notice 🌸
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. please read those carefully, because they spell out your rights and restrictions for this doc 🙈. if you pull Code Components out of this doc, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as that license says 🔥.
Table of Contents 🧚
1. Introduction ....................................................5
2. Terminology and Conventions .....................................6
2.1. Requirements Language ......................................6
2.2. Other Notation .............................................6
2.3. Integers ...................................................6
3. Definitions .....................................................6
4. Overview .......................................................10
4.1. Protocol Framework ........................................11
4.1.1. The PL .............................................13
4.1.2. The TML ............................................14
4.1.3. The FEM/CEM Interface ..............................14
4.2. ForCES Protocol Phases ....................................15
4.2.1. Pre-association ....................................16
4.2.2. Post-association ...................................18
4.3. Protocol Mechanisms .......................................19
4.3.1. Transactions, Atomicity, Execution, and Responses ..19
4.3.2. Scalability ........................................25
4.3.3. Heartbeat Mechanism ................................26
4.3.4. FE Object and FE Protocol LFBs .....................27
4.4. Protocol Scenarios ........................................27
4.4.1. Association Setup State ............................27
4.4.2. Association Established State or Steady State ......29
5. TML Requirements ...............................................31
5.1. TML Parameterization ......................................34
6. Message Encapsulation ..........................................35
6.1. Common Header .............................................35
6.2. Type Length Value (TLV) Structuring .......................40
6.2.1. Nested TLVs ........................................41
6.2.2. Scope of the T in TLV ..............................41
6.3. ILV .......................................................41
6.4. Important Protocol Encapsulations .........................42
6.4.1. Paths ..............................................42
6.4.2. Keys ...............................................42
6.4.3. DATA TLVs ..........................................43
6.4.4. Addressing LFB Entities ............................43
7. Protocol Construction ..........................................44
7.1. Discussion on Encoding ....................................48
7.1.1. Data Packing Rules .................................48
7.1.2. Path Flags .........................................49
7.1.3. Relation of Operational Flags with Global
Message Flags ......................................49
7.1.4. Content Path Selection .............................49
7.1.5. LFBselect-TLV ......................................49
7.1.6. OPER-TLV ...........................................50
7.1.7. RESULT TLV .........................................52
7.1.8. DATA TLV ...........................................55
7.1.9. SET and GET Relationship ...........................56
7.2. Protocol Encoding Visualization ...........................56
7.3. Core ForCES LFBs ..........................................59
7.3.1. FE Protocol LFB ....................................60
7.3.2. FE Object LFB ......................................63
7.4. Semantics of Message Direction ............................63
7.5. Association Messages ......................................64
7.5.1. Association Setup Message ..........................64
7.5.2. Association Setup Response Message .................66
7.5.3. Association Teardown Message .......................68
7.6. Configuration Messages ....................................69
7.6.1. Config Message .....................................69
7.6.2. Config Response Message ............................71
7.7. Query Messages ............................................73
7.7.1. Query Message ......................................73
7.7.2. Query Response Message .............................75
7.8. Event Notification Message ................................77
7.9. Packet Redirect Message ...................................79
7.10. Heartbeat Message ........................................82
8. High Availability Support ......................................83
8.1. Relation with the FE Protocol .............................83
8.2. Responsibilities for HA ...................................86
9. Security Considerations ........................................87
9.1. No Security ...............................................87
9.1.1. Endpoint Authentication ............................88
9.1.2. Message Authentication .............................88
9.2. ForCES PL and TML Security Service ........................88
9.2.1. Endpoint Authentication Service ....................88
9.2.2. Message Authentication Service .....................89
9.2.3. Confidentiality Service ............................89
10. Acknowledgments ...............................................89
11. References ....................................................89
11.1. Normative References .....................................89
11.2. Informative References ...................................90
Appendix A. IANA Considerations ..................................91
A.1. Message Type Namespace ....................................91
A.2. Operation Selection .......................................92
A.3. Header Flags ..............................................93
A.4. TLV Type Namespace ........................................93
A.5. RESULT-TLV Result Values ..................................94
A.6. Association Setup Response ................................94
A.7. Association Teardown Message ..............................95
Appendix B. ForCES Protocol LFB Schema ...........................96
B.1. Capabilities .............................................102
B.2. Components ...............................................102
Appendix C. Data Encoding Examples ..............................103
Appendix D. Use Cases ...........................................1071. Introduction 🎀
okay so Forwarding and Control Element Separation (ForCES) is basically a framework plus protocols that standardize how the control plane and the forwarding plane swap info inside a ForCES Network Element (ForCES NE) 💅. RFC 3654 set the ForCES requirements and RFC 3746 wrote the ForCES framework 🌸. a ForCES network can run more than one protocol, but in this doc, "ForCES protocol" and "protocol" only mean the one that handles info exchange between Control Elements (CEs) and Forwarding Elements (FEs) 🫶.
the ForCES FE model [RFC5812] gives you a formal way to define FE Logical Function Blocks (LFBs) using XML 🧚. LFB configuration components, capabilities, and associated events get defined when the LFB is formally created ✨. so the LFBs inside an FE are controlled in a standardized way by the ForCES protocol, which is giving very organized energy 💖.
this doc is where the ForCES protocol gets defined 🦋. the vibe is master-slave: FEs are the slaves and CEs are the masters 👑. the protocol has commands for moving LFB configuration info around, plus association setup, status, event notifications, and more 🔥.
Section 3 is the glossary, so check there for the terms 🍓.
Section 4 is the big overview 🌈. it covers the protocol framework, the Protocol Layer (PL), a Transport Mapping Layer (TML), and the ForCES protocol mechanisms 💜. Section 4.4 walks through a few protocol scenarios and the message exchanges in them 🙈.
this doc doesn't define the TML itself, but Section 5 spells out the services a TML MUST provide (that's the TML requirements) 🔥. the key word there is MUST, so it's non-negotiable, bestie 💅.
the ForCES protocol has one common header for every protocol message 🌸. the header is in Section 6.1 and the messages are in Section 7 🫶.
Section 8 covers the protocol support for high-availability stuff, like redundancy and fail over 👑.
Section 9 is where the security mechanisms from the PL and TML live 🔐💖.
2. Terminology and Conventions 💅
the next part picks up right here, so stay tuned, bestie 🧚✨
2.1. Requirements Language 💅
okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] describes. no cap, these are the words that decide how strict a rule is 🫶
2.2. Other Notation 🦋
in Table 1 and Table 2, we use this little notation to show how many of something there can be:
(value)+ .... means "1 or more instances of value"
(value)* .... means "0 or more instances of value"2.3. Integers 🔢
all integers are coded as unsigned binary integers of appropriate length. simple, clean, iconic 💖
3. Definitions 🎀
bestie, this document uses the same terminology as the ForCES requirements in [RFC3654] and the ForCES framework in [RFC3746]. we're repeating the definitions down here so you don't have to flip around 📖✨
Addressable Entity (AE):
A physical device that's directly addressable given some interconnect technology. like, on IP networks it's a device you reach with an IP address, and on a switch fabric it's a device you reach with a switch fabric port number 🌸
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 stuff like running control and signaling protocols. they're the boss energy 👑
CE Manager (CEM):
A logical entity in charge of generic CE management tasks. it's especially used during the pre-association phase to figure out which FE(s) a CE should talk to. this is called FE discovery, and it can involve the CE manager learning what the available FEs are capable of 🧚
Data Path:
The conceptual path that packets take inside the forwarding plane of an FE. 🌊
Forwarding Element (FE):
A logical entity that implements the ForCES protocol. FEs use the underlying hardware to do per-packet processing and handling, as directed or controlled by one or more CEs through the ForCES protocol 💅
FE Model:
A model that describes the logical processing functions of an FE. it's defined using Logical Function Blocks (LFBs) 🧩
FE Manager (FEM):
A logical entity responsible for generic FE management tasks. it's used during the pre-association phase to figure out which CE(s) an FE should talk to. this is called CE discovery, and it can involve the FE manager learning what the available CEs are capable of. an FE manager can use anything from a static configuration to a pre-association phase protocol (see below) to pick its CE(s). and since it's a logical entity, it might be physically combined with other logical entities like FEs 🦋
ForCES Network Element (NE):
An entity made up of one or more CEs and one or more FEs. to entities outside an NE, the NE looks like a single point of management. it also usually hides its internal organization from outside entities. mysterious and iconic 🌙
High Touch Capability:
This term applies to the capabilities some forwarders have for acting on the contents or headers of a packet based on content other than what's in the IP header. examples include quality of service (QoS) policies, virtual private networks, firewalls, and L7 content recognition 🔥
Inter-FE Topology:
See FE Topology.
Intra-FE Topology:
See LFB Topology.
LFB (Logical Function Block):
The basic building block that the ForCES protocol operates on. it's a well-defined, logically separable functional block that lives in an FE and is controlled by the CE through the ForCES protocol. an LFB might sit on the FE's data path and process packets, or it might be purely an FE control or configuration entity that the CE operates on. just know that the LFB is a functionally accurate abstraction of the FE's processing capabilities, but NOT a hardware-accurate picture of how the FE is actually built 🤓
FE Topology:
a representation of how the multiple FEs inside a single NE are interconnected. sometimes it's called inter-FE topology, to tell it apart from intra-FE topology (aka LFB topology) 🕸️
LFB Class and LFB Instance:
LFBs are sorted into LFB classes. an LFB instance represents the existence of an LFB class (or type). there can be multiple instances of the same LFB class (or type) in one FE. a class gets an LFB class ID, an instance gets an LFB instance ID, and put together, an LFB class ID plus an LFB instance ID uniquely pin down one LFB's existence 💜
LFB Meta Data:
meta data passes per-packet state from one LFB to another, but it never gets sent across the network. the FE model defines how this meta data is identified, produced, and consumed by the LFBs. it covers the functionality, not how the meta data gets encoded inside an implementation 🎀
LFB Component:
the operational parameters of the LFBs that the CEs need to be able to see are conceptualized in the FE model as LFB components. these include things like flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write through the ForCES protocol (see below) 🧁
LFB Topology:
a representation of how LFB instances are logically interconnected and placed along the data path inside one FE. it's sometimes called intra-FE topology, to tell it apart from inter-FE topology 🌈
Pre-association Phase:
the stretch of time when an FE manager and a CE manager are figuring out which FE(s) and CE(s) should be part of the same network element ⏳
Post-association Phase:
the stretch of time when an FE knows which CE is going to control it, and the other way around. this also includes the time when the CE and FE are setting up communication with each other 🤝
ForCES Protocol:
there can be multiple protocols in the overall ForCES architecture, but "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES framework in [RFC3746]. this protocol doesn't cover CE-to-CE communication, FE-to-FE communication, or communication between FE and CE managers. basically it works in a master-slave mode, where FEs are the slaves and CEs are the masters. this document defines the specifications for this ForCES protocol 👑💅
ForCES Protocol Layer (ForCES PL):
a layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself (including the requirements of the ForCES TML, as shown below). this document is where the ForCES PL specifications live 📜
ForCES Protocol Transport Mapping Layer (ForCES TML):
a layer in the ForCES protocol architecture that uses the capabilities of existing transport protocols to handle message transport. it deals with how protocol messages get mapped onto different transport media (like TCP, IP, ATM, Ethernet, etc.), and how to achieve and implement reliability, multicast, ordering, and so on. the ForCES TML specifications are detailed in separate ForCES documents, one for each TML 🚚
4. Overview ✨
the reader is pointed to the framework document [RFC3746], especially Sections 3 and 4, for an architectural overview and an explanation of how the ForCES protocol fits in. there might be some overlap in content between the framework document and this section, just to keep things clear 🫶 this document is the authority on the protocol, and [RFC3746] is the authority on the architecture 🌸
4.1. Protocol Framework ✨
Okay bestie, let's look at the big picture 🦋 Figure 1 is copied over from the framework document so we can see the setup. It shows one NE with two CEs and two FEs 💅
---------------------------------------
| 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
Figure 1: ForCES Architectural DiagramSo the ForCES protocol domain lives in the Fp reference points 🎀 The Protocol Element configuration reference points, Fc and Ff, also help get the ForCES protocol booted up 🌸 The protocol element configuration (the stuff marked Fc, Ff, and Fl in [RFC3746]) is out of scope of ForCES itself, but this document still talks about it a bit, since it's a huge part of the pre-association phase, and FEM and CEM both show up there 🧚
Figure 2 zooms in on the Fp interfaces, using an MPLS QoS-enabled Network Element as the example 💜
-------------------------------------------------
| | | | | | |
|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 | |
-------------------------------------------------
Figure 2: Examples of CE and FE FunctionsThe ForCES interface in Figure 2 is made of two pieces: the PL and the TML 🍓 Figure 3 shows how they stack up 👑
+------------------------------------------------
| CE PL |
+------------------------------------------------
| CE TML |
+------------------------------------------------
^
|
ForCES | (i.e., ForCES data + control
PL | packets )
messages |
over |
specific |
TML |
encaps |
and |
transport |
|
v
+------------------------------------------------
| FE TML |
+------------------------------------------------
| FE PL |
+------------------------------------------------
Figure 3: ForCES InterfaceThe PL is literally the ForCES protocol 😭 Its semantics and message layout are defined in this document. The TML layer is what connects two ForCES PLs, as Figure 3 shows ✨ The TML is out of scope for this document, but it is still within scope of ForCES. This document defines the requirements the PL needs the TML to meet 🫶
Both the PL and the TML are standardized by the IETF. Only one PL is defined, but several TMLs are expected to get standardized 🌈 For things to interoperate, the TML at the CE and the TML at the FE are expected to conform to the same definition 💅
Here's the flow: on transmit, the PL hands 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. Simple, iconic 🔥
4.1.1. The PL
The PL is common to all ForCES implementations, and it's standardized by the IETF as defined in this document 💖 The PL is responsible for associating an FE or CE to an NE, and it's also responsible for tearing down those associations 🙈 An FE uses the PL to send various subscribed-to events to the CE PL, and to respond to status requests coming from the CE PL 🦋 The CE configures both the FE and its associated LFBs' operational parameters using the PL 🎀 On top of that, the CE may send the FE requests to activate or deactivate it, reconfigure its HA parameterization, subscribe to specific events, etc. 🌸 More details are in Section 7 🧚
4.1.2. The TML
The TML is the one that transports the PL messages 💜 This is where the big stuff gets handled: transport-level reliability, congestion control, multicast, ordering, etc. 👑 More than one TML is expected to be standardized 🌈 The different possible TMLs can vary their implementations based on the capabilities of the underlying media and transport ✨ Since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML 🫶 Now the important part, bestie 😭 All ForCES protocol layer implementations MUST be portable across all TMLs, because all TMLs MUST have the top-edge semantics defined in this document 🔥
4.1.3. The FEM/CEM Interface
The FEM and CEM components are super valuable for setting up and configuring both the PL and the TML, but they're out of scope of the ForCES protocol 💅 The best way to think about them is as configurations or parameterizations for the PL and TML before they become active (or even at runtime, depending on the implementation) 🎀 In the simplest case, the FE or CE just reads a static configuration file 🌸 RFC 3746 has a more detailed description of how the FEM and CEM could be used 🦋 The pre-association phase, where the CEM and FEM can be used, is described briefly in Section 4.2.1 🧚
An example of the typical things the FEM/CEM could configure is TML-specific parameterizations such as:
- a. How the TML connection should happen (for example, what IP addresses to use, transport modes, etc.)
- b. The ID for the FE (FEID) or CE (CEID) (which would also be issued during the pre-association phase)
- c. Security parameterization such as keys, etc.
- d. Connection association parameters
An example of connection association parameters might be:
- simple parameters: send up to 3 association messages every 1 second
- complex parameters: send up to 4 association messages with increasing exponential timeout
4.2. ForCES Protocol Phases 🌈
Okay, so in relation to NEs, ForCES has two phases 💖 First there's the pre-association phase, where configuration, initialization, and bootup of the TML and PL layers happen 🍓 Then there's the post-association phase, where the ForCES protocol actually operates to manipulate the parameters of the FEs 👑 Figure 4 shows the whole vibe ✨
CE sends Association Setup
+---->--->------------>---->---->---->------->----+
| Y
^ |
| Y
+---+-------+ +-------------+
|FE pre- | | FE post- |
|association| CE sends Association Teardown | association |
|phase |<------- <------<-----<------<-------+ phase |
| | | |
+-----------+ +-------------+
^ Y
| |
+-<---<------<-----<------<----<---------<------+
FE loses association
Figure 4: The FE Protocol PhasesIn the mandated case, once an FE is associated, it may forward packets depending on how its specific LFBs are configured 🦋 An FE that's associated to a CE keeps 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 Section 8, and they're not discussed here so the basics stay super clear 🧚
The FE state transitions are controlled through the FE Object LFB FEState component, which is defined in [RFC5812], Section 5.1, and also explained in Section 7.3.2 💜
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 ✨
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 the CE explicitly configures it to transition to the OperEnable state 💅
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 💀
4.2.1. Pre-association 🎀
Okay so the ForCES interface gets configured during the pre-association phase. In a simple setup, the config is static and usually gets read from a saved configuration file 📁. Once pre-association is done, all the parameters for the association phase are well known ✨. A protocol like DHCP can fetch the config parameters instead of reading a static file. Note, though, that this still counts as static pre-association 💅. Dynamic configuration can also happen over the Fc, Ff, and Fl reference points (refer to [RFC3746]) 🦋. Vendors can even use their own proprietary service discovery protocol to pass the parameters. Honestly, this section only gives guidelines, and the details are left up to the implementation 🫶.
Here are some scenarios from the framework document that show what a pre-association exchange looks like 👀.
<----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)
| | | |
| | | |
Figure 5: Examples of a Message Exchange over the Ff and Fc
Reference Points
<-----------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|------------------------------->| |
| | | |
| | | |
Figure 6: Example of a Message Exchange over the Fl Reference PointBefore we move to the association phase, the FEM has already made contact with a CEM component 📞. ForCES interface initialization has finished, and authentication plus capability discovery may be complete too. At this point, both the FE and the CE have what they need to connect to each other for configuration, accounting, identification, and authentication 🔐. To sum up, by the end of this stage both sides have all the protocol parameters, like timers, etc. 💜. The Fl reference point can keep running during the association phase, and it can be used to force a disassociation of an FE or CE 💀. The specific interactions between the CEM and FEM during pre-association are out of scope, so this specification doesn't go into them any further. If you want a slightly more detailed take, check out the framework document [RFC3746] 🧚.
4.2.2. Post-association 🌸
In this phase, the FE and CE components talk to each other using the ForCES protocol (PL over TML), as defined in this document 🗣️. There are three sub-phases:
- Association Setup Stage
- Established Stage
- Association Lost Stage
4.2.2.1. Association Setup Stage 🚪
The FE tries to join the NE, and it may be rejected or accepted. Once it's granted access into the NE, capabilities exchange happens, with the CE querying the FE 🔍. After the CE has the FE's capability information, it can offer an initial configuration (possibly to restore state), and it can query certain components within either an LFB or the FE itself 🧠.
More details are in Section 4.4 📖.
When this stage completes successfully, the FE joins the NE and moves to the Established Stage 🎉.
4.2.2.2. Established Stage 🔄
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 it's programmed to do so 💓. This stage keeps going until a termination occurs, either because connectivity is lost or because the CE or the FE initiates a termination 😭.
For more details, check the protocol scenarios section, Section 4.4 🫶.
4.2.2.3. Association Lost Stage 💔
In this stage, the CE or the FE (or both) declare that the other side is no longer associated. The disconnection can be started by either party for administrative purposes, but it can also be driven by operational reasons, like loss of connectivity 📉.
There's a core LFB called the FE Protocol Object (FEPO), which is defined in Appendix B and Section 7.3.1 👑. FEPO defines various timers that can be used together with a traffic-sensitive heartbeat mechanism (Section 4.3.3) to detect loss of connectivity ⏱️.
Loss of connectivity between TMLs does not mean the PL layers have lost their association. If the TML can't repair the transport loss before the programmed FEPO timer thresholds associated with the FE are exceeded, then the association between the respective PL layers will be lost 🥀.
FEPO defines several policies that can be programmed to set the behavior when a loss of association is detected 🛠️. The FEPO's programmed CE failover policy (refer to Sections 8, 7.3.1, 4.3.3, and B) defines what happens upon loss of association 🔁.
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) 🧹.
4.3. Protocol Mechanisms 🦋
Lots of semantics are exposed to protocol users through the PL header 🎁. These include transaction capabilities, atomicity of transactions, two-phase commits, batching/parallelization, high availability, and failover, as well as command pipelines.
The EM (Execution Mode) flag, AT (Atomic Transaction) flag, and TP (Transaction Phase) flag, as defined in the common header (Section 6.1), are relevant to these mechanisms 🔧.
4.3.1. Transactions, Atomicity, Execution, and Responses 🧩
In the master-slave relationship, the CE instructs one or more FEs on how to execute operations and how to report the results 👑.
This section details the different execution modes the CE can order the FE(s) to perform, as defined in Section 4.3.1.1 ⚙️. It also describes the different modes the CE can ask the FE(s) to use when formatting responses after processing the requested operations. These modes relate to the transactional two-phase commit operations 🤝.
4.3.1.1. Execution ⚡
There are 3 execution modes you can request for a batch of operations spanning one or more LFB selectors (refer to Section 7.1.5) in one protocol message. The EM flag in the common header (Section 6.1) selects the execution mode for a protocol message, like so:
execute-all-or-nonecontinue-execute-on-failureexecute-until-failure
4.3.1.1.1. execute-all-or-none 🙌
When this mode is set, independent operations in a message MAY be targeted at one or more LFB selectors within an FE. All of these operations run 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 already ran before the failure will need to be undone. So yes, this mode has rollback 🔙.
Refer to Section 4.3.1.2.2 for how this mode is used with transactions. In that case, no operation is executed unless the CE issues a commit ✅.
Be careful with how you use this mode, because a mis-configuration could result in traffic losses. To add certainty to the success of an operation, use this mode in a transactional operation, as described in Section 4.3.1.2.2 💀.
4.3.1.1.2. continue-execute-on-failure 🏃♀️
If several independent operations are targeted at one or more LFB selectors, execution continues for all of the operations at the FE, even if one or more of them fail 💪.
4.3.1.1.3. execute-until-failure 🛑
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 that already completed are not undone. So there's no rollback in this mode 🙅.
4.3.1.2. Transaction and Atomicity 💜
4.3.1.2.1. Transaction Definition 📜
A transaction is a collection of one or more ForCES operations within one or more PL messages, and it MUST meet the ACIDity properties [ACID]. Here's what those mean:
- Atomicity: In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none of them are.
- 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 started.
- Isolation: A transaction in process and not yet committed MUST remain isolated from any other transaction.
- Durability: Committed data is saved by the system so that, even in the event of a failure and a system restart, the data is available in its correct state.
There are cases where the CE knows the exact memory and implementation details of the FE, like an FE-CE pair from the same vendor where the pair is tightly coupled. In that case, the transactional operations may be simplified further by extra computation at the CE. This view isn't discussed any further beyond noting that it is not disallowed 🤷.
As we just defined, a transaction is always atomic, and it MAY be:
- Within an FE alone. Example: updating multiple tables that depend on each other. If updating one fails, then any that were already updated MUST be undone 🧯.
- Distributed across the NE. Example: updating table(s) that are inter-dependent across several FEs (such as L3 forwarding-related tables) 🌐.
4.3.1.2.2. Transaction Protocol 💖
Okay so, the execution mode from Section 4.3.1.1 already gives us a way to do transactional stuff inside one stand-alone message 🎀. The execute-all-or-none mode can meet the ACID requirements 💅✨.
For transactional operations spanning multiple messages, whether that's within one FE or across FEs, the protocol supports a classic approach called two-phase commit (2PC) [2PCREF] 🦋. It gets this done using Config messages (Section 7.6.1) 🫶.
The COMMIT and TRCOMP operations, together with the AT and TP flags in the common header (Section 6.1), are the tools for 2PC-based transactions that span multiple messages 🌸.
The AT flag, when set, means this message belongs to an Atomic Transaction. All messages for a transaction operation MUST have the AT flag set. If it isn't set, the message is a stand-alone message and doesn't take part in any transaction operation that spans multiple messages 💜.
The TP flag tells you which Transaction Phase a message belongs to. There are 4 possible phases, and they're called:
- SOT (Start of Transaction) 🚀
- MOT (Middle of Transaction) 🧩
- EOT (End of Transaction) 🏁
- ABT (Abort) 💀
The COMMIT operation is how the CE tells the FE(s) to commit a transaction. When it's used with an ABT TP flag, the COMMIT operation tells the FE(s) to roll back (i.e., un-COMMIT) a transaction that was already committed 🔄.
The TRCOMP operation is a small addition to the classic 2PC approach 🍓. The CE sends TRCOMP to tell the FE(s) that the transaction they COMMITed is now over. This gives the FE(s) a chance to clear out any state they kept around in case they needed to roll back 🧹✨.
A transaction operation starts with a message whose TP flag is set to Start of Transaction (SOT). Multi-part messages after the first one are marked with the Middle of Transaction (MOT) flag. All messages from the CE MUST set the AlwaysACK flag (Section 6) so they solicit responses from the FE(s) 📬.
Before the CE issues a commit (more on that below), the FE MUST only validate that the operation can be executed, but not execute it 🔍.
Any failure notified by an FE makes the CE abort the transaction on all FEs involved in it. This is done by sending a Config message with an ABT flag and a COMMIT operation 🚨.
If no participating FE reports a failure, the commit phase is signaled from the CE to the FE with an End of Transaction (EOT) configuration message that has a COMMIT operation 🎯.
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):
- a. If any participating FE responds with a failure message in relation to the transaction.
- b. If no response is received from a participating FE within a specified timeout.
If all participating FEs 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 🙈.
Note that a transactional operation is generically atomic, so the execution modes of all messages in a transaction operation should always be kept the same and set to execute-all-or-none. If the EM flag is set to other execution modes, it will result in a transaction failure ⚠️.
As mentioned above, a transaction may span multiple messages. It's up to the CE to keep track of the different outstanding messages that make up a transaction. For example, the correlator field could be used to mark transactions and a sequence field could label the different messages within the same atomic transaction. But this is out of scope and up to implementations 🧠.
4.3.1.2.3. Recovery 🛟
Any of the participating FEs, the CE, or the associations between them may fail after the FE has sent the EOT Response message but before the CE has received all the responses. For example, the EOT response might never reach the CE 😭.
In this protocol revision, as indicated in Section 4.2.2.3, an FE that loses an association would be required to get entirely new state from the newly associated CE when it re-associates. This approach is simplistic and makes it likely that data path traffic gets lost, but it's a design choice that avoids the extra complexity of managing graceful restarts 🙃. The HA mechanisms (Section 8) are provided to allow for continuous operation in case of FE failures 💪.
There's flexibility in how an FE reacts when it loses an association. This is dictated by the CE failover policy (refer to Section 8 and Section 7.3) 🎀.
4.3.1.2.4. Transaction Messaging Example 🎬
This section shows how a successful two-phase commit between a CE and an FE would look in the simple case 🦋.
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 |
|<-----------------------------------------------------|Figure 7: Example of a Two-Phase Commit 🖼️
For the scenario above:
- In step 1, the CE issues a Config message with an operation of choice, like a DEL or SET. The transaction flags are set to indicate a Start of Transaction (SOT), Atomic Transaction (AT), and execute-all-or-none ✨.
- The FE validates that it can execute the request successfully, then sends an acknowledgment back to the CE in step 2 👍.
- In step 3, the CE repeats the same sort of construct as in step 1, but with the transaction flag changed to Middle of Transaction (MOT) 🔁.
- The FE validates that it can execute the request successfully, then sends an acknowledgment back to the CE in step 4 ✅.
- The CE-FE exchange keeps going the same way until all the operations and their parameters have been transferred to the FE. This happens in step (N-1) 📦.
- In step N, the CE issues a commit. A commit is a Config message with an operation of type COMMIT, and the transaction flag is set to End of Transaction (EOT). Basically, it's an "empty" message asking the FE to execute all the operations it has gathered since the beginning of the transaction (message #1) 🏁.
- The FE now executes the full transaction. Then it sends an acknowledgment back to the CE in step (N+1) that contains a COMMIT-RESPONSE 🎉.
- The CE has the easy job here: it just issues a TRCOMP operation to the FE in step (N+2) 💅.
4.3.2. Scalability 🚀
It's desirable that the PL doesn't become the bottleneck when larger bandwidth pipes show up. To pick a hypothetical example in today's terms: if a 100-Gbps pipe is available and there's sufficient work, the PL should be able to take advantage of it and use all of that 100-Gbps pipe 🌈. There are two mechanisms for this. The first is batching, and the second is a command pipeline 🧚.
Batching means being able to send multiple commands (such as Config) in one Protocol Data Unit (PDU). The size of the batch is affected by, among other things, the path MTU. The commands may belong to the same transaction, or they may belong to unrelated transactions that are independent of each other 📦.
Command pipelining allows independent transactions that don't affect each other to be pipelined. Each independent transaction could consist of one or more batches ⭐.
4.3.2.1. Batching 📦
There are several batching levels at different protocol hierarchies:
- Multiple PL PDUs can be aggregated under one TML message.
- Multiple LFB classes and instances (as indicated in the LFB selector) can be addressed within one PL PDU.
- Multiple operations can be addressed to a single LFB class and instance.
4.3.2.2. Command Pipelining 🧚
The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have come back from the FE. So pipelining is inherently supported by the protocol 🦋. Matching responses to requests can be done using the correlator field in the message header 🔗.
4.3.3. Heartbeat Mechanism 💓
Heartbeats (HBs) 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 cuts down on HB traffic during busy PL periods 🙌.
An HB can be sourced by either the CE or the FE. When the CE sources it, a response can be requested (similar to the ICMP ping protocol) 🏓. The FE can only generate HBs if the CE has configured it to do so. Refer to Section 7.3.1 and Section 7.10 for details 🎀.
4.3.4. FE Object and FE Protocol LFBs ✨
okay so every PL message works on LFBs 🧚, because that gives us way more flexibility for future upgrades. That means the maintenance and configurability of FEs, NEs, and the ForCES protocol itself MUST be expressed in terms of this LFB architecture 💅. So we make some special LFBs just for this job.
And this is the part that's kind of iconic 😭: the ForCES protocol gets controlled by the very same kind of structures (LFBs) it uses to control stuff like IP forwarding, filtering, etc. Protocol controlling itself, main character energy 👑.
Here are the two specialized LFBs we introduce 🎀:
- FE Protocol LFB, which is used to control the ForCES protocol.
- FE Object LFB, which is used to control components relative to the FE itself. Such components include FEState [RFC5812], vendor, etc.
You can find the details of these LFBs in Section 7.3 🌸.
4.4. Protocol Scenarios 🦋
Bestie, this section is a super high level tour of sample message sequences between a CE and an FE 💜. For the protocol message encoding, check Section 6.1, and for the semantics of the protocol, check Section 4.3 ✨.
4.4.1. Association Setup State 🫶
okay so associations among CEs and FEs get started with the Association Setup message from the FE 💖. If the CE grants a Setup Request, a successful Setup Response message gets sent back to the FE 🌈. If CEs and FEs are operating in an insecure environment, then the security associations have to be set up between them before any association messages can be exchanged 🙈. The TML MUST take care of establishing any security associations 🔥.
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 [RFC5812] 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 may be 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 the OperEnable state 🍓. An example of an FE starting in OperDisable then transitioning to OperEnable is illustrated in Figure 8 🦋. The CE could at any time also disable the FE's data path 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 Figure 8 below 🎀.
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 |
|---------------------->|
| |Figure 8: Message Exchange between CE and FE to Establish an NE Association
On successful completion of this state, the FE joins the NE 🌸.
4.4.2. Association Established State or Steady State 💖
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 keeps going until a termination (or deactivation) is initiated by either the CE or FE 🙈. Figure 9 below helps illustrate this state 🧚.
FE PL CE PL
| |
| Heartbeat |
|<---------------------------->|
| |
| Heartbeat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Component |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heartbeat |
|<-----------------------------|
. .
. .
| |Figure 9: Message Exchange between CE and FE during Steady-State Communication
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 (Section 8) 💅.
5. TML Requirements ✨
okay bestie, these are the things the TML is expected to meet 💅 This text does not spell out how those mechanisms get delivered. For example, they could be delivered via hardware, or between 2 or more TML software processes on different CEs or FEs in protocol-level schemes 🧚
Each TML MUST describe how it contributes to achieving the listed ForCES requirements. If for any reason a TML doesn't provide a service listed below, a justification needs to be provided 🎀
Implementations that support the ForCES protocol specification MUST implement [RFC5811]. Also, more TMLs might get specified in the future, and if a new TML that meets these requirements turns out to be better, then the "MUST implement TML" may be redefined 👑
- Reliability 🦋
Various ForCES messages need different levels of reliable delivery via the TML. It's the TML's job to provide these shades of reliability and describe how the different ForCES messages map to reliability 💜
The most common level is what we call strict or robust reliability, meaning no losses, corruption, or re-ordering of the information being transported, while still making sure delivery happens in a timely fashion ✨
Payloads like configuration from a CE and its response from an FE are mission critical, so they must be delivered with robust reliability. For this kind of information, the TML MUST either provide built-in protocol mechanisms or use a reliable transport protocol to achieve robust/strict reliability 🔥
Some information or payloads, like redirected packets or packet sampling, don't need robust reliability and can tolerate some losses. For this kind of information, the TML could define the use of a mechanism that isn't strictly reliable (while still conforming to other TML requirements, such as congestion control) 🌸
Some information or payloads, like heartbeat packets, would rather have timeliness than reliable delivery. For this kind of information, the TML could define the use of a mechanism that isn't strictly reliable (while still conforming to other TML requirements, such as congestion control) 💖
- Security 🔐
The TML provides security services to the ForCES PL. Because a ForCES PL is used to operate an NE, attacks designed to confuse, disable, or steal information from a ForCES-based NE may be seen as a prime objective during a network attack 💀
An attacker who can inject false messages into a PL stream can mess with either the FE's treatment of the data path (for example, by faking control data reported as coming from the CE) or the CE itself (by modifying events or responses reported as coming from the FE). That's why CE and FE node authentication and TML message authentication are so important 🙈
PL messages may also carry info that's valuable to an attacker, including info about the network configuration, encryption keys, and other sensitive control data. So care must be taken to keep their visibility limited to authorized users 🫶
- The TML MUST provide a mechanism to authenticate ForCES CEs and FEs, in order to prevent unauthorized CEs and unauthorized FEs from participating in the control and data path processing of a ForCES NE 🚫
- The TML SHOULD provide a mechanism to ensure message authentication of PL data transferred from the CE to the FE (and vice versa), in order to prevent the injection of incorrect data into PL messages 🔥
- The TML SHOULD provide a mechanism to ensure the confidentiality of data transferred from the ForCES PL, in order to prevent disclosure of PL-level information transported via the TML 💅
The TML SHOULD provide these services by employing TLS or IPsec 🎀
- Congestion control 🌊
The transport congestion control scheme used by the TML needs to be defined. The congestion control mechanism defined by the TML MUST prevent transport congestive collapse [RFC2914] on either the FE or the CE side 🫠
- Uni/multi/broadcast addressing/delivery, if any 📬
If there's any mapping between PL-level and TML-level uni/multi/broadcast addressing, it needs to be defined 🍓
- HA decisions 🔁
It's expected that availability of transport links is the TML's responsibility. However, depending on its configuration, the PL may want to take part in link failover schemes, so the TML MUST support this capability 👑
Please refer to Section 8 for details 🧚
- Encapsulations used 🎁
Different types of TMLs will encapsulate PL messages in different types of headers. The TML needs to specify the encapsulation it uses 🌈
- Prioritization ⭐
The TML is expected to be able to handle up to 8 priority levels needed by the PL, and to provide preferential treatment ✨
While the TML needs to define how this is achieved, the requirement to support up to 8 priority levels doesn't mean the underlying TML MUST be capable of providing up to 8 actual priority levels. If the underlying TML layer doesn't support 8 priority levels, the supported priority levels should be divided among the available TML priority levels. For example, if the TML only supports 2 priority levels, 0-3 could go in one TML priority level, while 4-7 could go in the other 🦋
The TML MUST NOT re-order config packets with the same priority 🚫
- Node Overload Prevention 🛡️
The TML MUST define the mechanisms it uses to help prevent node overload 🫶
Overload results in starvation of node compute cycles and/or bandwidth resources, which reduces the operational capacity of a ForCES NE. NE node overload could be deliberately instigated by a hostile node to attack a ForCES NE and create a denial of service (DoS). It could also be caused by a variety of other things, such as large control protocol updates (e.g., BGP flaps), which lead to a high frequency of CE-to-FE table updates; HA failovers; or component failures, which move an FE or CE's load and overwhelm the new CE or FE, and so on. Even though the environments SIP and ForCES operate in are different, [RFC5390] is a good guide to the generic node requirements you need to guard against 💜
A ForCES node CPU may get overwhelmed because the incoming packet rate is higher than it can keep up with. In that case, a node's transport queues grow and transport congestion follows 🌊 A ForCES node CPU may also be badly overloaded by very few packets, meaning there's no transport congestion at all (e.g., during a DoS attack against a table hashing algorithm that overflows the table and/or keeps the CPU busy so it can't process other tasks) 😭 The TML node overload solution specified MUST address both types of node overload scenarios 💖
5.1. TML Parameterization 🎀
It's expected that it should be possible to use a configuration reference point, such as the FEM or the CEM, to configure the TML 🧚
Some of the configured parameters may include:
- PL ID 🆔
- 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 🔌
- Number of transport connections 🔢
- Connection capability, such as bandwidth, etc. 📶
- Allowed/supported connection QoS policy (or congestion control policy) ⚖️
6. Message Encapsulation 🎁
All PL PDUs start with a common header (Section 6.1), followed by one or more TLVs (Section 6.2), which may nest other TLVs (Section 6.2.1). All fields are in network byte order 🌸
6.1. Common Header 🎀
okay so this is the common header, the part everyone has to read first 💅 it's got a version, a message type, a length, some IDs, a correlator, and flags, and it's all packed into a neat 32-bit-aligned layout ✨
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Common HeaderThe message is 32-bit aligned. 🌸
Version (4 bits): Version number. Current version is 1. 🦋
rsvd (4 bits): Unused at this point 🙈 A receiver should not interpret this field. Senders MUST set it to zero and receivers MUST ignore this field. so don't touch it, bestie 🫶
Message Type (8 bits): Commands are defined in Section 7. 🧚
Length (16 bits): length of header + the rest of the message in DWORDS (4-byte increments). ✨
Source ID (32 bits): Dest ID (32 bits):
- Each of the source and destination IDs are 32-bit IDs that are unique NE-wide and that identify the termination points of a ForCES PL message. these are the main character IDs of the whole message 👑
- IDs allow multi/broad/unicast addressing with the following approach:
- a. 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 of more FEs than CEs, the address space is split uniformly for simplicity. 💅
- b. The address space allows up to 2^30 (over a billion) CEs and the same amount of FEs. that's a LOT of room, periodt 😭
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ForCES ID Format- c. The 2 most significant bits called Type Switch (TS) are used to split the ID space as follows:
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
Figure 12: Type Switch ID Space- 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. ooh, secret squad vibes 🤫
- Multicast IDs can be used for both source or destination IDs. 💜
- Broadcast IDs can be used only for destination IDs. 📣
- 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. 🍓
Correlator (64 bits):
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. 🙃
The correlator field could be used in many implementations in 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 uses of the correlator are outside the scope of this specification. 💅
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. 🧠
Whenever the correlator field is not relevant, because no message is expected, the correlator field is set to 0. ✨
Flags (32 bits): Identified so far:
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| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Flags- ACK: ACK indicator (2 bits)
The ACK indicator flag is only used by the CE when sending a Config message (Section 7.6.1) or an HB message (Section 7.10) 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. 🎯
The flag values are defined as follows:
'NoACK'(0b00) - to indicate that the message receiver MUST NOT send any Response message back to this message sender. 🙅♀️'SuccessACK'(0b01) - to indicate that the message receiver MUST send a Response message back only when the message has been successfully processed by the receiver. 🎉'FailureACK'(0b10) - to indicate that 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. 🚨'AlwaysACK'(0b11) - to indicate that the message receiver MUST send a Response message. 📬
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 Section 4.3.1.1) 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'. one fail and the whole thing counts 😬
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:
- Association Setup message always expects a response. 🤝
- Association Teardown Message, and Packet Redirect message, never expect responses. 👋
- Query message always expects a response. 🔎
- Response message never expects further responses. 🛑
- Pri: Priority (3 bits)
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 protocol 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. ⚠️ priority is a whole vibe, but don't scramble your transaction messages 😭
- EM: Execution Mode (2 bits)
There are 3 execution modes; refer to Section 4.3.1.1 for details. 🎬
Reserved..................... (0b00)
`execute-all-or-none` ....... (0b01)
`execute-until-failure` ..... (0b10)
`continue-execute-on-failure` (0b11)- AT: Atomic Transaction (1 bit)
This flag indicates if the message is a stand-alone message or one of multiple messages that belong to 2PC transaction operations. See Section 4.3.1.2.2 for details. 🧩
Stand-alone message ......... (0b0)
2PC transaction message ..... (0b1)- TP: Transaction Phase (2 bits)
A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 4.3.1.2.2 for details. 🌈
SOT (start of transaction) ..... (0b00)
MOT (middle of transaction) .... (0b01)
EOT (end of transaction) ........(0b10)
ABT (abort) .....................(0b11)6.2. Type Length Value (TLV) Structuring ✨
okay so TLVs are literally everywhere in ForCES 💖 the protocol leans on them hard, and they have some really nice properties that make them perfect for encoding the XML definitions of the LFB class model 🎀 the big perks:
- binary type-value encoding that's super close to the XML string tag-value scheme 🦋
- fast, generalized binary-parsing functions 🔥
- forward and backward tag compatibility!! this is the same energy as XML: old apps can ignore new TLVs, and newer apps can ignore older TLVs 🫶
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) |
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: TLV RepresentationTLV Type (16):
the TLV type field is 2 octets, and it tells you what kind of data is wrapped up inside the TLV 🎀
TLV Length (16):
the TLV length field is 2 octets and counts the TLV type (2 octets), the TLV Length (2 octets), and the length of the TLV data in the value field, in octets. ngl the key bit here is that this is the actual length of the value, before any alignment padding gets added 💅
TLV Value (variable):
the TLV value field carries the data 💜 for extensibility, the TLV value may in fact be a TLV, and nesting is so iconic. padding is required when the length isn't a multiple of 32 bits, and it's the minimum number of octets needed to bring the TLV up to a multiple of 32 bits. the length of the value before padding is still whatever the TLV Length field says 🧚
Note: the value field could be empty, which means the smallest a TLV could ever be is 4 (length of "T" field and length of "L" field). tiny but mighty 🌸
6.2.1. Nested TLVs
TLV values can be other TLVs, and that's giving protocol flexibility 🦋 you can add new extensions just by introducing new TLVs when you need them. the nesting feature also gives us a conceptual optimization for turning the XML LFB definitions into the binary PL representation (which is represented by nested TLVs) 💖
6.2.2. Scope of the T in TLV
okay so there are two global name scopes for the "Type" in the TLV 👑 the first scope is for OPER-TLVs and it's defined in A.4, whereas the second scope is outside OPER-TLVs and it's defined in section A.2. two lanes, no drama 🙈
6.3. ILV
the ILV is a slight variation of the TLV 🧚 it sets the type ("T") to be a 32-bit local index that refers to a ForCES component ID (refer to Section 6.4.1). iconic glow-up ✨
The ILV length field is a 4-octet integer, and it counts the ILV type (4 octets), ILV Length (4 octets), and the length of the ILV data in the value field, in octets. same as the TLV, this length is the actual length of the value, before any alignment padding is added 🎀
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ILV Representationit should be noted that the "I" values are of local scope, and they're defined by the data declarations from the LFB definition 🌈 check Section 7.1.8 for how ILVs actually get used.
6.4. Important Protocol Encapsulations
in this section we're gonna review a few encapsulation concepts that the ForCES protocol uses for its operations 💅
we briefly re-introduce two concepts, paths and keys, from the ForCES model [RFC5812] so you have some context 🦋 the reader is referred to [RFC5812] for the finer details, so go there if you want the deep dive 🧠
for readability reasons, we introduce the encapsulation schemes that carry content in a protocol message: FULLDATA-TLV, SPARSEDATA-TLV, and RESULT-TLV 🎀
6.4.1. Paths
the ForCES model [RFC5812] defines an XML-based language that lets you formally define LFBs 🧚 it's kind of like the relationship between ASN.1 and SNMP MIB definitions (the MIB is analogous to the LFB, and ASN.1 is analogous to the XML model language). any entity that the CE configures on an FE MUST be formally defined in an LFB. these entities can be scalars (e.g., a 32-bit IPv4 address) or vectors (such as a nexthop table). each entity within the LFB gets a numeric 32-bit identifier known as a "component id", and that's what lets the component be "addressed" in a protocol construct 💖
these addressable entities can be hierarchical (e.g., a table column or a cell within a table row) 🌸 to address hierarchical data, the model [RFC5812] introduces the concept of a path. a path is a series of 32-bit component IDs, typically written in dot-notation (e.g., 1.2.3.4). Section 7 formally defines how paths are used to reference data that's being encapsulated within a protocol message 👑
6.4.2. Keys
the ForCES model [RFC5812] gives us two ways to address table rows 🦋 the standard/common mechanism is to reference a table row 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 ✨ basically, while the common way to address a table row is its table index, a table row's path could be derived from a key. the KEYINFO-TLV (Section 7) carries the data used to do the lookup 🔍
6.4.3. DATA TLVs
data going to or coming from 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.
in FULLDATA-TLV, the data is encoded so that a receiver who knows the path and the LFB definition can infer or correlate the TLV "Value" contents. this is basically an optimization that cuts down on how much description the transported data needs in the protocol grammar 🧚 refer to Appendix C for an example of FULLDATA-TLVs.
a number of operations in ForCES need to reference optional data within larger structures, and that's where SPARSEDATA-TLV comes in 🎀 it makes it way easier to encapsulate optionally appearing data components. refer to Appendix C for an example of SPARSEDATA-TLV.
RESULT-TLVs carry responses back from the FE based on a config issued by the CE 🫶 refer to Appendix C for examples of RESULT-TLVs and Section 7.1.7 for the layout.
6.4.4. Addressing LFB Entities
okay bestie, Section 6.4.1 and Section 6.4.2 cover how to target an entity within an LFB 💅 but the addressing mechanism needs an LFB type and instance to be selected first. that's the job of the LFB selector, which picks the LFB type and instance being targeted. Section 7 goes into more detail, but for now Figure 16 below shows the vibe 🌈 more examples of layouts are further along in the text (example: Figure 22).
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
Figure 16: Entity Addressing7. Protocol Construction ✨
okay so every protocol layer PDU 🎀 is a common header (see Section 6.1 💅) followed by a message body. The body is specific to its message type, and it's built out of one or more top-level TLVs 🧚. A top-level TLV can hold one or more sub-TLVs, and this doc calls those OPER-TLVs because they describe an operation that needs to happen 🔥
+-------------+---------------+---------------------+---------------+
| Message | Top-Level TLV | OPER-TLV(s) | Reference |
| Name | | | |
+-------------+---------------+---------------------+---------------+
| Association | (LFBselect)* | REPORT | Section 7.5.1 |
| Setup | | | |
| Association | ASRresult-TLV | none | Section 7.5.2 |
| Setup | | | |
| Response | | | |
| Association | ASTreason-TLV | none | Section 7.5.3 |
| Teardown | | | |
| Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | DEL | COMMIT | | |
| | | TRCOMP)+ | |
| Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 |
| Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | |
| Event | LFBselect | REPORT | Section 7.8 |
| Notifi- | | | |
| cation | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | |
| Heartbeat | none | none | Section 7.10 |
+-------------+---------------+---------------------+---------------+Table 1
Table 1 is basically your cheat sheet 📋 It shows how the different messages look. The numerical values for the message types are in Appendix A.1, and all the TLV values are in Appendix A.2 📚
An LFBselect TLV (refer to Section 7.1.5) 💜 holds the LFB Classid and LFB instance being referenced, plus the OPER-TLV(s) being applied to that reference.
Each type of OPER-TLV has its own rules for how it describes the paths and selectors it cares about 👑 Here's the BNF for the basic structure of an OPER-TLV, and Table 2 has the details for each type ✨
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-TLVFigure 17: BNF of OPER-TLV
- PATH-DATA-TLV 🎯 pinpoints the exact component being targeted, and it can have zero or more paths attached to it. When paths nest through the DATA construct (that's the vibe for SET and SET-PROP requests, plus GET-RESPONSE and GET-PROP-RESPONSE), the last PATH-DATA-TLV ends with either a FULLDATA-TLV, a SPARSEDATA-TLV, or a RESULT-TLV holding the encoded data or response.
- PATH 🗺️ is the path to the data being referenced.
- flags (16 bits) are used to further refine the operation applied to the path. More on these later.
- IDcount (16 bits): count of 32-bit IDs
- IDs: zero or more 32-bit IDs (the count is given by IDcount) that define the main path. Depending on the flags, the IDs could be field IDs only, or a mix of field and dynamic IDs. Zero is used for the special case of using the entire containing context as the result of the path.
- SELECTOR is an optional construct that narrows down the PATH 🔍 Right now, the only defined selector is the KEYINFO-TLV, which is used to select an array entry by the value of a key field. A SELECTOR is only valid when the flags also indicate that it's there.
- KEYINFO-TLV 🔑 contains the information used in content keying.
- A 32-bit KeyID is used in a KEYINFO-TLV. It says which key for the current array is being used as the content key for array entry selection.
- The key's data is what you look for in the array, in the fields identified by the key field. It's encoded using the rules for the contents of a FULLDATA-TLV, and it represents the field or fields that make up the key identified by the KeyID.
- DATA 📦 can hold a FULLDATA-TLV, a SPARSEDATA-TLV, a RESULT-TLV, or one or more further PATH-DATA selections. FULLDATA-TLV and SPARSEDATA-TLV are only allowed on SET or SET-PROP requests, or on responses that return content information (GET-RESPONSE, for example). PATH-DATA can be included to extend the path on any request.
- Note: Nested PATH-DATA-TLVs are supported as an efficiency measure to permit common subexpression extraction 🧠
- FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path has been selected by the PATH. Refer to Section 7.1 for details.
- The table below sums up where the FULL/SPARSEDATA-TLVs and the RESULT-TLV can show up for each OPER-TLV, and what's restricted 💅
+-------------------+-------------------------------+---------------+
| OPER-TLV | DATA TLV | RESULT-TLV |
+-------------------+-------------------------------+---------------+
| SET | | none |
| SET-PROP | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | |
| SET-RESPONSE | none | (RESULT-TLV)+ |
| SET-PROP-RESPONSE | none | (RESULT-TLV)+ |
| DEL | | none |
| DEL-RESPONSE | none | (RESULT-TLV)+ |
| GET | none | none |
| GET-PROP | none | none |
| GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| REPORT | (FULLDATA-TLV)+ | none |
| COMMIT | none | none |
| COMMIT-RESPONSE | none | (RESULT-TLV)+ |
| TRCOMP | none | none |
+-------------------+-------------------------------+---------------+Table 2
- RESULT-TLV ✅❌ contains the indication of whether each individual SET or SET-PROP succeeded. It's included because individual parts of a SET request can succeed or fail separately.
In summary, this approach has these vibes 🌈
- There can be one or more LFB class ID and instance ID combinations targeted in a message (batch).
- There can be one or more operations on an addressed LFB class ID/instance ID combination (batch).
- There can be one or more path targets per operation (batch).
- Paths may have zero or more data values associated with them (flexibility, and operation specific).
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. 🙈
7.1. Discussion on Encoding
Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV and SPARSEDATA-TLV) and why they exist 🤓 In this section, we explain how they're encoded.
7.1.1. Data Packing Rules
The encoding scheme used in this document follows these rules 📝
- 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.
- Variable-sized data within a FULLDATA-TLV will be encapsulated inside another FULLDATA-TLV, inside the V of the outer TLV. For an example of this setup, refer to Appendices C and D 🧁
- In the case of FULLDATA-TLVs:
- 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, the PATH may contain an index pointing to a row in the table. In that case, the FULLDATA-TLV's "V" will only contain the content with the index, in order to avoid ambiguity 🫶
7.1.2. Path Flags
Only bit 0, the SELECTOR Bit, is currently used in the path flags, as illustrated in Figure 18 🦋
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
|S| Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 18: Path Flags
The semantics of the flag are defined as follows:
- SELECTOR Bit: F_SELKEY(set to 1) indicates that a KEY Selector is present following this path information, and should be considered in evaluating the path content.
7.1.3. Relation of Operational Flags with Global Message Flags
Global flags, like the execution mode and the atomicity indicators defined in the header, apply to every operation in a message 🌍 They 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 itself 🎀
7.1.4. Content Path Selection
The KEYINFO-TLV describes the KEY as well as the associated KEY data 🔑 KEYs, which are used for content searches, are restricted and described in the LFB definition 💜
7.1.5. LFBselect-TLV
okay so the LFBselect TLV is just a regular TLV, the same kind we met back in Section 6.2 💖 it's giving familiar, and it's the one that picks out which LFB we're talking to 🎀
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: PL PDU LayoutType:
The type of the TLV is LFBselect. 🦋
Length:
This is the length of the whole TLV, including the T and L fields, in octets. ✨
LFB Class ID:
This field uniquely recognizes the LFB class/type. 🌸
LFB Instance ID:
This field uniquely identifies the LFB instance. 🧚
OPER-TLV:
This one describes an operation nested inside the LFBselect TLV. Note that usually there SHOULD be at least one OPER-TLV present for an LFB select TLV. 💅
7.1.6. OPER-TLV
The OPER-TLV is a placeholder in the grammar for the TLVs that define operations. ngl it's the "fill in the blank" slot, and the different types are listed in Table 3, below. 🍓
+-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments |
| | "Type" | |
+-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or |
| | | add or update components |
| SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | add or update component properties |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP |
| DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an component |
| DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry |
| | | response of a DEL |
| GET | 0x0007 | From CE to FE. Used to retrieve an |
| | | component |
| GET-PROP | 0x0008 | From CE to FE. Used to retrieve an |
| | | component property |
| GET-RESPONSE | 0x0009 | From FE to CE. Used to carry |
| | | response of a GET |
| GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry |
| | | response of a GET-PROP |
| REPORT | 0x000B | From FE to CE. Used to carry an |
| | | asynchronous event |
| COMMIT | 0x000C | From CE to FE. Used to issue a |
| | | commit in a 2PC transaction |
| COMMIT-RESPONSE | 0x000D | From FE to CE. Used to confirm a |
| | | commit in a 2PC transaction |
| TRCOMP | 0x000E | From CE to FE. Used to indicate |
| | | NE-wide success of 2PC transaction |
+-------------------+--------+--------------------------------------+
Table 3Different messages use OPER-TLV and define how they are used, so check out Table 1 and Table 2 to see the full picture 👑
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. it's giving clean division of labour 🌈
A GET-RESPONSE to a successful GET will have FULLDATA-TLVs added to the leaf paths to carry the requested data. For GET operations that fail, there's a RESULT-TLV in place of the FULLDATA-TLV. 🎀
For a SET-RESPONSE or SET-PROP-RESPONSE, each FULLDATA-TLV or SPARSEDATA-TLV in the original request gets replaced with a RESULT-TLV in the response. If the request set the FailureACK flag, then only the items that failed will show up in the response. If the request was for AlwaysACK, then every component of the request will appear in the response with RESULT-TLVs. ✨
Heads up bestie: if a SET/SET-PROP request has a structure in a FULLDATA-TLV and some field in that structure is invalid, the FE will not try to say which field was the problem. It will just tell you the operation failed. 💀
Also, if there are multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can pick which error it reports. So if a FULLDATA-TLV for a SET/SET-PROP of a structure tries to write one read-only field and also sets another field to an invalid value, the FE can return either error. 🙈
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 wants to delete something, the DEL operation should be used, whether the path refers to an array component or an optional structure component. 🫧
7.1.7. RESULT TLV
Okay so the RESULT-TLV is a TLV from Section 6.2, and it's the one that tells you how things went 💅✨ Here's its layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: RESULT-TLV
Defined Result ValuesNow the fun part, the list of Result Values. This table is the whole tea ☕🫖 Every value and what it means is right here:
+-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success |
| E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. |
| E_LENGTH_MISMATCH | 0x02 | Header length field |
| | | does not match actual |
| | | packet length. |
| E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch |
| | | in versions. |
| E_INVALID_DESTINATION_PID | 0x04 | Destination PID is |
| | | invalid for the message |
| | | receiver. |
| E_LFB_UNKNOWN | 0x05 | LFB Class ID is not |
| | | known by receiver. |
| E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known |
| | | by receiver but not |
| | | currently in use. |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified |
| | | instance of that class |
| | | does not exist. |
| E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. |
| E_COMPONENT_DOES_NOT_EXIST | 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). |
| E_EXISTS | 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). |
| E_NOT_FOUND | 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). |
| E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
| | | array with an unallowed |
| | | subscript. |
| E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a |
| | | parameter to a value |
| | | outside of its |
| | | allowable range. |
| E_CONTENTS_TOO_LONG | 0x0D | Attempt to write |
| | | contents larger than |
| | | the target object space |
| | | (i.e., exceeding a |
| | | buffer). |
| E_INVALID_PARAMETERS | 0x10 | Any other error with |
| | | data parameters. |
| E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not |
| | | acceptable. |
| E_INVALID_FLAGS | 0x12 | Message flags are not |
| | | acceptable for the |
| | | given message type. |
| E_INVALID_TLV | 0x13 | A TLV is not acceptable |
| | | for the given message |
| | | type. |
| E_EVENT_ERROR | 0x14 | Unspecified error while |
| | | handling an event. |
| E_NOT_SUPPORTED | 0x15 | Attempt to perform a |
| | | valid ForCES operation |
| | | that is unsupported by |
| | | the message receiver. |
| E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a |
| | | message (no error |
| | | detected in the message |
| | | itself). |
| E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occurred while |
| | | processing a message |
| | | (no error detected in |
| | | the message itself). |
| - | 0x18-0xFE | Reserved |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE cannot |
| | | decide what went |
| | | wrong). |
+-----------------------------+-----------+-------------------------+
Table 47.1.8. DATA TLV
Two TLVs live in this neighbourhood, and they're bffs 🫶 A FULLDATA-TLV has "T"= FULLDATA-TLV, then a 16-bit length, then the data value/contents. A SPARSEDATA-TLV is the same shape, just with "T" = SPARSEDATA-TLV 🦋 The difference is that every component in a SPARSEDATA-TLV's Value part gets wrapped up in its own ILV.
Here are the encoding rules for both. Appendix C is seriously so helpful for seeing them in action 🧚
- 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. 🎀
- FULLDATA-TLVs may be used at a particular path only if every component at that path level is present. Example 1(c) in Appendix C shows this with every component of the structure S sitting in the FULLDATA-TLV encoding. This holds whether the fields are fixed or variable length, and whether they're mandatory or optional 🌸
- 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 is what lets the decoder actually retrieve the data. Using example 1 from Appendix C again, the encoder and decoder are assumed to already know how structure S is laid out in its definition.
- In the case of a SPARSEDATA-TLV, order doesn't matter, since the "I" in the ILV uniquely identifies each component. Examples 1(a) and 1(b) in Appendix C show off the power of SPARSEDATA-TLV encoding 💜
- Inside a FULLDATA-TLV:
- Atomic, fixed-length field values are given without any TLV encapsulation.
- Atomic, variable-length field values are given inside FULLDATA-TLVs.
- Array values come as an index/subscript followed by the value, following "Data Packing Rules" (Section 7.1.1) and the examples in the appendices.
- Inside a SPARSEDATA-TLV, the values of all fields MUST be given with ILVs (32-bit index, 32-bit length). No shortcuts here, bestie 🙈
- FULLDATA-TLVs cannot contain an ILV. Not allowed, periodt 💀
- A FULLDATA-TLV can also contain a FULLDATA-TLV for variable-sized components. The decoder works out which is which using rule #3 above 🔥
7.1.9. SET and GET Relationship
Okay, the GET and SET relationship is so iconic 👑 It is expected that a GET-RESPONSE would satisfy the following:
- It would have exactly the same path definitions as the ones sent in the GET. The only difference is that a GET-RESPONSE will contain FULLDATA-TLVs.
- It should be possible to take the same GET-RESPONSE and turn it into a SET successfully by just changing the T in the operational TLV ✨
- There are exceptions to this rule, though 😭
- 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 comes back. Check out the examples using KEYS to see this in action 🦋
- When dumping a whole table in a GET, a GET-RESPONSE that just has its T edited to be SET will end up overwriting the table. Yikes, so be careful with that one 🍓
7.2. Protocol Encoding Visualization ✨
Okay bestie, picture the PL PDU as a little layered outfit 👗 A main header comes first, then one or more LFB selections, and each selection can hold one or more operations. 🎀
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
.
.
.
Figure 21: PL PDU Logical LayoutNext up is a closer look at a single operation inside a targeted LFB selection 🔍 This one shows all the nesting levels a path could take to reach the target path, and it's so satisfying 🦋
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
Figure 22: Sample Operation LayoutIf you want a more concise set of use cases for how the data encoding gets done, Appendix D has you covered 💖
7.3. Core ForCES LFBs 🧚
There are two LFBs that control how the ForCES protocol operates and how it talks to FEs and CEs 💜
- FE Protocol LFB
- FE Object LFB
Ngl, these two LFBs have the same form and interface as every other LFB, but they're super special 👑 They have fixed, well-known LFB Class and Instance IDs. They're statically defined (no dynamic instantiation allowed), and the protocol can't change their status. Any operation that tries to change the state of these LFBs (for instance, to disable the LFB) MUST result in an error. 🙅♀️ These LFBs also MUST exist before the first ForCES message can be sent or received, and all of their components MUST have pre-defined default values. Finally, they don't have input or output ports and they don't plug into the intra-FE LFB topology. Main character energy, no cap 💅
7.3.1. FE Protocol LFB 💖
The FE Protocol LFB is a logical entity in each FE that's used to control the ForCES protocol 🫶 Its Class ID is assigned the value 0x2, and its Instance ID is assigned the value 0x1. There MUST be one and only one instance of the FE Protocol LFB in an FE. Its components have pre-defined default values, specified here, and unless the CE makes explicit changes to them using Config messages, those default values MUST be used for correct operation of the protocol. Iykyk, so don't mess with them lightly 🙈
The formal definition of the FE Protocol Object LFB can be found in Appendix B.
7.3.1.1. FE Protocol Capabilities 🌸
FE Protocol capabilities are read-only 👀
7.3.1.1.1. SupportableVersions ✨
ForCES protocol version(s) supported by the FE.
7.3.1.1.2. FE Protocol Components 🎀
FE Protocol components can be read and set 🫧
7.3.1.1.2.1. CurrentRunningVersion 🦋
Current running version of the ForCES protocol.
7.3.1.1.2.2. FEID 🍓
FE unicast ID.
7.3.1.1.2.3. MulticastFEIDs 🌈
FE multicast ID(s) list. This is a list of multicast IDs that the FE belongs to, and the CE is the one who configures these IDs.
7.3.1.1.2.4. CEHBPolicy 💜
CE heartbeat policy. This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' (explained below), sets the operating parameters for the FE to check CE liveness. The policy values and their meanings are:
- 0 (default) - This policy says the CE will send a Heartbeat message to the FE(s) whenever the CE reaches a time interval in which no other PL messages were sent from the CE to the FE(s). Refer to Section 4.3.3 and Section 7.10 for details. The CE HDI component below is tied to this policy.
- 1 - The CE will not generate any HB messages. This actually means the CE does not want the FE to check CE liveness. 🙅♀️
- Others - Reserved.
7.3.1.1.2.5. CEHDI ⏰
CE Heartbeat Dead Interval (CE HDI). This is the time interval the FE uses to check CE liveness. If the FE hasn't received any messages from the CE within this interval, it deduces lost connectivity, which means the CE is dead or the association to the CE is lost 💀 The default value is 30 s.
7.3.1.1.2.6. FEHBPolicy 🔥
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 the CE can deduce its liveness. The policy values and their meanings are:
- 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 the CE whenever the CE sends such Heartbeat Request messages. Refer to Section 7.10 and Section 4.3.3 for details.
- 1 - This policy says the 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 the FE to the CE during that interval, as described in Section 4.3.3. 💪
- Others - Reserved.
7.3.1.1.2.7. FEHI 🌷
FE Heartbeat Interval (FE HI). This is the time interval the FE should use to send HB as long as no other messages were sent from the FE to the CE during that interval, as described in Section 4.3.3. The default value for an FE HI is 500 ms.
7.3.1.1.2.8. CEID 🫶
Primary CEID. This is the CEID the FE is associated with.
7.3.1.1.2.9. LastCEID 🕰️
Last Primary CEID. This is the CEID of the last CE the FE was associated with. This CE ID is reported to the new Primary CEID.
7.3.1.1.2.10. BackupCEs 🧸
This is the list of backup CEs an FE can use as backups. Refer to Section 8 for details.
7.3.1.1.2.11. CEFailoverPolicy 🚨
CE failover policy. This specifies how the FE behaves when its association with the CE is lost. This is tightly related to Section 7.3.1.1.2.8, Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an association is lost, depending on configuration, one of the policies below gets activated:
- 0 (default) - The FE should stop functioning immediately and transition to FE OperDisable.
- 1 - The FE should keep running and do what it can even without an associated CE. This basically requires the FE to support CE Graceful restart, and it defines that support in its capabilities. If the CEFTI expires before the FE re-associates with either the primary CEID (Section 7.3.1.1.2.8) or one of possibly several backup CEs (Section 7.3.1.1.2.10), the FE will go operationally down 😭
- Others - Reserved.
7.3.1.1.2.12. CEFTI ⌛
CE Failover Timeout Interval (CEFTI). This is the time interval associated with CE failover policy cases '0' and '1'. The default value is 300 seconds. It's advisable to set the CEFTI much higher than the CE Heartbeat Dead Interval (CE HDI), because expiring this parameter is absolutely devastating to the FE's operation 💀
7.3.1.1.2.13. FERestartPolicy 🔄
FE restart policy. This specifies how the FE behaves during an FE restart. The restart may come from an FE failure or from other reasons that have left the FE down and in need of a restart. The values are:
- 0(default)- Restart the FE from scratch. In this case, the FE should start from the pre-association phase.
- Others - Reserved for future use.
7.3.2. FE Object LFB 🌟
The FE Object LFB is a logical entity in each FE, and it holds components about the FE itself, not about how the ForCES protocol runs 🧁
The formal definition of the FE Object LFB can be found in [RFC5812]. This model captures the high-level properties of the FE that the CE needs to know before it can start working with the FE. The class ID for this LFB class is also assigned in [RFC5812]. The singular instance of this class will always exist and will always have instance ID 0x1 within its class. It's common, although not mandatory, for a CE to fetch much of the component and capability information from this LFB instance when it begins controlling the FE's operation 🫶
7.4. Semantics of Message Direction 🧭
Recall: the PL gives us a master(CE)-slave(FE) relationship. The LFBs live at the FE and get controlled by the CE 👑
When messages go from the CE, the LFB selector (class and instance) refers to the destination LFB selection that resides in the FE. 📬
When messages go from the FE to the CE, the LFB selector (class and instance) refers to the source LFB selection that resides in the FE. 📭
7.5. Association Messages 💌
The ForCES Association messages are used to establish and tear down associations between FEs and CEs. It's giving connection, bestie 🦋
7.5.1. Association Setup Message 💌
Okay bestie, this is the FE reaching out to the CE to set up a ForCES association between them 💖.
Message transfer direction: FE to CE 🦋
Message header: The Message Type is MessageType='AssociationSetup'. The ACK flag MUST be ignored 🙅♀️, and the Association Setup message always expects a response from the receiver (CE), whether or not the setup works. The correlator field is set so the FE can match the response that comes back 🔗. The FE may set the source ID to 0 in the header to ask the CE to assign an FE ID in the Setup Response message 🧚.
Message body: The body can optionally hold zero, one, or two LFBselect TLVs (see Section 7.1.5) 🎀. It only works with the FE Object and FE Protocol LFBs, so the LFB class ID in the LFBselect TLV only points to those two kinds of LFB 💅.
The OPER-TLV inside the LFBselect TLV is a REPORT operation. More than one component can be announced this way, so the FE can declare its config parameters without being asked 📣. These can include suggestions like the FE HB Interval or the FEID ✨.
OPER-TLV for Association Setup:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23: OPER-TLV
Type: Only one operation type is defined for the Association Setup message:
Type = "REPORT"- the FE uses this to report something to the CE 📝.
PATH-DATA-TLV for REPORT: This is the generic PATH-DATA-TLV format from the PATH-DATA BNF definition in Section 7 🧩. A PATH-DATA-TLV for the REPORT operation MAY contain FULLDATA-TLV(s), but SHALL NOT contain any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.7, and the FULLDATA-TLV is defined in Section 7.1.8 📚.
Here's a tree so you can see the whole PDU shape 🌳:
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 componentsFigure 24: PDU Format for Association Setup Message
7.5.2. Association Setup Response Message 🎉
This is the CE answering the FE's Setup message 💬. It tells the FE whether the setup worked, meaning whether an association was actually established ✅.
Message transfer direction: CE to FE
Message header: The Message Type is MessageType='AssociationSetupResponse'. The ACK flag MUST be ignored 🙃. The Setup Response message never expects any more responses from the receiver (FE) 🛑. The destination ID in the header is set to the source ID from the matching Association Setup message, unless that source ID was 0. If it was 0, the CE assigns an FE ID value and uses that value as the destination ID 🪄.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 25: ASResult OPER-TLV
Type (16 bits): The TLV type is "ASResult" 🏷️.
Length (16 bits): The length of the whole TLV, including the T and L fields, counted in octets 📏.
Association Setup result (32 bits): This says whether the Setup message worked, or whether the CE turned the FE's request down 🚦. The defined values are:
0= success 🥳1= FE ID invalid 🙅2= permission denied 🔒
Here's the PDU tree 🌳:
main hdr (type = Association Setup Response)
|
|
+--- T = ASResult-TLVFigure 26: PDU Format for Association Setup Response Message
7.5.3. Association Teardown Message 👋
This message can be sent by the FE or the CE to any ForCES element, to end its ForCES association with that element 💔.
Message transfer direction: CE to FE, or FE to CE (or CE to CE) 🔁
Message header: The Message Type is 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 0️⃣.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 27: ASTreason-TLV
Type (16 bits): The TLV type is "ASTreason" 🏷️.
Length (16 bits): The length of the whole TLV, including the T and L fields, counted in octets 📏.
Teardown reason (32 bits): This explains why the association is ending 😢. Several reason codes are defined:
0- normal teardown by administrator 🧑💼1- error - loss of heartbeats 💓2- error - out of bandwidth 📉3- error - out of memory 🧠4- error - application crash 💥255- error - other or unspecified ❓
Here's the PDU tree 🌳:
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason-TLVFigure 28: PDU Format for Association Teardown Message
7.6. Configuration Messages 🎛️
The ForCES Configuration messages are how the CE configures the FEs in a ForCES NE, and how the FEs report the results back to the CE 🛠️.
7.6.1. Config Message ⚙️
This is the CE sending the FE a message to configure LFB components in the FE 🧁. The CE also uses it to subscribe and unsubscribe to LFB events 🔔.
Like every ForCES message, a Config message is a common header followed by a message body made of one or more TLV data formats 📦. Here are the details:
Message transfer direction: CE to FE
Message header: The Message Type is MessageType= 'Config'. The ACK flag in the header can be set to any value defined in Section 6.1, to say whether the FE should send back a response 📬.
OPER-TLV for Config:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 29: OPER-TLV for Config
Type: This is the operation type for the Config message. Five operation types are defined 🎀:
Type = "SET"- sets LFB components 🧱.Type = "SET-PROP"- sets LFB component properties 🎨.Type = "DEL"- deletes some LFB components 🗑️.Type = "COMMIT"- sent to the FE to commit a 2pc transaction. A COMMIT TLV is an empty TLV, meaning it has no "V"alue. So its length is 4, which is just the header 🤝.Type = "TRCOMP"- sent to the FE to mark a 2pc transaction as successful from an NE perspective. A TRCOMP TLV is also empty, with no "V"alue, so its length is 4, which is just the header 🏁.
PATH-DATA-TLV: This is the generic PATH-DATA-TLV format from the PATH-DATA-TLV BNF definition in Section 7 🧩. For SET and SET-PROP, the PATH-DATA-TLV MUST contain either FULLDATA-TLV or SPARSEDATA-TLV(s), and MUST NOT contain any RESULT-TLV 🚫. For DEL, it MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.7, and FULLDATA-TLVs and SPARSEDATA-TLVs are defined in Section 7.1.8 📚.
Note: For Event subscription, the events are defined by the individual LFBs 🔔.
Here's the PDU tree for the whole thing 🌳:
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
.
.Figure 30: PDU Format for Configuration Message
7.6.2. Config Response Message ✨
okay bestie, this one is the FE's reply to a Config message 💌 It tells the CE whether the Config actually worked on the FE, and it also gives a detailed result for each component 🎀
Message transfer direction:
FE to CE
Message header:
The Message Type gets set to MessageType= 'Config Response' 💖 The ACK flag is always ignored here, and the Config Response never waits for another reply from the CE (the message receiver) 🦋
OPER-TLV for Config Response:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 31: OPER-TLV for Config Response
Type:
The operation type for the Config Response message. Two types of operations for the Config Response message are defined, plus two more that show up in the list below 🌸
Type = "SET-RESPONSE"- This is the response to the SET operation of LFB components.Type = "SET-PROP-RESPONSE"- This is the response to the SET-PROP operation of LFB component properties.Type = "DEL-RESPONSE"- This is the response to the DELETE operation of LFB components.Type = "COMMIT-RESPONSE"- This 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. 👑
PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format, defined in Section 7 in the PATH-DATA-TLV BNF definition. For the SET-RESPONSE operation, the PATH-DATA-TLV MUST contain RESULT-TLV(s). For the DEL-RESPONSE operation, it also MUST contain RESULT-TLV(s). The RESULT-TLV is defined in Section 7.1.7 🧚
Here's a tree picture so you can see the whole PDU format at once 🌈
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-TLVFigure 32: PDU Format for Config Response Message
7.7. Query Messages 🔍
The ForCES Query messages are how the CE asks the FE about LFBs, like their components, capabilities, statistics, and more ✨ Query messages cover the Query message and the Query Response message.
7.7.1. Query Message 💅
A Query message is a common header plus a message body with one or more TLV data formats. Here's the full scoop 🫶
Message transfer direction:
from CE to FE
Message header:
The Message Type gets set to MessageType= 'Query'. The ACK flag is always ignored, and a full response is always expected for a Query. The Correlator field in the header is set, so the CE can match the response back to the right query 🎯
OPER-TLV for Query:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 33: TLV for Query
Type:
The operation type for query. Two operation types are defined:
Type = "GET"- This asks to get LFB components.Type = "GET-PROP"- This asks to get LFB component properties.
PATH-DATA-TLV for GET/GET-PROP:
This is generically a PATH-DATA-TLV format, defined in Section 7 in the PATH-DATA-TLV BNF definition. For GET/GET-PROP, the PATH-DATA-TLV MUST NOT contain any SPARSEDATA-TLV or FULLDATA-TLV and RESULT-TLV in the data format. 🙅♀️
Tree picture time 🌸
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
.Figure 34: PDU Format for Query Message
7.7.2. Query Response Message 🦋
When the receiver gets a Query message, it should process the message and come up with a query result. The receiver sends that result back to the sender using the Query Response message. The result can be the information that was queried if the operation worked, or error codes if it failed, showing why it failed 💔
A Query Response is also a common header plus a message body with one or more TLVs describing the result. Full details below 💜
Message transfer direction:
from FE to CE
Message header:
The Message Type gets set to MessageType= 'QueryResponse'. The ACK flag is ignored. As a response itself, this message doesn't expect a further response 🌷
OPER-TLV for Query Response:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 35: TLV for Query Response
Type:
The operation type for query response. One operation type is defined:
Type = "GET-RESPONSE"- This is the response to the GET operation of LFB components.Type = "GET-PROP-RESPONSE"- This is the response to the GET-PROP operation of LFB components.
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
This is generically a PATH-DATA-TLV format, defined in Section 7 in the PATH-DATA-TLV BNF definition. For the GET-RESPONSE operation, the PATH-DATA-TLV MAY contain SPARSEDATA-TLV, FULLDATA-TLV, and/or RESULT-TLV(s) in the data encoding. The RESULT-TLV is defined in Section 7.1.7, and the SPARSEDATA-TLVs and FULLDATA-TLVs are defined in Section 7.1.8 🎀
Tree time again ✨
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
.Figure 36: PDU Format for Query Response Message
7.8. Event Notification Message 🔔
The Event Notification message is how the FE tells the CE about events that happen on the FE, asynchronously 💅
Every event an FE can generate is subscribable by the CE 🙌 The CE subscribes to an event with a Config message using the SET-PROP operation, and the included path names the event, as defined by the LFB Library and described by the FE Model.
As usual, an Event Notification is a common header plus a message body with one or more TLV data formats. Here's the detail 🌈
Message transfer direction:
FE to CE
Message header:
The Message Type gets set to 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 🦋
OPER-TLV for Event Notification:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 37: TLV for Event Notification
Type:
Only one operation type is defined for the Event Notification message:
Type = "REPORT"- This type of operation is for the FE to report something to the CE. 📣
PATH-DATA-TLV for REPORT:
This is generically a PATH-DATA-TLV format, defined in Section 7 in the PATH-DATA-TLV BNF definition. For the REPORT operation, the PATH-DATA-TLV MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV in the data format. ⚠️
Last tree for this part 🧚
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)Figure 38: PDU Format for Event Notification Message
7.9. Packet Redirect Message ✨
okay bestie, the Packet Redirect message is how data packets get passed between the CE and the FE 🦋 usually they're control packets, but they can also be data path packets that just need extra exception or high-touch processing 💅 and it's totally feasible for this message to carry no data packets and just meta data 🧚
The Packet Redirect message is laid out like this:
Message transfer direction:
CE to FE or FE to CE 💖
Message header:
the Message Type in the header is set to MessageType= 'PacketRedirect' 🎀
Message body:
this is one or more TLVs that contain or describe the packet being redirected 🌸 the TLV is specifically a Redirect TLV (with the TLV Type="Redirect"), and here's the detailed data format for a Redirect TLV in a Packet Redirect message 👀
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: Redirect_Data TLVMeta Data TLV:
this is a TLV that specifies meta data associated with the followed redirected data 🍓 the TLV looks like this:
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: METADATA-TLVMeta Data ILV:
this is an Identifier-Length-Value format that describes one meta data item 🦋 the ILV has the format:
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Meta Data ILVwhere Meta Data ID is an identifier for the meta data, which is statically assigned by the LFB definition 🧠
Redirect Data TLV:
this is a TLV describing one packet of data to be directed via the redirect operation 💅 the TLV format is:
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: Redirect Data TLVRedirected Data:
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 meta data infers what kind of packet is carried in the value field, which lets you decode the encapsulated data super easily 🙌
to see the whole PDU format at a glance, here's the tree structure:
main hdr (type = PacketRedirect)
|
|
+--- T = Redirect
. |
. +-- T = METADATA-TLV
| |
| +-- Meta Data ILV
| |
| +-- Meta Data ILV
| .
| .
|
+-- T = REDIRECTDATA-TLV
|
+-- // Redirected Data
Figure 43: PDU Format for Packet Redirect Message7.10. Heartbeat Message 💜
the Heartbeat (HB) message is how one ForCES element (FE or CE) asynchronously tells one or more other ForCES elements in the same ForCES NE that it's still alive 🫶 Section 4.3.3 describes the traffic-sensitive approach used.
a Heartbeat message is sent by a ForCES element periodically 💖 the parameterization and policy definition for heartbeats for an FE are managed as components of the FE Protocol Object LFB, and the CE can set them via a Config message 🎀 the Heartbeat message is a little different from other protocol messages, because it's only a common header with the message body left empty 🦋 here's the full scoop:
Message transfer direction:
FE to CE or CE to FE 💅
Message header:
the Message Type in the message header is set to MessageType = 'Heartbeat' 🌸 Section 4.3.3 describes the HB mechanisms used. the ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK' when the HB is sent ✨
- when set to
'NoACK', the HB is not soliciting for a response 💤 - when set to
'AlwaysACK', the HB Message sender is always expecting a response from its receiver 👀 according to the HB policies defined in Section 7.3.1, only the CE can send such an HB message to query FE liveness 👑 for simplicity and because the HB message is so minimal, the response to an HB message is another HB message, so no specific HB Response message is defined 🧚 whenever an FE receives an HB message marked with'AlwaysACK'from the CE, the FE MUST send an HB message back immediately 🔥 the HB message sent by the FE in response to the'AlwaysACK'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'AlwaysACK'set 🙅♀️ - when set to anything else other than
'NoACK'or'AlwaysACK', the HB message is treated as if it was a'NoACK'🤷♀️
the correlator field in the HB message header SHOULD be set accordingly when a response is expected, so a receiver can correlate the response correctly 💜 the correlator field MAY be ignored if no response is expected 🌈
Message body:
the message body is empty for the Heartbeat message 🫧
8. High Availability Support ✨
the ForCES protocol provides mechanisms for CE redundancy and failover, so it can support High Availability as defined in [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, and this information 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 🔥
8.1. Relation with the FE Protocol 🎀
Okay so, High Availability settings on an FE are controlled by configuring the FE Protocol Object LFB (check out Appendix B and Section 7.3.1 for that 💅). The FE Heartbeat Interval, the CE Heartbeat Dead Interval, and the CE Heartbeat policy are what help the FE notice when its connection to a CE is having problems 🫶. The CE failover policy decides what the FE does once it has spotted a failure ✨.
Figure 44 is the state machine from Figure 4, glowed up with new states so the FE can recover its connection 🦋.
(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 |
+_________________________________________+
Figure 44: FE State Machine Considering HASection 4.2 is where you'll find the transitions between the pre-association, associated, and not associated states 🧚.
Now, when communication breaks down between the FE and the CE (could be the CE acting up or a link failing, but not anything the FE did 🙈), one of two things happens. Either the TML on the FE tells the FE PL about the failure, or the FE spots it itself using the HB messages between FEs and CEs 👀. Either way, the communication failure MUST be treated as a loss of association between the CE and the matching FE 💀.
If the FE's FEPO CE failover policy is set to mode 0 (the default, bestie), the FE goes straight into the pre-association phase 🌸. That means if the association gets set up again, the FE has to rebuild all of its state from scratch 😭.
If the FE's FEPO CE failover policy is set to mode 1, that tells us the FE can do HA restart recovery 👑. In that case the FE moves to the not associated state and starts the CEFTI timer ⏱️. The FE MAY keep forwarding packets during this state 🚀. It MAY also cycle through any secondary CEs it has configured, round-robin style 🔁. It starts by moving its primary CE to the tail of the backup CEs, then makes the first secondary its new primary 🍓. After that it tries to associate with whichever CE is now the primary 💜. If it can't re-associate with any CE and the CEFTI timer runs out, the FE drops back to the pre-association state 😔.
If the FE manages to reconnect to a new primary CE before the CEFTI timer expires, it goes to the associated state 🎉. Once it's re-associated, the FE tries to get back any state it might have lost while it was not associated 🧼. How it does that is out of scope for this document, so we're leaving it alone 🙃.
Figure 45 shows the ForCES message sequences the FE uses to recover its connection 💖.
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 |<------------------------------------------>|
Figure 45: CE Failover for Report Primary ModeA CE-to-CE synchronization protocol would be needed for fast failover and to handle some of the tricky corner cases 🙈. But that's not something the ForCES protocol defines itself, since it's out of scope for this spec 🚫.
Also, an explicit message can be used to change the primary CE for an FE during normal operation 🔄. It's a Config message that sets the primary CE component in the FE Protocol Object, and it comes from the primary CE itself 🎀.
Oh, and the FEs in a ForCES NE could also use a multicast CE ID, meaning they could be associated with a whole group of CEs 🌈. That assumes a CE-CE synchronization protocol is in place, which again is out of scope here. In that setup, losing association means communication with the entire multicast group of CEs has been lost 😱. The mechanisms above still apply during that loss of association ✨. But if the secondary CE was also using the multicast CE ID that got lost, the FE will need to form a new association with a different CE ID 💅. If the capability exists, the FE MAY first try forming a new association with the original primary CE, using a different non-multicast CE ID 🦋.
8.2. Responsibilities for HA 💜
TML level:
- The TML controls logical connection availability and failover.
- The TML also controls peer HA management.
At this level, the TML is in charge of all the lower layers, like transport level stuff (IP addresses, MAC addresses, and so on) and what happens when the associated links go down 🫶.
PL level:
All the other stuff is the PL's job 🧚. That includes configuring the HA behavior during setup, the CE IDs used to tell primary and secondary CEs apart, the protocol messages used to report CE failure (Event Report), the Heartbeat messages used to detect association failure, the messages used to change the primary CE (Config), and the other HA-related operations we covered earlier 🌸.
Putting it together: if the path to a primary CE goes down, the TML handles failing over to a backup path, as long as one is available 🔁. If the CE is totally unreachable, the PL gets informed and takes the appropriate actions described earlier 🚨.
9. Security Considerations 🔐
The ForCES framework document [RFC3746], Section 8, goes into serious detail about a whole bunch of security threats, what those threats could do to the protocol, and how to respond to them 💀. This document doesn't repeat all that. Go read the ForCES framework document [RFC3746] for those details and to see how the ForCES architecture deals with them 📖.
ForCES PL relies on security services provided by the ForCES TML 🛡️. The TML offers services like endpoint authentication, message authentication, and confidentiality ✨. Endpoint authentication happens during the pre-association connection establishment phase, and message authentication is done every time the FE or CE gets a packet from its peer 🫶.
Here are the general security mechanisms that need to be in place for ForCES PL 💖:
- Security mechanisms are session controlled. Once security is turned on, depending on the chosen security level (No Security, Authentication, Confidentiality), it stays in effect for the entire duration of the session 🔒.
- An operator should configure the same security policies for both primary and backup FEs and CEs (if available). This keeps operations uniform and avoids unnecessary complexity in policy configuration 🎀.
9.1. No Security 🙈
When "No Security" is chosen for ForCES protocol communication, both endpoint authentication and message authentication service need to be performed by ForCES PL. Both of these mechanisms are weak and don't involve any cryptographic operations 😬. An operator can pick the "No Security" level when the ForCES protocol endpoints are inside a single box, for example 📦.
To get interoperable, uniform implementations across the different security levels, each CE and FE endpoint MUST implement this level 💜.
What's described in Section 9.1.1 and Section 9.1.2 are error checks, not security procedures 🧐. If you want the actual security procedures, check out Section 9.2 🔍.
9.1.1. Endpoint Authentication 🪪
Each CE and FE PL keeps a list of associations as part of its configuration 📋. That's done through the CEM and FEM interfaces 🔌. An FE MUST only connect to the CEs configured via the FEM 🚫. Similarly, a CE should accept connections and set up associations for the FEs configured via the CEM 🤝. The CE should validate the FE identifier before accepting connections during the pre-association phase ✅.
9.1.2. Message Authentication 📨
When a CE or FE starts a message, the receiving endpoint MUST validate who sent it by checking the CE or FE identifiers in the common header 🕵️♀️. That's what keeps protocol functioning proper 👑. This extra step is recommended even when the underlying TML layer security services are in place 💅.
9.2. ForCES PL and TML Security Service 🛡️
This section applies if an operator wants to use the TML security services 🎀. A ForCES TML MUST support one or more security services, such as endpoint authentication, message authentication, and confidentiality, as part of its TML security layer functions 🔐. The operator is responsible for picking an appropriate security service and configuring the security policies to match ✨. The details of that configuration are outside the scope of the ForCES PL and depend on the type of transport protocol and the nature of the connection 🌸.
All of these configurations should be done before starting the CE and FE 🚀.
When certificate-based authentication is used at the TML, the certificate can use a ForCES-specific naming structure for certificate names, and the security policies can then be configured at the CE and FE accordingly 📜.
Please refer to the specific TML documents for details on the security requirements of that particular TML 📚.
9.2.1. Endpoint Authentication Service 🪪
When TML security services are enabled, the ForCES TML performs endpoint authentication 🔑. A security association gets set up between the CE and FE, and it's transparent to the ForCES PL 🫥.
9.2.2. Message Authentication Service 📬
This is a TML-specific operation and it's transparent to the ForCES PL 🦋. For details, refer to Section 5 💖.
9.2.3. Confidentiality Service 🔐
Okay so this one is a TML-only thing 🫶, and the ForCES PL totally doesn't even notice it's happening ✨. Like, it's transparent to the PL. If you want the full tea, check out Section 5 💅.
10. Acknowledgments 🎀
Okay, big group hug time 🫶 to the ForCES Working Group, and to these amazing people for all their contributions 💖: Furquan Ansari, Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Zsolt Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang. We also owe a huge thank you to David Putzolu and Patrick Droz for their comments and suggestions on the protocol, and for their infinite patience 🥹. And Sue Hares and Alia Atlas get a massive shoutout for their extensive reviews of the document 👑.
Alia Atlas really went above and beyond here 🌸, making the document way more readable by passing along the IESG feedback. Ross Callon was the one who got us over the major humps so this could actually get published 🚀.
The editors used the xml2rfc [RFC2629] tools to create this document and are super grateful for how good those tools are 🧚. The editor also thanks Elwyn Davies for helping fix the XML source of this document 💜.
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008.
[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.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.11.2. Informative References
[2PCREF] Gray, J., "Notes on database operating systems", in
"Operating Systems: An Advanced Course" Lecture Notes in
Computer Science, Vol. 60, pp. 394-481, Springer-Verlag,
1978.
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction-
Orientated Database Recovery", 1983.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.Appendix A. IANA Considerations 🌈
Following the policies in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 5226 [RFC5226]), these are the namespaces ForCES defines 🦋:
- Message Type Namespace, Section 7
- Operation Type Namespace, Section 7.1.6
- Header Flags, Section 6.1
- TLV Type, Section 7
- TLV Result Values, Section 7.1.7
- LFB Class ID, Section 7.1.5 (resolved by model document, [RFC5812].
- Result: Association Setup Response, Section 7.5.2
- Reason: Association Teardown Message, Section 7.5.3
A.1. Message Type Namespace 💜
The Message Type is an 8-bit value. Here's the vibe for how the Message Type namespace gets defined ✨:
- Message Types 0x00 - 0x1F: These are part of the base ForCES protocol, and they get allocated through an IETF consensus action [RFC5226]. The values this spec assigns are:
0x00 Reserved
0x01 AssociationSetup
0x02 AssociationTeardown
0x03 Config
0x04 Query
0x05 EventNotification
0x06 PacketRedirect
0x07 - 0x0E Reserved
0x0F Hearbeat
0x11 AssociationSetupResponse
0x12 Reserved
0x13 ConfigResponse
0x14 QueryResponse- Message Types 0x20 - 0x7F: These are Specification Required [RFC5226]. Anything using this range MUST be documented in an RFC or other permanent and readily available reference.
- Message Types 0x80 - 0xFF: These are reserved for vendor private extensions and belong to individual vendors 🍓. IANA doesn't need to manage this range.
A.2. Operation Selection 🎀
The Operation Selection (OPER-TLV) namespace is 16 bits long. Here's the guideline for managing it 💅:
- OPER-TLV Type 0x0000-0x0FF: These get allocated through an IETF consensus process [RFC5226]. The values this spec assigns are:
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- OPER-TLV Type 0x0100-0x7FFF: Anything using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
- OPER-TLV Type 0x8000-0xFFFF: These are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range is unnecessary 🙈.
A.3. Header Flags 🚩
The Header flag field is 32 bits long. Header flags are part of the ForCES base protocol, and they get allocated through an IETF consensus action [RFC5226] ✨.
A.4. TLV Type Namespace 🧚
The TLV Type namespace is 16 bits long. Here's the guideline for managing it 💖:
- TLV Type 0x0000-0x01FF: These get allocated through an IETF consensus process [RFC5226]. The values this spec assigns are:
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- TLV Type 0x0200-0x7FFF: Anything using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
- TLV Type 0x8000-0xFFFF: These are reserved for vendor private extensions and belong to individual vendors. IANA management of this range is unnecessary 🌸.
A.5. RESULT-TLV Result Values 💀
The RESULT-TLV Result Value is an 8-bit value. Here are the values ✨:
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_ERRORAny value not assigned in this specification is designated as Assignment by Expert Review 🔍.
A.6. Association Setup Response 🦋
The Association Setup Response namespace is 32 bits long. Here's the guideline for managing it 🫶:
- Association Setup Response 0x0000-0x00FF: These get allocated through an IETF consensus process [RFC5226]. The values this spec assigns are:
0x0000 Success
0x0001 FE ID Invalid
0x0002 Permission Denied- Association Setup Response 0x0100-0x0FFF: These are Specification Required [RFC5226]. Values using this range MUST be documented in an RFC or other permanent and readily available reference [RFC5226].
- Association Setup Response 0x1000-0xFFFF: These are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range is unnecessary 🍓.
A.7. Association Teardown Message 🌈
The Association Teardown Message namespace is 32 bits long. Here's the guideline for managing it 👑:
- Association Teardown Message 0x00000000-0x0000FFFF: These get allocated through an IETF consensus process [RFC5226]. The values this spec assigns are:
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- Association Teardown Message 0x00010000-0x7FFFFFFF: These are Specification Required [RFC5226]. Anything using this range MUST be documented in an RFC or other permanent and readily available references. [RFC5226].
- Association Teardown Message 0x80000000-0xFFFFFFFFF: These are reserved for vendor private extensions and belong to individual vendors. IANA management of this range is unnecessary 💜.
Appendix B. ForCES Protocol LFB Schema ✨
okay so this schema is totally aligned with the LFB schema from the ForCES model [RFC5812] 💅
Section 7.3.1 spills all the tea on the different components defined in here 🫶
<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>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 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>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>
</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>B.1. Capabilities
Supportable Versions is the list of every ForCES version an FE can handle, so it's basically the FE's version wardrobe 👗🌸
FEHACapab is the rundown of the FE's HA capabilities. If the FE can't do graceful restarts or HA, then it's not going to be able to join the HA party described in Section 8.1 🥺
B.2. Components
All of the components get the full breakdown in Section 7.3.1 🎀
Appendix C. Data Encoding Examples 🎀
okay so this bit is all about showing how data actually gets encoded 💅 quick heads-up first: these examples don't show any padding 🙈
Example 1 🧚
Our first structure has three fixed-lengthof, mandatory fields:
struct S {
uint16 a
uint16 b
uint16 c
}(a) Describing all fields using SPARSEDATA-TLV
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)(b) Describing a subset of fields
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)Note: even though S has non-optional components, you can still uniquely identify each one, so you can selectively send components of S. Think of it like an update going from a CE to an FE 🫶
(c) Describing all fields using a FULLDATA-TLV
PATH-DATA-TLV
Path to an instance of S ...
FULLDATA-TLV
valueof(a)
valueof(b)
valueof(c)Example 2 💖
Next up is a structure with three fixed-lengthof fields. One is mandatory and two are optional:
struct T {
uint16 a
uint16 b (optional)
uint16 c (optional)
}This one is basically identical to Example 1, as you can see below ✨
(a) Describing all fields using SPARSEDATA-TLV
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)(b) Describing a subset of fields using SPARSEDATA-TLV
PATH-DATA-TLV
Path to an instance of S ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)(c) Describing all fields using a FULLDATA-TLV
PATH-DATA-TLV
Path to an instance of S ...
FULLDATA-TLV
valueof(a)
valueof(b)
valueof(c)Note: FULLDATA-TLV cannot be used unless all fields are being described 💀
Example 3 🌸
This one mixes fixed-lengthof and variable-length fields, with some mandatory and some optional. Heads-up that b is variable sized here 👀
struct U {
uint16 a
string b (optional)
uint16 c (optional)
}(a) Describing all fields using SPARSEDATA-TLV
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)(b) Describing a subset of fields using SPARSEDATA-TLV
Path to an instance of U ...
SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c)(c) Describing all fields using FULLDATA-TLV
Path to an instance of U ...
FULLDATA-TLV
valueof(a)
FULLDATA-TLV
valueof(b)
valueof(c)Note: a variable-length field needs an extra FULLDATA-TLV nested inside the outer FULLDATA-TLV, just like component b above does 🧁
Example 4 🦋
Last one in this batch: a structure that contains an array of another structure type 🌈
struct V {
uint32 x
uint32 y
struct U z[]
}(a) Encoding using SPARSEDATA-TLV, with two instances of z[], also described with SPARSEDATA-TLV, assuming only the 10th and 15th subscripts of z[] are encoded.
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)Peep the holes in z's components (10, then 15) 👀 Also notice the gap at index 15, where only components a and c show up and b is missing.
Appendix D. Use Cases 💅
Let's assume an LFB with the following components for the use cases below 🌸
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}All the examples use valueof(x) to show the value of the referenced component x. If the F_SEL** bits are missing (the bits equal 00), the flags won't show any selection ✨
All the examples only use FULLDATA-TLV for data encoding. SPARSEDATA-TLV would make more sense in some situations, but the emphasis here is on showing the message layout. Check out Appendix C for examples that use both FULLDATA-TLV and SPARSEDATA-TLV 🧚
1. To get foo1 💖
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)2. To set foo2 to 10 🌷
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-TLV3. To dump table2 🦋
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 tableNote: you should be able to take a GET-RESPONSE-TLV and turn it into a SET-TLV 🍓 If the result from the example above gets sent back in a SET-TLV (instead of a GET-RESPONSE_TLV), then the entire contents of the table get replaced right then and there 😭
4. Multiple operations example: creating entries 0-5 of table2 🌈
Error conditions are ignored here 🙈
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
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-TLV5. Block operations (with holes) example: replacing entries 0 and 2 of table2 👑
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-TLV6. Getting rows example: getting the first entry of table2 ⭐
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)7. Getting entries 0-5 of table2 🫶
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 = 5Result:
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)- Create a row in table2, index 5. ✨
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- Dump the contents of table1. Time to see everything in there 👀
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)
.
.
.- Using keys, bestie! 🔑 We're grabbing the row in table4 where j1=100. j1 is a defined key for this table and its KeyID is 1, so we're matching on that.
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)- Delete the row that matches the KEY (j1=100, j2=200) in table2. Heads up, the j1,j2 pair is a defined key for table2, so that's the combo we're hunting for 🎯
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- Dumping table3 now 🧜♀️ This one has a column with a component name that's variable sized, so the whole point of this use case is to show how that kind of component gets encoded. Iconic.
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)
.
.
.- Multiple atomic operations, and this one is giving "big plot twist" 🌪️
Note 1: This is basically adding a new nexthop entry and then atomically updating the L3 entries that point to an old NH so they point to the new one. Both tables are assumed to live in the same LFB, so no drama there. 💅
Note: Notice that both operations hit the LFB instance, and both are SET operations. Consistent queen behaviour 👑
//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- Selective setting! 🎀 On table4, for indices 1, 3, 5, 7, and 9, we replace j1 with 100, j2 with 200, and j3 with 300. j4 stays exactly as it is, because we're not touching it.
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- Table-of-tables time! 🪆 Get x1 from the table10 row with index 4, sitting inside table5 entry 10.
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)- Next up, from table5's row 10 table10, we grab the X2s where x1 equals 10. Recall that x1 is KeyID 1 ✨
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)- Last but not least, a further example of manipulating a table of tables 🌈 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 2Okay bestie, imagine you want to set three things in ONE go: table6.10.p1 to 111, table6.10.p2.20.a1 to 222, and table6.10.p2.20.a2.30.b1 to 333. All in one message, one operation 💅
table6.10.p1 to 111
table6.10.p2.20.a1 to 222
table6.10.p2.20.a2.30.b1 to 333There are two ways to make this happen 🦋
a) using nesting b) using a flat path data
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-TLVB. 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- Get a whole LFB (all its components, etc.). 🧚
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:
operation = GET-TLV
PATH-DATA-TLV
flags = 0 IDCount = 0Result:
operation = GET-RESPONSE-TLV
PATH-DATA-TLV
flags = 0 IDCount = 0
FULLDATA-TLV encoding of the FE Object LFBAuthors' Addresses 💜
Avri Doria (editor)
Lulea University of Technology
Rainbow Way
Lulea SE-971 87
Sweden
Phone: +46 73 277 1788
EMail: avri@ltu.seJamal Hadi Salim (editor)
Znyx
Ottawa, Ontario
Canada
Phone:
EMail: hadi@mojatatu.comRobert Haas (editor)
IBM
Saumerstrasse 4
8803 Ruschlikon
Switzerland
Phone:
EMail: rha@zurich.ibm.comHormuzd M Khosravi (editor)
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.comWeiming Wang (editor)
Zhejiang Gongshang University
18, Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
Phone: +86-571-28877721
EMail: wmwang@zjgsu.edu.cnLigang Dong
Zhejiang Gongshang University
18, Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
Phone: +86-571-28877751
EMail: donglg@zjgsu.edu.cnRam Gopal
Nokia
5, Wayside Road
Burlington, MA 310035
USA
Phone: +1-781-993-3685
EMail: ram.gopal@nsn.comJoel Halpern
P.O. Box 6049
Leesburg, VA 20178
USA
Phone: +1-703-371-3043
EMail: jmh@joelhalpern.comThat's the whole RFC, bestie! 🌈✨ You made it through all 22 parts 👑🫶
📦 where this page comes from
- ietf: rfc5810 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms