📄 rfc2748.txt
字号:
Finally, fault tolerance is a required capability for this protocol,
particularly due to the fact it is associated with the security and
service management of distributed network devices. Fault tolerance
can be achieved by having both the PEP and remote PDP constantly
verify their connection to each other via keep-alive messages. When a
failure is detected, the PEP must try to reconnect to the remote PDP
or attempt to connect to a backup/alternative PDP. While
disconnected, the PEP should revert to making local decisions. Once a
connection is reestablished, the PEP is expected to notify the PDP of
any deleted state or new events that passed local admission control
after the connection was lost. Additionally, the remote PDP may
request that all the PEP's internal state be resynchronized (all
previously installed requests are to be reissued). After failure and
before the new connection is fully functional, disruption of service
can be minimized if the PEP caches previously communicated decisions
and continues to use them for some limited amount of time. Sections
2.3 and 2.5 detail COPS mechanisms for achieving reliability.
2. The Protocol
This section describes the message formats and objects exchanged
between the PEP and remote PDP.
2.1 Common Header
Each COPS message consists of the COPS header followed by a number of
typed objects.
0 1 2 3
+--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+
| Message Length |
+--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0.
Durham, et al. Standards Track [Page 6]
RFC 2748 COPS January 2000
The fields in the header are:
Version: 4 bits
COPS version number. Current version is 1.
Flags: 4 bits
Defined flag values (all other flags MUST be set to 0):
0x1 Solicited Message Flag Bit
This flag is set when the message is solicited by
another COPS message. This flag is NOT to be set
(value=0) unless otherwise specified in section 3.
Op Code: 8 bits
The COPS operations:
1 = Request (REQ)
2 = Decision (DEC)
3 = Report State (RPT)
4 = Delete Request State (DRQ)
5 = Synchronize State Req (SSQ)
6 = Client-Open (OPN)
7 = Client-Accept (CAT)
8 = Client-Close (CC)
9 = Keep-Alive (KA)
10= Synchronize Complete (SSC)
Client-type: 16 bits
The Client-type identifies the policy client. Interpretation of
all encapsulated objects is relative to the client-type. Client-
types that set the most significant bit in the client-type field
are enterprise specific (these are client-types 0x8000 -
0xFFFF). (See the specific client usage documents for particular
client-type IDs). For KA Messages, the client-type in the header
MUST always be set to 0 as the KA is used for connection
verification (not per client session verification).
Message Length: 32 bits
Size of message in octets, which includes the standard COPS
header and all encapsulated objects. Messages MUST be aligned on
4 octet intervals.
Durham, et al. Standards Track [Page 7]
RFC 2748 COPS January 2000
2.2 COPS Specific Object Formats
All the objects follow the same object format; each object consists
of one or more 32-bit words with a four-octet header, using the
following format:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
The length is a two-octet value that describes the number of octets
(including the header) that compose the object. If the length in
octets does not fall on a 32-bit word boundary, padding MUST be added
to the end of the object so that it is aligned to the next 32-bit
boundary before the object can be sent on the wire. On the receiving
side, a subsequent object boundary can be found by simply rounding up
the previous stated object length to the next 32-bit boundary.
Typically, C-Num identifies the class of information contained in the
object, and the C-Type identifies the subtype or version of the
information contained in the object.
C-num: 8 bits
1 = Handle
2 = Context
3 = In Interface
4 = Out Interface
5 = Reason code
6 = Decision
7 = LPDP Decision
8 = Error
9 = Client Specific Info
10 = Keep-Alive Timer
11 = PEP Identification
12 = Report Type
13 = PDP Redirect Address
14 = Last PDP Address
15 = Accounting Timer
16 = Message Integrity
C-type: 8 bits
Values defined per C-num.
Durham, et al. Standards Track [Page 8]
RFC 2748 COPS January 2000
2.2.1 Handle Object (Handle)
The Handle Object encapsulates a unique value that identifies an
installed state. This identification is used by most COPS operations.
A state corresponding to a handle MUST be explicitly deleted when it
is no longer applicable. See Section 2.4 for details.
C-Num = 1
C-Type = 1, Client Handle.
Variable-length field, no implied format other than it is unique from
other client handles from the same PEP (a.k.a. COPS TCP connection)
for a particular client-type. It is always initially chosen by the
PEP and then deleted by the PEP when no longer applicable. The client
handle is used to refer to a request state initiated by a particular
PEP and installed at the PDP for a client-type. A PEP will specify a
client handle in its Request messages, Report messages and Delete
messages sent to the PDP. In all cases, the client handle is used to
uniquely identify a particular PEP's request for a client-type.
The client handle value is set by the PEP and is opaque to the PDP.
The PDP simply performs a byte-wise comparison on the value in this
object with respect to the handle object values of other currently
installed requests.
2.2.2 Context Object (Context)
Specifies the type of event(s) that triggered the query. Required for
request messages. Admission control, resource allocation, and
forwarding requests are all amenable to client-types that outsource
their decision making facility to the PDP. For applicable client-
types a PEP can also make a request to receive named configuration
information from the PDP. This named configuration data may be in a
form useful for setting system attributes on a PEP, or it may be in
the form of policy rules that are to be directly verified by the PEP.
Multiple flags can be set for the same request. This is only allowed,
however, if the set of client specific information in the combined
request is identical to the client specific information that would be
specified if individual requests were made for each specified flag.
C-num = 2, C-Type = 1
Durham, et al. Standards Track [Page 9]
RFC 2748 COPS January 2000
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
R-Type (Request Type Flag)
0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request
0x04 = Outgoing-Message request
0x08 = Configuration request
M-Type (Message Type)
Client Specific 16 bit values of protocol message types
2.2.3 In-Interface Object (IN-Int)
The In-Interface Object is used to identify the incoming interface on
which a particular request applies and the address where the received
message originated. For flows or messages generated from the PEP's
local host, the loop back address and ifindex are used.
This Interface object is also used to identify the incoming
(receiving) interface via its ifindex. The ifindex may be used to
differentiate between sub-interfaces and unnumbered interfaces (see
RSVP's LIH for an example). When SNMP is supported by the PEP, this
ifindex integer MUST correspond to the same integer value for the
interface in the SNMP MIB-II interface index table.
Note: The ifindex specified in the In-Interface is typically relative
to the flow of the underlying protocol messages. The ifindex is the
interface on which the protocol message was received.
C-Num = 3
C-Type = 1, IPv4 Address + Interface
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address specifies the
IP address that the incoming message came from.
Durham, et al. Standards Track [Page 10]
RFC 2748 COPS January 2000
C-Type = 2, IPv6 Address + Interface
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address specifies the
IP address that the incoming message came from. The ifindex is used
to refer to the MIB-II defined local incoming interface on the PEP as
described above.
2.2.4 Out-Interface Object (OUT-Int)
The Out-Interface is used to identify the outgoing interface to which
a specific request applies and the address for where the forwarded
message is to be sent. For flows or messages destined to the PEP's
local host, the loop back address and ifindex are used. The Out-
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -