RFC NNNN LFAP June 2001 Network Working Group P. Calato Request for Comments: NNNN M. MacFaden Category: Informational Riverstone Networks Inc Obsoletes: RFC 2124 June 2001 Category: Informational Light-weight Flow Accounting Protocol Data Definition Specification Version 5.0 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The Light-weight Flow Accounting Protocol Data Definition Specification defines the data which may be sent via the Light- weight Flow Accounting Protocol transport. LFAP transport and LFAP Data Definition, allow an external Flow Accounting Service (FAS) to record flow accounting information from a Connection Control Entity (CCE), allowing flexible Flow Accounting Services to be deployed by a vendor or customer without changes to, or undue burden on, the CCE. Specifically, this document specifies the data that may be exchanged between the CCE and the external FAS. Using LFAP, a FAS can maintain details of current or historical flows for billing, capacity planning and other purposes. Calato, MacFaden [Page 1] RFC NNNN LFAP June 2001 Table of Contents 1. INTRODUCTION 4 1.1 OVERVIEW 4 2. INFORMATION ELEMENTS (IE'S) 4 2.1 FLOW ID IE 5 2.2 SOURCE ADDRESS IE 5 2.3 DESTINATION ADDRESS IE 6 2.4 FLOW QUALIFIER IE 6 2.5 TIME IE 7 2.6 UTC TIME IE 7 2.7 DELTA TIME IE 8 2.8 CLASS OF SERVICE IE 8 2.9 SOURCE CCE ADDRESS IE 9 2.10 CLIENT DATA IE 9 2.11 COMMAND CODE IE 9 2.12 IE LIST IE 10 2.13 FAS ADDRESS IE 11 2.14 FAILURE CODE IE 11 2.15 FLOW STATE IE 12 2.16 BYTE COUNT IE 12 2.17 PACKET COUNT IE 13 2.18 PROTOCOL IDENTIFIER IE 13 2.19 SOURCE PORT IE 14 2.20 SOURCE AS IE 14 2.21 DESTINATION AS IE 14 2.22 INGRESS PORT IE 15 2.23 EGRESS PORT IE 15 2.24 EGRESS ATM SUBINTERFACE 15 2.25 EGRESS_FRAME_RELAY_SUBINTERFACE IE 15 2.26 NEXT_HOP_IP IE 16 2.27 TCP CONTROL BITS IE 16 2.28 NEXT HOP AS IE 16 2.29 SOURCE ADDRESS NETMASK IE 16 2.30 DESTINATION ADDRESS NETMASK IE 16 2.31 DESTINATION BGP COMMUNITY IE 17 2.32 SOURCE BGP COMMUNITY IE 17 2.33 TRAFFIC INDEX IE 17 2.34 VLAN ID IE 17 2.35 SOURCE VIRTUAL ADDRESS IE 18 2.36 SOURCE VIRTUAL PORT IE 18 2.37 DESTINATION VIRTUAL ADDRESS IE 19 2.38 DESTINATION VIRTUAL PORT IE 19 2.39 VENDOR SPECIFIC IE 19 2.40 FLOW LABEL IE 20 2.41 FRAGMENT ID IE 20 2.42 NUMERIC LIST OF IE'S 21 3. INDIVIDUAL MESSAGE CONTENTS 22 3.1 FLOW ACCOUNTING REQUEST (FAR) MESSAGE 22 3.2 FLOW UPDATE NOTIFICATION (FUN) MESSAGE 24 Calato, MacFaden [Page 2] RFC NNNN LFAP June 2001 3.3 ADMINISTRATIVE REQUEST (AR) MESSAGE 25 3.4 ADMINISTRATIVE REQUEST ACKNOWLEDGE (ARA) MESSAGE 25 4. ERROR HANDLING 26 4.1 ARA RELATED ERROR HANDLING 26 5. SESSION ESTABLISHMENT 27 6. SECURITY CONSIDERATIONS 27 7. AUTHOR'S ADDRESSES 27 8. REFERENCES 28 Calato, MacFaden [Page 3] RFC NNNN LFAP June 2001 1. Introduction Light-weight Flow Accounting Protocol, LFAP, allows an external Flow Accounting Service (FAS) to record flow accounting information from a Connetion Control Entity (CCE), allowing flexible Flow Accounting Services to be deployed by a vendor or customer without changes to, or undue burden on, the CCE. It provides a means for a CCE to send accounting information in a fault tolerant client server architecture. Specifically, this document specifies data that may be exchanged between the CCE and the external FAS using LFAP. A FAS can maintain details of current or historical flows for billing, capacity planning and other purposes. A significant advantage of this protocol is that it provides an efficient manner in which to move flow accounting information from the CCE to an accounting application. LFAP uses a push rather than a pull architecture, which enables the CCE to send data when necessary and to pack the data into dense messages. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.1 Overview The Information Elements (IE's) section defines the format and semantics of data passed to the LFAP server. The Message Content section defines what IE's are delivered via message types defined in the LFAP transport. The session establishment section defines the required message exchange that must take place before flow data can be sent. 2. Information Elements (IE's) LFAP messages contain Information Elements (IE's). General IE format is described by the LFAP Specification[1]. Individual IE's are described in the following sections. If the same IE occurs multiple times in a message, the last IE listed is used, unless specified otherwise. Calato, MacFaden [Page 4] RFC NNNN LFAP June 2001 2.1 Flow ID IE In order to accumulate 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 globally unique prefix when requested by the CCE. The CCE then assigns a CCE identifier that it guarantees to be unique for each flow admitted with a given FAS flow identifier prefix. If the CCE needs to reuse a CCE identifier, it must acquire a new FAS flow prefix. 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 = 65 |FAS Length = 8 |CCE Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |+-+-+-+-+- FAS assigned Flow Identifier Prefix -+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+ | CCE assigned Flow Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The CCE assigned identifier is a monotonically increasing number. It starts at 1 and increases by 1 until it reaches FFFFFFFF. If FFFFFFFF is reached a new Flow Prefix MUST be obtained and the CCE identifier must be reset to 1. Both the FAS Flow Prefix and the CCE identifier MUST be non-zero. Multiple Flow ID IE's may occur in either an AR or ARA message. The semantics are defined in the AR and ARA message contents section. 2.2 Source Address IE Source address associated with a 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 = 66 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family Number | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calato, MacFaden [Page 5] RFC NNNN LFAP June 2001 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 2.3 Destination Address IE Destination address associated with a flow. TYPE is 67, format is as shown for Source Address IE. 2.4 Flow Qualifier IE Flow Qualifier IE's contain additional information about a flow. The IE is comprised of a qualifier ID, a length and a value. Flow Qualifier IE format: 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 = 68 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qualifier ID | Qualifier Value length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Qualifier Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Additional Qualifier Pairs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following qualifier ID's and values are presently defined. Their value length is 4 bytes. Flow Qualifier ID Value Meaning Checkpoint 1 1 Checkpoint flow hourly 2 Checkpoint flow Daily 3 Checkpoint flow weekly 4 Checkpoint flow every 5 minutes 5 Checkpoint flow every 15 minutes Calato, MacFaden [Page 6] RFC NNNN LFAP June 2001 Connection priority 2 100 Priority of this connection is Premium 200 Priority of this connection is High 300 Priority if this connection is Medium 400 Priority of this connection is Low A switch may map several of its internal priority queues into a Premium, High, Medium or Low category 2.5 Time IE The time (as a SNMPv2 TimeStamp [1443]) associated with the status/statistics observed or other events. TYPE is 69 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 = 69 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.6 UTC Time IE The time in seconds since 00:00:00 UTC, January 1, 1970 associated with the status/statistics observed or other events. If both Time and UTC_TIME are present, UTC Time takes precedence. TYPE is 70 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 = 70 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calato, MacFaden [Page 7] RFC NNNN LFAP June 2001 2.7 Delta Time IE The number in 100ths of seconds over which the statistics were observed. TYPE is 71 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 = 71 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.8 Class of Service IE The class of service associated with a flow. TYPE is 72 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 = 72 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|T| CoS Type | Class of Service value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I - 1 bit indicating the Class of Service Received R - 1 bit indicating the Class of Service Transmitted Both I and R may be set, however, at least one of them MUST be set. Note - How the flow was treated internally to the CCE is specified in the Connection Priority of the Flow Qualifier IE. CoS Type - 6 bits, defines the Class of Service field. Possible values are: 1 - IPv4, CoS value is defined by ToS in RFC 791 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 3 - MPLS, CoS value is defined by Exp in RFC 3032 4 - VLAN, CoS value is defined by user_priority in IEEE 802.1q[802.1q] and IEEE 802.1p[802.1p] A CoS Type of zero "0" is invalid. More than one Class of Service IE can be present in a FAR message. The FAR message contents section defines the semantics. Calato, MacFaden [Page 8] RFC NNNN LFAP June 2001 2.9 Source CCE Address IE Source CCE address is the address of the CCE reporting the flow, TYPE is 73. Format is as shown for Source Address IE. This information is used by applications to later correlate the ingress/egress port with a specific CCE. It is also used to maintain the source CCE information when there is an intermediate proxy. For example, given the picture below: SW1 -------- P1 ------ FAS1 ^ | SW2---------- | Flows coming from SW1 and SW2 through proxy P1 would look to the FAS like the same TCP connection. With the SRC CCE in the message the original CCE address is maintained. 2.10 Client Data IE Arbitrary client data (OCTET STRING [8824]). If used, this IE MUST be able to be safely ignored by either the CCE or FAS. 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 = 74 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.11 Command Code IE Command Code is a request 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 = 75 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved - must be zero. Calato, MacFaden [Page 9] RFC NNNN LFAP June 2001 Command code has one of the following values and meanings: 1 - RETURN_INDICATED_FLOWS - Used by the FAS to give CCE a list of Flow IE's that it wants the CCE to return FUNs on. 2 - RETURN_FLOW_PREFIX - Used by the CCE to request a new flow prefix. 3 - RETURN_TIME - Used to request the current uptime. May be sent by either the FAS or CCE but generally used by the FAS. Allows FAS to determine CCE uptime to FAS wall clock time. This command SHOULD be processed immediately. 4 - REQUESTED_IEs - Used by the FAS to provide a hint on what data is being collected. Mandatory IE's must still be sent even if not in the list. IEs listed MUST be included if the CCE supports it. IEs not listed or not supported MAY be omitted. A command code of zero "0" is invalid. 2.12 IE List IE List of IE types. 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 = 76 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE type 1 | IE type 2 | ~ ~ ~ | | IE type n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Count - the number of IE types listed Reserved - must be zero IE type - the numeric value of the IE requested. IE Type format is defined in the LFAP Specification [1]. Values are defined in both the LFAP Specification and this document. Calato, MacFaden [Page 10] RFC NNNN LFAP June 2001 2.13 FAS Address IE This is the Address of a FAS. The CCE uses this IE in the List of FAS's AR message and the CR 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 = 77 | 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 = IP (IP Version 4) as specified in RFC 1700 2 = IP6 (IP Version 6) as specified in RFC 1700 2.14 Failure Code IE Failure code is the reason why a command request 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 = 78 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Failure Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved - must be zero. Failure code has one of the following values and meanings: 1 - NO_SUCH_FLOW - The specified flow was not found Calato, MacFaden [Page 11] RFC NNNN LFAP June 2001 2.15 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 = 79 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Flow State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved - must be zero. Flow state has one of the following values and meanings: 1 - INACTIVE - Flow is inactive 2 - ACTIVE - Flow is active 2.16 Byte Count IE Contains the count of octets sent and received associated with the identified 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 = 80 or 81 | LENGTH = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+- Bytes Received -+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+- Bytes Sent -+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 80 Means that the byte count is a running counter and is the count from the beginning of the flow establishment. Type 81 Means that the byte count is a delta counter and is the count since the last FUN message. Calato, MacFaden [Page 12] RFC NNNN LFAP June 2001 2.17 Packet Count IE Contains the count of packets, cells or frames sent and received associated with the identified 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 = 82 or 83 | LENGTH = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+- Packets/Cells/Frames Received -+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+- Packets/Cells/Frames Sent -+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Type 82 means that the packet/cell/frame count is a running counter and is the count from the beginning of the flow establishment. A Type 83 means that the packet/cell/frame count is a delta counter and is the count since the last FUN message. 2.18 Protocol Identifier IE Used to specify the protocol layers associated with a flow. The protocol identifier is specified to the highest layer decoded by the CCE. Protocol Identifier is specified as an OCTET STRING [8824]. The Protocol identifier is composed of the protocolDirID and protocolDirParameters as defined in RFC 2021. The protocol identifier encoding is enumerated in RFC 2074. The Protocol identifier uses the protocolDirTable INDEX Format defined in RFC 2074. 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 = 84 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Protocol Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calato, MacFaden [Page 13] RFC NNNN LFAP June 2001 2.19 Source Port IE In the case of TCP, UDP and IPX, the protocol IE may not be enough to determine the application layer protocol. RFC 2074 only uses the destination port/socket number. However, it may be the source port/socket number that identifies the application layer. This IE is used to report source port/socket number (note the destination port/socket is part of the protocol IE). TYPE 85 is UDP source port [see RFC 768], TYPE 86 is TCP source port [see RFC 793] and TYPE 87 is IPX source socket [The IPX protocol is defined by the Novell Corporation. A complete description of IPX may be secured at the following address: Novell, Inc. 122 East 1700 South P. O. Box 5900 Provo, Utah 84601 USA 800 526 5463 Novell Part # 883-000780-001] 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 = 85, 86 or 87 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port/Socket Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.20 Source AS IE The Autonomous System (AS) numbers for the source address associated with a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4): 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 = 88 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.21 Destination AS IE The Autonomous System (AS) numbers for the destination address associated wit a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4): The TYPE is 89 and the format is the same is for Source AS IE. Calato, MacFaden [Page 14] RFC NNNN LFAP June 2001 2.22 Ingress Port IE The ingress ifIndex for the flow is provided in this IE. ifIndex is defined by RFC 2233. TYPE is 90: 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 = 90 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.23 Egress Port IE The egress ifIndex for the flow is provided in this IE. ifIndex is defined by RFC 2233. TYPE is 91 and format is the same as for Ingress Port IE. 2.24 Egress ATM Subinterface The egress vpi/vci for the flow is provided in this IE. vpi/vci id defined by the ATM Forum UNI 3.1 specification: 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 = 92 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vpi | vci | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.25 EGRESS_FRAME_RELAY_SUBINTERFACE IE The egress DLCI for the flow is provided in this IE. ITU Q.922 defines the DLCI range. The frDlcmiState is defined in RFC 2115 and defines the specific values of the DLCI. 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 = 93 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | frDlcmiState | DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calato, MacFaden [Page 15] RFC NNNN LFAP June 2001 2.26 NEXT_HOP_IP IE Address of the next hop, TYPE is 94. Format is as shown for Source Address IE. 2.27 TCP Control Bits IE The TCP control bits seen for this flow. Note a 0 value for each bit only indicates that the flag was not detected (i.e. it may have occurred but was not detected by the reporting CCE). TCP Control Bits are defined by RFC 793. The bits are right justified and the remaining bits must be zero. TYPE is 94 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 = 95 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved Control Bits (6 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved - must be zero. 2.28 Next Hop AS IE The Autonomous System (AS) numbers for the next hop IP. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). TYPE is 96 and IE format is the same as for Source AS IE: 2.29 Source Address Netmask IE The number of bits in the CIDR netmask, as defined in RFC 1519, for the source address. The reserved field must be zero. 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 = 97 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | bit count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.30 Destination Address Netmask IE The CIDR netmask, as defined in RFC 1519, for the destination address. TYPE is 98 and format is as shown for Source Address Netmask IE: Calato, MacFaden [Page 16] RFC NNNN LFAP June 2001 2.31 Destination BGP Community IE The BGP community number for the destination address. BGP community number is defined by RFC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE = 99 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Community | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.32 Source BGP Community IE The BGP community number for the source address. TYPE is 100 and format is the same as for Destination BGP Community IE: 2.33 Traffic Index IE The traffic index associated with the flow. The index number is user defined but its size is limited to 16 bits with 0xFFFF and 0xFFFE being reserved. An index can map to one or more BGP Communities, an AS path or IP prefix. 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 = 101 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | traffic index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.34 VLAN ID IE The VLAN ID associated with the flow. VLAN ID is defined by IEEE standard 802.1q - 1998[802.1q]. Note - for flows which are inter- VLAN, the VLAN ID is that of the outgoing VLAN. 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 = 102 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | VLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calato, MacFaden [Page 17] RFC NNNN LFAP June 2001 2.35 Source Virtual Address IE A CCE may be involved in redirecting flows. This IE captures information needed for proper accounting of redirected flows. The Source Virtual IE contains the source address of the flow as transmitted by the CCE. It is generally different than the source address IE, which contains the address of the actual source of the 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 = 104 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family Number | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The reserved field must be zero. The type filed contains the type of translation performed on the source address. The following types are currently available: 1 - NAT 2 - LSNAT 3 - Web Cache 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 = IP (IP Version 4) as specified in RFC 1700 2 = IP6 (IP Version 6) as specified in RFC 1700 2.36 Source Virtual Port IE A CCE may be involved in redirecting flows. This IE captures information needed for proper accounting of redirected flows. The Source Virtual port IE contains the source port of the flow as transmitted by the CCE. It may be different than the source port IE, which contains the port of the actual source of the flow. The IP Protocol field defines the value of the source port number (e.g. 17 is UDP which is defined by RFC 768). Calato, MacFaden [Page 18] RFC NNNN LFAP June 2001 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 = 105 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | IP Protocol | IP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type field contains the type of translation performed on the source port. The following types are currently available: 1 - NAT 2 - LSNAT 3 - Web Cache The IP Protocol field is defined by the IP protocol spec [RFC 791]. 2.37 Destination Virtual Address IE The Destination Virtual IE contains the destination address of the flow as received by the CCE. It is generally different than the destination port number, which contains the actual destination address of the flow. TYPE is 106 and IE format is the same is for Source Virtual Address IE: 2.38 Destination Virtual Port IE The Destination Virtual port IE contains the destination port of the flow as received by the CCE. It may be different than the destination port recorded in the Protocol ID IE, which contains the actual destination port of the flow. TYPE is 107 and IE format is the same is for Source Virtual Port IE: 2.39 Vendor Specific IE Vendors may add their own information to the protocol. Information contained in this IE is vendor specific. OID and OID Value is defined by ITU X.680.X683 (1997) and is encoded as defined by ITU X.690.691(1997). This IE MUST not contain any information which cannot be safely ignored by the CCE or FAS. If multiple Vendor Specific IE's with the same OID occur, then the vendor defines semantics of ordering. Calato, MacFaden [Page 19] RFC NNNN LFAP June 2001 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 = 108 | LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OID Length | OID Value Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ OID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ OID value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.40 Flow Label IE The Flow Label IE contains the IPV6 Flow Label information as defined by RFC 2460. TYPE is 109 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 = 109 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.41 Fragment ID IE The fragment ID associated with the flow. RFC 791 and RFC 2460 define fragment ID. TYPE is 110 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 = 110 | LENGTH = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calato, MacFaden [Page 20] RFC NNNN LFAP June 2001 2.42 Numeric List of IE's The numeric list of IE's is as follows: 65 Flow ID IE 66 Source Address IE 67 Destination Address IE 68 Flow Qualifier IE's 69 Time IE 70 UTC Time IE 71 Delta Time IE 72 Type of Service IE 73 Source CCE Address IE 74 Client Data IE 75 Command Code IE 76 IE List 77 FAS Address IE 78 Failure Code IE 79 Flow State IE 80 ,81 Byte Count IE 82 ,83 Packet Count IE 84 Protocol Identifier IE 85 86,87 Source Port IE 88 Source AS IE 89 Destination AS IE 90 Ingress Port IE 91 Egress Port IE 92 Egress ATM Subinterface 93 Egress Frame Relay Subinterface 94 Next Hop IP 95 TCP Control Bits IE 96 Next Hop AS IE 97 Source Address Netmask IE 98 Destination Address Netmask IE 99 Destination BGP Community IE 100 Source BGP Community IE 101 Traffic Index IE 102 VLAN ID_IE 103 VLAN Priority IE 104 Source Virtual Address IE 105 Source Virtual Port IE 106 Destination Virtual Address IE 107 Destination Virtual Port IE 108 Vendor Specific IE 109 Flow Label IE 110 Fragment ID IE Calato, MacFaden [Page 21] RFC NNNN LFAP June 2001 3. Individual Message contents 3.1 Flow Accounting Request (FAR) Message FAR messages may contain the following IEs: Flow ID IE - Globally unique flow identifier Source Address IE - flow "from" address Destination Address IE - flow "to" address Flow Qualifier IE - Priority and checkpoint size Time IE - switch time at flow creation UTC Time IE - switch time at flow creation Class of Service IE - Class of Service associated with the flow Source CCE Address IE - address of the CCE recording the flow Client Data IE - arbitrary data Protocol Identifier IE - highest layer protocol decoded by the CCE for this flow Source Port IE - flow "from" port (note flow "to" port is recorded in Protocol ID IE Source AS IE - The AS numbers for the Source address IE Destination AS IE - The AS numbers for Destination address IE Ingress Port IE - The ifIndex of the ingress port Egress Port IE - The ifIndex of the egress port Egress ATM Subinterface IE - The vpi/vci associated with this flow Egress Frame Relay Subinterface - The DLCI associated with this flow Next Hop IP IE - The next hop address associated with this flow. TCP Control Bits IE - TCP flags seen during the course of this flow Next Hop AS_IE - The AS of the next hop address Source Address Netmask IE - Net mask associated with the source address Destination Address Netmask IE - Net mask associated with the Destination address Destination BGP Community IE - The BGP community associated with the destination address Source BGP Community IE - The BGP community associated with the source address Traffic Index IE - Traffic index associated with this flow VLAN ID IE - The VLAN associated with the flow VLAN Priority IE - The VLAN priority associated with this flow Calato, MacFaden [Page 22] RFC NNNN LFAP June 2001 Source Virtual Address IE - The source address as transmitted by the CCE Source Virtual Port IE - The source port as transmitted by the CCE Destination Virtual Address IE - The destination address as received by the CCE Destination Virtual Port IE - The destination port as received by the CCE Vendor Specific IE - Additional information supplied by a specific vendor implementation. Flow Label IE - The IPV6 flow label associated with the Flow. Fragment ID IE - The Fragment ID associated with the flow. Mandatory IE's Flow ID Time or UTC Time Optional IE's Source Address IE Destination Address IE Flow Qualifier IE's Type of Service IE Source CCE Address IE Client Data IE Protocol Identifier IE Source Port IE Source AS IE Destination AS IE Ingress Port IE Egress Port IE Egress ATM Subinterface Egress Frame Relay Subinterface Next Hop IP TCP Control Bits IE Next Hop AS_IE Source Address Netmask IE Destination Address Netmask IE Destination BGP Community IE Source BGP Community IE Traffic Index IE VLAN ID IE VLAN Priority IE Source Virtual Address IE Source Virtual Port IE Destination Virtual Address IE Destination Virtual Port IE Vendor Specific IE Calato, MacFaden [Page 23] RFC NNNN LFAP June 2001 Flow Label IE Fragment ID IE FAR messages contain information for a single flow, meaning different flows MUST be reported via separate FAR messages. The multiple record IE MUST NOT be used. If more than on Class of Service IE is present then different CoS Types fields have a cumulative affect. For example, a flow may arrive with an IPv4 Class of Service and then is transmitted over MPLS with another Class of Service. Two IEs are needed to represent this. Additionally, if two CoS IEs have the same CoS Type but have different I and R bits set, the affect is also cumulative. However, it is more space efficient to merely set both I and R in one IE. If two CoS IE's have the same type and same I/R bit set, the last IE value is used. 3.2 Flow Update Notification (FUN) Message FUN messages may contain the following IE's: Time IE - time when flow statistics were gathered UTC Time IE - time when flow statistics were gathered Delta Time IE - time covered by this update 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 Vendor Specific IE - Additional information supplied by a specific vendor implementation. Mandatory IE's Flow ID Time, UTC Time or Delta Time - If using 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 - assumed active if not given Byte Count Packet Count Vendor Specific IE FUN messages are sent periodically (as specified in the CCE configuration) by a CCE to the FAS. FUN messages may also be sent as a result of an AR. If only a single flow is being reported on Calato, MacFaden [Page 24] RFC NNNN LFAP June 2001 then just the IE's and their values are present. If multiple flows are to be reported on then the multiple record IE MUST be used so IEs can be associated with a specific Flow ID. This also results in reduced overhead on transmissions. Each record along with the fixed information in the multi-record IE is handled as if it arrived in its own FUN message, except the message counter is only incremented once. The flow ID identifies the flow to which this update applies. Flow state is the state of the flow at the time statistics were collected. 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 an alternative FAS. 3.3 Administrative Request (AR) Message AR messages MUST contain a Command Code IE. Based on the command, various IE's are required as listed below. RETURN_INDICATED_FLOWS Mandatory IE's Flow ID IE - the multiple record IE must be used to list more than one Flow ID. Multiple Flow IDs indicate a request for a FUN on each Flow ID listed. RETURN_FLOW_PREFIX No IE's are given RETURN_TIME - This command SHOULD be processed immediately No IE's are given REQUESTED_IES Mandatory IE's IE_LIST IE Either the CCE or the FAS send AR messages when they seek to perform one of the Command IE's. 3.4 Administrative Request Acknowledge (ARA) Message ARA messages may contain the following IE's based on the command code: Calato, MacFaden [Page 25] RFC NNNN LFAP June 2001 RETURN_INDICATED_FLOWS Optional IE's Failure Code - if FAS requested statistics on an unknown flow Flow ID IE - Flow ID of unknown flow The multiple record IE MUST be used to list more than one failure code/flow ID pair. RETURN_PREFIX Mandatory IE's Flow Identifier Prefix IE - Contains the requested prefix. RETURN_TIME Mandatory IE Time IE - If the ARA is a response to an AR command to return time. The timestamp is the time at which the ARA was created. The time between the AR and ARA, measured by the AR sender, SHOULD be no more than 30 seconds. This process MAY be repeated until an acceptable window is reached. Note: - the ARA SHOULD be sent immediately. REQUESTED_IEs No IE's are given. 4. Error Handling 4.1 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 Failure Code set to NO_SUCH_FLOW and contains the Flow ID copied from the corresponding AR message. If there were multiple flows that were non-existent then the multi-IE format MAY have the Failure Code in the fixed information section and the individual Flow ID's in the record section. Calato, MacFaden [Page 26] RFC NNNN LFAP June 2001 If the CCE does not support the command requested by the FAS it simply ignores the request for those commands that are unsupported and returns an empty ARA. 5. Session Establishment Before flow information is sent, certain information MAY be exchanged. The FAS MAY send an AR message with the command REQUESTED_IEs and the list of IE's it desires. If no such message is sent, the CCE will send any IE's it has been locally configured to send with the default of all IE's supported by the CCE. The FAS MAY send one or more AR messages with the command code RETURN_TIME, until an ARA is returned with an acceptable amount of delay. When the FAS is ready to receive flow data it MUST send a Flow Export Ready (FER) message. The CCE can send an AR message with the command RETURN_FLOW_PREFIX if does not already have one. 6. Security Considerations Security is addressed in the LFAP Specification[1]. 7. Author's Addresses Paul Calato Phone: +1 (603) 334-2625 Email: calato@riverstonenet.com Mike MacFaden Phone: +1 (408) 878-6525 Email: mrm@riverstonenet.com Riverstone Networks, Inc. is located at: 5200 Great America Parkway Santa Clara, CA 95054 USA Calato, MacFaden [Page 27] RFC NNNN LFAP June 2001 8. References [1] "Light-weight Flow Accounting Protocol Specification Version 5.0" draft-riverstone-lfap-00.txt, June 2001 [768] "User Datagram Protocol", RFC 768, August 1980 [791] "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 791, September 1981 [793] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 793, September 1981 [1443] "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, April 1993. [1519] "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [1700] "Assigned Numbers", RFC 1700, October 1994. [1771] "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995 [1930] "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996 [1997] "BGP Communities Attribute", RFC 1997, August 1996 [2021] "Remote Network Monitoring Management Information Base Version 2" RFC 2021, January 1977. [2074] "Remote Network Monitoring MIB Protocol Identifiers" RFC 2074, January 1997. [2115] "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997 [2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [2233] "The Interfaces Group MIB using SMIv2ö, RFC 2119, November 1997 [2460] "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 [3032] "MPLS Label Stack Encoding", RFC 3032, January 2001 Calato, MacFaden [Page 28] RFC NNNN LFAP June 2001 [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. [802.1p] "IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Common specifications Part 3: Media Access Control (MAC) Bridges Adopted by the ISO/IEC and redesignated as ISO/IEC 15802- 3:1998", ANSI/IEEE Std 802.1D, 1998 Edition [802.1q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Std 802.1Q-1998 Expires December 2001 Calato, MacFaden [Page 29]