📄 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 1997Client 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 subaddressFlow 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 reuseAmsden, 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 activePolicy 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 1997Service 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 + -