RFC relevance of messages

As per Relevance of the word messages, we have this rfc below:

Network Working Group P.
Request for Comments: 2124 J.
Category: Informational P.
S.
G.
Cabletron Systems Inc
March 1997

Cabletron's Light-weight Flow Admission Protocol
Version 1.0

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

Light-weight Flow Admission Protocol, LFAP, allows an external
Admission Service (FAS) to manage flow admission at the switch
allowing flexible Flow Admission Services to be deployed by a
or customer without changes to, or undue burden on, the switch

Specifically, this document specifies the protocol between the
Connection Control Entity (CCE) and the external FAS. Using LFAP,
Flow Admission Service can: allow or disallow flows, define
parameters under which a given flow is to operate (operating policy
or, redirect the flow to an alternate destination. The FAS may
maintain details of current or historical flows for billing,
planning and other purposes

Table of

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

Amsden, et. al. Informational [Page 1]

RFC 2124 LFAP March 1997

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 .................................................... 21

1.

Light-weight Flow Admission Protocol, LFAP, allows an external
Admission Service (FAS) to manage flow admission at the switch
allowing flexible Flow Admission Services to be deployed by a
or customer without changes to, or undue burden on, the switch.
provides a means for network managers, or management systems,
establish connection admission parameters for multiple switches in
single management domain by configuring policy information and
data via a single centralized connection admission control point

Specifically, this document specifies the protocol between the
Connection Control Entity (CCE) and the external FAS. Using LFAP,
Flow Admission Service can: allow or disallow flows, define
parameters under which a given flow is to operate (operating policy
or, redirect the flow to an alternate destination. The FAS may
maintain details of current or historical flows for billing,
planning and other purposes

A significant advantage of this protocol is that it relieves
vendors from the complexity of policy enforcement under any number
policy representation schemes. Similarly, switch
managers do not need to translate organization-determined policy
usage procedures, limitations and guidelines into an
large set of vendor-specific representations. Finally, use of such
scheme makes possible plug-and-play connection management at
present time - in the absence of a standardized representation
connection policies

This document describes the message flow between switch CCE and FAS
the messages used and error handling that applies. This
the LFAP interface definition

Amsden, et. al. Informational [Page 2]

RFC 2124 LFAP March 1997

2. Message

Initiating message flows between CCE and FAS entities
originate at the switch. Therefore, the switch is the point at
connectivity is originated. The CCE must have IP reachability
some approach described elsewhere (e.g. [1577] or [LANE]) and an
address for the FAS must be preconfigured at the switch CCE. The
establishes TCP connectivity using the registered port number - ###.

As shown below, Flow Admission Request (FAR) messages are sent by
switch's Call Control Entity (CCE) to the Flow Admission
(FAS). These messages are sent when a flow is about to be set up
the switch and contain specific information relating to the flow -
such as flow identifier, source/destination and
information about the flow - that may be required to determine
admissibility of the flow and any operating policies that apply
the flow if it is admitted

The FAS responds with a Flow Admission Acknowledge (FAA) message (
the CCE) with a status indicating connection admissibility and
operating policy information that applies to the flow. If a
message contains mandatory operating policies that the switch
does not understand, the switch would abort the flow using the
Admission Update (FAU) message

,--------------------. ,--------------------.
| FAS | | Switch |
| | | CCE |
`--+----+----+-------' `------+-----+----+--'
^ | ^ ^ | ^ | ^ ^ ^ ^ ^ | ^ | | ^ |
| | | | | | | | | AR | | | | | | | | |
| | | | | | | | '--------------' | | | | | | | |
| | | | | | | | ARA | | | | | | | |
| | | | | | | '------------------' | | | | | | |
| | | | | | | FUA | | | | | | |
| | | | | | `------------------------' | | | | | |
| | | | | | FUN | | | | | |
| | | | | `----------------------------' | | | | |
| | | | | FCR | | | | |
| | | | `----------------------------------' | | | |
| | | | FCA | | | |
| | | `--------------------------------------' | | |
| | | FAU | | |
| | '--------------------------------------------' | |
| | FAA | |
| `------------------------------------------------' |
| FAR |
`----------------------------------------------------'

Amsden, et. al. Informational [Page 3]

RFC 2124 LFAP March 1997

When a connection is established, periodically during the course
maintaining the connection and when a change in connection
occurs, the switch CCE sends a Flow Update Notification (FUN)
to the FAS. The FAS, in turn, responds with a Flow
Acknowledge (FUA) message with a Flow failure code if a an
condition has been detected. An example of error conditions would
receipt of a FUN message indicating octets received and sent for
connection never admitted

The FAS may send a Flow Change Request (FCR) to the CCE either
effect a change in the state of a specific connection or to set
new/changed policy information that applies to the flow

The CCE replies with a Flow Change Acknowledge (FCA) message and
respond with a flow failure code indicating the offending flow
policy change

Either the CCE or the FAS may initiate a Administrative Request (AR).
The CCE uses it to get a Flow Identifier Prefix. The FAS uses it
request FUN messages be returned on some set of flows

The requested entity (FAS or CCE) replies with a
Request Acknowledge. The FAS uses the ARA to return the
Flow Prefix. The CCE uses the ARA to return any Flow Identifiers
were in error on the AR

3. Message Contents and

LFAP defines nine messages: "Flow Admission Request", "Flow
Acknowledge", "Flow Admission Update", "Flow Update Notification",
"Flow Update Acknowledge", "Flow Change Request", "Flow
Acknowledge", "Administrative Request" and "Administrative
Acknowledge" (FAR, FAA, FAU, FUN, FUA, FCR, FCA, AR,
respectively).

FAR messages are sent by a switch call control entity (CCE) to
Flow Admission Service (FAS). FAA messages are responses from the
to the CCE. FUA messages are responses from the CCE only under
conditions. FUN messages originate at switches and are
by FUA messages from the FAS. FCR messages are sent by the FAS to
CCE and are acknowledged by FCA messages. AR messages are sent
either the Entity (FAS or CCE) and are acknowledged by the
messages

Amsden, et. al. Informational [Page 4]

RFC 2124 LFAP March 1997

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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The general message format for all LFAP messages is as shown above
Version is 1 and Op Codes are as follows

FAR - 1
FAA - 2
FAU - 3
FUN - 4
FUA - 5
FCR - 6
FCA - 7
AR - 8
ARA - 9

The Status field serves as a Status on the overall message.
values that Status may assume are

STATUS
SUCCESS = 0
CORRUPTED = 1
VERSION = 2

Message ID is used to associate each original message with
corresponding response and must be unique for the combination
sender and responder while an original message is pending.
Message Length excludes the 8 octets of the message header

3.1. IE

IE fields consist of 2-octet TYPE, 2-octet LENGTH and a
length VALUE sub-fields. All IEs are even multiples of 4 octets
length, left-aligned and zero filled if necessary. Length is
excluding the 4 octet TYPE and LENGTH fields

Individual IEs are formated as described in following sections

Amsden, et. al. Informational [Page 5]

RFC 2124 LFAP March 1997

Byte Count

Contains the count of octets sent and received associated with
identified connection. 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 -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 1 Means that the byte count is a running counter and is
count from the beginning of the flow establishment
Type 2 Means that the byte count is a delta counter and is
count since the last FUN message

Packet Count

Contains the count of packets cells or frames sent and
associated with the identified connection. 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 -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 3 Means that the packet/cell/frame count is a running
and is the count from the beginning of the flow establishment
Type 4 Means that the packet/cell/frame count is a delta
and is the count since the last FUN message

Amsden, et. al. Informational [Page 6]

RFC 2124 LFAP March 1997

Client Data

For use in determination of admission policy relative to a
connection request based on arbitrary client data (OCTET
[8824]). 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

Destination address associated with a message. 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
any pad of zeros used to align the address field

Address Family Numbers include

1 - 14 (decimal) as specified in [1700]
15 E.164 with NSAP format

Flow ID

In order to accumulate the flow accounting statistics across
FAS's in case of a FAS failure a globally unique flow
needs to be formed. To accomplish this the FAS assigns a prefix
requested by the CCE. The CCE then assigns a CCE flow
that it guaranties to be unique for the use of the FAS
identifier prefix for each flow admitted. If the CCE needs to

Amsden, et. al. Informational [Page 7]

RFC 2124 LFAP March 1997

a CCE flow ID it must acquire a new FAS prefix. If a CCE
support the FAS flow identifier then it does not request a FAS
and uses a FAS length of 0 in all updates to the flow. If the
does not support the FAS identifier prefix then when a CCE fails
all calls will need to be readmitted and will be seen as two
calls at the accumulation point. Flow ID IE is copied exactly in
messages that refer to this flow. 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

Flow state is the intended end state for the Flow associated with
message containing this IE. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flow state has one of the following values and meanings

0 - INACTIVE - Flow is
1 - ACTIVE - Flow is

Policy IE'

There are two basic types of Policy IE's Optional and Mandatory.
the case of optional operating policy if the combination of
and value given cannot be interpreted by a switch CCE it may
safely ignored. In the case of mandatory operating policy if
combination of policy and value given cannot be interpreted by
switch CCE it must abort the flow state. Examples of
operating policies are Checkpoint Timer and Connection Priority

Amsden, et. al. Informational [Page 8]

RFC 2124 LFAP March 1997

There are also two forms of the policy ID. The first is where
policy ID is a number and the second is where the policy ID is
Object Identifier. The policy ID's with number values are
in this document and its proposed changes over time. The
Identifier IDs can be used by individual implementers to
proprietary or experimental additions to this document and still
compliant with the general form of this document

Operating Policy IEs are comprised of Policy ID, a length and
value. In the case of the policies defined in this document a
is required and specified here. In the case of policies using the
format the length may be implied by the OID or be part of the
value as determined by individual implementation

Policy IE format for Policy ID's defined in this

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 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 ID's and policy values are presently defined
under consideration

Policy ID Value

Usage 01xx The purpose of this set
policies is for
constraints. This set
policies in the future
include Connection Count
Maximum Bandwidth and
Time

Amsden, et. al. Informational [Page 9]

RFC 2124 LFAP March 1997

Routing 02xx The purpose of these
is to allow for
routing policies to
enforced in the a
environment. This set
policies may
Optimization,
Transit List,
Transit List and Path Cost

Administrative 03
Keep Statistics 0301 = 0 Keep statistics on this
Not= 0 Do Not keep statistics on
Connection 0302 1 - 255 Priority of this
Priority Less is
Checkpoint 0303 1 - 2^31 Seconds between FUN on a

Threshold 0304 1 - 2^63 # of bytes to collect
sending a FUN on a

Connectionless 04xx The purpose of these
is to control
unaware calls. This set
include Inactivity Timer
Bandwidth allocation

Policy IE format when Policy ID is a Object

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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 11 is an optional policy and type 12 is a mandatory policy

Amsden, et. al. Informational [Page 10]

RFC 2124 LFAP March 1997

Service Identifier

Used in determination of admission policy relative to a
connection request based on service type. Service Identifier
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

Source address associated with a message. TYPE is 14, format is
shown for Destination Address IE

Source Switch Address

Source Switch address associated with a message. TYPE is 15,
is as shown for Destination Address IE

Destination Switch Address

Destination Switch address associated with a message. TYPE is 16,
format is as shown for Destination Address IE

Time

The time (as a SNMPv2 TimeStamp [1443]) associated with
status/statistics observed. TYPE is 17 and 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Amsden, et. al. Informational [Page 11]

RFC 2124 LFAP March 1997

Multiple Record

The Multiple Record IE is composed of 4 parts. The
descriptor, fixed information, record format IEs and
records. The record descriptor consist of two fields the first
is the length of the fixed information field. The second is
length of the Record format section. The fixed information is
IE's that apply to all the records that follow. The Record Format
the list of IE's that make up each record. The individual
section contains the individual records that are being reported
the format given by the Record Format section

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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Amsden, et. al. Informational [Page 12]

RFC 2124 LFAP March 1997

Flow Failure Code

Flow failure code is the reason why a operation an a given
failed. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flow failure code has one of the following values and meanings

0 - POLICY_REJECT - A policy reject has
1 - NO_SUCH_FLOW - The specified was flow was not
2 - AMBIGUOUS - Duplicate FAR caused this
3 - DESTINATION_UNKNOWN - The redirect destination was

Command Code

Command Code is a administrative request command to perform
particular function. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Command code has one of the following values and meanings

0 - RETURN_INDICATED_FLOWS - Return FUNs
1 - RETURN_ALL_CHANGED_FLOWS - Return FUNs
2 - RETURN_ALL_FLOWS - Return FUNs
3 - RETURN_FLOW_PREFIX - Return a new flow

Amsden, et. al. Informational [Page 13]

RFC 2124 LFAP March 1997

Flow Identifier Prefix

The flow Identifier prefix IE gives the prefix that the FAS
created to maintain a globally unique ID. 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)

Status is set to SUCCESS in FAR messages. In addition, FAR
may contain the following IEs

Source Switch Address IE - address of switch making
Dest Switch Address IE - address of switch to which
request is
Source Address IE - flow "from"
Destination Address IE - flow "to"
Service Identifier IE - identifier for service
Flow ID IE - locally unique identifier for
(unique to update reporting entity
Client Data IE - client data as applied to this
Time IE - switch time of admission

Mandatory IE'
Source
Destination
Flow

Optional IE'
Source Switch
Destination Switch
Client

Amsden, et. al. Informational [Page 14]

RFC 2124 LFAP March 1997

FAR messages are sent by a switch CCE when it seeks verification
validity of a flow that is about to be established. FAR
refer to a single flow only and do not multi IE functionality.
and destination addresses are those determined by the switch CCE
the points of origin and termination of a flow. Service ID is
service type/category associated with the desired flow. The
data is arbitrary information about the client associated with
desired flow

3.3. Flow Admission Acknowledge (FAA)

Status reflects the result of the corresponding FAR message (
Error Handling for details). Message ID is copied from the
message. In addition, FAA messages may have the following IEs

Optional Operating Policy IE - policy(s) that may apply
this flow
Mandatory Operating Policy IE - policy(s) that must apply
this flow

Destination Address IE - may be included if the
should be redirected
Flow Failure Code IE - indicates the cause of

FAA messages are sent by a FAS in response to FAR messages
from a switch CCE. Operating policy information is that determined
the FAS as either desirable or required for the flow specified in
corresponding FAR message

3.4. Flow Admission Update (FAU)

Status reflects the result of the corresponding FAA message (
Error Handling for details). Message ID is copied from the FAR
FAA message. In addition, FAU messages may have the following IEs

Flow ID IE - identifier for the
Flow Failure Code IE - indicates the cause of flow

FUA messages are sent by a switch CCE in response to FAA
received from a FAS. The FAU message is returned by the switch
only if an a error was detected as a result of the FAA message

Amsden, et. al. Informational [Page 15]

RFC 2124 LFAP March 1997

3.5. Flow Update Notification (FUN)

Status is set to SUCCESS in FUN messages. In addition, FUN
may contain the following IEs

Time IE - switch time of
Flow ID IE - identifier for the
Flow State IE - state of the flow at time of
Byte Count IE - octets sent and received for this
Packet Count IE - packets sent and received for this

Mandatory IE'
Time - If multiple IE, only needs to be given once in
information section. If given in record format must
in each individual record

Optional IE's at least one must be
Flow
Byte
Packet

FUN messages are sent periodically (possibly as specified in
operating policy associated with the flow) by an CCE to the FAS.
Time IE may be given first and only once. If it is only a single
being reported on then just the IE's and their values are returned
If multiple flows are to be reported on then the multiple record
should be used. This results in reduced overhead on transmissions
FUN messages may are also be sent as a result of a AR message or
FCR message. The FCR message would be one that request that the
state be set to inactive

The flow ID identifies the flow to which this update applies.
state is the state of the flow at the time this message is sent
Counts are as specified in the IE definitions. The FAS's
coordinated and will resolve the reception of FUN information from
CCE who has lost connection with its FAS and has gone to
alternative FAS

3.6. Flow Update Acknowledge (FUA)

Status is set to SUCCESS in FUA messages unless an error is
(see "Error Handling"). Message ID is copied from the FUN message

Amsden, et. al. Informational [Page 16]

RFC 2124 LFAP March 1997

FUA messages are sent by the FAS to acknowledge a FUN message
the switch CCE. If a FUN message contained a multiple record IE
any of the updates had a error then the FUA would contain a
IE with a Flow ID and Flow Failure Code. A status of
indicates that the information in the corresponding FUN message
been accepted and is now the responsibility of the FAS

3.7. Flow Change Request (FCR)

Status is set to SUCCESS in FCR messages. In addition, a FCR
may contain the following 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
apply to this flow
Mandatory Operating Policy IE - possibly new policy(s) that
apply to this flow

Mandatory IE'
Flow

Optional IE'
Flow
Optional Operating
Mandatory Operating

FCR messages are sent by the FAS to the CCE to provide additional (
change existing) operating policy information or to stop a flow
Flow ID is used to identify the flow to which this message applies
The FAS can stop a flow by setting it's flow state to inactive.
will cause the CCE to generate a FUN message with the final
statistics. It will also cause the CCE to return a inactive
state on the given flow. If the FAS wishes to change
policy information it merely includes the new information in the
message along with the flow id

3.8. Flow Change Acknowledge (FCA)

Status is set to SUCCESS in FCA messages unless an error is
(see "Error Handling"). Message ID is copied from the FCR message
FCA messages contain IEs if a error was detected in the
FCR message (see "Error Handling").

If an error occurs then a FCR may contain the following IE'

Flow ID IE - if FAS requested statistics on
unknown flow

Amsden, et. al. Informational [Page 17]

RFC 2124 LFAP March 1997

Flow Failure Code - for the Flow ID IE above

FCA messages are sent by a switch CCE in response to an FCR

3.9. Administrative Request (AR)

Status is set to SUCCESS in AR messages. In addition, AR messages
contain the Command IEs

Mandatory IE'
Command

AR messages are sent by either the a switch CCE or the FAS when
seeks to perform one of the Command IE's

3.10. Administrative Request Acknowledge (ARA)

Status reflects the result of the corresponding AR message (see
Handling for details). Message ID is copied from the AR message.
addition, ARA messages may have the following IEs

Flow ID IE - if FAS requested statistics on
unknown flow
Flow Failure Code - for the Flow ID IE above
Flow Identifier Prefix IE - if the ARA is the response to a
Command to RETURN_FLOW_PREFIX

ARA messages are sent by a FAS or CCE in response to AR
received CCE or FAS respectively

4. Error

Incompatible version - Receipt of any LFAP request or
message, with a version number other than that (or those)
by the receiving component will result in a response (acknowledge
message with a Status of VERSION. The resulting message will
no IEs and, as a result, may be considered a generic FAILURE message

Corrupted message contents - Receipt of a LFAP message which
be understood will result in a similar generic FAILURE message
Status set to CORRUPTED. A FAA message may contain a Flow ID IE
if this IE is included in the portion of the corrupt LFAP
that is before the point where corruption occurs. The LFAP
should re-send the original message at least one time if it is
desired to admit the requested connection

Amsden, et. al. Informational [Page 18]

RFC 2124 LFAP March 1997

With the exception of incompatible version and corrupted
contents, error handling is naturally related to the processing
response messages by both response sender and receiver.
sections are thus organized around processing of FAA, FUA, FCA
ARA messages

4.1. FAA Related Error

Non-unique Flow ID - Receipt of a FAR message with a non-unique
ID may occur for two reasons: the CCE may have re-sent a FAR
and an error may have occurred in the ID generation function. If
entire message is the same in every respect, with the
exception of Message ID, as a FAR message received previously,
FAS will respond in the same way as it would have responded to
prior message. Otherwise, the Flow ID will be returned with a
Failure Code set to AMBIGUOUS. The CCE should choose a new Flow
and retry the FAR message if it is still desired to admit
requested connection

Flow is inadmissible - The FAS may determine that flow is
admissible for policy reasons. In this case the Flow ID is
along with the Flow Failure Code of POLICY_REJECT

4.2. FUA Related Error

Flow Not Admitted - Receipt of Flow information for an
connection. Flow ID IE identifies a flow which was not admitted
for which admission status has been lost. The FAS will return
Flow ID and a Flow Failure Code of NO_SUCH_FLOW. The switch
should send an appropriate FAR message. The FAS may track
of this error and send a FCR message to the CCE requesting
of the reported connection

4.3. FCA Related Error

Flow change requested for a non-existent flow - The Flow ID
identifies a connection for which this CCE has no state information
The FCA message has the Flow ID and a Flow Failure Code set
NO_SUCH_FLOW and contains the Flow ID and copied from
corresponding FCR message

Policy changes requested were not supported by the CCE. The
message has the Flow ID and a Flow Failure Code set to POLICY_
and contains the Flow ID copied from the corresponding FCR message

Amsden, et. al. Informational [Page 19]

RFC 2124 LFAP March 1997

4.4. ARA Related Error

Flow statistics requested for a non-existent flow - The Flow ID
identified a connection for which this CCE has no state information
The ARA message has the Flow ID and a Flow Failure Code set
NO_SUCH_FLOW and contains the Flow ID copied from the
FCR message. If there were multiple flows that were non-
then the multi ie format could have the Flow Failure Code in
fixed information section and the individual Flow ID's in the
section

5. Security

Security issues are not discussed in this memo

6. Author's

Paul
Phone: +1 (603) 337-7408
EMail: amsden@ctron.

Jim
Phone: +1 (603) 337-5247
EMail: amsden@ctron.

Paul
Phone: +1 (603) 337-7625
EMail: amsden@ctron.

Stephen
Phone: +1 (603) 337-7061
EMail: amsden@ctron.

Gregory
Phone: +1 (603) 337-5318
EMail: amsden@ctron.

Cabletron Systems, Inc. is located at

P.O. Box 5005
Rochester, NH, 03866-5005

Amsden, et. al. Informational [Page 20]

RFC 2124 LFAP March 1997

7.

[363] "B-ISDN ATM Adaptation Layer (AAL) Specification,"
International Telecommunication Union, ITU-T
I.363, Mar. 1993.

[1443] "Textual Conventions for version 2 of the Simple
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
- Protocol Identification in the Network Layer", ISO/IEC
9577: 1990 (E) 1990-10-15.

[LANE] "LAN Emulation Over ATM Specification - Version 1.0",
Forum af-lane-021.000, January, 1995.

Amsden, et. al. Informational [Page 21]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX