RFC 3215
LDP State Machine
LDP State Machine ✨
RFC 3215 🎀 Network Working Group, Request for Comments: 3215. Category: Informational. Authors: C. Boscher and P. Cheval (Alcatel), L. Wu (Cisco), and E. Gray (Sandburst). Date: January 2002. The title block doesn't list anything this RFC obsoletes or updates.
Status of this Memo 💅
This memo gives information to the Internet community. It is not an Internet standard of any kind, and it can be shared freely with no restrictions on distribution. 🌸
Copyright Notice 🦋
Copyright (C) The Internet Society (2002). All Rights Reserved. 💜
Abstract 🧚
okay so this doc gives state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. The current LDP spec doesn't define any state machine for processing LDP messages, and that's a big deal, bestie. We think a shared state machine is super important so that different LDP and CR-LDP implementations can actually work together. 🫶
Here's the tour. Section 1 defines the terms. Section 2 has two sets of state machine tables for ATM switch LSRs that use downstream-on-demand mode. One is for ATM LSRs without vc-merge capability, and the other is for ATM LSRs that do have vc-merge capability. Section 3 gives a state machine for ATM LSRs that use downstream unsolicited mode. ✨
We focus on the LDP state machines and the control blocks they use to set up and keep up LSPs. We do NOT cover the "LDP controller" stuff, the part in charge of LDP session initialization, address mapping message management, routing interfaces, and so on. That's all defined in the LDP spec already, so we're not redoing it. 💅
Even though these state machines are made for ATM-LSRs, they can easily be adapted for other types of LSRs. 🌈
Table Of Contents 🍓
1. Terminology ................................................... 4
2. State Machine for Downstream-on-Demand Mode ................... 4
2.1 An LSR's Behavior in the Case of a Next Hop Change ........... 4
2.2. ATM Switch LSR with No VC-merge Capability .................. 5
2.2.1 LSP Control Block .......................................... 5
2.2.2 States ..................................................... 7
2.2.3 Events ..................................................... 8
2.2.4 State Transitions .......................................... 9
2.2.5 State Machine .............................................. 10
2.2.5.1 State -- "IDLE" .......................................... 10
2.2.5.2 State -- "RESPONSE_AWAITED" .............................. 13
2.2.5.3 State -- "ESTABLISHED" ................................... 16
2.2.5.4 State -- "RELEASE_AWAITED" ............................... 21
2.2.6 Handling the Next Hop Change ............................... 23
2.2.6.1 Next Hop Trigger Control Block ........................... 24
2.2.6.2 States ................................................... 24
2.2.6.3 Events ................................................... 24
2.2.6.4 State Transition for next hop change ..................... 25
2.2.6.5 State Machine ............................................ 25
2.2.6.5.1 State -- "IDLE" ........................................ 25
2.2.6.5.2 State -- "NEW_NH_RETRY" ................................ 27
2.2.6.5.3 State -- "NEW_NH_RESPONSE_AWAITED" ..................... 28
2.2.7 LDP Related Message Handling ............................... 29
2.3. ATM Switch LSR with VC-merge ................................ 31
2.3.1 VC-merge ................................................... 31
2.3.2 Control Block .............................................. 31
2.3.3 State Machines for Downstream-on-demand Mode ............. 34
2.3.3.1 State of the Upstream LSP Control Block's State Machine
for Downstream-on-demand Mode ............................ 34
2.3.3.2 Events of the Upstream LSP Control Block's State Machine
for Downstream-on-demand Mode ............................ 35
2.3.3.3 State Transitions of the Upstream LSP Control Block's State
Machine for Downstream-on-demand Mode .................... 36
2.3.3.4 Upstream LSP Control Block's State Machine
for Downstream-on-demand Mode ............................ 37
2.3.3.4.1 State -- "IDLE" ........................................ 37
2.3.3.4.2 State -- "RESPONSE_AWAITED" ............................ 39
2.3.3.4.3 State -- "ESTABLISHED" ................................. 42
2.3.3.4.4 State -- "RELEASE_AWAITED" ............................. 45
2.3.3.5 State of the Downstream LSP Control Block's State Machine
for Downstream-on-demand Mode ............................ 47
2.3.3.6 Events of the Downstream LSP Control Block's State Machine
for Downstream-on-demand Mode ............................ 47
2.3.3.7 State Transitions of the Downstream LSP Control Block's
State Machine for Downstream-on-demand mode .............. 48
2.3.3.8 Downstream LSP Control Block's State Machine for
Downstream-on-demand Mode ................................ 49
2.3.3.8.1 State -- "IDLE" ........................................ 48
2.3.3.8.2 State -- "RESPONSE_AWAITED" ............................ 50
2.3.3.8.3 State -- "ESTABLISHED" ................................. 52
2.3.3.9 State of the Next_Hop_Trigger_Control_Block's State
Machine for Downstream-on-demand Mode .................... 53
2.3.3.10 Events of the Next_Hop_Trigger_Control_Block's State
Machine for Downstream-on-demand Mode ................... 53
2.3.3.11 State Transitions of the Next_Hop_Trigger_Control_Block's
State Machine for Downstream-on-demand Mode ............. 55
2.3.3.12 State Machine ........................................... 55
2.3.3.12.1 State -- "IDLE" ....................................... 55
2.3.3.12.2 State -- "NEW_NH_RETRY" ............................... 57
2.3.3.12.3 State -- "NEW_NH_RESPONSE_AWAITED" .................... 58
2.3.4 LDP Related Message Processing ............................. 59
3. State Machine for Downstream Unsolicited ...................... 61
3.1 Control Block ................................................ 61
3.2 States of the Upstream LSP Control Block's State Machine
for Downstream Mode .......................................... 62
3.3 Events of the Upstream LSP Control Block's State Machine
for Downstream Mode .......................................... 62
3.4 State Transitions of Upstream LSP Control Block's State
Machine for Downstream Mode .................................. 64
3.5 Upstream LSP Control Block's State Machine for
Downstream Mode .............................................. 65
3.5.1 : State -- "IDLE" .......................................... 65
3.5.2 : State -- "ESTABLISHED" ................................... 66
3.5.3 : State -- "RELEASE_AWAITED" ............................... 67
3.5.4 : State -- "RESOURCE_AWAITED" .............................. 69
3.6 State of the Downstream LSP Control Block's State Machine
for Downstream Mode .......................................... 70
3.7 Events of the Downstream LSP Control Block's State Machine
for Downstream Mode .......................................... 70
3.8 State Transitions of Downstream LSP Control Block's State
Machine for Downstream Mode .................................. 71
3.9 Downstream LSP Control Block's State Machine
for Downstream Mode .......................................... 71
3.9.1 : State -- "IDLE" .......................................... 71
3.9.2 : State -- "ESTABLISHED" ................................... 73
3.10 LDP Related Message Processing for downstream mode .......... 74
4. Security Considerations ....................................... 75
5. Acknowledgements .............................................. 76
6. References .................................................... 76
7. Authors' Address .............................................. 77
8. Full Copyright Statement ...................................... 781. Terminology ✨
Here are the message names we keep using, bestie 🫶
LDP-REQUEST: LDP Label Request messageLDP-MAPPING: LDP Label Mapping messageLDP-WITHDRAW: LDP Label Withdraw messageLDP-RELEASE: LDP Label Release messageLDP-ABORT: LDP Abort message used to abort a LSP setup.LDP-NAK: LDP Notification message used to reject an LDP message.
2. State Machine for Downstream-on-Demand Mode 🦋
In this doc we give two sets of state machines. One is for the ATM LSR without VC-merge capability, and the other is for the ATM LSR that does have VC-merge capability. 💖
State machines are described in terms of control blocks, states, events, response actions, and state transitions. Control blocks hold the info needed to handle events. A control block can also hold extra info that a specific implementation needs, or that supports other required functions. Either way, any extra info needed for the procedures in the LDP specification [4], or for the management objects in the LDP MIB [3], lives in a specific LDP implementation. It can sit inside the control block structure or be stored some other way. 🌸
The state machines cover both independent LSP control and ordered LSP control. ✨
Loop detection and loop prevention messages get processed as specified in [4]. How loop detection and loop prevention messages affect state transitions is left for further study. 🔮
2.1 An LSR's Behavior in the Case of a Next Hop Change 🌈
When there's a topology change and an LSR spots a new better next hop for an LSP, it may behave in 2 different ways. 👀
- It tries to do a "local repair". This means it extends the LSP through the new next hop, releases the old path from this LSR forward, and then splices into this newly extended LSP. 🔧
- If the LSP was created with the "pinned" option (CR-LDP[5]), the LSR ignores the new next hop change, and the LSP stays unchanged. The LSR may decide to send an LDP-MAPPING containing attributes for this New Next Hop (NH) that have changed. 💅
2.2. ATM Switch LSR with No VC-merge Capability 🎀
In an MPLS domain where some ATM LSRs don't have VC-merge capability, downstream-on-demand mode is required for those ATM LSRs [1]. "Conservative label retention mode" is also required in this case [1]. 🍓
Each LSP has 2 kinds of state machines involved. 🧚
- The LSP Control Block and its state machine, which handle normal LSP setup. It gets created when the LSR receives a new LDP Request, and it gets deleted when the LSP for that request is torn down. 🏗️
- The Next Hop Trigger Control Block and its state machine, which handle switching over to a better LSP through a different next hop. It gets created when the LSR decides to switch over to a better next hop, and it gets deleted when the LSR finishes switching over. This state machine uses a timer (and has corresponding states) so the switch over happens in a timely way after a routing transient has had time to stabilize. ⏰💜
2.2.1 LSP Control Block ✨
okay bestie, every LSP gets its own LSP Control Block 🎀. Think of it as the LSP's personal notebook 📓 and it can hold all of this:
- Upstream Label Request ID (assigned by the upstream LSR), that is the 'Message Id' in the Label Request Message received from the upstream LSR.
- Downstream Label Request ID (assigned by this LSR itself), that is 'Message Id' in the Label Request Message sent to the downstream LSR.
- Upstream LDP Identifier
- Downstream LDP Identifier
- State
- FEC
- Upstream Label (assigned by this LSR)
- Downstream Label (assigned by the downstream LSR)
- Trigger Control Block Pointer, (Only used at the ingress LSR of a LSP) that points to the control block that triggers setting up this LSP or tearing down this LSP.
- Next Hop Control Block Pointer, that points to the control block that is used for switching over to a better LSP.
To find one specific LSP Control Block, you can use any of these index combos 🔍:
- Downstream Label and Downstream LDP Identifier, or
- Upstream Label and Upstream LDP Identifier, or
- Downstream Label Request ID and Downstream LDP Identifier
- Upstream Label Request ID and Upstream LDP Identifier
Here is how the control blocks connect to each other 💕. The detail definition of Next Hop Trigger Control Block is described in section 2.2.6.
Picture an LSP that goes through (LSR-A, LSR-B, LSR-C, LSR-D):
LSR-A ----> LSR-B ---> LSR-C ---> LSR-DThe control blocks in LSR-A are:
+-----------------------+
| Trigger Control Block |
| (e.g, by config) |
+-----------------------+
^
|(Trigger Control block pointer)
|
|
+-----------------------+
| LSP Control Block |
+-----------------------+Now the plot twist 😈. When LSR-B detects a better next hop to LSR-D through LSR-E, and it decides to switch over to it, so the control blocks in LSR-B are:
+-----------------------+
| LSP Control Block |
| (original LSP) |
+-----------------------+
(LSP ^ |
Control | | (Next Hop Trigger Control Block Pointer)
Block | |
Pointer) | v
+--------------------------------+
| Next Hop Trigger Control Block |
+--------------------------------+
^ |
(Trigger | | (New Next Hop LSP
Control | | Control Block Pointer)
Block | |
Pointer)| |
| v
+------------------------+
| LSP Control Block |
| (for LSP: LSR-B, LSR-E,|
| LSR-D) |
+------------------------+2.2.2 States 🌸
This section lays out the states used in the state machine for the ATM non VC-merge LSR. Here they are:
- IDLE: This is the initial LSP state, when the LSP Control Block is created.
- RESPONSE_AWAITED: This state means that the LSR has received and processed an LDP-REQUEST from an upstream LSR, or it has received an internal set up request. It has sent a new LDP-REQUEST towards a downstream LSR. The LSR is waiting for the LDP-MAPPING from the downstream LSR.
- ESTABLISHED: This state means that the LSR has received the LDP-MAPPING from the downstream LSR and the LSP is up and operational ✨.
- RELEASE_AWAITED: This state means that the LSR has sent a LDP-WITHDRAW upstream and is waiting for the LDP-RELEASE before freeing up the label resource.
2.2.3 Events 💌
These are the things that can happen to an LSR, and they're what kick the state machine into action:
- LDP Request: The LSR receives an LDP-REQUEST from an upstream LSR.
- LDP Mapping: The LSR receives an LDP-MAPPING from a downstream LSR.
- LDP Release: The LSR receives an LDP-RELEASE from an upstream LSR.
- LDP Withdraw: The LSR receives an LDP-WITHDRAW from a downstream LSR.
- LDP Upstream Abort: The LSR receives an LDP-ABORT from an upstream LSR.
- LDP Downstream NAK: The LSR receives an LDP-NAK (notification) from a downstream LSR.
- Upstream Lost: The LSR loses its LDP session with an upstream LDP peer.
- Downstream Lost: The LSR loses its LDP session with a downstream LDP peer.
- Internal SetUp: For some reason, e.g. a configuration request of a traffic engineering tunnel, or recognizing a new FEC could trigger an Internal SetUp event to set up a new LSP from this node.
- Internal Destroy: The LSR sends an Internal Destroy event to tear down an LSP.
- Internal Cross-Connect: The LSR sends an Internal Cross-Connect to splice two LSPs into one LSP. This happens when a LSR switches over to a better next hop.
- Internal New NH: The LSR decides to switch over to the better next hop.
2.2.4 State Transitions 🦋
The diagram below gives a quick look at how the states move around:
+-------------------+
| |<-------------------+
+-------->| IDLE | |
| | |----------+ |
| +-------------------+ | |
|(LDP Release) | | |
|(LDP Upstream |(LDP Request 1) | | (LDP Release)
| Abort |(Internal SetUp) | | (Upstream Lost)
|(Internal Destroy) | | |
|(Upstream Lost) v | |
| +-------------------+ | |
+---------| | | |
| RESPONSE_AWAITED | | |
+---------| | | |
| +-------------------+ | |
| | | |
|(Downstream Lost) |(LDP Mapping) | |
|(LDP Downstream | | |
| NAK) | +---------------+ |
| | | (LDP Request 2) |
| | | |
| v v |
| +-------------------+ (LDP Withdraw 1) |
| | | (Internal Destroy) |
| | ESTABLISHED |------------>-------+
| | | |
| +-------------------+ |
| | |
| | |
| |(LDP Withdraw 2) | (LDP Upstream
| |(Downstream Lost) | Abort)
| | |
| v |
| +-------------------+ |
| | | |
+-------->| RELEASE_AWAITED |------------>-------+
| |
+-------------------+2.2.5 State Machine 🔥
Now for the good stuff: what each state does when each event shows up 👑.
2.2.5.1 State -- "IDLE" 💜
Here's everything that happens while an LSR is sitting in IDLE, event by event:
State: IDLE
Event: LDP Request
New State: Depends upon the action routine.
Actions:
If this LSR is the LSP Egress or Proxy Egress [2]
Then:
Choose an upstream label, connect this upstream label to the local
IP forwarding module, allocate the resources, send the LDP-MAPPING
upstream with the upstream label, and go to the new state
`ESTABLISHED'.
else
Obtain a next hop (or interface) with the FEC specified in the
LDP-REQUEST, propagate the LDP-REQUEST, with newly assigned
Message ID by this LSR, towards the obtained next hop, and go to
the new state `RESPONSE_AWAITED'.
If the LSR uses the independent control mode [2], choose an
upstream label, connect this upstream label to the local IP
forwarding module, go to the ESTABLISHED state and send an LDP-
MAPPING upstream with the upstream label.
If unable to process the request for any reason, issue an LDP-NAK to
the sender with the appropriate error code, go to IDLE and delete the
LSP Control Block.
State: IDLE
Event: LDP Mapping
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Release
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Withdraw
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Upstream Abort
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Downstream NAK
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: Upstream Lost
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: Downstream Lost
New State: IDLE
Actions:
Ignore the event. It is an internal implementation error.
State: IDLE
Event: Internal SetUp
New State: RESPONSE_AWAITED
Actions:
Set up the Trigger Control Block pointer,
Obtain a next hop (or interface) with the FEC specified in the
Internal SetUp message, send a LDP-REQUEST towards the obtained
next hop, and go to the new state `RESPONSE_AWAITED'.
State: IDLE
Event: Internal Destroy
New State: IDLE
Actions:
Ignore. It is an internal implementation error.
State: IDLE
Event: Internal Cross-Connect
New State: IDLE
Actions:
Ignore. It is an internal implementation error.
State: IDLE
Event: Internal New NH
New State: IDLE
Actions:
Ignore. It is an internal implementation error.2.2.5.2 State -- "RESPONSE_AWAITED" 🎀
okay so this is the waiting room, bestie 🥹 the LSR already sent its request and is just sitting there hoping for an answer. here's how it reacts to everything that can happen 💅
State: RESPONSE_AWAITED
Event: LDP Request
New State: RESPONSE_AWAITEDIgnore the event. It is an internal implementation error. A non VC merge ATM LSR must create a new LSP control block for a new LDP request. 💀
State: RESPONSE_AWAITED
Event: LDP Mapping
New State: ESTABLISHEDthis is the glow-up moment ✨ the mapping finally shows up, so:
- If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event `Internal LSP UP' to the Trigger control block.
- Else If the LSR uses the ordered control mode, choose an upstream label.
- Connect the upstream label to the downstream label. Allocate the resources. Propagate the LDP-MAPPING upstream with the upstream label.
If unable to process the message, disconnect the upstream label from the downstream label, free the upstream label, release the resources, send an LDP-RELEASE downstream and an LDP-NAK upstream with status (No Label Resources [4]), go to IDLE and delete the LSP Control Block. the big oops path 😭
State: RESPONSE_AWAITED
Event: LDP Release
New State: IDLEIf the LSR uses the independent control mode, free the upstream label.
Send an LDP-ABORT downstream, go to IDLE and delete the LSP Control Block.
Note: This should only occur if the LSR uses the independent control mode. In the ordered control mode, no upstream label mapping will have been sent corresponding to this LSP while waiting for a label mapping from downstream. ⚠️ ordered mode never sent anything upstream here, so there's nothing to take back 🙈
State: RESPONSE_AWAITED
Event: LDP Withdraw
New State: RESPONSE_AWAITEDIgnore the event. It's a protocol error from the downstream LSR. not me, the downstream LSR 🙄
State: RESPONSE_AWAITED
Event: LDP Upstream Abort
New State: IDLEIf the LSR uses the independent control mode, free the upstream label.
Send an LDP-ABORT downstream.
Delete the LSP Control Block.
State: RESPONSE_AWAITED
Event: LDP Downstream NAK
New State: Depends on the action routine.- If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event `Internal LSP DOWN' to the Trigger control block, go to IDLE and delete the LSP Control Block.
- Else If the LSR uses the independent control mode, send an LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'.
If the LSR uses the ordered control mode, send an LDP-NAK upstream, go to IDLE and delete the LSP Control Block.
State: RESPONSE_AWAITED
Event: Upstream Lost
New State: IDLEIf the LSR uses the independent control mode, free the upstream label.
Send an LDP-ABORT downstream, go to IDLE and delete the LSP Control Block.
State: RESPONSE_AWAITED
Event: Downstream Lost
New State: Depends on the action routine.- If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event `Internal LSP DOWN' to the trigger control block, go to IDLE and delete the LSP Control Block.
- Else, If the LSR uses the independent control mode, free the upstream label and send an LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'.
If the LSR uses the ordered control mode, send an LDP-NAK upstream (with a status `No Route' [4]), go to IDLE and delete the LSP Control Block.
State: RESPONSE_AWAITED
Event: Internal SetUp
New State: RESPONSE_AWAITEDIgnore, it is an internal implementation error.
State: RESPONSE_AWAITED
Event: Internal Destroy
New State: IDLESend an LDP-ABORT downstream, go to IDLE and delete the LSP Control Block.
State: RESPONSE_AWAITED
Event: Internal Cross-Connect
New State: RESPONSE_AWAITEDIgnore the event. It is an internal implementation error.
State: RESPONSE_AWAITED
Event: Internal New NH
New State: RESPONSE_AWAITEDSend LDP-ABORT to the old downstream, and send LDP-REQUEST to the new next hop. 🔁 switching teams, and it's all handled ✨
2.2.5.3 State -- "ESTABLISHED" 👑
and now the main character era 🌈 this is where the LSP is fully up and running, and it has to handle every plot twist like a pro
State: ESTABLISHED
Event: LDP Request
New State: ESTABLISHEDIgnore the event. It's an internal implementation error. For non VC-merge ATM LSR, a new LSP control block is always created for each LDP request. 🙅♀️ it never gets reused
State: ESTABLISHED
Event: LDP Mapping
New State: ESTABLISHEDProcess the LDP-MAPPING, that may contain the new attributes of the label mapping and then propagate the LDP-MAPPING upstream. 🫶 passing the good news along
State: ESTABLISHED
Event: LDP Release
New State: IDLEDisconnect the upstream label from the downstream label.
Free the upstream label.
Free the resources.
Send event `Internal Destroy' to the Next Hop Trigger Control Block if it was in the middle of switching over to the better next hop.
Propagate the LDP-RELEASE downstream if the LSR is not the egress for the LSP, go to IDLE and delete the LSP Control Block.
State: ESTABLISHED
Event: LDP Withdraw
New State: Depends on the action routine.- Free the resources and send LDP-RELEASE downstream.
- If it is independent control mode, set the state to
IDLE', create a internal LDP Request with the information in the LSP Control Block, and pass eventLDP Request' to its own state machine. - Else for the ordered control mode:
- 3.1) If the LSP is triggered to be setup by itself (e.g it is the ingress LSR of this LSP), send event `Internal LSP Down' to the trigger control block, go to IDLE and delete the LSP Control Block.
- 3.2) Else, if it is triggered by the incoming LDP Request, disconnect the upstream label from the downstream label. Propagate the LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'.
- 3.3) If the LSP is in the middle of switching over to a better LSP, send event `Internal Destroy' to the state machine of its New Next Hop LSP Control Block, go to IDLE and delete the LSP Control Block.
State: ESTABLISHED
Event: LDP Upstream Abort
New State: ESTABLISHEDIgnore the event.
Note: This scenario can occur if the upstream LSR sends a LDP-ABORT at about the same time as the local LSR sends a LDP-MAPPING. In this situation, it should be up to exactly one of the two LSRs as to whether or not the label that was sent remains valid. The LDP specification [4] procedures leave the choice to the upstream LSR that must send an LDP-RELEASE if it will not use the label provided. 🤝 a little standoff, and only one side gets to decide
State: ESTABLISHED
Event: LDP Downstream NAK
New State: ESTABLISHEDIgnore the event. It is a protocol error from the downstream LSR. The downstream LSR should always LSP-WITHDRAW to tear down the LSP when the LSP is established. 🙄 the downstream LSR needs to get it together
State: ESTABLISHED
Event: Upstream Lost
New State: IDLEDisconnect the upstream label from the downstream label.
Free the upstream label.
Send event `Internal Destroy' to the Next Hop Trigger Control Block if it was in the middle of switching over to the better next hop.
Free the resources.
Propagate an LDP-RELEASE downstream, go to IDLE and delete the LSP Control Block.
State: ESTABLISHED
Event: Downstream Lost
New State: Depends on the action routine.- If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event `Internal LSP NAK' to the Trigger control block, go to IDLE and delete the LSP Control Block.
- Else, disconnect the upstream label from the downstream label. Propagate an LDP-WITHDRAW upstream and go to `RELEASE_AWAITED' state.
- Send event `Internal Destroy' to the Next Hop Trigger Control Block if it was in the middle of switching over to the better next hop.
State: ESTABLISHED
Event: Internal Setup
New State: ESTABLISHEDIgnore, it is an internal implementation error.
State: ESTABLISHED
Event: Internal Destroy
New State: IDLEDisconnect the upstream label from the downstream label if it is not the ingress of the LSP.
Free the resources.
Send an LDP-RELEASE downstream, go to IDLE and delete the LSP Control Block.
State: ESTABLISHED
Event: Internal Cross-Connect
New State: ESTABLISHEDConnect the upstream label to the downstream label.
May need to send a new LDP-MAPPING upstream with the attributes from the new next hop.
Reset Trigger Control Block Pointer to zero.
State: ESTABLISHED
Event: Internal New NH
New State: ESTABLISHED- If the LSR was in the middle of switching over to a better next hop (Next Hop Trigger Control Block Pointer is not zero), it send `Internal New NH' to that control block.
- Else, create a new Next Hop Trigger Control Block, set Next Hop Trigger Control Block pointer to point to this control block, and pass 'Internal New NH' to this control block. 🔄 new next hop, who dis? and it gets handled ✨
2.2.5.4 State -- "RELEASE_AWAITED" 🦋
okay bestie, this is the waiting room 🫶 the LSR is sitting in RELEASE_AWAITED, just waiting on that LDP-RELEASE from upstream. most events here are either "ignore it, it's an internal bug" or "wait, that's a protocol error, send a release anyway" 💅
State: RELEASE_AWAITED
Event: LDP Request
New State: RELEASE_AWAITED
Actions:
Ignore the event. It is an internal implementation error.
State: RELEASE_AWAITED
Event: LDP Mapping
New State: RELEASE_AWAITED
Actions:
It is a protocol error from the downstream LDP peer, but anyway
send a LDP-RELEASE downstream.
State: RELEASE_AWAITED
Event: LDP Release
New State: IDLE
Actions:
1) Free the upstream label
2) Delete the control block.
State: RELEASE_AWAITED
Event: LDP Withdraw
New State: RELEASE_AWAITED
Actions:
It is a protocol error from the downstream LDP peer, but send a
LDP- RELEASE anyway.
State: RELEASE_AWAITED
Event: LDP Upstream Abort
New State: IDLE
Actions:
1) Free the upstream label
2) Delete the control block.
State: RELEASE_AWAITED
Event: LDP Downstream NAK
New State: RELEASE_AWAITED
Actions:
Ignore the event. Continue waiting for the LDP-RELEASE from
upstream.
State: RELEASE_AWAITED
Event: Upstream Lost
New State: IDLE
Actions:
1) Free the upstream label
2) Delete the control block.
State: RELEASE_AWAITED
Event: Downstream Lost
New State: RELEASE_AWAITED
Actions:
Ignore the event. Continue waiting for the LDP-RELEASE from
upstream.
State: RELEASE_AWAITED
Event: Internal SetUp
New State: RELEASE_AWAITED
Actions:
Ignore the event. It is an internal implementation error.
State: RELEASE_AWAITED
Event: Internal Destroy
New State: RELEASE_AWAITED
Actions:
Ignore the event. It is an internal implementation error.
State: RELEASE_AWAITED
Event: Internal Cross-Connect
New State: RELEASE_AWAITED
Actions:
Ignore the event. It is an internal implementation error.2.2.6 Handling the Next Hop Change ✨
so here's the glow-up moment 🌈 when an LSR spots a better next hop, it may decides to set up a brand new LSP through that next hop. this happens for example when an LSR is configured as "local repair", or when it's configured as "global repair" and it's the ingress end of an LSP. the move is to create a Next Hop Trigger Control Block and run its state machine to build the new LSP through the better next hop 🦋
2.2.6.1 Next Hop Trigger Control Block 🎀
this little block keeps track of three things:
-- State
-- LSP Control Block Pointer, that points to the original LSP control
block.
-- New Next Hop LSP Control Block Pointer, that points to the LSP
Control Block that is setting up an LSP through the new next hop.2.2.6.2 States 🌸
-- IDLE
This is the initial LSP state, when the Trigger_Control_Block is
created.
-- NEW_NH_RETRY
This is the state where an LSR waits for a retry timer to expire and
then tries to establish an LSP through a new next hop.
-- NEW_NH_RESPONSE_AWAITED
This is the state where an LSR is in the middle of establishing a new
LSP through a new next hop. It has triggered a LSP control block to
send an LDP-REQUEST towards the new next hop and is waiting for the
LDP-MAPPING.2.2.6.3 Events 🧚
-- Internal New NH
The LSR detects there is a new next hop for a FEC.
-- Internal Retry Timeout
The LSP retry timer expires.
-- Internal LSP UP
The LSP to the new Next Hop is UP
-- Internal LSP NAK
The LSP through the new next hop could not get set up
-- Internal Destroy
This event is triggered when the LSR lost the LDP session with its
upstream neighbor.2.2.6.4 State Transition for next hop change 🗺️
+---------------------+
| |
| IDLE |<------------+
| | |
+---------------------+ |
| |
| |
| (Internal New NH) |
| |
v |
+---------------------+ |
| | |
| NEW_NH_RETRY |----------->-+
| | (Internal |
+---------------------+ Destroy) |
| |
| |
| (Internal retry timeout) |
| |
v |
+---------------------+ |
| | (Internal |
| NEW_NH_RESPONSE | Destroy) |
| _AWAITED |----------->-+
| | |
+---------------------+ |
| |
| (Internal LSP UP) |
| (Internal LSP NAK) |
+------------------------>-+2.2.6.5 State Machine 💜
2.2.6.5.1 State -- "IDLE" 💤
State: IDLE
Event: Internal New NH
New State: NEW_NH_RETRY
Actions:
Start the LSP retry timer and go to the `NEW_NH_RETRY' state.
State: IDLE
Event: Internal retry timeout
New State: IDLE
Actions:
Ignore. It is an internal implementation error.
State: IDLE
Event: Internal LSP UP
New State: IDLE
Actions:
Ignore. It is an internal implementation error.
State: IDLE
Event: Internal LSP NAK
New State: IDLE
Actions:
Ignore. It is an internal implementation error.
State: IDLE
Event: Internal destroy
New State: IDLE
Actions:
Ignore. It is an internal implementation error.2.2.6.5.2 State -- "NEW_NH_RETRY" ⏰
State: NEW_NH_RETRY
Event: Internal New NH
New State: NEW_NH_RETRY
Actions:
Restart the LSP retry timer.
State: NEW_NH_RETRY
Event: Internal retry timeout
New State: Depends on action routine.
Actions:
If the new next hop is the same one as the old next hop, go to
IDLE and delete the control block.
Otherwise, create an LSP control block that will try to establish
a new LSP through the new next hop, send event `Internal Setup' to
its state machine and go to NEW_NH_RESPONSE_AWAITED.
State: NEW_NH_RETRY
Event: Internal LSP UP
New State: NEW_NH_RETRY
Actions:
Ignore. It is an internal implementation error.
State: NEW_NH_RETRY
Event: Internal LSP NAK
New State: NEW_NH_RETRY
Actions:
Ignore. It is an internal implementation error.
State: NEW_NH_RETRY
Event: Internal destroy
New State: IDLE
Actions:
Stop the timer, go to IDLE and delete the control block.2.2.6.5.3 State -- "NEW_NH_RESPONSE_AWAITED" 🫧
State: NEW_NH_RESPONSE_AWAITED
Event: Internal New NH
New State: NEW_NH_RETRY
Actions:
Restart the LSP retry timer, send `Internal destroy' to the
control block of the LSP for the new next hop and go to the
`NEW_NH_RETRY' state.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal retry timeout
New State: NEW_NH_RESPONSE_AWAITED
Actions:
Ignore. It is an internal implementation error.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal LSP UP
New State: IDLE
Actions:
Send event `Internal cross-connect' event to the LSP control block
of the new next hop.
Send event `Internal destroy' event to the original LSP control
block.
Then go to IDLE and delete the control block.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal LSP NAK
New State: IDLE
Actions:
Delete the control block.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal destroy
New State: IDLE
Actions:
Send event `Internal destroy' the control block for the new LSP
through the new next hop.2.2.7 LDP Related Message Handling ✨
Okay bestie, this is where the LSR sorts its inbox 💅 Every LDP message gets its own routine, so here's how each one is handled:
- If an LSR receives an LDP-REQUEST from an upstream LSR:
- a) If this is a duplicate request, discard the message. A duplicate request means that there is a LSP Control Block that has the same FEC, Upstream Label Request ID and Upstream Label Request ID and same Upstream LDP Session Identifier. 🙈
- b) Otherwise, create a new LSP Control Block, store the relevant information from the message into the control block, then pass the event `LDP Request' to its state machine. 🎀
- If an LSR receives an LDP-MAPPING from a downstream LSR:
- a) Extract the 'Label Request Message ID' field and from the LDP-MAPPING.
- b) Find an LSP Control Block that has the same Downstream Label Request ID and the same Downstream LDP Session Identifier.
- c) If an LSP Control Block is found, pass the event `LDP Mapping' to its state machine.
- d) If there is no matching LSP Control Block found, then try to find an LSP Control Block that has the same Downstream Label and the same Downstream LDP Session Identifier.
- e) If an LSP Control Block is found, pass the event `LDP Mapping' to its state machine.
- f) Otherwise, ignore the LDP-MAPPING and send a LDP-RELEASE downstream. 😭
- If an LSR receives an LDP-RELEASE from an upstream LSR:
- a) Find an LSP Control Block that has the same Upstream Label and the same Upstream LDP Session Identifier.
- b) If an LSP Control Block is found, pass the event `LDP Release' to its state machine.
- c) Otherwise, ignore the message.
- If an LSR receives an LDP-WITHDRAW from a downstream LSR:
- a) Find an LSP Control Block that has the same Downstream Label and the same Downstream LDP Session Identifier.
- b) If an LSP Control Block is found, pass the event `LDP Withdraw' to its state machine.
- c) Otherwise, ignore the LDP-WITHDRAW and send a LDP-RELEASE downstream.
- If an upstream LDP peer is lost:
- a) Find all the LSP Control Blocks whose upstream LDP peer is that LSR.
- b) Then pass the event `Upstream Lost' to their state machines.
- If a downstream LDP peer is lost:
- a) Find all the LSP Control Blocks whose downstream LDP peer is that LSR.
- b) Then pass the event `Downstream Lost' to their state machines.
- If the LSR detects a new next hop for an FEC: For each LSP that needs "local repair", or it needs "global repair" and it is the ingress of the LSP, pass event "Internal New NH" to its state machine. 🦋
- If an LSR receives an LDP-Abort from an upstream LSR:
- a) Extract the LDP Request ID value from the LDP-Abort message.
- b) Find an LSP Control Block that has the same Upstream Label Request ID and the same Upstream LDP Session Identifier.
- c) If an LSP Control Block is found, pass the event `LDP Upstream Abort' to its state machine.
- d) Otherwise, ignore the message.
- If the LSR receives an LDP-NAK from a downstream LSR:
- a) Extract the LDP Request ID value from the LDP-NAK.
- b) Find an LSP Control Block that has the same Downstream Label Request ID and the same Downstream LDP Session Identifier.
- c) If an LSP Control Block is found, pass the event `LDP Downstream NAK' to its state machine.
- d) Otherwise, ignore the message.
2.3. ATM Switch LSR with VC-merge 🧚
2.3.1 VC-merge
A VC-merge capable LSR can map multiple incoming labels (VPI/VCI) into one outgoing label. It is possible that this LSR can only merge a limited number of incoming labels into a single outgoing label. As described in [2], suppose, for example, that due to some hardware limitation a node is capable of merging four incoming labels into a single outgoing label. Suppose however, that this particular node has six incoming labels arriving at it for a particular FEC. In this case, this node may merge these into two outgoing labels. 🍓
When an upstream LSR has a limited merging capability, it is difficult for a downstream LSR to know how many labels should be assigned to each FEC. In this case, downstream-on-demand is the move. 💖
2.3.2 Control Block
There are 3 types of control blocks involved: Upstream LSP Control Block, Downstream LSP Control Block, and Next Hop Trigger Control Block.
There is one Upstream LSP Control Block for each LDP-REQUEST received.
There is one Downstream LSP Control Block for each unique LDP-REQUEST sent to a downstream LSR. There can be multiple Downstream LSP Control Blocks per FEC in an LSR. This can be the result of an upstream LSR asking for a label for an FEC. This LSR has to assign a unique upstream label and it can not merge this upstream label into an existing downstream label for this FEC. 🔥
There is one Next Hop Trigger Control Block for each FEC for which a better next hop has been detected and the LSR has decided to switch to this better next hop. It could be the result of "local repair" or "global repair" if the LSR is the ingress LSR of the LSP.
A Downstream LSP Control Block contains a list of pointers to Upstream LSP Control Blocks or the Next Hop Trigger Control Block. This means that this LSR has decided to map the multiple labels listed in the Upstream LSP Control Blocks and the Next Hop Trigger Control Block into a single label listed in the Downstream LSP Control Block. 👑
An Upstream LSP Control Block may contain the following information:
- Upstream LDP Session Identifier
- State
- Upstream Label (assigned by this LSR)
- Downstream LSP Control Block pointer
- Upstream LDP Request ID (assigned by the upstream LSR in downstream-on-demand mode)
- Next_Hop_Trigger_Block pointer
Upstream Label and Upstream LDP Session Identifier can be used to locate a unique Upstream LSP Control Block.
If an LSR is using downstream-on-demand mode, it can use the Upstream LDP Request ID and the Upstream LDP Session Identifier to locate a unique Upstream LSP Control Block.
An Next_Hop_Trigger LSP Control Block may contain the following information:
- Upstream LSP Control Block pointer, that points to the one that is needed to switch over to the better next hop
- State
- Downstream LSP Control Block pointer
A Downstream LSP Control Block may contain the following information:
- FEC
- State
- Downstream LDP Session Identifier
- list of pointers to the Upstream LSP Control Blocks or the Trigger_Control_Blocks that are merged at this LSR for this FEC
- Downstream Label (assigned by the downstream LSR)
- Downstream Label Request ID (assigned by the LSR itself if it is using downstream-on-demand mode)
Downstream Label, Downstream LDP Session Identifier can be used to locate a unique Downstream LSP Control Block.
If an LSR is using downstream-on-demand mode, it can also use the Downstream Label Request ID and the Downstream LDP Session Identifier to locate a unique Downstream LSP Control Block.
The following diagram details the relationship between these 2 types of control blocks:
For example, the LSR has decided to merge 3 LDP-REQUESTs of a FEC from upstream LSR1, LSR2, LSR3 into one LDP-REQUEST and sent it to a downstream LSR4.
+---------------------+
| |
| Upstream_LSP_Control|
| _Block for Upstream|------+
| LSR1 | |
+---------------------+ |
|
+---------------------+ |
| | |
| Upstream_LSP_Control| | (merged into)
| _Block for Upstream |------+
| LSR2 | |
+---------------------+ | +------------------------------+
| | |
+---------------------+ +--->| Downstream LSP Control Block |
| Next_Hop_Trigger_ | | | for Downstream LSR4 |
| LSP Control Block |------+ | |
| | +------------------------------+
+---------------------+2.3.3 State Machines for Downstream-on-demand Mode
The following sections describe the state machines used in downstream-on-demand mode. 🌸
2.3.3.1 State of the Upstream LSP Control Block's State Machine for Downstream-on-demand Mode
IDLE: This is the initial LSP state.RESPONSE_AWAITED: This state means that the LSR has received and processed an LDP-REQUEST from an upstream LSR, and has sent a new LDP-REQUEST towards a downstream LSR. The LSR is waiting for the LDP-MAPPING from the downstream LSR.ESTABLISHED: This state means that the LSR has received the LDP-MAPPING from the downstream LSR and the LSP is up and operational. ✨RELEASE_AWAITED: This state means that the LSR has sent a LDP-WITHDRAW upstream and is waiting for the LDP-RELEASE before freeing up the label resource.
2.3.3.2 Events of the Upstream LSP Control Block's State Machine for Downstream-on-demand Mode
LDP Request: The LSR receives an LDP-REQUEST from an upstream LSR.Internal Downstream Mapping: This event is sent by one Downstream LSP Control Block's state machine. This Downstream LSP Control Block is the merged Downstream LSP Control Block of this Upstream LSP Control Block. The event is the result of receiving an LDP-MAPPING by the Downstream LSP Control Block's state machine.LDP Release: The LSR receives an LDP-RELEASE from an upstream LSR.Internal Downstream Withdraw: This event is sent by one Downstream LSP Control Block's state machine. This Downstream LSP Control Block is the merged Downstream LSP Control Block of this Upstream LSP Control Block. The event is the result of receiving an LDP-WITHDRAW by the Downstream LSP Control Block's state machine.LDP Upstream Abort: The LSR receives an LDP-ABORT from an upstream LSR.Internal Downstream NAK: This event is sent by one Downstream LSP Control Block's state machine. This Downstream LSP Control Block is the merged Downstream LSP Control Block of this Upstream LSP Control Block. The event is the result of receiving an LDP-NAK by the Downstream LSP Control Block's state machine, or it detects an error. 🙈Upstream Lost: The LSR loses the LDP session with its upstream LDP peer.Internal New NH: The LSR detects there is better next hop and decides to establish the lsp through this better next hop.Internal Re-Cross-Connect: This event is used to trigger splicing into a different downstream LSP. This can happens when it is switched over to a better LSP through the new next hop. 🦋
2.3.3.3 State Transitions of the Upstream LSP Control Block's State Machine for Downstream-on-demand Mode ✨
Okay bestie, this diagram is the whole vibe check for how the upstream control block hops between states in downstream-on-demand mode 🗺️🦋
+-------------------+
| |
+-------->| IDLE |<-------------------+
| | | |
| +-------------------+ |
|(LDP Abort) | |
|(Internal |(LDP Request) |
| Downstream NAK) | |
|(Upstream Lost) | (Upstream Lost) |
| v (LDP Release) |
| +-------------------+ |
| | | |
+---------| RESPONSE_AWAITED | |
| | |
+-------------------+ |
| |
|(Internal Downstream |
| mapping) |
| |
v |
+-------------------+ |
| | |
| ESTABLISHED |------->------------+
| | |
+-------------------+ |
| |
| |
|(Internal Downstream Withdraw) |
|(Internal Downstream NAK) |
v |
+-------------------+ (LDP Upstream |
| | Abort) |
|RELEASE_AWAITED |------->------------+
| |
+-------------------+2.3.3.4 Upstream LSP Control Block's State Machine for Downstream-on-demand Mode 🌸
Alright, now we get into the nitty-gritty of what happens in each state. Let's gooo 💅
2.3.3.4.1 State -- "IDLE" 🎀
- State: IDLE
- Event: LDP Request
- New State: Depends upon the action routine.
- Actions:
- If this LSR is the LSP Egress or Proxy Egress [2], then choose an upstream label, allocate the resources, connect this upstream label to the local IP forwarding module, send an LDP-MAPPING upstream with the upstream label, and go to the state
ESTABLISHED. - Otherwise, obtain a next hop (or interface). Find a Downstream LSP Control Block that has the same FEC and the same next hop and is also able to merge more input labels. If none is found, create a new Downstream LSP Control Block with the state
IDLE. - If the state of the Downstream LSP Control Block is
ESTABLISHED, choose an upstream label, connect the upstream label with the downstream label, send an LDP-MAPPING upstream with the upstream label, and go to the stateESTABLISHED. - If the state of the Downstream LSP Control Block is not
ESTABLISHED, set the state of the Upstream LSP Control Block toRESPONSE_AWAITED. If the LSR uses the independent control mode [2], choose an upstream label and send an LDP-MAPPING upstream. - Pass the event
Internal AddUpstreamto the Downstream LSP Control Block's state machine. - If unable to process the request for any reason, issue an LDP-NAK to the sender with the appropriate error code, go to IDLE, and delete the control block.
- If this LSR is the LSP Egress or Proxy Egress [2], then choose an upstream label, allocate the resources, connect this upstream label to the local IP forwarding module, send an LDP-MAPPING upstream with the upstream label, and go to the state
Now the IDLE state's "nope, not happening" events. Each one just gets ignored, because if it shows up here it's an internal implementation error 🙈
- State: IDLE
- Event: Internal Downstream Mapping
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: LDP Release
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: Internal Downstream Withdraw
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: LDP Upstream Abort
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: Internal Downstream NAK
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: Upstream Lost
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: Internal Re-Cross-Connect
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
- State: IDLE
- Event: Internal New NH
- New State: IDLE
- Actions: Ignore the event. It is an internal implementation error.
2.3.3.4.2 State -- "RESPONSE_AWAITED" 🦋
- State: RESPONSE_AWAITED
- Event: LDP Request
- New State: RESPONSE_AWAITED
- Actions: Ignore the event. It is an internal implementation error.
- State: RESPONSE_AWAITED
- Event: Internal Downstream Mapping
- New State: Depends on the action routine.
- Actions:
- If the LSR uses the ordered control mode, assign an upstream label, connect the upstream label to the downstream label, allocate the resources, send an LDP-MAPPING upstream with the upstream label, and go to
ESTABLISHED. - If unable to process the message for any reason, issue an LDP-NAK upstream and an LDP-RELEASE downstream, go to IDLE, and delete the control block.
- If the LSR uses the ordered control mode, assign an upstream label, connect the upstream label to the downstream label, allocate the resources, send an LDP-MAPPING upstream with the upstream label, and go to
- State: RESPONSE_AWAITED
- Event: LDP Release
- New State: RESPONSE_AWAITED
- Actions: Ignore the event. It is a protocol error from the upstream peer. 🚩
- State: RESPONSE_AWAITED
- Event: Internal Downstream Withdraw
- New State: RESPONSE_AWAITED
- Actions: Ignore the event. It is an internal implementation error.
- State: RESPONSE_AWAITED
- Event: LDP Upstream Abort
- New State: IDLE
- Actions:
- If the LSR uses the independent control mode, free the upstream label and the resources.
- Send the event
Internal DeleteUpstreamto its Downstream LSP Control Block's state machine. - Delete the control block.
- State: RESPONSE_AWAITED
- Event: Internal Downstream NAK
- New State: IDLE
- Actions:
- If the LSR uses the independent control mode, free the upstream label and the resources. Then, send an LDP-WITHDRAW upstream.
- If the LSR uses the ordered control mode, propagate the LDP-NAK upstream.
- Delete the control block.
- State: RESPONSE_AWAITED
- Event: Upstream Lost
- New State: IDLE
- Actions:
- If the LSR uses the independent control mode, free the upstream label and the resources.
- Send the event
Internal DeleteUpstreamto its Downstream LSP Control Block's state machine. - Delete the control block.
- State: RESPONSE_AWAITED
- Event: Internal Re-Cross-Connect
- New State: RESPONSE_AWAITED
- Actions: Ignore the event. It is an internal implementation error.
- State: RESPONSE_AWAITED
- Event: Internal New NH
- New State: Depends on the actions.
- Actions:
- Send the event
Internal DeleteUpstreamto its old downstream control block. - Find a Downstream LSP Control Block that has the same FEC and the same next hop and is also able to merge more input labels. If none is found, create a new Downstream LSP Control Block with the state
IDLE. - If the state of the Downstream LSP Control Block is
ESTABLISHED, choose an upstream label, connect the upstream label with the downstream label, send an LDP-MAPPING upstream with the upstream label, and go to the stateESTABLISHED. - If the state of the Downstream LSP Control Block is not
ESTABLISHED, set the state of the Upstream LSP Control Block toRESPONSE_AWAITED. - Pass the event
Internal AddUpstreamto the new Downstream LSP Control Block's state machine.
- Send the event
That's the whole RESPONSE_AWAITED lineup, slay 🌈👑
2.3.3.4.3 State -- "ESTABLISHED" 🌸
State: ESTABLISHED
Event: LDP Request
New State: ESTABLISHED- Ignore the event 🙈 this is an internal implementation error, so it should never really happen.
State: ESTABLISHED
Event: Internal Downstream Mapping
New State: ESTABLISHED- Process the new attributes of the mapping, then propagate the LDP-MAPPING upstream ✨
State: ESTABLISHED
Event: LDP Release
New State: IDLE- Disconnect the upstream label from the downstream label, then free the upstream label and its resources 🧹
- Send the event `Internal DeleteUpstream' to its Downstream LSP Control Block's state machine.
- Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if the LSR was in the middle of switching over to the better next hop.
- Delete the control block. Bye bye 👋
State: ESTABLISHED
Event: Internal Downstream Withdraw
New State: Depends on the action routine.- If it uses independent mode, set its state to
IDLEand create an internalLDP Request, then send it to its own state machine. - Else:
- Disconnect the upstream label from the downstream label.
- Propagate the LDP-WITHDRAW upstream and go to state
RELEASE_AWAITED.
- Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if the LSR was in the middle of switching over to the better next hop.
State: ESTABLISHED
Event: LDP Upstream Abort
New State: ESTABLISHED- Ignore the event.
Note: This can happen if the upstream LSR sends an LDP-ABORT at about the same time as the local LSR sends an LDP-MAPPING. In that situation, exactly one of the two LSRs gets to decide whether the label that was sent stays valid 🫶 The LDP specification [4] procedures leave that choice to the upstream LSR, which must send an LDP-RELEASE if it will not use the label provided.
State: ESTABLISHED
Event: Internal Downstream NAK
New State: Depends on the action routine.- If it uses independent mode, set its state to
IDLEand create an internalLDP Request, then send it to its own state machine. - Else:
- Disconnect the upstream label from the downstream label.
- Send an LDP-WITHDRAW upstream and go to state
RELEASE_AWAITED.
- Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if the LSR was in the middle of switching over to the better next hop.
State: ESTABLISHED
Event: Upstream Lost
New State: IDLE- Disconnect the upstream label from the downstream label, then free the upstream label and the resources 💀
- Send the event `Internal DeleteUpstream' to its Downstream LSP Control Block's state machine.
- Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if the LSR was in the middle of switching over to the better next hop.
- Delete the control block.
State: ESTABLISH
Event: Internal Re-Cross-Connect
New State: ESTABLISH- Reconnect the upstream label to the new downstream label.
- Send the event `Internal DeleteUpstream' to its old Downstream LSP Control Block's state machine.
State: ESTABLISH
Event: Internal New NH
New State: ESTABLISH- Create a new Next_Hop_Trigger_Control_Block and pass it the event `Internal New NH' to its state machine.
2.3.3.4.4 State -- "RELEASE_AWAITED" 🦋
State: RELEASE_AWAITED
Event: LDP Request
New State: RELEASE_AWAITED- Ignore the event. It is a protocol error from the upstream LSR 🚩
State: RELEASE_AWAITED
Event: Internal Downstream Mapping
New State: RELEASE_AWAITED- Ignore the event. It is an internal implementation error.
State: RELEASE_AWAITED
Event: LDP Release
New State: IDLE- Free the upstream label resource and delete the control block.
State: RELEASE_AWAITED
Event: Internal Downstream Withdraw
New State: RELEASE_AWAITED- Ignore the event. It is a protocol error from the downstream LSR.
State: RELEASE_AWAITED
Event: LDP Upstream Abort
New State: IDLE- Free the upstream label resource and delete the control block.
State: RELEASE_AWAITED
Event: Internal Downstream NAK
New State: RELEASE_AWAITED- Ignore the event, and keep waiting for the LDP-RELEASE 👀
State: RELEASE_AWAITED
Event: Upstream Lost
New State: IDLE- Free the upstream label resource and delete the control block.
State: RELEASE_AWAITED
Event: Internal New NH
New State: RELEASE_AWAITED- Ignore the event, and keep waiting for the LDP-RELEASE.
State: RELEASE_AWAITED
Event: Internal Re-Cross-Connect
New State: RELEASE_AWAITED- Ignore the event. It is an internal implementation error.
2.3.3.5 State of the Downstream LSP Control Block's State Machine for Downstream-on-demand Mode ✨
IDLE
This is the initial LSP state 🌱
RESPONSE_AWAITED
This state means the LSR has received an LDP-REQUEST from an upstream LSR, has processed it, and has sent a new LDP-REQUEST towards a downstream LSR. The LSR is now waiting for the LDP-MAPPING from that downstream LSR ⏳
ESTABLISHED
This state means the LSR has received the LDP-MAPPING from the downstream LSR, so the LSP is up and operational 🎀
2.3.3.6 Events of the Downstream LSP Control Block's State Machine for Downstream-on-demand Mode 💌
Internal AddUpstream
This event is sent by an Upstream LSP Control Block's state machine when it is created.
Internal DeleteUpstream
This event is sent by an Upstream LSP Control Block's state machine when it is deleted.
LDP Mapping
The LSR receives an LDP-MAPPING from a downstream LSR.
LDP Withdraw
The LSR receives an LDP-WITHDRAW from a downstream LSR.
LDP Downstream NAK
The LSR receives an LDP-NAK from a downstream LSR.
Downstream Lost
The LSR loses the LDP session with its downstream LSR.
2.3.3.7 State Transitions of the Downstream LSP Control Block's State Machine for Downstream-on-demand mode 🗺️
+-------------------+
| |
| IDLE |<--------------+
| | |(last Internal
+-------------------+ | DeleteUpstream)
| |(LDP Withdraw)
|(1st Internal AddUpstream)|
| |(LDP Downstream
v | NAK)
+-------------------+ |(Downstream
| | | Lost)
| RESPONSE_AWAITED |---------->----+
| | |
+-------------------+ |
| |
|(LDP Mapping) |
| |
v |
+-------------------+ |
| | |
| ESTABLISHED |-------->------+
| |
+-------------------+2.3.3.8 Downstream LSP Control Block's State Machine for Downstream-on-demand Mode. 🧠
2.3.3.8.1 State -- "IDLE" 🌙
State: IDLE
Event: Internal AddUpstream
New State: RESPONSE_AWAITED- Initialize the list of pointers in the Upstream LSP Control Block so it contains the newly added upstream pointer.
- Send a new LDP-REQUEST downstream and go to the state
RESPONSE_AWAITED.
State: IDLE
Event: Internal DeleteUpstream
New State: IDLE- Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Mapping
New State: IDLE- Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Withdraw
New State: IDLE- Ignore the event. It is an internal implementation error.
State: IDLE
Event: LDP Downstream NAK
New State: IDLE- Ignore the event. It is an internal implementation error.
State: IDLE
Event: Downstream Lost
New State: IDLE- Ignore the event. It is an internal implementation error.
2.3.3.8.2 State -- "RESPONSE_AWAITED" ⏳
State: RESPONSE_AWAITED
Event: Internal AddUpstream
New State: RESPONSE_AWAITED- Add the pointer to the new Upstream LSP Control Block to the Upstream LSP Control Block pointers list.
State: RESPONSE_AWAITED
Event: Internal DeleteUpstream
New State: Depend on the action routine- Delete the Upstream LSP Control Block pointer from the Upstream LSP Control Block pointers list.
- If the list becomes empty, release the resources, send an LDP-Abort downstream, go to IDLE, and then delete the control block.
State: RESPONSE_AWAITED
Event: LDP Mapping
New State: ESTABLISHED- For each Upstream LSP Control Block in the Upstream LSP Control Block pointers list, pass the event
Internal Downstream Mappingto its state machine. 🎉
State: RESPONSE_AWAITED
Event: LDP Withdraw
New State: RESPONSE_AWAITED- It is a protocol error from the downstream LDP peer, so send an LDP-RELEASE downstream.
State: RESPONSE_AWAITED
Event: LDP Downstream NAK
New State: IDLE- For each Upstream LSP Control Block in the Upstream LSP Control Block pointers list, pass the event
Internal Downstream NAKto its state machine. - Release the resources, and delete the control block.
State: RESPONSE_AWAITED
Event: Downstream Lost
New State: IDLE- For each Upstream LSP Control Block in the Upstream LSP Control Block pointers list, pass the event
Internal Downstream NAKto its state machine. - Release the resources, and delete the control block.
2.3.3.8.3 State -- "ESTABLISHED" 🌸
State: ESTABLISHED
Event: Internal AddUpstream
New State: ESTABLISHEDActions: okay so this one's simple 💅 Add the pointer to the new Upstream LSP Control Block onto the Upstream LSP Control Block pointers list. Then we just chill in ESTABLISHED.
State: ESTABLISHED
Event: Internal DeleteUpstream
New State: Depends on the action routine.Actions: first, delete that Upstream LSP Control Block's pointer from its Upstream LSP Control Block pointers list. ✂️ If the list ends up empty, release the resources, send an LDP-RELEASE downstream, go to IDLE, and then delete the control block 🫠. Otherwise, remain in the ESTABLISHED state, no drama.
State: ESTABLISHED
Event: LDP Mapping
New State: ESTABLISHEDActions: for each Upstream LSP Control Block in the Upstream LSP Control Block pointers list, pass the event `Internal Downstream mapping' to its state machine 📨. It's giving group chat broadcast.
State: ESTABLISHED
Event: LDP Withdraw
New State: IDLEActions: for each Upstream LSP Control Block in the Upstream LSP Control Block pointers list, pass the event `Internal Downstream withdraw' to its state machine. Then release the resources, delete the control block, and send LDP-RELEASE downstream 👋. Byeee.
State: ESTABLISHED
Event: LDP Downstream NAK
New State: ESTABLISHEDActions: this is a protocol error from the downstream LDP peer 🚨. Not it, bestie.
2.3.3.9 State of the Next_Hop_Trigger_Control_Block's State Machine for Downstream-on-demand Mode 🦋
IDLE: this is the initial LSP state, the very beginning 🌱.
NEW_NH_RETRY: this is the state where an LSR waits for a retry timer to expire and then tries to establish an LSP through a new next hop ⏳.
NEW_NH_RESPONSE_AWAITED: this one means the LSR has sent a new LDP-REQUEST towards a downstream LSR and is waiting for the LDP-MAPPING from that downstream LSR 👀.
2.3.3.10 Events of the Next_Hop_Trigger_Control_Block's State Machine for Downstream-on-demand Mode 🎀
Internal New NH: this is the trigger to set up an LSP through a better next hop 🚀.
Internal Downstream Mapping: this event is sent by one Downstream LSP Control Block's state machine. That Downstream LSP Control Block is the merged Downstream LSP Control Block of this Upstream LSP Control Block 🧩. The event happens because the Downstream LSP Control Block's state machine received an LDP-MAPPING.
Internal Downstream NAK: this event is sent by one Downstream LSP Control Block's state machine too, and that one is also the merged Downstream LSP Control Block of this Upstream LSP Control Block. It shows up when the Downstream LSP Control Block's state machine receives an LDP-NAK, or when it detects an error 😬.
Internal Destroy: this event stops the procedure of switching over to the better next hop 🛑.
2.3.3.11 State Transitions of the Next_Hop_Trigger_Control_Block's State Machine for Downstream-on-demand Mode 🗺️
+---------------------+
| |
| IDLE |<------------+
| | |
+---------------------+ |
| |
| |
| (Internal New NH) |
| |
v |
+---------------------+ |
| | |
| NEW_NH_RETRY |----------->-+
| | (Internal |
+---------------------+ Destroy) |
| |
| |
| (Internal retry timeout) |
| |
v |
+---------------------+ |
| | (Internal |
| NEW_NH_RESPONSE | Destroy) |
| _AWAITED |----------->-+
| | |
+---------------------+ |
| |
| (Internal Downstream |
| Mapping |
| (Internal Downstream |
| NAK) |
+------------------------>-+2.3.3.12 State Machine 🌈
2.3.3.12.1 State -- "IDLE" 💜
State: IDLE
Event: Internal New NH
New State: NEW_NH_RETRYActions: start the LSP retry timer and go to the `NEW_NH_RETRY' state ⏰.
State: IDLE
Event: Internal retry timeout
New State: IDLEActions: ignore it. It's an internal implementation error 🙈.
State: IDLE
Event: Internal Downstream Mapping
New State: IDLEActions: ignore it. It's an internal implementation error 🙈.
State: IDLE
Event: Internal Downstream NAK
New State: IDLEActions: ignore it. It's an internal implementation error 🙈.
State: IDLE
Event: Internal destroy
New State: IDLEActions: ignore it. It's an internal implementation error 🙈.
2.3.3.12.2 State -- "NEW_NH_RETRY" 🍓
State: NEW_NH_RETRY
Event: Internal New NH
New State: NEW_NH_RETRYActions: restart the LSP retry timer 🔁.
State: NEW_NH_RETRY
Event: Internal retry timeout
New State: Depends on the action routine.Actions: if the new next hop is the same one as the old next hop, go to IDLE and delete the control block. Otherwise, go to NEW_NH_RESPONSE_AWAITED, find a downstream LSP control block that goes through the same next hop for the same FEC, and if there are none, create one. Then pass the `Internal AddUpstream' event to its state machine 🪄.
State: NEW_NH_RETRY
Event: Internal Downstream Mapping
New State: NEW_NH_RETRYActions: ignore it. It's an internal implementation error 🙈.
State: NEW_NH_RETRY
Event: Internal Downstream NAK
New State: NEW_NH_RETRYActions: ignore it. It's an internal implementation error 🙈.
State: NEW_NH_RETRY
Event: Internal destroy
New State: IDLEActions: stop the timer and delete the control block 🧹.
2.3.3.12.3 State -- "NEW_NH_RESPONSE_AWAITED" 🦄
State: NEW_NH_RESPONSE_AWAITED
Event: Internal New NH
New State: NEW_NH_RETRYActions: restart the LSP retry timer, and send the event `Internal destroy' to the control block of the LSP for the new next hop 🫧.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal retry timeout
New State: NEW_NH_RESPONSE_AWAITEDActions: ignore it. It's an internal implementation error 🙈.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal Downstream Mapping
New State: IDLEActions: send the Internal Re-cross-connect' event to the upstream LSP control block of the new next hop 🔗. Then send the DeleteUpstream' event to the downstream LSP control block of the the new next hop, since the upstream has spliced into the new next hop ✨. Finally, delete the control block.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal Downstream NAK
New State: IDLEActions: delete the control block 🗑️.
State: NEW_NH_RESPONSE_AWAITED
Event: Internal destroy
New State: IDLEActions: send the `Internal DeleteUpstream' event to the control block for the new LSP through the new next hop 📤.
2.3.4 LDP Related Message Processing 💌
- If an LSR receives an LDP-REQUEST:
- a) If this is a duplicate request, discard the message. A duplicate request means that there is a LSP Control Block that has the same FEC, Upstream Label Request ID and Upstream LDP Session Identifier.
- b) Otherwise, create a new Upstream LSP Control Block. Then pass the event `LDP Request' to this Upstream LSP Control Block's state machine.
- If an LSR receives an LDP-MAPPING:
- Locate a Downstream LSP Control Block that has the same FEC, the same Downstream LDP Session Identifier and the same Downstream Label. If a Downstream LSP Control Block is found, pass the event `LDP Mapping' to its state table. This could mean that the attributes of label binding have changed.
- Otherwise, use the Downstream LDP request ID (the 'Label Request Message ID' field in the LDP-MAPPING) and Downstream LDP Session Identifier to locate the Downstream LSP Control Block and pass the event `LDP Mapping' to its state machine. If no Downstream LSP Control Block is found, ignore the message.
- If an LSR receives an LDP-RELEASE:
- Locate an Upstream LSP Control Block that has the same FEC, the same Upstream Label, the same Upstream LDP Session Identifier. If no Upstream LSP Control Block is found, ignore the message. If an Upstream LSP Control Block is found, send the event `LDP Release' to its state machine.
- If an LSR receives an LDP-WITHDRAW:
- Find a Downstream LSP Control Block that has the same FEC, the same Downstream LDP Session Identifier and the same Downstream Label. Pass the event `LDP Withdraw' to its state machines.
- If an Upstream LDP peer is lost:
- Pass the event `Upstream Lost' to the state machines of all the Upstream LSP Control Blocks whose upstream LDP peer is that LSR.
- If a Downstream LDP peer is lost:
- Pass the event `Downstream Lost' to the state machines of all the Downstream LSP Control Blocks whose downstream LDP peer is that LSR.
- If a next hop of an FEC is changed:
- For all the Upstream LSP Control Blocks that are affected by this change, pass the event `Internal New NH' to their state machines.
- If an LSR receives an LDP-ABORT from an upstream LSR:
- Use the Upstream LDP Request ID and Upstream LDP Session Identifier to locate the Upstream LSP Control Block and pass the event `LDP Abort' to its state machine.
- If an LSR receives an LDP-NAK from a downstream LSR:
- Use the Downstream LDP Request ID and Downstream Session Identifier to locate a Downstream_LSP_control_block and pass the event `LDP Downstream NAK' to its state machine.
3. State Machine for Downstream Unsolicited ✨
The following sections describe the state machines for the ATM-LSR that uses downstream unsolicited mode 🌷.
While both independent LSP control and ordered LSP control modes are possible, only the ordered mode is taken into account, because the independent LSP control mode uses the liberal label retention mode and so is considered burning too many ATM resources. 💸
In downstream unsolicited mode, multiple path is not supported in this version and will be For Further Study (FFS) 🔮. We suspect that with multiple next hops and Downstream mode, it is easy to get into a loop condition 🌀. Be careful out there, bestie!
3.1 Control Block
okay so there are 2 types of control blocks in this one: the Upstream LSP Control Block and the Downstream LSP Control Block 💖
For each FEC in the routing table there's a list of Upstream LSP Control Blocks, one for each LDP peer. An Upstream LSP Control Block gets created for a FEC once there's a label ready to hand to that upstream. It gets deleted when the FEC is deleted from the FEC table, when the LDP peer disappears, or when the downstream label is withdrawn 🦋
Each FEC in the routing table gets exactly one Downstream LSP Control Block. It shows up when the FEC is inserted into the forwarding table and gets deleted when the FEC is removed from it ✨
An Upstream LSP Control Block can hold:
- Upstream LDP Session Identifier
- State
- Upstream Label (assigned by this LSR)
- FEC
Upstream Label plus Upstream LDP Session Identifier, or FEC plus Upstream LDP Session Identifier, can be used to find one unique Upstream LSP Control Block. Iconic 💅
A Downstream LSP Control Block can hold:
- FEC
- State
- Downstream LDP Session Identifier
- Downstream Label (assigned by the downstream LSR)
- Downstream Label Request ID (assigned by the LSR itself)
Downstream Label plus Downstream LDP Session Identifier, or FEC plus Downstream LDP Session Identifier, can be used to find one unique Downstream LSP Control Block 🎀
3.2 States of the Upstream LSP Control Block's State Machine for Downstream Mode
Here are the states the Upstream LSP Control Block can be in, bestie 🌸
- IDLE: this is the starting state for the LSP 🌱
- ESTABLISHED: the LSR has gotten the LDP-MAPPING from the downstream LSR, so the LSP is up and running and literally working 🔥
- RELEASE_AWAITED: the LSR is waiting on an LDP-RELEASE in response to the LDP-WITHDRAW it sent out 🫠
- RESOURCES_AWAITED: the LSR is waiting for label resources to free up 🧚
3.3 Events of the Upstream LSP Control Block's State Machine for Downstream Mode
These are the things that can happen and make the state machine react 👑
- Internal Downstream Mapping: a Downstream LSP Control Block's state machine sends this one. It happens when that state machine gets an LDP-MAPPING. It also happens when an LDP peer shows up and there's a downstream label ready for this FEC 🍓
- LDP Release: the LSR gets an LDP-RELEASE from an upstream LSR 💜
- Internal Withdraw: a Downstream LSP Control Block's state machine sends this one, when it gets an LDP-WITHDRAW 🙈
- Resource Available: a local resource (like a label) has become available 🌈
- Delete FEC: the FEC has been removed from the forwarding table 💀
- Upstream Lost: the upstream LDP peer is gone 😭
3.4 State Transitions of Upstream LSP Control Block's State Machine for Downstream Mode
This is the map of how the Upstream LSP Control Block bounces between states, so you can follow the whole thing at a glance 🗺️
|
|(created when
|a label is to be distributed
| to the LDP peer)
v
+-------------------+
| |
| IDLE |<--------------+
| | |
+-------------------+ |
| |
| |
| |(LDP Release)
| |
|(Internal Downstream |
+-------------------| Mapping) |
| | |
|(no label resource)v |
| +-------------------+ |
| | | |
| +-----| ESTABLISHED |---------------+
| | | | ^
| | +-------------------+ |
| |(delete FEC) ^ |
| |(Internal |(Resource Available) | (LDP Release)
| | Withdraw) | | (Internal
| | | | Downstream
| | | | Withdraw)
| | +-------------------+ |
+--------->| | |
| |RESOURCES_AWAITED |---------------+
| | | |
| +-------------------+ |
| |
| (Internal Downstream Withdraw) |(LDP Release)
| +-------------------+ |
| | | |
+---->| RELEASE_AWAITED |---------------+
| |
+-------------------+3.5 Upstream LSP Control Block's State Machine for Downstream Mode
Now for the fun part: what the Upstream LSP Control Block actually does in each state, event by event 🎬
3.5.1 : State -- "IDLE"
Starting from IDLE, here's the drama 💅
State: IDLE
Event: Internal Downstream mapping
New State: Depends on the action routine.
Actions
Choose an upstream label, connect the upstream label with the
downstream label, propagate the LDP-MAPPING upstream and go to
state `ESTABLISHED'
If there is no resource for the upstream label, go to state
`RESOURCE_AWAITED'.
State: IDLE
Event: LDP Release
New State: IDLE
Actions
Ignore the event. It is an internal implementation error.
State: IDLE
Event: Internal Downstream Withdraw
New State: IDLE
Actions
Ignore the event. It is an internal implementation error.
State: IDLE
Event: Resource Available
New State: IDLE
Actions
Ignore the event. It is an internal implementation error.
State: IDLE
Event: Delete FEC
New State: IDLE
Actions
Delete the control block.
State: IDLE
Event: Upstream Lost
New State: IDLE
Actions
Delete the control block.3.5.2 : State -- "ESTABLISHED"
Once it's ESTABLISHED, this is how things go 🌟
State: ESTABLISHED
Event: Internal Downstream Mapping
New State: ESTABLISHED
Actions
Process the new attributes of the new mapping message.
Propagate the LDP-MAPPING upstream.
State: ESTABLISHED
Event: LDP Release
New State: IDLE
Actions
Disconnect upstream label from downstream label.
Release the upstream label resource
Delete the control block.
State: ESTABLISHED
Event: Internal Downstream Withdraw
New State: RELEASE_AWAITED
Actions
Disconnect upstream label from downstream label.
Propagate the LDP-WITHDRAW upstream.
State: ESTABLISHED
Event: Resource Available
New State: ESTABLISHED
Actions
Ignore the event. It is an internal implementation error.
State: ESTABLISHED
Event: Delete FEC
New State: RELEASE_AWAITED
Actions
Send a LDP-WITHDRAW upstream.
State: ESTABLISHED
Event: Upstream Lost
New State: IDLE
Actions
Release the upstream label and delete the control block.3.5.3 : State -- "RELEASE_AWAITED"
Here's what happens while we're stuck in RELEASE_AWAITED, waiting it out 🫶
State: RELEASE_AWAITED
Event: Internal Downstream Mapping
New State: RELEASE_AWAITED
Actions
Ignore the message.
State: RELEASE_AWAITED
Event: LDP Release
New State: IDLE
Actions
Release the upstream label and delete the control block.
State: RELEASE_AWAITED
Event: Internal Downstream Withdraw
New State: RELEASE_AWAITED
Actions
Ignore the event.
State: RELEASE_AWAITED
Event: Resource Available
New State: RELEASE_AWAITED
Actions
Ignore the event. It is an internal implementation error.
State: RELEASE_AWAITED
Event: Delete FEC
New State: RELEASE_AWAITED
Actions
Do nothing.
State: RELEASE_AWAITED
Event: Upstream Lost
New State: IDLE
Actions
Release the upstream label and delete the control block.3.5.4 : State -- "RESOURCE_AWAITED"
And finally, the RESOURCE_AWAITED vibes, where we wait for a label to show up ⏳
State: RESOURCE_AWAITED
Event: Internal Downstream Mapping
New State: RESOURCE_AWAITED
Actions
Ignore the message.
State: RESOURCE_AWAITED
Event: LDP Release
New State: RESOURCE_AWAITED
Actions
Ignore the message. It is an internal implementation error.
State: RESOURCE_AWAITED
Event: Internal Downstream Withdraw
New State: IDLE
Actions
Delete the control block.
State: RESOURCE_AWAITED
Event: Resource Available
New State: ESTABLISHED
Actions
Allocate an upstream label, connect the upstream label with the
downstream label, and send LDP-MAPPING upstream.
State: RESOURCE_AWAITED
Event: Delete FEC
New State: IDLE
Actions
Delete the control block.
State: RESOURCE_AWAITED
Event: Upstream Lost
New State: IDLE
Actions
Delete the control block.3.6 State of the Downstream LSP Control Block's State Machine for Downstream Mode
Switching over to the Downstream LSP Control Block 🦋
- IDLE: this is the starting state for the LSP 🌱
- ESTABLISHED: the LSR has gotten the LDP-MAPPING from the downstream LSR 💖
3.7 Events of the Downstream LSP Control Block's State Machine for Downstream Mode
These are the triggers for the Downstream side 👀
- LDP Mapping: the LSR gets an LDP-MAPPING from a downstream LSR 🎀
- LDP Withdraw: the LSR gets an LDP-WITHDRAW from a downstream LSR 😭
- Delete FEC: the FEC gets deleted from the forwarding table 💀
- Next Hop Change: the next hop for this FEC changes to a different LSR 🔀
- Downstream Lost: the downstream peer is gone 🫠
3.8 State Transitions of Downstream LSP Control Block's State Machine for Downstream Mode
And here's the map for the Downstream side 🗺️
|
|(FEC is being added into the forwarding table)
v
+-------------------+
| |
| IDLE |<--------------+
| | |
+-------------------+ |
| |
| |(LDP Withdraw)
| |(Internal New NH)
| |(Downstream Lost)
| (LDP Mapping) |
| |
v |
+-------------------+ |
| | |
| ESTABLISHED |---------------+
| |
+-------------------+
|
|(FEC is deleted from the forwarding table)
v3.9 Downstream LSP Control Block's State Machine for Downstream Mode
3.9.1 : State -- "IDLE" 🌸
State: IDLE Event: LDP mapping New State: ESTABLISHED
okay so when a mapping shows up while we're sitting in IDLE, we make an Upstream LSP Control Block for every LDP peer except the downstream LSR that handed us the label 🫶. Then we pass Internal Downstream Mapping into each of those Upstream LSP Control Blocks' state machines. ✨
State: IDLE Event: LDP withdraw New State: IDLE
Bestie, this one is giving "should never happen" 🙈. We just ignore the event, because getting it here is an internal implementation error 💀.
State: IDLE Event: Delete FEC New State: IDLE
Simple and iconic 💅. We delete the control block and stay in IDLE.
State: IDLE Event: Next Hop Change New State: IDLE
Nothing to see here, we just ignore it 🦋.
State: IDLE Event: Downstream Lost New State: IDLE
Also ignored 🌈. Not every event needs a whole reaction, periodt.
3.9.2 : State -- "ESTABLISHED" 💜
State: ESTABLISHED Event: LDP mapping New State: ESTABLISHED
We stay right where we are 👑. For each Upstream_LSP_control_block of this FEC, we pass the event Internal downstream mapping to its state machine.
State: ESTABLISHED Event: LDP withdraw New State: IDLE
Okay this one has two jobs 😭. For each Upstream_LSP_control_block for this FEC, we pass the event Internal downstream Withdraw to its state machine. Then we send a LDP Withdraw downstream. 🎀
State: ESTABLISHED Event: Delete FEC New State: IDLE
We send LDP-RELEASE downstream and then delete the control block 🧚.
State: ESTABLISHED Event: Next Hop Change New State: IDLE
Main character moment ✨. For each Upstream_LSP_control_block for this FEC, we pass Internal downstream Withdraw to its state machine, and then we send LDP-REQUEST to the new next hop 🔥.
State: ESTABLISHED Event: Downstream Lost New State: IDLE
We send LDP-WITHDRAW to all Upstream_Control_Block's state machines of this FEC 🥺.
3.10. LDP Related Message Processing for downstream mode. 🍓
Okay this is the part where the LSR reacts to each message it gets. Here's the whole vibe, bestie 💖:
- If an LSR receives an LDP-REQUEST: if there is a next hop for this FEC and there is a
Downstream_Control_Blockfor this FEC whose state isESTABLISHED, we create a newUpstream_Control_Blockand pass theinternal Mappingevent to its state machine. 🌸 - If an LSR receives an LDP-MAPPING: we look for a Downstream LSP Control Block that has the same FEC, the same Downstream LDP Session Identifier and the same Downstream Label. If we find one, we pass the event
LDP Mappingto its state table. This could mean the attributes of the label binding have changed 👀.- Otherwise, if there is no matching Downstream LSP Control Block, we look for a Downstream LSP Control Block of this FEC whose next hop is this downstream peer, and pass the event
LDP Mappingto its state machine 🦋.
- Otherwise, if there is no matching Downstream LSP Control Block, we look for a Downstream LSP Control Block of this FEC whose next hop is this downstream peer, and pass the event
- If an LSR receives an LDP-RELEASE: we look for an Upstream LSP Control Block that has the same FEC, the same Upstream Label and the same Upstream LDP Session Identifier. If there isn't one, we ignore the message 🙈. If we do find one, we send the event
LDP Releaseto its state machine 💅. - If an LSR receives an LDP-WITHDRAW: we find a Downstream LSP Control Block that has the same FEC, the same Downstream LDP Session Identifier and the same Downstream Label, then pass the event
LDP Withdrawto its state machines 🌈. - If an Upstream LDP peer is lost: we pass the event
Upstream Lostto the state machines of all the Upstream LSP Control Blocks whose upstream LDP peer is that LSR 😭. - If a Downstream LDP peer is lost: we pass the event
Label Withdrawto the state machines of all the Downstream LSP Control Blocks whose downstream LDP peer is that LSR 🥀. - If a next hop of an FEC is changed: we find all the Downstream LSP Control Blocks that have the same FEC and the same next hop, and pass the event
Next Hop Changeto their state machines 🔁. - If there is a FEC being added to the forwarding table: we create a new Downstream LSP Control Block with state
IDLE✨. - If the FEC is deleted from the forwarding table: we send the
Delete FECevent to its control block 👋. - If an LSR receives an LDP-NAK from an upstream LSR: we ignore the message. An LDP-NAK should never appear in the downstream-mode LSR 🙅♀️.
- If an LSR receives an LDP-NAK from a downstream LSR: we ignore the message. It is a protocol error from the downstream LSR 🚨.
4. Security Considerations ✨
Okay bestie, the security part is serious 🔐. This document is an informational extension of the LDP specification [4]. The state machines here are meant to clarify the procedures defined in the LDP specification, but they do not supplant or override anything defined there 💜.
Implementations of a state machine may be vulnerable to spurious events generated by an external source 😬. In this document, events fall into two categories: internal events, and external events caused by receipt of an LDP message 🫣.
LDP messages may be protected using the mechanisms described in the LDP specification. See "Security Considerations" in the LDP specification [4] 🛡️.
Security considerations relating to the generation of spurious internal events are not addressed in this document ⚠️. Plan for that on your own, babe 💀.
5. Acknowledgements 🫶
The authors want to give a shout-out to the helpful comments and suggestions of Bob Thomas, Myunghee Son and Adrian Farrel 🎀.
6. References 📚
[1] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G.,
Rekhter, Y. and P. Doolan, "MPLS Using LDP and ATM Switching",
RFC 3035, January 2001.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[3] Cucchiara, J., Sjostrand, H. and J. Lucianai, "Definition of
Managed Objects for the Multiprotocol Label Switching, Label
Distribution Protocol (LDP)", Work in Progress.
[4] Andersson, L., Doolan, P., Feldman, F., Fredette, A. and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[5] Jamoussi, B., Ed., O., Andersson, L., Callon, R., Dantu, R., Wu,
L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish,
M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-
Based LSP Set up Using LDP", RFC 3212, January 2002.7. Authors' Address 🌷
Christophe Boscher
Alcatel
Le Mail
44700 Orvault
France
Phone: (33) 251781828
EMail: christophe.boscher@alcatel.fr
Pierrick Cheval
Alcatel
5 rue Noel-Pons
92734 Nanterre Cedex
France
Phone: (33) 146524027
EMail: pierrick.cheval@space.alcatel.fr
Liwen Wu
Cisco Systems, Inc.
3550 Cisco Way
San Jose, CA 95134
U.S.A
Phone: 408-853-4065
EMail: liwwu@cisco.com
Eric Gray
Sandburst Corporation
600 Federal Drive
Andover, MA 01810
Phone: (978) 689-1610
EMail: eric.gray@sandburst.com8. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society 💖.
📦 where this page comes from
- ietf: rfc3215 2002-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms