doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc2124.txt b/doc/rfc/rfc2124.txt
new file mode 100644
index 0000000..139e985
--- /dev/null
+++ b/doc/rfc/rfc2124.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          P. Amsden
+Request for Comments: 2124                                      J. Amweg
+Category: Informational                                        P. Calato
+                                                              S. Bensley
+                                                                G. Lyons
+                                                  Cabletron Systems Inc.
+                                                              March 1997
+
+     Cabletron's Light-weight Flow Admission Protocol Specification
+                              Version 1.0
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Light-weight Flow Admission Protocol, LFAP, allows an external Flow
+   Admission Service (FAS) to manage flow admission at the switch,
+   allowing flexible Flow Admission Services to be deployed by a vendor
+   or customer without changes to, or undue burden on, the switch.
+
+   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.
+
+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
+
+
+
+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.  Introduction
+
+   Light-weight Flow Admission Protocol, LFAP, allows an external Flow
+   Admission Service (FAS) to manage flow admission at the switch,
+   allowing flexible Flow Admission Services to be deployed by a vendor
+   or customer without changes to, or undue burden on, the switch. It
+   provides a means for network managers, or management systems, to
+   establish connection admission parameters for multiple switches in a
+   single management domain by configuring policy information and other
+   data via a single 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.
+
+   A significant advantage of this protocol is that it relieves switch
+   vendors from the complexity of policy enforcement under any number of
+   policy representation schemes. Similarly, switch configuration
+   managers do not need to translate organization-determined policy or
+   usage procedures, limitations and guidelines into an arbitrarily
+   large set of vendor-specific representations. Finally, use of such a
+   scheme makes possible plug-and-play connection management at the
+   present time - in the absence of a standardized representation for
+   connection policies.
+
+   This document describes the message flow between switch CCE and FAS,
+   the messages used and error handling that applies. This constitutes
+   the LFAP interface definition.
+
+
+
+
+
+
+
+
+
+
+
+Amsden, et. al.              Informational                      [Page 2]
+
+RFC 2124                          LFAP                       March 1997
+
+
+2.  Message Flows
+
+   Initiating message flows between CCE and FAS entities always
+   originate at the switch.  Therefore, the switch is the point at which
+   connectivity is originated.  The CCE must have IP reachability using
+   some approach described elsewhere (e.g.  [1577] or [LANE]) and an IP
+   address for the FAS must be preconfigured at the switch CCE.  The CCE
+   establishes TCP connectivity using the registered port number - ###.
+
+   As shown below, Flow Admission Request (FAR) messages are sent by a
+   switch's Call Control Entity (CCE) to the Flow Admission Service
+   (FAS). These messages are sent when a flow is about to be set up by
+   the switch and contain specific information relating to the flow -
+   such as flow identifier, source/destination and qualifying
+   information about the flow - that may be required to determine the
+   admissibility of the flow and any operating policies that apply to
+   the flow if it is admitted.
+
+   The FAS responds with a Flow Admission Acknowledge (FAA) message (to
+   the CCE) with a status indicating connection admissibility and any
+   operating policy information that applies to the flow.  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                         |
+     `----------------------------------------------------'
+
+
+
+Amsden, et. al.              Informational                      [Page 3]
+
+RFC 2124                          LFAP                       March 1997
+
+
+   When a connection is established, periodically during the course of
+   maintaining the connection and when a change in connection state
+   occurs, the switch CCE sends a Flow Update Notification (FUN) message
+   to the FAS.  The FAS, in turn, responds with a Flow Update
+   Acknowledge (FUA) message with a Flow failure code if a an error
+   condition has been detected. An example of error conditions would be
+   receipt of a FUN message indicating octets received and sent for a
+   connection never admitted.
+
+   The FAS may send a Flow Change Request (FCR) to the CCE either to
+   effect a change in the state of a specific connection or to set any
+   new/changed policy information that applies to the flow.
+
+   The CCE replies with a Flow Change Acknowledge (FCA) message and may
+   respond  with a flow failure code indicating the offending flow or
+   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 to
+   request FUN messages be returned on some set of flows.
+
+   The requested entity (FAS or CCE) replies with a 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).
+
+   FAR messages are sent by a switch call control entity (CCE) to the
+   Flow Admission Service (FAS). FAA messages are responses from the FAS
+   to the CCE. FUA messages are responses from the CCE only under error
+   conditions. FUN messages originate at switches and are acknowledged
+   by FUA messages from the FAS. FCR messages are sent by the FAS to the
+   CCE and are acknowledged by FCA messages. AR messages are sent by
+   either the Entity (FAS or CCE) and are acknowledged by the ARA
+   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. The
+   values that Status may assume are:
+
+          STATUS:
+             SUCCESS   = 0
+             CORRUPTED = 1
+             VERSION   = 2
+
+   Message ID is used to associate each original message with its
+   corresponding response and must be unique for the combination of
+   sender and responder while an original message is pending. The
+   Message Length excludes the 8 octets of the message header.
+
+3.1.  IE Formats
+
+   IE fields consist of 2-octet TYPE, 2-octet LENGTH and a variable
+   length VALUE sub-fields. All IEs are even multiples of 4 octets in
+   length, left-aligned and zero filled if necessary. Length is computed
+   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 IE
+
+   Contains the count of octets sent and received 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 = 1 or 2         |          LENGTH = 16          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-                Bytes Received               -+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-                  Bytes Sent                 -+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type 1 Means that the byte count is a running counter and is the
+          count from the beginning of the flow establishment.
+   Type 2 Means that the byte count is a delta counter and is the
+          count since the last FUN message.
+
+Packet Count IE
+
+   Contains the count of packets cells or frames sent and received
+   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 counter
+          and is the count from the beginning of the flow establishment.
+   Type 4 Means that the packet/cell/frame count is a delta counter
+          and is the count since the last FUN message.
+
+
+
+
+Amsden, et. al.              Informational                      [Page 6]
+
+RFC 2124                          LFAP                       March 1997
+
+
+Client Data IE
+
+   For use in determination of admission policy relative to a specific
+   connection request based on arbitrary client data (OCTET STRING
+   [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 IE
+
+   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 excluding
+   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 subaddress
+
+Flow ID IE
+
+   In order to accumulate the flow accounting statistics across multiple
+   FAS's in case of a FAS failure a globally unique flow identifier
+   needs to be formed.  To accomplish this the FAS assigns a prefix if
+   requested by the CCE.  The CCE then 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
+
+
+
+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 cannot
+   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.  If the CCE
+   does not 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.  Flow ID IE is copied exactly in all
+   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 IE
+
+   Flow state is the intended end state for the Flow associated with the
+   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 inactive
+          1 - ACTIVE      - Flow is active
+
+Policy IE's
+
+   There are two basic types of Policy IE's Optional and Mandatory. In
+   the case of optional operating policy if the combination of policy
+   and value given cannot be interpreted by a switch CCE it may be
+   safely ignored. In the case of mandatory operating policy if the
+   combination of policy and value given cannot be interpreted by a
+   switch CCE it must abort the flow state. Examples of optional
+   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 the
+   policy ID is a number and the second is where the policy ID is an
+   Object Identifier. The policy ID's 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 comprised of Policy ID, a length and a
+   value. In the case of the policies defined in this document a length
+   is required and specified here. In the case of policies using the OID
+   format the length may be implied by the OID or be part of the policy
+   value as determined by 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 ID's and policy values are presently defined or
+   under consideration.
+
+  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.
+
+
+
+
+
+Amsden, et. al.              Informational                      [Page 9]
+
+RFC 2124                          LFAP                       March 1997
+
+
+  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 a 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                     ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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 IE
+
+   Used in determination of admission policy relative to a specific
+   connection request based on service type. 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, format is as
+   shown for Destination Address IE.
+
+Source Switch Address IE
+
+   Source Switch address associated with a message. TYPE is 15, format
+   is as shown for Destination Address IE.
+
+Destination Switch Address IE
+
+   Destination Switch address associated with a message. TYPE is 16,
+   format is as shown for Destination Address IE.
+
+Time IE
+
+   The time (as a SNMPv2 TimeStamp [1443]) associated with the
+   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 IE
+
+   The Multiple Record IE is composed of 4 parts.  The record
+   descriptor, fixed information, record format IEs and individual
+   records.  The record descriptor consist of two fields the first field
+   is the length of the fixed information field.  The second is the
+   length of the Record format section.  The fixed information is the
+   IE's that apply to all the records that follow. The Record Format is
+   the list of IE's that make up each record. The individual record
+   section contains the individual records that are being reported in
+   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 IE
+
+   Flow failure code is the reason why a operation an a given flow
+   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 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 unknown
+
+Command Code IE
+
+   Command Code is a administrative request command to perform a
+   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 indicated
+     1 - RETURN_ALL_CHANGED_FLOWS  - Return FUNs indicated
+     2 - RETURN_ALL_FLOWS          - Return FUNs indicated
+     3 - RETURN_FLOW_PREFIX        - Return a new flow prefix
+
+
+
+
+
+
+
+
+
+
+Amsden, et. al.              Informational                     [Page 13]
+
+RFC 2124                          LFAP                       March 1997
+
+
+Flow Identifier Prefix IE
+
+   The flow Identifier prefix IE gives the prefix that the FAS has
+   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) Message
+
+   Status is set to SUCCESS in FAR messages. In addition, FAR messages
+   may contain the following IEs:
+
+      Source Switch Address IE  - address of switch making request
+      Dest Switch Address IE    - address of switch to which the
+                                  request is made
+      Source Address IE         - flow "from" address
+      Destination Address IE    - flow "to" address
+      Service Identifier IE     - identifier for service requested
+      Flow ID IE                - locally unique identifier for flow
+                                  (unique to update reporting entity)
+      Client Data IE            - client data as applied to this request
+      Time IE                   - switch time of admission request
+
+   Mandatory IE's
+      Source Address
+      Destination Address
+      Flow ID
+      Time
+
+   Optional IE's
+      Source Switch Address
+      Destination Switch Address
+      Client Data
+
+
+
+
+
+
+
+
+
+
+Amsden, et. al.              Informational                     [Page 14]
+
+RFC 2124                          LFAP                       March 1997
+
+
+   FAR messages are sent by a switch CCE when it seeks verification of
+   validity of a flow that is about to be established. FAR messages
+   refer to a single flow only and do not multi IE functionality. Source
+   and destination addresses are those determined by the switch CCE as
+   the points of origin and termination of a flow. Service ID is the
+   service type/category associated with 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). Message ID is copied from the FAR
+   message. In addition, FAA messages may 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. Operating policy information is that determined by
+   the FAS as either desirable or required for the flow specified 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).  Message ID is copied from the FAR or
+   FAA message. In addition, FAU messages may have the following IEs:
+
+      Flow ID IE           - identifier for the flow
+      Flow Failure Code IE - indicates the cause of flow failure
+
+   FUA messages are sent by a switch CCE in response to FAA messages
+   received from a FAS.  The FAU message is returned by the switch CCE
+   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) Message
+
+   Status is set to SUCCESS in FUN messages.  In addition, FUN messages
+   may contain the following IEs:
+
+      Time IE         - switch time of notification
+      Flow ID IE      - identifier for the flow
+      Flow State IE   - state of the flow at time of notification
+      Byte Count IE   - octets sent and received for this flow
+      Packet Count IE - packets sent and received for this flow
+
+   Mandatory IE's
+      Time - If multiple IE, only needs to be given once in fixed
+             information section. If given in record format must be
+             in each individual record.
+
+   Optional IE's at least one must be present
+      Flow State
+      Byte Count
+      Packet Count
+
+   FUN messages are sent periodically (possibly as specified in an
+   operating policy associated with the flow) by an CCE to the FAS. The
+   Time IE may be given first and only once. If it is only a single flow
+   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 IE
+   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 a
+   FCR message. The FCR message would be one that request that the flow
+   state be set to inactive.
+
+   The flow ID identifies the flow to which this update applies.  Flow
+   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 are
+   coordinated and will resolve the reception of FUN information from a
+   CCE who has lost connection with its FAS and has gone to a
+   alternative FAS.
+
+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.
+
+
+
+
+
+
+
+
+
+Amsden, et. al.              Informational                     [Page 16]
+
+RFC 2124                          LFAP                       March 1997
+
+
+   FUA messages are sent by the FAS to acknowledge a FUN message from
+   the switch CCE. If a FUN message contained a multiple record IE and
+   any of the updates had a error then the FUA would contain a multiple
+   IE with a Flow ID and Flow Failure Code. A status of SUCCESS
+   indicates that the information in the corresponding FUN message has
+   been accepted and is now the responsibility of the FAS.
+
+3.7.  Flow Change Request (FCR) Message
+
+   Status is set to SUCCESS in FCR messages. In addition, a FCR message
+   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 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 State
+      Optional Operating Policy
+      Mandatory Operating Policy
+
+   FCR messages are sent by the FAS to the CCE to provide additional (or
+   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.  This
+   will cause the CCE to generate a FUN message with the final flow
+   statistics.  It will also cause the CCE to return a inactive flow
+   state on the given flow.  If the FAS wishes to change operating
+   policy information it merely includes the new information in the FCR
+   message along with the flow id.
+
+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 a error was detected in the corresponding
+   FCR message (see "Error Handling").
+
+   If an error occurs then a FCR may contain the following IE's
+
+      Flow ID IE        - if FAS requested statistics on an
+                          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) Message
+
+   Status is set to SUCCESS in AR messages. In addition, AR messages may
+   contain the Command IEs:
+
+   Mandatory IE's
+      Command IE
+
+   AR messages are sent by either the a switch CCE or the FAS when they
+   seeks 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. In
+   addition, ARA messages may have the following IEs:
+
+      Flow ID IE                 - if FAS requested statistics on an
+                                   unknown flow.
+      Flow Failure Code          - for the Flow ID IE above.
+      Flow Identifier Prefix IE  - if the ARA is the response to a CCE
+                                   Command to RETURN_FLOW_PREFIX.
+
+   ARA messages are sent by a FAS or CCE in response to AR message
+   received CCE or FAS respectively.
+
+4.  Error Handling
+
+   Incompatible version - Receipt of any LFAP request or notification
+   message, with a version number other than that (or those) supported
+   by the receiving component will result in a response (acknowledge)
+   message with a Status of VERSION. The resulting message will contain
+   no IEs and, as a result, may be considered a generic FAILURE message.
+
+   Corrupted message contents - Receipt of a LFAP message which cannot
+   be understood will result in a similar generic FAILURE message with
+   Status set to CORRUPTED. A FAA message may contain a Flow ID IE only
+   if this IE is included in the portion of the corrupt LFAP message
+   that is before the point where corruption occurs. The LFAP sender
+   should re-send the original message at least one time if it is still
+   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 message
+   contents, error handling is naturally related to the processing of
+   response messages by both response sender and receiver. Below
+   sections are thus organized around processing of FAA, FUA, FCA and
+   ARA messages.
+
+4.1.  FAA Related Error Handling
+
+   Non-unique Flow ID - Receipt of a FAR message with a non-unique Flow
+   ID may occur for two reasons: the CCE may have re-sent a FAR message
+   and an error may have occurred in the ID generation function.  If the
+   entire message is the same in every respect, with the possible
+   exception of Message ID, as a FAR message received previously, the
+   FAS will respond in the same way as it would have responded to that
+   prior message.  Otherwise, the Flow ID will be returned with a Flow
+   Failure Code set to AMBIGUOUS. The CCE should choose a new Flow ID
+   and retry the FAR message if it is still desired to admit the
+   requested connection.
+
+   Flow is inadmissible - The FAS may determine that flow is not
+   admissible for policy reasons. In this case the Flow ID is returned
+   along with the Flow Failure Code of POLICY_REJECT.
+
+4.2.  FUA Related Error Handling
+
+   Flow Not Admitted - Receipt of Flow information for an unadmitted
+   connection. Flow ID IE identifies a flow which was not admitted or
+   for which admission status has been lost. The FAS will return the
+   Flow ID and a Flow Failure Code of NO_SUCH_FLOW. The switch CCE
+   should send an appropriate FAR message. The FAS may track occurrences
+   of this error and send a FCR message to the CCE requesting dropping
+   of the reported connection.
+
+4.3.  FCA Related Error Handling
+
+   Flow change requested for a non-existent flow - The Flow ID IE
+   identifies a connection for which this CCE has no state information.
+   The FCA message has the Flow ID and a Flow Failure Code set to
+   NO_SUCH_FLOW and contains the Flow ID and copied from the
+   corresponding FCR message.
+
+   Policy changes requested were not supported by the CCE.  The FCA
+   message has the Flow ID and a Flow Failure Code set to POLICY_REJECT
+   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 Handling
+
+   Flow statistics requested for a non-existent flow - The Flow ID IE
+   identified a connection for which this CCE has no state information.
+   The ARA message has the Flow ID and a Flow Failure Code set to
+   NO_SUCH_FLOW and contains the Flow ID copied from the corresponding
+   FCR message.  If there were multiple flows that were non-existent
+   then the multi ie format could have 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.
+
+6.  Author's Addresses
+
+    Paul Amsden
+    Phone:  +1 (603) 337-7408
+    EMail:  amsden@ctron.com
+
+    Jim Amweg
+    Phone:  +1 (603) 337-5247
+    EMail:  amsden@ctron.com
+
+    Paul Calato
+    Phone:  +1 (603) 337-7625
+    EMail:  amsden@ctron.com
+
+    Stephen Bensley
+    Phone:  +1 (603) 337-7061
+    EMail:  amsden@ctron.com
+
+    Gregory Lyons
+    Phone:  +1 (603) 337-5318
+    EMail:  amsden@ctron.com
+
+Cabletron Systems, Inc. is located at:
+
+    P.O. Box 5005
+    Rochester, NH, 03866-5005
+    USA
+
+
+
+
+
+
+
+
+
+Amsden, et. al.              Informational                     [Page 20]
+
+RFC 2124                          LFAP                       March 1997
+
+
+7.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Amsden, et. al.              Informational                     [Page 21]
+