From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2124.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc2124.txt (limited to 'doc/rfc/rfc2124.txt') 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] + -- cgit v1.2.3