📄 rfc2124.txt
字号:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Bytes Received -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Bytes Sent -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 Means that the byte count is a running counter and is the
count from the beginning of the flow establishment.
Type 2 Means that the byte count is a delta counter and is the
count since the last FUN message.
Packet Count IE
Contains the count of packets cells or frames sent and received
associated with the identified connection. IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 3 or 4 | LENGTH = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Packets/Cells/Frames Received -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+- Packets/Cells/Frames Sent -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3 Means that the packet/cell/frame count is a running counter
and is the count from the beginning of the flow establishment.
Type 4 Means that the packet/cell/frame count is a delta counter
and is the count since the last FUN message.
Amsden, et. al. Informational [Page 6]
RFC 2124 LFAP March 1997
Client Data IE
For use in determination of admission policy relative to a specific
connection request based on arbitrary client data (OCTET STRING
[8824]). IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 5 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Client Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Address IE
Destination address associated with a message. IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 6 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Number | Address Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Length field contains the length of the address excluding
any pad of zeros used to align the address field.
Address Family Numbers include:
1 - 14 (decimal) as specified in [1700]
15 E.164 with NSAP format subaddress
Flow ID IE
In order to accumulate the flow accounting statistics across multiple
FAS's in case of a FAS failure a globally unique flow identifier
needs to be formed. To accomplish this the FAS assigns a prefix if
requested by the CCE. The CCE then assigns a CCE flow identifier
that it guaranties to be unique for the use of the FAS flow
identifier prefix for each flow admitted. If the CCE needs to reuse
Amsden, et. al. Informational [Page 7]
RFC 2124 LFAP March 1997
a CCE flow ID it must acquire a new FAS prefix. If a CCE cannot
support the FAS flow identifier then it does not request a FAS prefix
and uses a FAS length of 0 in all updates to the flow. If the CCE
does not support the FAS identifier prefix then when a CCE fails over
all calls will need to be readmitted and will be seen as two separate
calls at the accumulation point. Flow ID IE is copied exactly in all
messages that refer to this flow. IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 7 |FAS Length = 8 |CCE Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
|+-+-+-+-+- FAS assigned Flow Identifier Prefix -+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+
| CCE assigned Flow Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow State IE
Flow state is the intended end state for the Flow associated with the
message containing this IE. IE format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 8 | LENGTH = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow state has one of the following values and meanings:
0 - INACTIVE - Flow is inactive
1 - ACTIVE - Flow is active
Policy IE's
There are two basic types of Policy IE's Optional and Mandatory. In
the case of optional operating policy if the combination of policy
and value given cannot be interpreted by a switch CCE it may be
safely ignored. In the case of mandatory operating policy if the
combination of policy and value given cannot be interpreted by a
switch CCE it must abort the flow state. Examples of optional
operating policies are Checkpoint Timer and Connection Priority.
Amsden, et. al. Informational [Page 8]
RFC 2124 LFAP March 1997
There are also two forms of the policy ID. The first is where the
policy ID is a number and the second is where the policy ID is an
Object Identifier. The policy ID's with number values are identified
in this document and its proposed changes over time. The Object
Identifier IDs can be used by individual implementers to apply
proprietary or experimental additions to this document and still be
compliant with the general form of this document.
Operating Policy IEs are comprised of Policy ID, a length and a
value. In the case of the policies defined in this document a length
is required and specified here. In the case of policies using the OID
format the length may be implied by the OID or be part of the policy
value as determined by individual implementation.
Policy IE format for Policy ID's defined in this document
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 9 + 10 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy ID | Policy Value length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
~ Policy Value ~
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Policy Pairs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 9 is an Optional Policy and type 10 is a Mandatory Policy.
The following policy ID's and policy values are presently defined or
under consideration.
Policy ID Value Meaning
Usage 01xx The purpose of this set of
policies is for usage
constraints. This set of
policies in the future may
include Connection Count,
Maximum Bandwidth and Connect
Time.
Amsden, et. al. Informational [Page 9]
RFC 2124 LFAP March 1997
Routing 02xx The purpose of these polices
is to allow for various
routing policies to be
enforced in the a switching
environment. This set of
policies may include
Optimization, Designated
Transit List, Restricted
Transit List and Path Cost.
Administrative 03xx
Keep Statistics 0301 = 0 Keep statistics on this flow
Not= 0 Do Not keep statistics on flow
Connection 0302 1 - 255 Priority of this connection
Priority Less is higher
Checkpoint 0303 1 - 2^31 Seconds between FUN on a flow
Timer
Checkpoint
Threshold 0304 1 - 2^63 # of bytes to collect before
sending a FUN on a flow
Connectionless 04xx The purpose of these policies
is to control connection
unaware calls. This set will
include Inactivity Timer and
Bandwidth allocation.
Policy IE format when Policy ID is a Object Identifier
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 11 + 12 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Policy OID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Policy ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Policy Pairs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 11 is an optional policy and type 12 is a mandatory policy.
Amsden, et. al. Informational [Page 10]
RFC 2124 LFAP March 1997
Service Identifier IE
Used in determination of admission policy relative to a specific
connection request based on service type. Service Identifier is
specified as an OCTET STRING [8824].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 13 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Service Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Address IE
Source address associated with a message. TYPE is 14, format is as
shown for Destination Address IE.
Source Switch Address IE
Source Switch address associated with a message. TYPE is 15, format
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -