RFC 1953
Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0
Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 🦋
- RFC number: 1953
- Series: Network Working Group
- Authors: P. Newman (Ipsilon), W. L. Edwards (Sprint), R. Hinden (Ipsilon), E. Hoffman (Ipsilon), F. Ching Liaw (Ipsilon), T. Lyon (Ipsilon), G. Minshall (Ipsilon)
- Category: Informational
- Date: May 1996
- Obsoletes or updates: nothing is listed in the title block
Status of this Memo 📜
Okay bestie, first things first 💅 This document is here to provide information for the Internet community 🫶 It does not specify an Internet standard of any kind, and distribution of this memo is unlimited ✨
IESG Note
Real talk 🙈 This memo documents a private protocol for IPv4-based flows. The protocol is not the product of an IETF working group, and it is not a standards track document. It hasn't necessarily gotten the widespread, in-depth community review that standards track documents get 💀
Abstract 🎀
So IFMP (the Ipsilon Flow Management Protocol) is a protocol that lets a node tell an adjacent node to slap a layer 2 label onto a specific IP flow 🏷️ That label gives more efficient access to cached routing info for that flow ✨ It can also let the node switch later packets in that flow at layer 2 instead of forwarding them at layer 3 🔥
Table of Contents 🗂️
1. Introduction....................................................2
2. Flow Types......................................................2
3. IFMP Adjacency Protocol.........................................4
3.1 Packet Format.............................................4
3.2 Procedure.................................................7
4. IFMP Redirection Protocol......................................10
4.1 Redirect Message.........................................12
4.2 Reclaim Message..........................................13
4.3 Reclaim Ack Message......................................15
4.4 Label Range Message......................................16
4.5 Error Message............................................17
References........................................................19
Security Considerations...........................................19
Authors' Addresses................................................191. Introduction ✨
IFMP is basically a protocol for telling an adjacent node to attach a layer 2 label to a specific IP flow 💖 The label gives more efficient access to cached routing info for that flow, and in certain cases it lets the flow get switched instead of routed 🦋
If a network node's upstream and downstream links both redirect a flow at that node, then the node can switch the flow at the data link layer instead of forwarding it at the network layer 🚀 The label space is managed at the downstream end of each link, and redirection messages get sent upstream to tie a particular flow to a given label. Each direction of transmission on a link gets treated separately 🌸
If the flow isn't refreshed before the lifetime field in the redirect message expires, the association between the flow and the label gets thrown out 💀 To refresh it, you send a redirect message that's identical to the original, before the lifetime runs out ⏰
Several flow types can be specified, and each one defines the set of packet header fields used to identify a flow. There must be an ordering among the different flow types so that a most specific match operation may be performed 👑
A particular flow gets specified by a flow identifier. That identifier holds the contents of the set of header fields, as defined for the flow type it belongs to 🧚
This document specifies IFMP for IPv4 on a point-to-point link 🎀 The definition of labels and the encapsulation of flows are in a separate document for each specific data link technology. The spec for ATM data links is given in [ENCAP] ✨
2. Flow Types 🌈
A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination, where the packets are related in terms of their routing and any logical handling policy they may require 💅
A flow is identified by its flow identifier 🦋
You can define several different flow types. The particular set of header fields used to identify a flow is the flow type, and the values of those fields for a particular flow make up the flow identifier for that flow. Those values must be invariant in all packets belonging to the same flow at any point in the network 🫶
Flow types are sub- or super-sets of each other, so there's a clear hierarchy 👑 That's what makes a most specific match operation possible. (If additional flow types are defined in the future that are not fully ordered, then the required behavior will be defined.) Each flow type also specifies an encapsulation to use after a flow of that type gets redirected 🌸 The encapsulations for each flow type are in a separate document for each specific data link technology, and flows over ATM data links get theirs in [ENCAP] ✨
Three flow types are defined in this version of the protocol 🍓
Flow Type 0 🩷
Flow Type 0 is used to change the encapsulation of IPv4 packets from the default encapsulation 🌸
For Flow Type 0: Flow Type = 0 and Flow ID Length = 0.
The Flow Identifier for Flow Type 0 is null (zero length).
Flow Type 1 💜
Flow Type 1 is designed for protocols such as UDP and TCP, where the first four octets after the IPv4 header specify a Source Port number and a Destination Port number 💖
For Flow Type 1, Flow Type = 1 and Flow ID Length = 4 (32 bit words).
The format of the Flow Identifier for Flow Type 1 is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Time to Live | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flow Type 2 🧁
For Flow Type 2, Flow Type = 2 and Flow ID Length = 3 (32 bit words).
The format of the Flow Identifier for Flow Type 2 is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL | Reserved | Time to Live | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved fields are unused and should be set to zero by the sender and ignored by the receiver 🫧
3. IFMP Adjacency Protocol 🦋
The IFMP Adjacency Protocol lets a host or router discover the identity of the peer at the other end of a link 🔍 It's also used to sync state across the link, detect when the peer at the other end of the link changes, and exchange a list of IP addresses assigned to the link 🫶
3.1 Packet Format ✨
okay bestie, this is where we get into the actual bytes 💅 All IFMP messages in the Adjacency Protocol MUST be wrapped inside an IPv4 packet and MUST be sent to the IP limited broadcast address (255.255.255.255). The Protocol field in the IP header MUST contain the value 101 (decimal), which tells everyone the packet is carrying an IFMP message 🎀 And the Time to Live (TTL) field in the IP header MUST be set to 1, so these packets never leave the link 🦋
Every IFMP Adjacency Protocol message has the same structure, so here's the layout 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Op Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Identity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Next Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | Max Ack Intvl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address List ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version The IFMP protocol version number. The current Version = 1. 🌸
Op Code This tells you what the message is for. Four Op Codes are defined for the IFMP Adjacency Protocol:
SYN: Op Code = 0
SYNACK: Op Code = 1
RSTACK: Op Code = 2
ACK: Op Code = 3Checksum This is the 16-bit one's complement of the one's complement sum of a pseudo header (info pulled from the IP header) plus the IFMP message itself 🔥 The pseudo header is conceptually stuck onto the front of the IFMP message, and it has the Source Address, the Destination Address, and the Protocol fields from the IPv4 header. It also has the total length of the IFMP message, counting from the Version field. (That's the same as the Total Length field from the IPv4 header minus the length of the IPv4 header itself, so yes, it's literally the same number, periodt 🧚)
Sender Instance For the SYN, SYNACK, and ACK messages, this is the sender's instance number for the link. The receiver uses it to figure out when the link comes back up after going down, or when the identity of the peer at the other end changes 👀 The instance number is a 32 bit number that is guaranteed to be unique within the recent past, and it changes when the link or node comes back up after going down. It works kind of like the initial sequence number (ISN) in TCP [RFC 793], so if you know TCP, you already get the vibe 💜 Zero is not a valid instance number, so don't even try it 🙈 For the RSTACK message, the Sender Instance field is set to the value of the Peer Instance field from the incoming message that caused the RSTACK message to be generated.
Peer Instance For the SYN, SYNACK, and ACK messages, this is what the sender believes the peer's current instance number is for the link. If the sender doesn't know the peer's current instance number for the link, the sender MUST set this field to zero 🫶 For the RSTACK message, the Peer Instance field is set to the value of the Sender Instance field from the incoming message that caused the RSTACK message to be generated.
Peer Identity For the SYN, SYNACK, and ACK messages, this is the IP address of the peer that the sender thinks is at the other end of the link. The Peer Identity is taken from the Source IP Address of the IP header of a SYN or a SYNACK message. If the sender doesn't know the IP address of the peer at the other end of the link, the sender MUST set this field to zero 💅 For the RSTACK message, the Peer Identity field is set to the value of the Source Address field from the IP header of the incoming message that caused the RSTACK message to be generated.
Peer Next Sequence Number This gives the value of the peer's Sequence Number that the sender expects to show up in the next IFMP Redirection Protocol message. Here's the drama 😭 If a node is in the ESTAB state, and the Peer Next Sequence Number in an incoming ACK message is greater than the Sequence Number plus one (counting from the last IFMP Redirection Protocol message sent out of the port where the incoming ACK arrived), the link SHOULD be reset. The procedure to reset the link is defined in section 3.2 🔥
Max Ack Intvl Maximum Acknowledgement Interval is the longest amount of time the sender of the message will wait before sending an ACK message ⏰
Address List A list of one or more IP addresses that the sender of the message has assigned to the link. The list MUST have at least one entry that is identical to the Source Address in the IP header 🌈 The contents of this list are not used by the IFMP protocol, but they can be made available to the routing protocol, which is honestly kind of iconic of it 🦋
3.2 Procedure ✨
The IFMP Adjacency Protocol is described by the rules and state tables in this section. Let's go, bestie 🚀
The rules and state tables use the following operations:
- The "Update Peer Verifier" operation is defined as storing the Sender Instance and the Source IP Address from a SYN or SYNACK message received from the peer on a particular port 💖
- The procedure "Reset the link" is defined as:
- Generate a new instance number for the link
- Delete the peer verifier (set the stored values of Sender Instance and Source IP Address of the peer to zero)
- Set Sequence Number and Peer Next Sequence Number to zero
- Send a SYN message
- Enter the SYNSENT state
The state tables use the following Boolean terms and operators 🧠
A The Sender Instance in the incoming message matches the
value stored from a previous message by the "Update Peer
Verifier" operation for the port on which the incoming
message is received.
B The Sender Instance and the Source IP Address in the
incoming message matches the value stored from a previous
message by the "Update Peer Verifier" operation for the
port on which the incoming message is received.
C The Peer Instance and Peer Identity in the incoming message
matches the value of the Sender Instance and the Source IP
Address currently in use for all SYN, SYNACK, and ACK
messages transmitted out of the port on which the incoming
message was received.
"&&" Represents the logical AND operation
"||" Represents the logical OR operation
"!" Represents the logical negation (NOT) operation.A timer is REQUIRED for the periodic generation of SYN, SYNACK, and ACK messages. The period of the timer is unspecified, but a value of one second is suggested ⏱️
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are:
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
Packet Arrives: If incoming message is an RSTACK
If A && C && !SYNSENT
Reset the link
Else Discard the message
Else the following State Tables.State synchronization across a link is considered to be achieved when a node reaches the ESTAB state 🎉
State Tables 📋
State: SYNSENT
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+======================================================================+State: SYNRCVD
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | SYNRCVD |
+======================================================================+State: ESTAB
+=======================================================================+
| Condition | Action | New State |
+=====================+=====================================+===========+
| SYN || SYNACK | Send ACK (note 1) | ESTAB |
+---------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 1) | ESTAB |
+---------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB |
+=======================================================================+Note 1: No more than one ACK SHOULD be sent within any time period of length defined by the timer. 🙈✨
4. IFMP Redirection Protocol ✨
okay so this is where the Redirection Protocol lives and it is giving main character energy 💅 every IFMP Redirection message gets wrapped up inside an IPv4 packet 🎀 and sent to the unicast IP address of the peer on the other end of the link. you get that address from the adjacency protocol 🦋 and the IP header's Protocol field MUST contain 101 (decimal) so everyone knows it's an IFMP message 🧚 the TTL field MUST be set to 1 🙈
All IFMP Redirection Protocol messages have the same structure, bestie 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Op Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version The IFMP protocol version number, currently Version = 1. 💜
Op Code This field gives the message type. Five message types are currently defined for the IFMP Redirection Protocol 👑
REDIRECT: Op Code = 4
RECLAIM: Op Code = 5
RECLAIM ACK: Op Code = 6
LABEL RANGE: Op Code = 7
ERROR: Op Code = 8Checksum ngl this one is a whole vibe 🧮 it's the 16-bit one's complement of the one's complement sum of a pseudo header made from information in the IP header, plus the IFMP message itself. the pseudo header gets conceptually prefixed to the IFMP message and holds the Source Address, the Destination Address, and the Protocol fields from the IPv4 header, along with the total length of the IFMP message starting at the version field. that length is the same as the IPv4 Total Length field minus the length of the IPv4 header itself 🌈
Sender Instance The sender's instance number for the link, taken from the IFMP Adjacency Protocol. 🫶
Peer Instance What the sender believes the peer's current instance number is for the link, taken from the IFMP Adjacency protocol. 🦋
Sequence Number The sender MUST increment this by one, modulo 2**32, for every IFMP Redirection Protocol message sent across a link. it lets the receiver process the messages in order 🍓 and it gets set to zero when a node resets the link.
Message Body this holds a list of one or more IFMP Redirection Protocol message elements. every element in the list has the same message type, because the Op Code field applies to the whole IFMP message 💖 the number of elements in a single packet MUST NOT cause the total size of the IFMP message to exceed the MTU size of the underlying data link. and only a single message element is permitted in a Label Range message or in an Error message ✨
No IFMP Redirection Protocol messages can be sent across a link until the IFMP Adjacency Protocol has achieved state synchronization across that link 🙈 any IFMP Redirection Protocol messages received on a link that doesn't currently have state synchronization MUST be discarded 💀 for every received IFMP Redirection Protocol message, the receiver MUST check the Source IP Address from the IP header, the Sender Instance, and the Peer Instance. the incoming message MUST be discarded if the Sender Instance and the Source IP Address fields don't match the values stored by the "Update Peer Verifier" operation of the IFMP Adjacency Protocol for the port the message came in on. the incoming message MUST also be discarded if the Peer Instance field doesn't match the current value for the Sender Instance of the IFMP Adjacency Protocol 🔥
4.1 Redirect Message 🦋
okay the Redirect Message element is how you tell an adjacent node to attach one or more labels to packets from one or more specified flows, each for a specified amount of time 🧚 the Redirect message is not acknowledged, so no reply needed 🙃
Each Redirect message element looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flow Type this specifies the Flow Type of the flow identifier in the Flow Identifier field 🎀
Flow ID Length this specifies the length of the Flow Identifier field in integer multiples of 32 bit words 🌸
Lifetime field this specifies, in seconds, how long this redirection is valid 💜 the association of flow identifier and label SHOULD be discarded at a time no greater than what the Lifetime field says. and a value of zero is not valid 🙈
Label field this holds a 32 bit label 🍓 the format of the label depends on the type of physical link the Redirect message is sent across. (the format of the label for ATM data links is specified in [ENCAP].) ✨
Flow Identifier this identifies the flow the specified label should be associated with 🦋 the length of the Flow Identifier field MUST be an integer multiple of 32 bit words so the 32 bit alignment stays intact 🫶
A node can send an IFMP message with one or more Redirect message elements across a link to its upstream neighbor. each Redirect message element asks the upstream neighbor to associate a given link-level label with packets from a specified flow, for up to a specified amount of time 🔥 a node that gets an IFMP message with Redirect message elements from an adjacent downstream neighbor can choose to ignore any or all of them 💅 neither the IFMP message nor any of its Redirect message elements gets acknowledged.
if the node decides to accept a Redirect message element and redirect that flow, it SHOULD attach the label from that element to every further packet sent on that flow, until it decides to stop or the specified lifetime runs out 🌈 while the flow stays redirected, the encapsulation defined by the Flow Type in the Redirect message element MUST be used for every packet in that flow 🧚 if the label in a Redirect message element is outside the range that can be handled across the relevant link, a Label Range message can be sent back to the sender. the Label Range message tells the sender of the Redirect message what range of labels can be sent across the link 👑
if a Redirect message element comes in for a flow that's already redirected, the Label field in the received element MUST be checked against the label stored for the redirected flow 💀 if they match, the lifetime of the redirected flow gets reset to whatever the Redirect message element says. if they don't match, the Redirect message element is ignored and the flow goes back to the default state 🙃 there's a minimum time between Redirect message elements for the same flow, and the default value is one second ⭐
if a receiving node finds an error in any field of a Redirect message element, it MUST discard that element without affecting any other Redirect message elements in the same IFMP message 🙈 the receiver SHOULD return an error message to the sender only if it doesn't understand the version of the IFMP protocol in the received message, or doesn't understand a Flow Type in any of the Redirect message elements 😭 an Error Message SHOULD be returned for each Flow Type that isn't understood 🫶
4.2 Reclaim Message
okay so the Reclaim message element is how a node tells an adjacent upstream node "hey, unbind these flows from their labels and release the labels" 🦋 the whole point is cleaning up bindings so the labels can be reused ✨
Each Reclaim message element has this structure 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flow Type specifies the Flow Type of the Flow Identifier contained in the Flow ID field 🌸
Flow ID Length specifies the length of the Flow Identifier field in integer multiples of 32 bit words 🧚
Reserved is unused and SHOULD be set to zero by the sender and ignored by the receiver. (Yes, I'm capitalising it, it's that important 💅)
Label contains the label to be released 🎀
Flow Identifier contains the flow identifier to be unbound ✨
A node can send a Reclaim message element to instruct an adjacent upstream node to unbind a flow from the label it's currently bound to, return the flow to the default forwarding state, and release the label. Each Reclaim message element applies to a single flow and a single label, no mixing 🫶 When the receiver has completed the operation, it MUST issue a Reclaim Ack message element. Reclaim Ack message elements can be grouped together, in any order, into one or more IFMP Reclaim Ack messages and sent back to the sender as proof the operation is done 💜
If a Reclaim message element is received indicating an unknown flow, a Reclaim Ack message element MUST be returned containing the same Label and Flow Identifier fields from the Reclaim message 🙈
If a Reclaim message element is received indicating a known flow, but with a Label that is not currently bound to that flow, the flow MUST be unbound and returned to the default forwarding state, and a Reclaim Ack message is sent containing the actual label the flow was previously bound to. this one is giving "I know exactly where you've been" 👀
If the receiver detects an error in any of the fields of a Reclaim message element, the receiver MUST discard that message element, without affecting any other Reclaim message elements in the same message. The receiver MUST return an error message to the sender only if it does not understand the version of the IFMP protocol in the received message, or does not understand a Flow Type in one of the Reclaim message elements. no drama, just the two exceptions 💀
4.3 Reclaim Ack Message
the Reclaim Ack message element is how a receiving node says "got it, those labels are released" ✨ it's the confirmation that closes the loop 🦋
Each Reclaim Ack message element has this structure 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flow Type specifies the Flow Type of the Flow Identifier contained in the Flow Identifier field 🌸
Flow ID Length specifies the length of the Flow Identifier field in integer multiples of 32 bit words 🧚
Reserved is unused and SHOULD be set to zero by the sender and ignored by the receiver 💅
Label contains the label released from the flow specified by the Flow Identifier 🎀
Flow Identifier contains the Flow Identifier from the Reclaim message element that requested the release of the label specified in the Label field ✨
A Reclaim Ack message element MUST be sent in response to each Reclaim message element received. It's sent to indicate that the requested flow is now unbound and the label is now free 🕊️ If possible, each Reclaim Ack message element SHOULD NOT be sent until all data queued for transmission on the link, using the label specified for release, has been sent. so the label isn't released while there's still stuff waiting to go out, very responsible 🫶
If a Reclaim Ack message element is received specifying a flow for which no Reclaim message element was issued, that Reclaim Ack message element MUST be ignored, but no other Reclaim Ack message elements in the same message MUST be affected. 🙃
If a Reclaim Ack message element is received specifying a different label from the one sent in the original Reclaim message element for that flow, the Reclaim Ack message element SHOULD be handled as if the reclaim operation were successful. the vibe is "close enough, we move on" 🍓
If an error is detected in any of the fields of a Reclaim Ack message element, that message element MUST be discarded, but no other Reclaim Ack message elements in the same message MUST be affected.
The receiver SHOULD return an Error message to the sender only if it does not understand the version of the IFMP protocol in the received message, or does not understand a Flow Type in one of the Reclaim Ack message elements. 💜
4.4 Label Range Message
the Label Range message element is what a node sends back when a Redirect message asked for a label that's outside the range the receiver can actually handle 🙈 it's basically "not that one bestie, here's what I CAN do" 💅 it tells the sender which label range can be handled on the relevant link 🦋
Only a single Label Range message element is permitted in a Label Range message. Each one looks like this 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Minimum Label is the minimum value of label that can be specified in an IFMP Redirection Protocol message across this link 🌸
Maximum Label is the maximum value of label that can be specified in an IFMP Redirection Protocol message across this link 🧚
All values of label within the range from Minimum Label to Maximum Label, inclusive, MAY be specified in an IFMP Redirection Protocol message across the link. so the range is inclusive on both ends, no edge cases being left out 🎀
4.5 Error Message
an Error message can be sent by a node in response to any IFMP Redirection Protocol message 🚨 think of it as the "oops, something went wrong" text of this protocol 💀
Only a single Error message element is permitted in an Error message. The Error message element has this structure 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Error Code specifies which error has occurred 🔥
Each Error message can specify a single Parameter. 🫶
Two Error message elements are specified:
Bad Version: Error Code = 1. The sender of the Error message cannot process the version of the IFMP protocol of the message that caused the error. This message MUST only be sent if the version of the message that caused the error is greater than the most recent version that the sender of the Error message can process. The Parameter field of this Error message gives the most recent version of the IFMP protocol that the sender can process, right justified, with the unused most significant bits of the Parameter field set to zero. this one's a little dramatic: the version has to be newer than what the sender knows, not just different 🙄
Bad Flow Type: Error Code = 2. The sender of the Error message does not understand a Flow Type that was received in the message that caused the error. The Flow Type that caused the error is given in the Parameter field, right justified, with the unused most significant bits of the Parameter field set to zero. the error tells you exactly which Flow Type confused it, which is iconic of it 👑
REFERENCES ✨
[ENCAP] Newman, P., et. al., "Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0," Ipsilon Networks, RFC 1954, May 1996.
[RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, September 1981.
SECURITY CONSIDERATIONS 🔐
Security issues are not discussed in this memo. 🙈 no security section, bestie. I'm not saying it's safe, I'm saying the memo didn't go there 💀
AUTHORS' ADDRESSES 💌
Here are the authors, with their contact details, exactly as listed:
Peter Newman Phone: +1 (415) 846-4603
Ipsilon Networks, Inc. EMail: pn@ipsilon.com
W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334
Sprint EMail: texas@sprintcorp.com
Robert M. Hinden Phone: +1 (415) 846-4604
Ipsilon Networks, Inc. EMail: hinden@ipsilon.com
Eric Hoffman Phone: +1 (415) 846-4610
Ipsilon Networks, Inc. EMail: hoffman@ipsilon.com
Fong Ching Liaw Phone: +1 (415) 846-4607
Ipsilon Networks, Inc. EMail: fong@ipsilon.com
Tom Lyon Phone: +1 (415) 846-4601
Ipsilon Networks, Inc. EMail: pugs@ipsilon.com
Greg Minshall Phone: +1 (415) 846-4605
Ipsilon Networks, Inc. EMail: minshall@ipsilon.comIpsilon Networks, Inc. is located at:
2191 East Bayshore Road
Suite 100
Palo Alto, CA 94303
USASprint is located at:
Sprint
Sprint Technology Services - Long Distance Division
9300 Metcalf Avenue
Mailstop KSOPKB0802
Overland Park, KS 66212-6333
USA📦 where this page comes from
- ietf: rfc1953 1996-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms