One document matched: draft-riverstone-lfap-data-01.txt
Differences from draft-riverstone-lfap-data-00.txt
INTERNET-DRAFT Expires: December 2002 INTERNET-DRAFT
Network Working Group P. Calato
Request for Comments: NNNN M. MacFaden
Category: Informational Riverstone Networks Inc
Obsoletes: RFC 2124 June 2002
Category: Informational
Light-weight Flow Accounting Protocol Data Definition Specification
Version 5.0
<draft-riverstone-lfap-data-01.txt>
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 Informational [Page 1]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 IDENTIFIER PREFIX IE ....................................12
2.16 FLOW STATE IE ................................................12
2.17 BYTE COUNT IE ................................................12
2.18 PACKET COUNT IE ..............................................13
2.19 PROTOCOL IDENTIFIER IE .......................................14
2.20 SOURCE PORT IE ...............................................14
2.21 SOURCE AS IE .................................................15
2.22 DESTINATION AS IE ............................................15
2.23 INGRESS PORT IE ..............................................15
2.24 EGRESS PORT IE ...............................................15
2.25 VLAN ID IE ...................................................15
2.26 IN MPLS LABEL IE .............................................16
2.27 OUT MPLS LABEL IE ............................................16
2.28 NEXT HOP ADDR IE .............................................17
2.29 LDP FEC IE ...................................................17
2.30 INGRESS ATM SUBINTERFACE .....................................17
2.31 EGRESS ATM SUBINTERFACE ......................................17
2.32 INGRESS_FRAME_RELAY_SUBINTERFACE IE ..........................18
2.33 EGRESS_FRAME_RELAY_SUBINTERFACE IE ...........................18
2.34 TCP CONTROL BITS IE ..........................................18
2.35 NEXT HOP AS IE ...............................................19
2.36 SOURCE ADDRESS NETMASK IE ....................................19
2.37 DESTINATION ADDRESS NETMASK IE ...............................19
2.38 SOURCE BGP COMMUNITY IE ......................................19
2.39 DESTINATION BGP COMMUNITY IE .................................20
2.40 TRAFFIC INDEX IE .............................................20
2.41 SOURCE VIRTUAL ADDRESS IE ....................................20
2.42 SOURCE VIRTUAL PORT IE .......................................21
2.43 DESTINATION VIRTUAL ADDRESS IE ...............................22
2.44 DESTINATION VIRTUAL PORT IE ..................................22
Calato, MacFaden Informational [Page 2]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.45 VENDOR SPECIFIC IE ...........................................22
2.46 FLOW LABEL IE ................................................23
2.47 FRAGMENT ID IE ...............................................23
NUMERIC LIST OF IE'S ..............................................24
3. INDIVIDUAL MESSAGE CONTENTS ......................................25
3.1 FLOW ACCOUNTING REQUEST (FAR) MESSAGE .........................25
3.2 FLOW UPDATE NOTIFICATION (FUN) MESSAGE ........................27
3.3 ADMINISTRATIVE REQUEST (AR) MESSAGE ...........................29
3.4 ADMINISTRATIVE REQUEST ACKNOWLEDGE (ARA) MESSAGE ..............29
4. ERROR HANDLING ...................................................30
4.1 ARA RELATED ERROR HANDLING ....................................30
5. SESSION ESTABLISHMENT ............................................30
6. SECURITY CONSIDERATIONS ..........................................31
7. AUTHOR'S ADDRESSES ...............................................31
8. REFERENCES .......................................................31
Calato, MacFaden Informational [Page 3]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
1. Introduction
Light-weight Flow Accounting Protocol, LFAP, allows 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. 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 Informational [Page 4]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 Informational [Page 5]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 Informational [Page 6]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 Informational [Page 7]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 Informational [Page 8]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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.
Command code has one of the following values and meanings:
Calato, MacFaden Informational [Page 9]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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.
5 - LIST_OF_FASS - Used by the CCE to inform the FAS
of an updated list of FAS's that
the CCE has been given. This list
must be
given in the order that the CCE
would search.
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
Calato, MacFaden Informational [Page 10]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
defined in the LFAP Specification [1]. Values are
defined in both the LFAP Specification and this
document.
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 Informational [Page 11]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.15 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 = 79 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
|+-+-+-+-+- FAS assigned Flow Identifier Prefix -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.16 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 = 80 | 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.17 Byte Count IE
Contains the count of octets sent and received associated with the
identified flow. IE format is:
Calato, MacFaden Informational [Page 12]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 = 81 or 82 | LENGTH = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Bytes Received -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Bytes Sent -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 81 Means that the byte count is a running counter and is the
count from the beginning of the flow establishment.
Type 82 Means that the byte count is a delta counter and is the
count since the last FUN message.
2.18 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 = 83 or 84 | LENGTH = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Packets/Cells/Frames Received -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Packets/Cells/Frames Sent -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Type 83 means that the packet/cell/frame count is a running
counter and is the count from the beginning of the flow
establishment.
A Type 84 means that the packet/cell/frame count is a delta counter
and is the count since the last FUN message.
Calato, MacFaden Informational [Page 13]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.19 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 = 85 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Protocol Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.20 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 86 is UDP source
port [see RFC 768], TYPE 87 is TCP source port [see RFC 793] and
TYPE 88 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 = 86, 87 or 88 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port/Socket Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calato, MacFaden Informational [Page 14]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.21 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 = 89 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.22 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 90 and the format is the
same is for Source AS IE.
2.23 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 = 91 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.24 Egress Port IE
The egress ifIndex for the flow is provided in this IE. ifIndex is
defined by RFC 2233. More than one egress port IE may be present in
a FAR message. The FAR message contents section defines the
semantics. TYPE is 92 and format is the same as for Ingress Port
IE.
2.25 VLAN ID IE
VLAN ID is defined by IEEE standard 802.1q - 1998[802.1q]. For
intra-VLAN flows, the source and destination VLAN ID are the same.
For inter-VLAN traffic, the source VLAN ID is the VLAN associated
with the flow where the traffic entered the CCE and the destination
Calato, MacFaden Informational [Page 15]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
is the VLAN associated with the flow where the traffic exited the
CCE. For example, with simple port based VLANs the source VLAN
would be that of the ingress port and the destination VLAN would be
that of the egress port. A value of 65535, which is outside the
valid range of VLAN IDs, is used here to indicate that value has
been omitted. This allows either Source or Destination VLAN ID to
be reported independently. 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 = 93 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source VLAN ID | Destination VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.26 In MPLS Label IE
The incoming MPLS Label associated with an MPLS LSP. RFC 3032
define the MPLS label. TYPE is 111 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 = 94 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More than one label IE can be present in a FAR message. The FAR
message contents section defines the semantics.
2.27 Out MPLS Label IE
The outgoing MPLS Label associated with an MPLS LSP. RFC 3032
define the MPLS label. TYPE is 112 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 | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More than one label IE can be present in a FAR message. The FAR
message contents section defines the semantics.
Calato, MacFaden Informational [Page 16]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.28 NEXT HOP ADDR IE
Address of the next hop, TYPE is 96. Format is as shown for Source
Address IE.
2.29 LDP FEC IE
The Flow Equivalency Class associated with the MPLS flow. The FEC
Element is encoded as described in the Label Distribution Protocol
Specification (LDP Specification) RFC 3036 and Internet Draft
draft-martini-l2circuit-trans-mpls-07.txt. Only one FEC element may
be encoded. However, more than one LDP FEC IE may be present in a
FAR message. See the FAR message for semantics.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ FEC Element ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.30 Ingress ATM Subinterface
The Ingress 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 = 98 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vpi | vci |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.31 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 = 99 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vpi | vci |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calato, MacFaden Informational [Page 17]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.32 INGRESS_FRAME_RELAY_SUBINTERFACE IE
The ingress 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 = 100 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| frDlcmiState | DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.33 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 = 101 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| frDlcmiState | DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.34 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 = 102 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved Control Bits (6 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved - must be zero.
Calato, MacFaden Informational [Page 18]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.35 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 103 and IE format is the same as for Source AS IE:
2.36 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 = 104 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | bit count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.37 Destination Address Netmask IE
The CIDR netmask, as defined in RFC 1519, for the destination
address. TYPE is 105 and format is as shown for Source Address
Netmask IE:
2.38 Source BGP Community IE
The BGP community number for the source address. BGP community
number is defined by RFC 1997. More than one Source BGP Community
IE may be present. See FAR message for semantics. TYPE is 105, 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 = 106 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Community |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calato, MacFaden Informational [Page 19]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.39 Destination BGP Community IE
The BGP community number for the destination address. BGP community
number is defined by RFC 1997. More than one Destination BGP
Community IE may be present. See FAR message for semantics. TYPE is
107 and format is the same as for Source BGP Community IE.
2.40 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 = 108 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | traffic index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.41 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 = 109 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Number | Address Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved field must be zero.
Calato, MacFaden Informational [Page 20]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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.42 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).
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 = 110 | 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].
Calato, MacFaden Informational [Page 21]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.43 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 111 and IE format is the same is for
Source Virtual Address IE:
2.44 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 112 and IE format is
the same is for Source Virtual Port IE:
2.45 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.
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 = 113 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID Length | OID Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OID value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calato, MacFaden Informational [Page 22]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
2.46 Flow Label IE
The Flow Label IE contains the IPV6 Flow Label information as
defined by RFC 2460. TYPE is 113 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 = 114 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.47 Fragment ID IE
The fragment ID associated with the flow. RFC 791 and RFC 2460
define fragment ID. TYPE is 114 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 = 115 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calato, MacFaden Informational [Page 23]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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 Class 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 Identifier Prefix IE
80 Flow State IE
81 ,82 Byte Count IE
83 ,84 Packet Count IE
85 Protocol Identifier IE
86 ,87,88 Source Port IE
89 Source AS IE
90 Destination AS IE
91 Ingress Port IE
92 Egress Port IE
93 VLAN ID_IE
94 In MPLS Label IE
95 Out MPLS Label IE
96 Next Hop Addr IE
97 LDP_FEC IE
98 Ingress ATM Subinterface
99 Egress ATM Subinterface
100 Ingress Frame Relay Subinterface
101 Egress Frame Relay Subinterface
102 TCP Control Bits IE
103 Next Hop AS IE
104 Source Address Netmask IE
105 Destination Address Netmask IE
106 Source BGP Community IE
107 Destination BGP Community IE
108 Traffic Index IE
109 Source Virtual Address IE
110 Source Virtual Port IE
111 Destination Virtual Address IE
112 Destination Virtual Port IE
113 Vendor Specific IE
114 Flow Label IE
115 Fragment ID IE
Calato, MacFaden Informational [Page 24]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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
VLAN ID IE - The VLAN associated with the flow
In MPLS Label IE - Incoming MPLS label
Out MPLS Label IE - Outgoing MPLS Label
Next Hop Addr IE - The next hop address associated with
this flow.
LDP FEC - The Flow Equivalency Class (FEC)
associated with an MPLS flow.
Egress ATM Subinterface IE - The vpi/vci associated with this
flow
Ingress ATM Subinterface IE - The vpi/vci associated with this
flow
Ingress Frame Relay Subinterface - The DLCI associated with this
flow
Egress Frame Relay Subinterface - The DLCI 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
Calato, MacFaden Informational [Page 25]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
Source BGP Community IE - The BGP community associated with
the source address
Destination BGP Community IE - The BGP community associated with
the destination address
Traffic Index IE - Traffic index associated with this
flow
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
Class 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
VLAN ID IE
In MPLS Label IE
Out MPLS Label IE
Next Hop Addr IE
LDP FEC IE
Ingress ATM Subinterface IE
Egress ATM Subinterface IE
Ingress Frame Relay Subinterface IE
Egress Frame Relay Subinterface IE
TCP Control Bits IE
Next Hop AS IE
Source Address Netmask IE
Calato, MacFaden Informational [Page 26]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
Destination Address Netmask IE
Destination BGP Community IE
Source BGP Community IE
Traffic Index IE
Source Virtual Address IE
Source Virtual Port IE
Destination Virtual Address IE
Destination Virtual Port IE
Vendor Specific IE
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.
If more than one Egress Port IE is present, it indicates that the
flow exits multiple ports. For example, with VLAN flooding. Order
is not significant.
If more than one MPLS label IE is present, the order MUST be the
same as the order of the label stack as defined in RFC 3032.
If more than one LDP FEC IE is present, semantics are as described
in RFC 3036 and Internet Draft draft-martini-l2circuit-trans-mpls-
07.txt.
If more than one Source/Destination BGP community are present, it
indicates that the associated address is part of more than one BGP
community. Order is not significant.
3.2 Flow Update Notification (FUN) Message
FUN messages may contain the following IE's:
Time IE - time when flow statistics were gathered
Calato, MacFaden Informational [Page 27]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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
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.
Calato, MacFaden Informational [Page 28]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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:
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
Calato, MacFaden Informational [Page 29]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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.
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.
Calato, MacFaden Informational [Page 30]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
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
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
Calato, MacFaden Informational [Page 31]
INTERNET-DRAFT LFAP Data Definition V5.0 June 2002
[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
[3036] "LDP Specification", RFC 3036, January 2001
[draft-martini-l2circuit-trans-mpls-07.txt]
"Transport of Layer 2 Frames Over MPLS",
draft-martini-l2circuit-trans-mpls-07.txt, July 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 2002
Calato, MacFaden Informational [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-23 19:43:15 |