Cisco Cisco Packet Data Gateway (PDG)

Seite von 990
Diameter Dictionaries and Attribute Definitions   
▀  Diameter Attributes 
 
 
▄  AAA Interface Administration and Reference, StarOS Release 17 
56 
   
Field 
Description 
options 
The different options are as follows: 
 
frag — Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be 
used in conjunction with either tcpflags or TCP/UDP port specifications.  
 
ipoptions spec — Match if the IP header contains the comma separated list of options specified in spec.  
The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts 
(timestamp). The absence of a particular option may be denoted with a '!'.  
 
tcpoptions spec — Match if the TCP header contains the comma separated list of options specified in spec.  
The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack 
(selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular 
option may be denoted with a '!'.  
 
established — TCP packets only. Match packets that have the RST or ACK bits set.  
 
setup — TCP packets only. Match packets that have the SYN bit set but no ACK bit. 
 
tcpflags spec — TCP packets only. Match if the TCP header contains the comma separated list of flags 
specified in spec.  
The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted 
with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero 
offset. See the frag option for details on matching fragmented packets.  
 
icmptypes types — ICMP packets only. Match if the ICMP type is in the list types. The list may be specified 
as any combination of ranges or individual types separated by commas. Both the numeric values and the 
symbolic values listed below can be used. 
The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), 
echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad 
(12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address 
mask request (17) and address mask reply (18).  
 
QoSFilterRule 
 The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be 
marked or metered based on the following information that is associated with it: 
 
Direction (in or out) 
 
Source and destination IP address (possibly masked) 
 
Protocol 
 
Source and destination port (lists or ranges) 
 
DSCP values (no mask or range) 
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each 
packet is evaluated once. If no rule matches, the packet is treated as best effort. An access device that is unable to 
interpret or apply a QoS rule SHOULD NOT terminate the session 
QoSFilterRule filters MUST follow the format: 
action dir proto from src to dst [options]