RFC 5972
General Internet Signaling Transport (GIST) State Machine
General Internet Signaling Transport (GIST) State Machine 🎀
bestie, okay so this RFC is from the IETF, and it's been around since October 2010 🍓. It's Informational, which means it's published for info and it is not a standards-track spec. The title is the General Internet Signaling Transport (GIST) State Machine 💜.
The authors are T. Tsenov and H. Tschofenig from Nokia Siemens Network, X. Fu, Ed. from Univ. Goettingen, C. Aoun (a consultant), and E. Davies from Folly Consulting 🫶. It has ISSN 2070-1721. There are no Obsoletes or Updates lines in the header, so it doesn't replace anything and doesn't change anything else 💅.
Abstract ✨
So the vibe here is that this doc describes state machines for GIST. It lays out the states that GIST nodes go through for a given flow, plus the transitions between them, so you can see how GIST might get implemented 🦋.
Status of This Memo 🌸
Again, this one is not an Internet Standards Track spec. It's just published for info 🙈.
It is a product of the IETF, it represents the consensus of the IETF community, and it went through public review. The IESG approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🔥.
For current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5972 💖.
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 stood on the publication date. Read those carefully, bestie, because they're your rights and restrictions 👑. Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 🧚.
Some of this doc may include material from IETF Documents or IETF Contributions published or publicly available before November 10, 2008. The folks who own the copyright on some of that stuff might not have let the IETF Trust allow modifications outside the IETF Standards Process 😭. Unless you get a proper license from them, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English ✨.
Table of Contents 💅
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Notational Conventions Used in State Diagrams ...................3
4. State Machine Symbols ...........................................5
5. Common Rules ....................................................6
5.1. Common Procedures ..........................................7
5.2. Common Events ..............................................8
5.3. Common Variables ...........................................9
6. State Machines .................................................11
6.1. Diagram Notations .........................................12
6.2. State Machine for GIST Querying Node ......................12
6.3. State Machine for GIST Responding Node ....................16
7. Security Considerations ........................................18
8. Acknowledgments ................................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
Appendix A. State Transition Tables ...............................20
A.1. State Transition Tables for GIST Querying Node ............20
A.2. State Transition Tables for GIST Responding Node ..........241. Introduction 🦋
Okay so the state machines in this doc are just an illustration of how the GIST protocol from [1] could get implemented for GIST nodes sitting at different spots along a flow path. If there's any difference between this doc and [1], [1] wins 👑. These state machines are informative only, and implementations can get the same results with totally different methods 💖.
There are two kinds of GIST signaling entities:
- GIST querying node: a GIST node that starts the discovery of the next peer 🔥.
- GIST responding node: a GIST node that is the discovered next peer 🫶.
The doc describes a set of state machines for these two entities so you can see how GIST might be implemented 🌸.
2. Terminology 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2] 🎀.
3. Notational Conventions Used in State Diagrams ✨
So this part is the notation section 🧚. A bunch of the text is reused from [3], and the state diagrams follow the conventions in Section 8.2.1 of [4]. Some extra state machine details come from [5] 💅.
RFC 4137 [3] reproduced the following text from Section 8.2.1 of IEEE 802-1X-2004 [4]. I've rewritten it in my own words, but I kept every rule 🍓.
State diagrams show how the protocol behaves through a bunch of cooperating state machines. Each one is a group of connected states that are mutually exclusive, which means only one state per machine can be active at any moment 🌈.
. . .
Every allowed transition between states is drawn as an arrow, and the arrowhead shows which way the transition can go. The labels on the arrows are the conditions that have to be met before the transition can happen. Every condition is an expression that evaluates to TRUE or FALSE, and if it's TRUE, the condition is met 💖. The label UCT means an unconditional transition, so UCT is always TRUE 💅.
A global transition is one that can happen from any state, as long as its condition is met. These get drawn with an open arrow, which means no specific state is named as where the transition starts 👑. When a global transition's condition is met, it beats every other exit condition, UCT included 🔥. The special global condition BEGIN beats all the other global conditions. Once it's asserted, it stays asserted until every state block has run to the point where its variable assignments and other effects stop changing 🦋.
When you enter a state, the procedures for that state (if it has any) run exactly once, in the order they're listed on the page 🌸. Each action is atomic, meaning one procedure finishes completely before the next one starts 💜. Nothing runs outside a state block 🎀. Only one state block's procedures run at a time, even when the conditions for state blocks in different machines are all satisfied. All the procedures in the running block finish before any other block can transition in and run 🫶. So from the outside, running any state block looks atomic compared to any other block, and the transition condition from the previous state is TRUE when execution starts ✨. The order that state blocks in different machines run in isn't defined, except where their transition conditions force an order 🧚. A variable that's set to a value in a state block keeps that value until a later block runs a procedure that changes it 💅.
Once all the procedures in a state are done, every exit condition for that state (including all the global transition conditions) gets checked over and over until one of them is met 🌈. The label ELSE is a transition that happens when none of the other exit conditions are met, so ELSE is TRUE only when every other exit condition from that state is FALSE 🍓. If two or more exit conditions at the same precedence become TRUE at the same time, the choice of which one causes the transition is arbitrary 💖.
On top of all that, this doc adds two clarifications. First, every boolean variable starts out FALSE before the state machine runs 🔥. Second, there's a shorthand notation specific to this doc:
<variable> = <expression1> | <expression2> | ...When a statement like this runs, the variable ends up with exactly one of the expressions as its value 👑. Which expression gets picked is decided outside the state machine. It could be environmental, configurable, or based on another state machine, like the one for the method 🦋.
4. State Machine Symbols ✨
Okay, these are the little symbols the state machines use, and they're basically the vocab you need to read the diagrams 🧚
( ): Used to force the precedence of operators in boolean expressions and to delimit the argument(s) of actions within state boxes. 💅;: Used as a terminating delimiter for actions within state boxes. When a state box has multiple actions, they run in the order you'd read English, left to right and top to bottom 📖=: Assignment action. The value of the expression on the right gets assigned to the variable on the left. If you chain it likea = b = X, the value after the right-most assignment operator gets assigned to every variable to the left of that right-most operator. Chaotic but make it make sense 🌈!: Logical NOT operator. 🙅♀️&&: Logical AND operator. 🫶||: Logical OR operator. 💜if...then...: Conditional action. If the boolean expression after the "if" evaluates to TRUE, the action after the "then" gets executed ✨{ statement 1, ... statement N }: Compound statement. Braces group statements that run together as if they were one single statement 🎀!=: Inequality. Evaluates to TRUE if the expression on the left is not equal in value to the expression on the right. 🦋==: Equality. Evaluates to TRUE if the expression on the left is equal in value to the expression on the right. 🌸>: Greater than. Evaluates to TRUE if the value of the expression on the left is greater than the value of the expression on the right. 👑<=: Less than or equal to. Evaluates to TRUE if the value on the left is either less than or equal to the value on the right. 🍓++: Increments the preceding integer operator by 1. ⭐+: Arithmetic addition operator. 🧮&: Bitwise AND operator. 🔥
5. Common Rules 🎀
Okay so throughout the whole doc we use terms that are defined in [1], like Query, Response, and Confirm. Those are the MVPs, so keep them in mind 💖
The state machine is all about handling GIST messages that match a Message Routing State's Message Routing Information (MRI), NSIS Signaling Layer Protocol identifier (NSLPID), and session identifier (SID), and that have no protocol errors. Separate parallel instances of the state machines should handle messages for different Message Routing States (MRSs). Each one gets its own lane, bestie 🛣️
The state machine shows the states and transitions of the upstream and downstream peers of the Message Routing State. It's the whole friend group, not just one person 🫂
To keep things simple, not every object in a message is shown. Only the ones that matter for the case at hand are included. State machines don't show how messages that don't affect the states get handled, because nobody needs that drama 🙈
The state machines in this document don't cover every single function of a GIST node. We call the stuff we're skipping "lower-level pre-processing" 🧹. That covers message forwarding, sending NSLP data without MRS establishment, and handing received messages to the right MRS. Pre-processing only gives the MRS state machine the messages that match a waiting Query/Response cookie, or the triplet (MRI, NSLPID, SID) of an established MRS. In the state machines, this shows up as "rx_*" events 💅
Management of messaging associations (MAs) is covered in this document through procedures, events, and variables that describe how an MA interacts with the MRS state machines. There's no separate state machine for MA management in here, so that's a little plot twist 🌀
5.1. Common Procedures 🧚
Tx_Query: Transmit of Query message. 📤Tx_Response: Transmit of Response message. 📤Tx_Confirm: Transmit of Confirm message. 📤Tx_Data: Transmit of Data message. 📤Tg_MessageStatus: NSLP/GIST API message that tells the NSLP application a message wasn't delivered successfully. 😭Tg_RecvMsg: NSLP/GIST API message that hands a received message to the NSLP application. 📬Tg_NetworkNotification: NSLP/GIST API message that tells the NSLP application the MRS has changed. 🔔Install downstream/upstream MRS: Installs a new Message Routing State and saves the matching peer state info (IP address and UDP port, or a pointer to the MA being used) for the current Message Routing State. It can also update that peer state info if it already exists. 🏠Delete MRS: Deletes the installed downstream/upstream peer's info for the current Message Routing State, and deletes the Message Routing State too if it's needed. Bye bye 👋Refresh MRS: Refreshes an installed MRS. Keeping it fresh 🌿Queue NSLP info: Saves NSLP messages in a queue until the conditions for sending them are met, like when a required MA association has been established. Patience is a virtue 🕰️CheckPeerInfo: Matches the sender of a received data message against the installed peer info in the MRS. Checking the guest list 📋Delete MA: Deletes or disconnects the MA that was being used. 🔌Stop using shared MA: Stops using a shared MA. If no other MRSs are using that shared MA anymore, the local policy decides whether it gets deleted or kept 🤷♀️Tg_Establish_MA: Triggers the establishment of a new MA. Let's get this party started 🎉Start/Restart a timer variable (Section 5.3): Starts or restarts a certain timer ⏱️Install/Update/Delete UpstreamPeerInfo variable (Section 5.3): Manages the upstream peer info in the state machine of the responding node. 🧠
5.2. Common Events 🌸
Rx_Query: Receipt of a Query message. 📥Rx_Response: Receipt of a Response message. 📥Rx_Confirm: Receipt of a Confirm message. 📥Rx_Data: Receipt of a Data message. 📥Tg_SendMsg: NSLP/GIST API message from the NSLP application that requests sending an NSLP message. Send it, babe 💌Tg_SetStateLifetime(time_period): NSLP/GIST API message that provides info on how long a Routing State (RS) should live, as the application requires. "Time_period = 0" means the NSLP application is canceling the established RSs/MAs. Ending it all 💀Tg_InvalidRoutingState: NSLP/GIST API notification from the NSLP application about a path change. Route's changed, so we pivot 🛤️Tg_ERROR: General error event or system-level error. 🚨Tg_MA_Established: A new MA has been successfully established. We did it! 🥳Tg_MA_Error: Error event involving the MA being used. 😬Timeout a timer variable (Section 5.3): A certain timer has timed out. Time's up ⌛
5.3. Common Variables 🦋
These variables are defined as:
- Specific information carried in the received messages. 📦
- Conditions that are results of processes not defined in the state machine model. 🧩
The state machine logic is based on these general conditions and the message parameters. Vibes check ✅
The type of mode and destination info is decided by the NSLP application parameters and the local GIST policy. In this doc, that's represented by the common variables D-mode, C-mode, and MAinfo. 🎀
C-mode: The message MUST be transmitted in C-mode. This is set by the "Message transfer attributes" that the NSLP application sets to any of these values:- "Reliability" is set to TRUE.
- "Security" is set to values that request secure handling of a message.
- "Local processing" is set to values that require services offered by C-mode (e.g., congestion control) [1].
D-mode: The message MUST be transmitted in D-mode. This is set by local policy rules. If the "Message transfer attributes" are NOT set by the NSLP application to any of the following values, then:- "Reliability" is set to TRUE.
- "Security" is set to values that request special security handling of a message.
- "Local processing" is set to values that require services offered by C-mode [1].
MAinfo: GIST message parameters that describe the required MA or proposed MA, e.g., "Stack-proposal" and "Stack-Configuration-Data" [1]. 🧾NSLPdata: NSLP application data. 💾RespCookie: Responder Cookie that the responding node sends with the Response message when its local policy requires a confirmation from the querying node. 🍪ConfirmRequired: Indicator that a Confirm message is required by the local policy rule for installing a new MRS. 🚦NewPeer: Indicator that a Response message came in from a new responding peer. New friend unlocked 👋MAexist: Indicator that an existing MA will be reused for data transfer between peers. Reuse, recycle, respect 🌍UpstreamPeerInfo: Upstream peer info that's saved in an established MRS. 🗂️T_Inactive_QNode: Message Routing State lifetime timer in the querying node. ⏳T_Expired_RNode: Message Routing State lifetime timer in the responding node. ⏳T_Refresh_QNode: Message Routing State refresh timer in the querying node. 🔄T_No_Response: Timer for the waiting period for a Response message in the querying node. 🫠T_No_Confirm: Timer for the waiting period for a Confirm message in the responding node. 🫠No_MRS_Installed: Data the responding node sends in a Response message to indicate that a Confirm message was lost. Oops 🙃
6. State Machines 👑
The next section presents the state machine diagrams of GIST peers. RFC 5972 is published as a .txt file, and a supplementary .pdf is being published too 📄
In the .pdf, the state machine diagrams are drawn in full detail. All the state machine info (the triggering event, the action taken, and the variable status) is shown right there in the diagrams 🎨
In the .txt, the state machine diagrams only show transition numbers. After each diagram, there's a list of state transition descriptions. The full transition details (triggering event, action taken, and variable status) are in the state transition tables in Appendix A 📚
Please use the .pdf version whenever possible. It's the clearer representation of the state machine. If the two documents ever disagree, go with the .pdf version 💖
6.1. Diagram Notations 🦋
+--------------------------------+
| STATE |
+--------------+-----------------+
|
|
ooooo
o N o Transition N
ooooo
|
v
+--------------------------------+
| STATE |
+--------------------------------+
Figure 1: Diagram notations6.2. State Machine for GIST Querying Node 🦋
okay so here's the querying node's state machine diagram 💖 Transition descriptions come right after it.
For the full scoop on each transition (what sets it off, what it does, and what happens to the variables), go check out Appendix A.1 🎀
+-----------+ ooooo
| Any State +----------o 18 o
+-----------+ ooooo
|
v
+-----------------------------------------------------------------+
| IDLE |
+--+--------------------------------------------------------------+
| ^ ^ ^
| | | |
ooooo ooooo ooooo ooooo ooooo | |
o 1 o o 2 o +o 3 o+ +o 4 o+ +o 5 o+ | |
ooooo ooooo | ooooo | | ooooo | | ooooo | | |
| | | | | | | | | |
v | | v | v | v | |
+-----------+-----+----------+----------+--------+ | |
| Wait Response | | |
+--+-------------------------------------+-------+ | |
| ^ | | |
| | | | |
ooooo | ooooo ooooo ooooo |
o 6 o | +o 5 o+ o 7 o o 8 o |
ooooo | | ooooo | ooooo ooooo |
| | | | | | |
| | | v v | |
| | +----+-------------------------------+---+ |
| | | Wait MA Establishment | |
| | +------------------------------+---------+ |
| | ^ | |
| | | | |
| ooooo ooooo ooooo ooooo ooooo
| o 9 o o 11 o +o 13 o+ o 12 o o 10 o
| ooooo ooooo | ooooo | ooooo ooooo
| | | | | | |
v | | | v v |
+----------+----------+--------+------------------------------+---+
| Established Downstream MRS |
+--+-----------+-----------+-----------+-----------+--------------+
| ^ | ^ | ^ | ^ | ^
| | | | | | | | | |
| ooooo | | ooooo | | ooooo | | ooooo | | ooooo |
+o 16 o+ +o 14 o+ +o 15 o+ +o 4 o+ +o 17 o+
ooooo ooooo ooooo ooooo ooooo
Figure 2: State Machine for GIST Querying NodeNow the transitions, bestie 👑 Labels are kept exactly as they are, so you can match each one to the diagram ✨
1**) An initial request from the NSLP application comes in and sparks Query messages asking for either D-mode or C-mode 🌸 Depending on the node's local policy, NSLP data might be piggybacked in the Query requesting D-mode 🫶 The Query may carry MAinfo if C-mode transport is needed.
2) The T_No_Response timer runs out and the max number of retries has been hit 😭 The NSLP application gets told that GIST peer discovery failed.
3) The T_No_Response timer runs out. The Query gets resent 🔁
4) A Data message shows up. It gets checked to see if its sender matches the installed downstream peer info in the MRS, and if it does, it gets processed ✅ In WaitResponse state, this might happen during an MA upgrade, when the downstream peer still isn't aware that the new MA has been established 🙈
5) The NSLP application hands over data to send. It gets queued because the downstream peer hasn't been discovered yet, or the required MA still isn't established 💅
6) A Response message is received. If a D-mode connection is requested, or the available MA can be reused for the requested C-mode, the MRS gets established 👑
7*) A Response message is received. If a C-mode connection has to be established and there's no available MA to reuse, MA establishment kicks off and the system waits for it to finish 🧚
8) MA establishment fails 💀 The NSLP application gets notified of the unsuccessful message delivery.
9) The NSLP application hands over data to send, and the requested transport parameters need an upgrade of the established MRS from D-mode/C-mode to C-mode. Or, the NSLP application tells the GIST instance about a path change. Either way, downstream GIST peer discovery starts 🦋
10) The MRS lifetime runs out, or the NSLP application says the MRS isn't needed anymore 🍓 The MRS gets deleted. If it's not needed, the MA gets deleted too. The NSLP application is notified of the MRS change.
11*) The path change is detected when a Response message from a new downstream GIST peer comes in 👀 A new MA must be established for the requested C-mode.
12*) A new MA is established ✨ The MRS gets installed, and the queued NSLP data gets sent.
13) The T_Refresh_QNode timer runs out, so the Query message gets sent 🌈
14) The NSLP application hands over data to send, and it's sent via a Data message toward the downstream GIST peer 💜
15) The Response message from the downstream GIST peer is received. The peer hasn't changed, and the MRS is refreshed (the T_Refresh_QNode timer gets restarted) 🌸
16) The path change is detected when a Response message from a new downstream GIST peer comes in. D-mode is requested, or the existing MA can be reused for the requested C-mode 🔥
17) The responding peer says it hasn't received a Confirm message and doesn't have an established upstream MRS, so the Confirm message gets resent 🫶
18) A general error or a system-level error happens 🙈 The MRS gets deleted. If it's not needed, the MA gets deleted too. The NSLP application is notified of the MRS change.
Remarks, since these matter too 🎀
*) Response and Confirm messages might be sent either in D-mode or C-mode, before or after MA establishment. That depends on the node's local three-way handshake policy and on whether there are MAs available to reuse. See [1] for details.**) Depending on GIST local policy, NSLPdata might be sent as the payload of Query and Confirm messages (piggybacking) 💖6.3. State Machine for GIST Responding Node 🎀
okay so here's the GIST responding node state machine, bestie 🦋 the diagram comes first, then the transition descriptions. if you want the full details (triggering event, action taken, and variable status), go check Appendix A.2 💅
+-----------+ ooooo
| Any State +----------o 14 o
+-----------+ ooooo
|
v
+-----------------------------------------------------------------+
| IDLE |
+--+-------------------------------+------------------------------+
| ^ | ^
| | | |
ooooo | ooooo ooooo ooooo
o 1 o | o 2 o +o 4 o+ o 3 o
ooooo | ooooo | ooooo | ooooo
| | | | | |
| | v | v |
| | +--------------------+---------------+---+
| | | Wait Confirm |
| | +---------+------------------+-----------+
| | | ^ | ^
| | | | | |
| ooooo ooooo ooooo ooooo | ooooo |
| +o 13 o+ o 8 o o 5 o o 7 o +o 6 o+
| | ooooo | ooooo ooooo ooooo ooooo
| | | | | |
v | v | v |
+------+-------------+------------------------+-------------------+
| Established Upstream MRS |
+------+-------------+-------------+------------+-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| ooooo | | ooooo | | ooooo | | ooooo |
+o 9 o+ +o 11 o+ +o 12 o+ +o 10 o+
ooooo ooooo ooooo ooooo
Figure 3: State Machine for GIST Responding Node- A Query message is received. The MRS is installed immediately because local policy permits it. The Query message might carry piggybacked NSLP data that will be provided to the NSLP application.
- A Query message is received. Local policy requires an explicit Confirm message for MRS installation. The Query message might carry piggybacked NSLP data that will be provided to the NSLP application.
- T_No_Confirm timer expires. Note that all cases of lost handshake GIST messages are handled only by the GIST querying node via resend of the Query message.
- A Query message is received again. This means that the sent Response message has not been received by the upstream GIST peer. The Response message is resent.
- A Confirm message is received that causes installation of the upstream MRS.
- In case of a lost Confirm message, data messages might be received from the upstream GIST node (it is unaware of the lost Confirm message). A Response message indicating the loss of the Confirm is sent back to the upstream GIST node.
- A Query message is received (from either an existing upstream GIST node or a new upstream GIST node) with a request to change the used GIST operation mode (from D-mode/C-mode to C-mode, if available; otherwise, it stays the same). Local policy requires an explicit Confirm message for MRS installation.
- The MRS lifetime expires or the NSLP application notifies that the MRS is no longer needed. The MRS is deleted. If used and not needed, the MA is deleted, too. The NSLP application is notified of the MRS change.
- The NSLP application provides data for sending. NSLP data is sent if the discovery process is successfully accomplished, or it is queued if a Confirm message is still expected to confirm establishment of an MA.
- A Query message is received. If it is sent from a new upstream GIST node, then there is a path change. Local policy does not need an explicit Confirm message for MRS installation. The MRS data is updated.
- A Query message is received with a request to change the used GIST operation mode (from D-mode/C-mode to C-mode, if available; otherwise, it stays the same). Local policy does not need an explicit Confirm message for MRS installation. The MRS data is updated.
- A Data message is received. Data messages are accepted only if the complete MRS is installed, e.g., the upstream peer info is installed. If not, then a Confirm message is expected and the Data message is not accepted. A Response message indicating the loss of the Confirm is sent back to the upstream GIST node.
- A Confirm message is received. It accomplishes assignment of an existing MA (or establishment of a new MA) needed for data transfer between peers. The information for the used MA is installed as the upstream peer info.
- A general error or system-level error occurs. The MRS is deleted. If not needed, the MA is deleted, too. The NSLP application is notified of the MRS change.
7. Security Considerations 🔥
okay, this part is serious, bestie 💀 this document does not raise new security considerations. the security considerations are handled in the GIST specification [1] and in [6], so go read those too 🫶
8. Acknowledgments 🌸
the authors want to thank Christian Dickmann, who helped refine the state machine 👑
the authors also want to thank Robert Hancock, Ingo Juchem, Andreas Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi, and Bernd Schloer for their insightful comments 🧚
9. References 📚
9.1. Normative References
- [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
- [3] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, August 2005.
- [4] Institute of Electrical and Electronics Engineers, "Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE 802-1X-2004, December 2004.
- [5] Fajardo, V., Ed., Ohba, Y., and R. Marin-Lopez, "State Machines for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5609, August 2009.
- [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
Appendix A. State Transition Tables 🦋
okay so the state transition tables below show the state diagrams in ASCII format. bestie, please use the .pdf version whenever you can, because it's the clearer way to see the state machine 💖
for each state there's a separate table, and every row lists:
- an event that triggers a transition,
- the actions taken as a result of the incoming event,
- and the new state where the transition ends.
A.1. State Transition Tables for GIST Querying Node ✨
okay bestie, for the GIST Querying Node you wanna look at Figure 2 🦋 it's the state machine diagram and these tables are basically the receipts for it 💅
IDLE state 💖
-----------
State: IDLE
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
1) |tg_SendMsg |tx_Query |Wait
** | |start T_No_Response |Response
| |Queue NSLP data |
| | |
18)|Tg_ERROR |Delete MRS |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------WaitResponse state 🌸
-----------
State: WaitResponse
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
2) |(timeout T_No_Response) |tg_MessageStatus |IDLE
|&&(MaxRetry) | |
| | |
3) |(timeout T_No_Response) |Tx_Query |Wait
|&&(!MaxRetry) |restart T_No_Response |Response
| | |
4) |rx_Data |IF(CheckPeerInfo) |Wait
| | tg_RecvMsg to Appl.|Response
| | |
5) |tg_SendMsg |Queue NSLP data |Wait
| | |Response
| | |
6) |rx_Response)|| |Install MRS |Established
|(rx_Response(MAinfo)&& |IF (RespCookie) |Downstream
|(MAexist)) | tx_Confirm(RespCookie)|MRS
| |tx_Data(Queued NSLP data)|
| | |
7) |rx_Response(MAinfo)&& |tg_Establish_MA |Wait MA
* |(!MAexist) |(tx_Confirm) |Establish.
| | |
| | |
18)|Tg_ERROR |(Delete MRS) |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------Established Downstream MRS state 🧚
-----------
State: Established Downstream MRS
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
4) |rx_Data |IF(CheckPeerInfo) |Established
| | tg_RecvMsg to Appl.|Downstream
| | |MRS
| | |
9) |((tg_SendMsg)&&(C-mode) |tx_Query |Wait
|&&(!MAexist))|| |Queue NSLP data |Response
|(tg_MA_error)|| | |
|(tg_InvalidRoutingState)| |
| | |
10)|(timeout T_Inactive_ |Delete MRS |IDLE
| QNode)|||IF (MA is used) |
|(tg_SetStateLifetime(0))| (Delete MA)|| |
| | (Stop using shared MA)|
| |Tg_NetworkNotification |
| | |
11)|(rx_Response(MAinfo)&& |((Delete MA)|| |Wait MA
* |(NewPeer)&&(!MA_exist)) |(Stop using shared MA)) |Establish.
| |tg_Establish_MA |
| |(tx_Confirm) |
| | |
13)|timeout T_Refresh_QNode |tx_Query |Established
| | |Downstream
| | |MRS
| | |
14)|tg_SendMsg |tx_Data |Established
| |restart T_Inactive_QNode |Downstream
| | |MRS
| | |
15)|(rx_Response)&& |Refresh MRS |Established
|(!NewPeer) |restart T_Inactive_QNode |Downstream
| | |MRS
| | |
16)|(rx_Response)|| |IF (MA is used) |Established
|(rx_Response(Mainfo)&& | (Delete MA)|| |Downstream
|(MAexist)))&&(NewPeer) | (Stop using shared MA)|MRS
| |Install MRS |
| |restart T_Inactive_QNode |
| |IF (RespCookie) |
| | tx_Confirm(RespCookie)|
| | |
17)|rx_Response(No_MRS_ |tx_Confirm(RespCookie) |Established
| installed)|tx_Data(Queued NSLP data)|Downstream
| | |MRS
| | |
18)|Tg_ERROR |(Delete MRS) |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------
Wait MA Establishment state 🍓
-----------
State: Wait MA Establishment
-----------
+Transition
| |Condition |Action |State
V--+------------------------+-------------------------+-----------
5) |tg_SendMsg |Queue NSLP data |Wait MA
| | |Establish.
| | |
8) |tg_MA_error |Delete MRS |IDLE
| |tg_MessageStatus |
| | |
12)|tg_MA_Established |Install MRS |Established
* | |(tx_Confirm) |Downstream
| |tx_Data(Queued NSLP data)|MRS
| | |
18)|Tg_ERROR |Delete MRS |IDLE
| |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------A.2. State Transition Tables for GIST Responding Node ✨
Okay bestie, peep the state machine diagram in Figure 3 🦋 Then the tables are literally the whole plot 💅
-----------
State: IDLE
-----------
+Transition
| |Condition |Action |State
v--+------------------------+-------------------------+-----------
1) |rx_Query&& |tx_Response |Established
|(!ConfirmRequired) |Install MRS |Upstream
| |IF(NSLPdata) |MRS
| | tg_RecvMsg(NSLPdata)|
| | to Appl.|
| | |
2) |rx_Query&& |tx_Response |Wait
|(ConfirmRequired) |start T_No_Confirm |Confirm
| |IF(NSLPdata) |
| | tg_RecvMsg(NSLPdata)|
| | to Appl.|
| | |
---+------------------------+-------------------------+-----------Next up, the WAIT CONFIRM state, which is giving very "waiting by the phone" energy 📱🌸
-----------
State: WAIT CONFIRM
-----------
+Transition
| |Condition |Action |State
v--+------------------------+-------------------------+-----------
3) |timeout T_No_Confirm | |IDLE
| | |
4) |rx_Query&& |tx_Response |Wait
|(ConfirmRequired) |start T_No_Confirm |Confirm
| |IF(NSLPdata) |
| | tg_RecvMsg(NSLPdata)|
| | to Appl.|
| | |
5) |rx_Confirm |Install Upstream MRS |Established
| | |Upstream
| | |MRS
| | |
6) |rx_Data |tx_Response(No_MRS_ |Wait
| | installed)|Confirm
| | |
14)|(Tg_ERROR)|| |(Delete MRS) |IDLE
|(Tg_MA_Error) |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------And last but definitely not least, the Established Upstream MRS state, which is the main character era 👑✨
-----------
State: Established Upstream MRS
-----------
+Transition
| |Condition |Action |State
v--+------------------------+-------------------------+-----------
7) |(rx_Query)&& |Delete MRS |Wait
|(ConfirmRequired) |tx_Response |Confirm
| |start T_No_Confirm |
| |IF(MA is used) |
| | (Delete MA)|| |
| | (Stop using shared MA)|
| |IF(NSLPdata) |
| | tg_RecvMsg(NSLPdata) |
| | to Appl.|
| | |
8) |(timeout T_Expire_RNode)|Delete MRS |IDLE
||| |tg_NetworkNotification |
|(tg_SetStateLifetime(0))|IF(MA is used) |
| | (Delete MA)|| |
| | (Stop using shared MA)|
| | |
9) |tg_SendMsg |IF(!UpstreamPeerInfo) |Established
| | Queue NSLP data |Upstream
| |ELSE tx_Data |MRS
| | |
10)|rx_Query |IF (NewPeer) |Established
| | Update UpstreamPeerInfo|Upstream
| |tx_Response |MRS
| |restart T_Expire_RNode |
| | |
11)|rx_Query(MAinfo)&& |Delete UpstreamPeerInfo |Established
|(!ConfirmRequired) |restart T_Expire_RNode |Upstream
| |tx_Response(MAinfo) |MRS
| | |
12)|rx_Data |IF(UpstreamPeerInfo) |Established
| | (tg_RecvMsg to Appl.)|Upstream
| | &&(restart_T_Expire_ |MRS
| | RNode)|
| |ELSE |
| | tx_Error(No_MRS_ |
| | installed)|
| | |
13)|rx_Confirm |Install UpstreamPeerInfo |Established
| |tx_Data(queued_NSLP_data)|Upstream
| | |MRS
| | |
14)|(Tg_ERROR)|| |(Delete MRS) |IDLE
|(Tg_MA_Error) |IF (MA is used) |
| | ((Delete MA)|| |
| | (Stop using shared MA))|
| |Tg_NetworkNotification |
| | |
---+------------------------+-------------------------+-----------Authors' Addresses 🎀
Meet the squad behind this spec 🫶 Here's how to reach each of them:
Tseno Tsenov
Sofia, Bulgaria
EMail: tseno.tsenov@mytum.de
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
EMail: Hannes.Tschofenig@nsn.com
Xiaoming Fu (editor)
University of Goettingen
Computer Networks Group
Goldschmidtstr. 7
Goettingen 37077
Germany
EMail: fu@cs.uni-goettingen.de
Cedric Aoun
Consultant
Paris, France
EMail: cedaoun@yahoo.fr
Elwyn B. Davies
Folly Consulting
Soham, Cambs, UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com📦 where this page comes from
- ietf: rfc5972 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms