RFC 2124
Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0
RFC 2124: Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 🎀
okay bestie, this is RFC 2124 💅 It came out in March 1997 and the title is Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0. The authors are P. Amsden, J. Amweg, P. Calato, S. Bensley and G. Lyons, all from Cabletron Systems Inc. 🦋 It's Informational, so it's giving "here's some info for the internet crowd," not a standard. It doesn't obsolete or update anything listed in its header.
Status of this Memo ✨
This memo gives information to the internet community. It does not specify an internet standard of any kind. Distribution of this memo is unlimited 🌸
Abstract 💖
So the big idea is LFAP, the Light-weight Flow Admission Protocol 🔥 It lets an external Flow Admission Service (FAS) run flow admission at the switch. The best part is that vendors or customers can deploy flexible Flow Admission Services without changing the switch or putting an undue burden on it. Main character energy 👑
This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. With LFAP, a Flow Admission Service can:
- allow or disallow flows
- define the parameters a given flow operates under (operating policy)
- or redirect the flow to an alternate destination
The FAS can also keep track of current or historical flows for billing, capacity planning and other purposes 📊
Table of Contents 🧚
1. Introduction .................................................. 2
2. Message Flows ................................................. 3
3. Message Contents and Format ................................... 4
3.1. IE Formats ............................................. 5
3.2. Flow Admission Request (FAR) Message ................... 14
3.3. Flow Admission Acknowledge (FAA) Message ............... 15
3.4. Flow Admission Update (FAU) Message .................... 15
3.5 Flow Update Notification (FUN) Message .................. 16
3.6. Flow Update Acknowledge (FUA) Message .................. 16
3.7. Flow Change Request (FCR) Message ...................... 17
3.8. Flow Change Acknowledge (FCA) Message .................. 17
3.9. Administrative Request (AR) Message .................... 18
3.10. Administrative Request Acknowledge (ARA) Message ...... 18
4. Error Handling ................................................ 18
4.1. FAA Related Error Handling ............................. 19
4.2. FUA Related Error Handling ............................. 19
4.3. FCA Related Error Handling ............................. 19
4.4. ARA Related Error Handling ............................. 20
5. Security Considerations ....................................... 20
6. Author's Addresses ............................................ 20
7. References .................................................... 211. Introduction 🦋
LFAP, the Light-weight Flow Admission Protocol, lets an external Flow Admission Service (FAS) manage flow admission at the switch 💅 Flexible Flow Admission Services can be deployed by a vendor or customer without changes to, or undue burden on, the switch. It gives network managers, or management systems, a way to set connection admission parameters for multiple switches in a single management domain. They do this by configuring policy information and other data through one centralized connection admission control point 🎀
Specifically, this document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. Using LFAP, a Flow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes ✨
Okay, the big win here is that LFAP takes a huge weight off switch vendors 🫶 They don't have to deal with enforcing policy under any number of policy representation schemes. Switch configuration managers don't have to translate organization-determined policy or usage procedures, limitations and guidelines into an arbitrarily large set of vendor-specific representations either 😭 And it makes plug-and-play connection management possible right now, even though there's no standardized representation for connection policies yet. Iconic 🔥
This document describes the message flow between switch CCE and FAS, the messages used, and the error handling that applies. Together, this is the LFAP interface definition 🌈
2. Message Flows 🌸
Message flows between CCE and FAS entities always start at the switch 💖 That makes the switch the point where connectivity originates. The CCE needs IP reachability using some approach described elsewhere (e.g. [1577] or [LANE]), and an IP address for the FAS has to be preconfigured at the switch CCE. The CCE sets up TCP connectivity using the registered port number - ### 🧚
So, Flow Admission Request (FAR) messages are sent by a switch's Call Control Entity (CCE) to the Flow Admission Service (FAS) 💅 These get sent when a flow is about to be set up by the switch. They carry specific info about the flow, like the flow identifier, source/destination and qualifying information, which may be needed to decide whether the flow is admissible and what operating policies apply if it gets admitted 👑
The FAS answers with a Flow Admission Acknowledge (FAA) message, sent back to the CCE. It has a status showing whether the connection is admissible, plus any operating policy info that applies to the flow 🦋 Now here's the drama: if a FAA message contains mandatory operating policies that the switch CCE does not understand, the switch would abort the flow using the Flow Admission Update (FAU) message 😭
,--------------------. ,--------------------.
| FAS | | Switch |
| | | CCE |
`--+----+----+-------' `------+-----+----+--'
^ | ^ ^ | ^ | ^ ^ ^ ^ ^ | ^ | | ^ |
| | | | | | | | | AR | | | | | | | | |
| | | | | | | | '--------------' | | | | | | | |
| | | | | | | | ARA | | | | | | | |
| | | | | | | '------------------' | | | | | | |
| | | | | | | FUA | | | | | | |
| | | | | | `------------------------' | | | | | |
| | | | | | FUN | | | | | |
| | | | | `----------------------------' | | | | |
| | | | | FCR | | | | |
| | | | `----------------------------------' | | | |
| | | | FCA | | | |
| | | `--------------------------------------' | | |
| | | FAU | | |
| | '--------------------------------------------' | |
| | FAA | |
| `------------------------------------------------' |
| FAR |
`----------------------------------------------------'Once a connection is established, the switch CCE keeps sending Flow Update Notification (FUN) messages to the FAS 📊 It does this periodically while it maintains the connection, and whenever the connection state changes. The FAS replies with a Flow Update Acknowledge (FUA) message, and if it detects an error condition, that FUA carries a Flow failure code 🙈 One example of an error condition is getting a FUN message that reports octets received and sent for a connection that was never admitted.
The FAS may send a Flow Change Request (FCR) to the CCE. It does this either to change the state of a specific connection or to set any new or changed policy information that applies to the flow 💜
The CCE replies with a Flow Change Acknowledge (FCA) message. It may also respond with a flow failure code that points at the offending flow or policy change 💅
Either the CCE or the FAS can start an Administrative Request (AR) 🌈 The CCE uses it to get a Flow Identifier Prefix. The FAS uses it to ask for FUN messages to be sent back on some set of flows.
The requested entity (FAS or CCE) replies with an Administrative Request Acknowledge 🧚 The FAS uses the ARA to return the requested Flow Prefix. The CCE uses the ARA to return any Flow Identifiers that were in error on the AR.
3. Message Contents and Format 💖
LFAP defines nine messages: "Flow Admission Request", "Flow Admission Acknowledge", "Flow Admission Update", "Flow Update Notification", "Flow Update Acknowledge", "Flow Change Request", "Flow Change Acknowledge", "Administrative Request" and "Administrative Request Acknowledge" (FAR, FAA, FAU, FUN, FUA, FCR, FCA, AR, ARA respectively) 🎀
Here's the cast list. FAR messages are sent by a switch call control entity (CCE) to the Flow Admission Service (FAS). FAA messages are the FAS's responses to the CCE. FUA messages are responses from the CCE, but only under error conditions 🙈 FUN messages originate at switches and get acknowledged by FUA messages from the FAS. FCR messages are sent by the FAS to the CCE and get acknowledged by FCA messages. AR messages can be sent by either entity (FAS or CCE), and they get acknowledged by ARA messages 🫶
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 | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Information Element (IE) Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Every LFAP message uses the general format shown above 🌸 Version is 1, and the Op Codes go like this:
FAR - 1
FAA - 2
FAU - 3
FUN - 4
FUA - 5
FCR - 6
FCA - 7
AR - 8
ARA - 9The Status field is the status for the whole message 💅 Its possible values are:
STATUS:
SUCCESS = 0
CORRUPTED = 1
VERSION = 2The Message ID links each original message to its matching response 🧚 A Message ID must be unique for the combination of sender and responder while an original message is pending. And the Message Length doesn't count the 8 octets of the message header ✨
3.1. IE Formats 🦋
IE fields are made up of a 2-octet TYPE, a 2-octet LENGTH and a variable-length VALUE sub-field 💖 Every IE comes in even multiples of 4 octets, left-aligned and zero-filled if needed. The LENGTH is computed without counting the 4-octet TYPE and LENGTH fields 🎀
The formats for the individual IEs are laid out in the sections that follow 🌈
Byte Count IE ✨
okay so the Byte Count IE is literally how you keep track of the count of octets sent and received for the identified connection 🧚 the IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 1 or 2 | LENGTH = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Bytes Received -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Bytes Sent -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+there are two flavours of byte count 💅
- Type 1 means the byte count is a running counter, and it's the count from the beginning of the flow establishment 🌸
- Type 2 means the byte count is a delta counter, and it's the count since the last FUN message 🦋
Packet Count IE 🎀
the Packet Count IE contains the count of packets, cells or frames sent and received for the identified connection. the IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 3 or 4 | LENGTH = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Packets/Cells/Frames Received -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Packets/Cells/Frames Sent -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the two types here are giving the same vibe as before 👑
- Type 3 means the packet/cell/frame count is a running counter and is the count from the beginning of the flow establishment 🧚
- Type 4 means the packet/cell/frame count is a delta counter and is the count since the last FUN message 💜
Client Data IE 🫶
this one is for deciding admission policy for a specific connection request, based on arbitrary client data (OCTET STRING [8824]). the IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 5 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Client Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Destination Address IE 🍓
the Destination Address IE holds the destination address associated with a message. the IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 6 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Number | Address Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Address Length field contains the length of the address excluding any pad of zeros used to align the address field. 🙈
the Address Family Numbers include:
1 - 14 (decimal)as specified in [1700]15E.164 with NSAP format subaddress
Flow ID IE 🌈
okay this one is a bit of a saga, so get comfy 🧋 the goal is to accumulate the flow accounting statistics across multiple FAS's if a FAS fails, and for that you need a globally unique flow identifier. so the FAS assigns a prefix if the CCE requests one, and then the CCE assigns a CCE flow identifier that it guaranties to be unique for the use of the FAS flow identifier prefix for each flow admitted. if the CCE needs to reuse a CCE flow ID, it must acquire a new FAS prefix. if a CCE can't support the FAS flow identifier, then it does not request a FAS prefix and uses a FAS length of 0 in all updates to the flow. and if the CCE doesn't support the FAS identifier prefix, then when a CCE fails over, all calls will need to be readmitted and will be seen as two separate calls at the accumulation point. the Flow ID IE is copied exactly in all messages that refer to this flow. the IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 7 |FAS Length = 8 |CCE Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
|+-+-+-+-+- FAS assigned Flow Identifier Prefix -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+
| CCE assigned Flow Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flow State IE 🦋
the Flow State IE carries the intended end state for the Flow associated with the message containing this IE. the IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 8 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Flow State has one of these values and meanings:
0 - INACTIVE - Flow is inactive
1 - ACTIVE - Flow is activePolicy IE's 💅
there are two basic types of Policy IE's: Optional and Mandatory. with an optional operating policy, if the combination of policy and value given can't be interpreted by a switch CCE, it may be safely ignored. with a mandatory operating policy, if the combination of policy and value given can't be interpreted by a switch CCE, it must abort the flow state. examples of optional operating policies are Checkpoint Timer and Connection Priority. 🔥
there are also two forms of the policy ID. the first is where the policy ID is a number, and the second is where the policy ID is an Object Identifier. the policy IDs with number values are identified in this document and its proposed changes over time. the Object Identifier IDs can be used by individual implementers to apply proprietary or experimental additions to this document and still be compliant with the general form of this document. ✨
Operating Policy IEs are made up of a Policy ID, a length and a value. for the policies defined in this document, a length is required and specified here. for policies using the OID format, the length may be implied by the OID or be part of the policy value, as decided by the individual implementation. 🧚
Policy IE format for Policy ID's defined in this document 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 9 + 10 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy ID | Policy Value length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
~ Policy Value ~
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Policy Pairs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 9 is an Optional Policy and type 10 is a Mandatory Policy. 💖
the following policy IDs and policy values are presently defined or under consideration. this is the table, bestie 🍓
Policy ID Value Meaning
Usage 01xx The purpose of this set of
policies is for usage
constraints. This set of
policies in the future may
include Connection Count,
Maximum Bandwidth and Connect
Time.
Routing 02xx The purpose of these polices
is to allow for various
routing policies to be
enforced in the a switching
environment. This set of
policies may include
Optimization, Designated
Transit List, Restricted
Transit List and Path Cost.
Administrative 03xx
Keep Statistics 0301 = 0 Keep statistics on this flow
Not= 0 Do Not keep statistics on flow
Connection 0302 1 - 255 Priority of this connection
Priority Less is higher
Checkpoint 0303 1 - 2^31 Seconds between FUN on a flow
Timer
Checkpoint
Threshold 0304 1 - 2^63 # of bytes to collect before
sending a FUN on a flow
Connectionless 04xx The purpose of these policies
is to control connection
unaware calls. This set will
include Inactivity Timer and
Bandwidth allocation.Policy IE format when Policy ID is an Object Identifier 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 11 + 12 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Policy OID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Policy ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Policy Pairs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so the type 11 one is an optional policy, and type 12 is a mandatory policy. Main character energy 💅✨
Service Identifier IE 🦋
This one is used in figuring out the admission policy for a specific connection request based on service type. The Service Identifier is specified as an OCTET STRING [8824]. 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 13 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Service Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Source Address IE 🌸
Source address associated with a message. TYPE is 14, and the format is the same as the Destination Address IE.
Source Switch Address IE 🍓
Source Switch address associated with a message. TYPE is 15, and the format is the same as the Destination Address IE.
Destination Switch Address IE 🧚
Destination Switch address associated with a message. TYPE is 16, and the format is the same as the Destination Address IE.
Time IE ⭐
This is the time (as an SNMPv2 TimeStamp [1443]) associated with the status/statistics observed. TYPE is 17, and the format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 17 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Multiple Record IE 📦
The Multiple Record IE is composed of 4 parts. 🔥 There's the record descriptor, the fixed information, the record format IEs, and the individual records. The record descriptor has two fields: the first is the length of the fixed information field, and the second is the length of the Record Format section. The fixed information is the IEs that apply to all the records that follow. The Record Format is the list of IEs that make up each record. The individual record section holds the individual records being reported, in the format given by the Record Format section. It's giving organized 🗂️💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 18 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of fixed Information | Length of Record Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Fixed Information ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Record Format ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Individual Record (1) |
| Individual Record (2) |
| Individual Record (3) |
| . |
~ . ~
| . |
| Individual Record (n) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flow Failure Code IE 💀
The flow failure code is the reason why an operation on a given flow failed. The IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 19 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Failure Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The flow failure code has one of the following values and meanings:
0 - POLICY_REJECT - A policy reject has occurred
1 - NO_SUCH_FLOW - The specified was flow was not found
2 - AMBIGUOUS - Duplicate FAR caused this error
3 - DESTINATION_UNKNOWN - The redirect destination was unknownCommand Code IE 🎀
Command Code is an administrative request command to perform a particular function. The IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 20 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The command code has one of the following values and meanings:
0 - RETURN_INDICATED_FLOWS - Return FUNs indicated
1 - RETURN_ALL_CHANGED_FLOWS - Return FUNs indicated
2 - RETURN_ALL_FLOWS - Return FUNs indicated
3 - RETURN_FLOW_PREFIX - Return a new flow prefixFlow Identifier Prefix IE 🧚♀️
The Flow Identifier Prefix IE gives the prefix that the FAS created to keep a globally unique ID. The IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 21 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
|+-+-+-+-+- FAS assigned Flow Identifier Prefix -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.2. Flow Admission Request (FAR) Message ✨
Status is set to SUCCESS in FAR messages. On top of that, FAR messages may contain the following IEs:
- Source Switch Address IE: the address of the switch making the request
- Dest Switch Address IE: the address of the switch the request is made to
- Source Address IE: the flow "from" address
- Destination Address IE: the flow "to" address
- Service Identifier IE: the identifier for the service requested
- Flow ID IE: a locally unique identifier for the flow (unique to the update reporting entity)
- Client Data IE: client data as applied to this request
- Time IE: the switch time of the admission request
Mandatory IE's 🔒
- Source Address
- Destination Address
- Flow ID
- Time
Optional IE's 🌈
- Source Switch Address
- Destination Switch Address
- Client Data
FAR messages are sent by a switch CCE when it wants to verify that a flow about to be established is valid. 💖 FAR messages refer to a single flow only, and they don't do multi IE functionality. The source and destination addresses are the ones the switch CCE determined as the points where the flow starts and ends. The Service ID is the service type/category tied to the desired flow. The client data is arbitrary information about the client associated with the desired flow.
3.3. Flow Admission Acknowledge (FAA) Message 🦋
Status reflects the result of the corresponding FAR message (see Error Handling for details). The Message ID is copied from the FAR message. FAA messages may also have the following IEs:
- Optional Operating Policy IE: policy(s) that may apply to this flow.
- Mandatory Operating Policy IE: policy(s) that must apply to this flow.
- Destination Address IE: may be included if the flow should be redirected.
- Flow Failure Code IE: indicates the cause of flow failure
FAA messages are sent by a FAS in response to FAR messages received from a switch CCE. The operating policy info is whatever the FAS decided is either desirable or required for the flow named in the corresponding FAR message. 🫶
3.4. Flow Admission Update (FAU) Message 🔥
Status reflects the result of the corresponding FAA message (see Error Handling for details). The Message ID is copied from the FAR or FAA message. FAU messages may also have the following IEs:
- Flow ID IE: identifier for the flow
- Flow Failure Code IE: indicates the cause of flow failure
FAU messages are sent by a switch CCE in response to FAA messages received from a FAS. The FAU message is only returned by the switch CCE if an error was detected as a result of the FAA message. 👑
Okay, that's where this part ends, but there's a lot more to come! 🌸
3.5. Flow Update Notification (FUN) Message 🦋
Okay so, Status gets set to SUCCESS in FUN messages 💖 and FUN messages can also carry these IEs:
Time IE: switch time of notificationFlow ID IE: identifier for the flowFlow State IE: state of the flow at time of notificationByte Count IE: octets sent and received for this flowPacket Count IE: packets sent and received for this flow
Mandatory IE's:
Time: if it's a multiple IE, it only needs to be given once in the fixed information section. If it's given in record format, it must be in each individual record.
Optional IE's (at least one must be present):
Flow StateByte CountPacket Count
FUN messages are sent periodically by a CCE to the FAS 🌸 (possibly on a schedule set in an operating policy tied to the flow). The Time IE may come first and only once. If only one flow is being reported on, you just return the IEs and their values. If multiple flows are being reported, use the multiple record IE. This cuts down on overhead for transmissions, which is so smart ✨. FUN messages may also be sent because of an AR message or an FCR message. The FCR message would be the one requesting that the flow state be set to inactive 🧚.
The flow ID tells you which flow this update applies to 💅. Flow state is the state of the flow at the moment this message is sent. Counts are as specified in the IE definitions. The FAS's are coordinated, and they'll sort out receiving FUN information from a CCE that lost its connection with its FAS and went to an alternative FAS. That's giving teamwork 🫶
3.6. Flow Update Acknowledge (FUA) Message 💜
Status is set to SUCCESS in FUA messages unless an error is detected (see "Error Handling"). Message ID is copied from the FUN message.
FUA messages are sent by the FAS to acknowledge a FUN message from the switch CCE. If a FUN message had a multiple record IE and any of the updates had an error, then the FUA would contain a multiple IE with a Flow ID and Flow Failure Code 😭. A status of SUCCESS means the info in the corresponding FUN message was accepted and is now the FAS's responsibility. Trust, bestie 👑
3.7. Flow Change Request (FCR) Message 🎀
Status is set to SUCCESS in FCR messages. An FCR message may also contain these IEs:
Flow ID IE: identifier for the flow.Flow State IE: set to inactive to stop a flow.Optional Operating Policy IE: possibly new policy(s) that may apply to this flow.Mandatory Operating Policy IE: possibly new policy(s) that must apply to this flow.
Mandatory IE's:
Flow ID
Optional IE's:
Flow StateOptional Operating PolicyMandatory Operating Policy
FCR messages are sent by the FAS to the CCE to add to or change existing operating policy info, or to stop a flow 🍓. Flow ID says which flow this message applies to. The FAS can stop a flow by setting its flow state to inactive. That makes the CCE generate a FUN message with the final flow statistics, and the CCE also returns an inactive flow state on that flow. If the FAS wants to change operating policy info, it just includes the new info in the FCR message along with the flow ID. Easy 💅
3.8. Flow Change Acknowledge (FCA) Message 🌈
Status is set to SUCCESS in FCA messages unless an error is detected (see "Error Handling"). Message ID is copied from the FCR message. FCA messages contain IEs if an error was detected in the corresponding FCR message (see "Error Handling").
If an error occurs, an FCR may contain these IE's:
Flow ID IE: if the FAS requested statistics on an unknown flow.Flow Failure Code: for theFlow ID IEabove.
FCA messages are sent by a switch CCE in response to an FCR 🦋
3.9. Administrative Request (AR) Message ⭐
Status is set to SUCCESS in AR messages. AR messages may also contain the Command IEs:
Mandatory IE's:
Command IE
AR messages are sent by either the switch CCE or the FAS when they want to perform one of the Command IE's 🧚
3.10. Administrative Request Acknowledge (ARA) Message 💖
Status reflects the result of the corresponding AR message (see Error Handling for details). Message ID is copied from the AR message. ARA messages may also have these IEs:
Flow ID IE: if the FAS requested statistics on an unknown flow.Flow Failure Code: for theFlow ID IEabove.Flow Identifier Prefix IE: if the ARA is the response to a CCE Command toRETURN_FLOW_PREFIX.
ARA messages are sent by a FAS or CCE in response to an AR message received from the CCE or FAS respectively 🫶
4. Error Handling 🔥
Incompatible version: if a component gets any LFAP request or notification message with a version number other than the one (or ones) it supports, it responds with an acknowledge message whose Status is VERSION. That response contains no IEs, so it may be treated as a generic FAILURE message 🙈
Corrupted message contents: if a component receives an LFAP message it can't understand, it sends back a similar generic FAILURE message with Status set to CORRUPTED. A FAA message may contain a Flow ID IE only if that IE was included in the part of the corrupt LFAP message that came before the point of corruption. The LFAP sender should re-send the original message at least one time if it still wants to admit the requested connection 😭
Apart from incompatible version and corrupted message contents, error handling is basically tied to how both the response sender and receiver process response messages. The sections below are organized around processing FAA, FUA, FCA and ARA messages 💅
4.1. FAA Related Error Handling 🌸
Non-unique Flow ID: receiving a FAR message with a non-unique Flow ID can happen for two reasons. The CCE may have re-sent a FAR message, or an error may have happened in the ID generation function. If the entire message matches a FAR message received previously in every respect, except possibly Message ID, the FAS responds the same way it would have to that prior message. Otherwise, the Flow ID is returned with a Flow Failure Code set to AMBIGUOUS. The CCE should choose a new Flow ID and retry the FAR message if it still wants to admit the requested connection 💖
Flow is inadmissible: the FAS may decide a flow isn't admissible for policy reasons. In that case, the Flow ID is returned along with the Flow Failure Code of POLICY_REJECT 🚫
4.2. FUA Related Error Handling 🧚
Flow Not Admitted: this is when Flow information comes in for an unadmitted connection. The Flow ID IE identifies a flow that was not admitted, or whose admission status was lost. The FAS returns the Flow ID with a Flow Failure Code of NO_SUCH_FLOW. The switch CCE should send an appropriate FAR message. The FAS may keep track of how often this error happens and send an FCR message to the CCE asking it to drop the reported connection 👑
4.3. FCA Related Error Handling 🍓
Flow change requested for a non-existent flow: the Flow ID IE identifies a connection this CCE has no state information for. The FCA message carries the Flow ID with a Flow Failure Code set to NO_SUCH_FLOW, and it contains the Flow ID copied from the corresponding FCR message.
Policy changes requested were not supported by the CCE: the FCA message carries the Flow ID with a Flow Failure Code set to POLICY_REJECT, and it contains the Flow ID copied from the corresponding FCR message 🌈
4.4. ARA Related Error Handling ✨
Flow statistics requested for a non-existent flow: the Flow ID IE identified a connection this CCE has no state information for. The ARA message carries the Flow ID with a Flow Failure Code set to NO_SUCH_FLOW, and it contains the Flow ID copied from the corresponding FCR message. If there were multiple non-existent flows, the multi IE format could put the Flow Failure Code in the fixed information section and the individual Flow ID's in the record section 🦋
5. Security Considerations 💀
Security issues are not discussed in this memo. 🙈 Yes, you read that right, no security section at all. Bestie, this is a real gap, so keep it in mind when you implement anything from this doc 😭🔥
6. Author's Addresses 🎀
- Paul Amsden Phone:
+1 (603) 337-7408EMail:amsden@ctron.com - Jim Amweg Phone:
+1 (603) 337-5247EMail:amsden@ctron.com - Paul Calato Phone:
+1 (603) 337-7625EMail:amsden@ctron.com - Stephen Bensley Phone:
+1 (603) 337-7061EMail:amsden@ctron.com - Gregory Lyons Phone:
+1 (603) 337-5318EMail:amsden@ctron.com
Cabletron Systems, Inc. is located at:
P.O. Box 5005
Rochester, NH, 03866-5005
USA7. References 📚
[363]: "B-ISDN ATM Adaptation Layer (AAL) Specification," International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.[1443]: "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, April 1993.[1700]: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.[8824]: Information technology - Open Systems Interconnection - "Specification of Abstract Syntax Notation One (ASN.1), Second edition", ISO/IEC TR 8824: 1990 (E) 1990-12-15.[9577]: "Telecommunications and Information Exchange Between Systems - Protocol Identification in the Network Layer", ISO/IEC TR 9577: 1990 (E) 1990-10-15.[LANE]: "LAN Emulation Over ATM Specification - Version 1.0", ATM Forum af-lane-021.000, January, 1995. 🫶
📦 where this page comes from
- ietf: rfc2124 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms