Internet Draft Weiming Wang
Expiration: May 2004 Hangzhou Univ. of Commerce
File: draft-wang-forces-grmp-01.txt Yunfei Guo
Working Group: ForCES Hi-Tech R&D
Guangming Wang
Ligang Dong
Hangzhou Univ. of Commerce
November 2003
General Router Management Protocol (GRMP) Version 1
draft-wang-forces-grmp-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines the General Router Management Protocol (GRMP)
Version 1. This protocol is based on an open programmable router
architecture defined in the ForCES requirements and in the ForCES
framework. GRMP protocol is designed to meet all the requirements for
the ForCES protocol at Fp reference point in the architecture, where
the ForCES protocol acts as a base protocol and ForCES FE model as a
data model for this protocol.
Table of Contents
Abstract...........................................................1
1. Introduction....................................................3
2. Definitions.....................................................3
3. GRMP Protocol Overview..........................................6
Internet Draft GRMP V1 Nov. 2003
3.1. GRMP Message Organizing....................................6
3.2. Message Format.............................................7
3.3. GRMP Message Encapsulation................................11
3.4. Common Data Format in GRMP Messages.......................11
3.4.1. ACK Message Data Format..............................11
3.4.2. TLV Data Format......................................12
3.4.3. List Data Format.....................................13
3.4.4. AE Address Data Format...............................13
3.4.5. Object Class and the Data Format.....................14
4. GRMP Messages..................................................15
4.1. FE Management Messages....................................15
4.1.1. FE Join Request Message..............................15
4.1.2. FE Leave Request Message.............................17
4.1.3. FE Topology Query and Response Messages..............17
4.1.4. FE Capability Query and Response Messages............19
4.1.5. FE Action Manipulate Message.........................22
4.1.6. FE Attribute Manipulate Message......................23
4.1.7. FE Attribute Query and Response Messages.............25
4.1.8. FE Event Report Message..............................27
4.2. LFB Management Messages...................................30
4.2.1. LFB Action Manipulate Message........................30
4.2.2. LFB Topology Query and Response Messages.............33
4.2.3. LFB Attribute Manipulate Message.....................34
4.2.4. LFB Attribute Query and Response Messages............36
4.3. Datapath Management Messages..............................37
4.3.1. Datapath Manipulate Message..........................38
4.3.2. Datapath Query and Response Messages.................38
4.4. CE Informing Messages.....................................40
4.4.1. CE Query request and Response Messages...............40
4.4.2. CE Event Report Message..............................41
4.5. Managed Object (MO) Management Messages...................43
4.5.1. MO Get Message.......................................44
4.5.2. MO Set Message.......................................44
4.5.3. MO Response Message..................................45
4.6. GRMP Slave Management.....................................45
4.6.1. GRMP Slave Model.....................................45
4.6.2. DoS Protection Policy................................46
4.6.3. DoS Attack Alert Policy..............................48
4.6.4. CE Failover or Leave Policy..........................48
4.6.5. FE Failover and Rejoin Policy........................49
4.6.6. FE Heartbeat Policy..................................50
4.6.7. GRMP Version Assignment..............................51
4.7. Packet Redirection Messages...............................51
4.8. GRMP Batch Messages.......................................52
5. Security Considerations........................................53
6. IANA Considerations............................................54
7. References.....................................................54
7.1. Normative References......................................54
7.2. Informative References....................................54
8. Appendix A Definitions for Code Value.........................55
9. Acknowledgments................................................55
Wang, et. al., Expires May 2004 [Page 2]
Internet Draft GRMP V1 Nov. 2003
10. Authors' Addresses............................................55
Conventions used in this document
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. Introduction
The concept of IP Forwarding and Control Element Separation (ForCES)
separates a general IP Network Element (NE) like a RFC1812 compliant
router [1] into a control plane and a forwarding plane [2]. The
control plane is composed of one or more Control Elements (CEs). The
forwarding plane is composed of several Forwarding Elements (FEs)
connected into an FE topology. Each FE is modeled with multiple
Logical Functional Blocks (LFBs) that are connected into an FE LFB
topology. A set of protocols is used in ForCES for the management and
operations of the CEs and FEs. [2] has defined the ForCES general
requirements and [3] has defined the ForCES framework.
General Router Management Protocol (GRMP) Version 1 defined in this
document intends to be a ForCES protocol, which acts at the Fp
reference point in the ForCES framework [3]. GRMP is designed to meet
all the requirements for the ForCES protocol at the Fp reference
point.
GRMP protocol is a master-slave protocol. CEs act as masters and FEs
as slaves. Slaves have rights to send to masters request, response or
report messages, while masters can send command messages to slaves as
well as send request, response, or report messages. GRMP protocol
acts in a mode of a base-protocol associated with a data model [5],
where GRMP is as a base-protocol and ForCES FE model [6] as a Data
Model. GRMP defines basic management messages, while managed data are
defined in the associated ForCES FE model. Most of the data types and
functional descriptions related to specific IP services such as
routing service conforming to RFC 1812, QoS configurations, high-
touch capabilities like NAT and firewall should be expressed by
Logical functional Blocks (LFBs) and LFB topologies. The ForCES
protocol application layer is responsible on how to configure the
LFBs and the LFB topologies based on the FE capabilities in order to
implement specific IP services and QoS resources deployment.
GRMP is developed separately from General Switch Management Protocol
(GSMP) protocol [4] [10]. However, GRMP has been considering its
possible compatibility with GSMP, with the work currently ongoing
within the GSMP group that is adding flexibility to the base
specification, GRMP is willing to work with the GSMP group to
integrate this with GSMP.
2. Definitions
Wang, et. al., Expires May 2004 [Page 3]
Internet Draft GRMP V1 Nov. 2003
This document follows the definitions in [2] and [3]. We include the
definitions that are often quoted in this document as follows:
Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on IP
networks, it is a device to which we can communicate using an IP
address; and on a switch fabric, it is a device to which we can
communicate using a switch fabric port number
Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by a CE via the
ForCES protocol.
Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs how to process
packets. CEs handle functionality such as the execution of control
and signaling protocols.
Pre-association Phase - The period of time during which a FE Manager
(see below) and a CE Manager (see below) are determining which FE and
CE should be part of the same network element.
Post-association Phase - The period of time during which a FE does
know which CE is to control it and vice versa, including the time
during which the CE and FE are establishing communication with one
another.
ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" refers
only to the ForCES post-association phase protocol (see below).
ForCES Post-Association Phase Protocol - The protocol used for post-
association phase communication between CEs and FEs. This protocol
does not apply to CE-to-CE communication, FE-to-FE communication, or
to communication between FE and CE managers. The ForCES protocol is
a master-slave protocol in which FEs are slaves and CEs are masters.
This protocol includes both the management of the communication
channel (e.g., connection establishment, heartbeats) and the control
messages themselves. This protocol could be a single protocol or
could consist of multiple protocols working together.
FE Model - A model that describes the logical processing functions
of a FE.
FE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which CE(s) a FE should
communicate. This process is called CE discovery and may involve the
FE manager learning the capabilities of available CEs. A FE manager
may use anything from a static configuration to a pre-association
Wang, et. al., Expires May 2004 [Page 4]
Internet Draft GRMP V1 Nov. 2003
phase protocol (see below) to determine which CE(s) to use. Being a
logical entity, a FE manager might be physically combined with any of
the other logical entities such as FEs.
CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE should
communicate. This process is called FE discovery and may involve the
CE manager learning the capabilities of available FEs. A CE manager
may use anything from a static configuration to a pre-association
phase protocol (see below) to determine which FE to use. Being a
logical entity, a CE manager might be physically combined with any of
the other logical entities such as CEs.
Pre-association Phase Protocol - A protocol between FE managers and
CE managers that is used to determine which CEs or FEs to use. A pre-
association phase protocol may include a CE and/or FE capability
discovery mechanism. Note that this capability discovery process is
wholly separate from (and does not replace) that used within the
ForCES protocol. However, the two capability discovery mechanisms may
utilize the same FE model.
ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside a NE, the NE represents a
single point of management. Similarly, a NE usually hides its
internal organization from external entities.
High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents
or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT,
firewall, and L7 content recognition.
FE Topology - Representation of how the multiple FEs in a single NE
are interconnected.
Definitions introduced other than [2] and [3] are as follows:
Logical Functional Block (LFB) - A functional building block in an
FE that is usually defined by ForCES FE model.
Datapath - A data path connection that connects LFBs together in an
FE model. Via a datapath, IP packets (or other data) can be
transferred from one LFB to other LFBs.
FE LFB Topology - Representation on how LFBs in an FE are
interconnected via datapaths.
Managed Object (MO) - In GRMP, it specifically denotes objects that
are managed by some network management protocols like SNMP. Managed
objects for SNMP are the objects identified by the Object Identifiers
defined in SNMP MIBs [9].
Wang, et. al., Expires May 2004 [Page 5]
Internet Draft GRMP V1 Nov. 2003
3. GRMP Protocol Overview
3.1. GRMP Message Organizing
GRMP protocol is composed of protocol messages. GRMP organizes these
messages according to the different object layers in ForCES
architecture as follows:
1. FE Coarse Layer
. FE management messages
These messages take a whole FE as the managed object. Messages of
this type include that for operation of FE join or leave, FE action,
FE attribute, FE event report, etc. Messages of this type also
include that for GRMP slave management, which is a module GRMP
protocol has defined in a FE that is responsible for protocol message
interpreting, executing, generating, and encapsulating at the FE side.
2. FE Fine Layer
. LFB management messages
This type of messages is for the management of LFB layer operation.
It takes LFBs as its managed objects. Messages of this type include
that for operation of LFB action, LFB attribute, etc.
. Datapath management messages
This type of messages is for the management of datapaths in an FE.
It takes datapathes as the managed objects.
3. CE Layer
. CE Informing messages
This type of messages takes CE as the operated object. Because CE
acts as a master in ForCES protocol, allowed operations to CE from
FE are only that like CE attribute query, CE event report, etc.
4. Protocol Layer and others
Messages of this type include:
. GRMP ACK message
. Packet redirection messages
. GRMP Batch messages
. Managed Object(MO) management messages
In order to support network management tools like SNMP in ForCES
architecture, GRMP provides these management messages. The messages
take Managed Objects (MOs) defined in some specific network
management tools as their operating objects. Operations of MOs are
that like MO get, MO set, and MO response.
From the perspective of the message communication in between CE and
FE, GRMP messages can be divided into following types:
1. Messages for query and response types. These messages can be from
CE to FE, or from FE to CE.
Wang, et. al., Expires May 2004 [Page 6]
Internet Draft GRMP V1 Nov. 2003
2. Messages for command and configuration types. These messages are
only from CE to FE.
3. Messages for report types. These messages can be from CE to FE,
or from FE to CE.
GRMP has defined a "Object Class" prefix to allow managed objects to
be defined inside GRMP protocol, by different versions of ForCES FE
models, or by vendors, in order to make GRMP protocol more scalable
and flexible regarding its managed entities.
3.2. Message Format
GRMP messages have the following uniform message format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ GRMP Message Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GRMP Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 Checksum(Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. GRMP Message Header
A GRMP Message Header has following format and fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| SubVer| Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C|I| Reserved| SubMeg Num | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
Version number, this version of GRMP is set to 0x01.
SubVer:
Sub version of the protocol. Sub version of this GRMP is 0x00.
Message Type:
Value Description
0 GRMP ACK message
1 - 15 reserved
16 - 31 for FE management messages
Wang, et. al., Expires May 2004 [Page 7]
Internet Draft GRMP V1 Nov. 2003
32 - 47 for LFB management messages
48 - 63 for Datapath management messages
64 - 79 for CE informing messages
0thers for other messages
Result:
The Result field in the message header acts as an indicator for
error control of message communications as well as message processing.
It indicates if receiver of the message needs to send an extra GRMP
ACK(acknowledge) Message (see Section 3.4.1 for ACK message
definition) to sender of the message. Along with the followed Code
field, possible errors of communications or message processing can be
reported to the message sender.
The Result field for all messages except GRMP ACK message possibly
has one of following values:
Value Description
0(NoAck) Default value, a message receiver does
not need to send back an ACK message to
message sender in any case.
1(NoSuccessAck) If a message is successfully processed,
the receiver does not send an ACK
message, or else an ACK message is sent
back to the sender.
2(AckAll) A receiver sends back an ACK message in
any case.
4(SuccessAck) A receiver sends back an ACK message
only when it has successfully processed
it.
Others Reserved, and all undefined value will
be taken as the default value (NoAck).
For a message like a query or a request message that has been
defined to expect a response message, the Result field in the message
header is ignored and always be taken as "NoSuccessAck" by receiver,
that is, when the system can process the request successfully, it
will send back a normal expected response message to the request
sender. When the system finds any problem during transmission or in
processing this request, it will send a GRMP ACK message back to
sender to tell the failure and its reason by setting the Code field
(see below).
For a request message that does not expect a response message, which
is like FE join or leave request message, the Result field is used
normally.
Code:
To indicate the reason for errors for message communications or for
message processing. This field is only used in GRMP response messages
or in GRMP ACK message. In other messages, this field is always set
Wang, et. al., Expires May 2004 [Page 8]
Internet Draft GRMP V1 Nov. 2003
to zero. It is mostly used to pass an error code in a failure
response, but it can also be used to give further information in a
success response. See Appendix A for Code value definitions.
Transaction Identifier:
Used for the system to uniquely distinguish individual received
messages. It is usually generated by message senders in an ascend
order. For request messages, the sender may select any transaction
identifier; while for response messages, the transaction identifier
is set to the same value as that of the message it responses to. If a
message is segmented into several sub messages (see below), the
transaction identifiers for all sub segment messages keep the same.
To facilitate the distinguish of messages from CE or from FE, the
transaction identifier generated by CE or by FE is set differently by
limiting that as follows:
first bit = 0 CE generated Transaction Identifier
first bit = 1 FE generated Transaction Identifier
This approach has following advantages:
1. It avoids the probability (though a little) that CE and FE might
generate the same transaction identifiers at the same time, which may
complicate the processing of the messages.
2. In the case a FE fails over and is to restart, CE may check the
FE transaction identifier to gain its knowledge on the information
remained in the FE, to speed the restart process (See Section 4.1.7).
By using different transaction identifier space, CE can also recall
the FE configuration information more easily.
P flag:
Priority flag for this message.
P = 0 the message has normal priority
P = 1 the message has high priority
The priority flag is used for receiver of the message to know if the
message should be processed ahead of other lower priority messages.
C flag:
A flag to decide if or not to use CRC-32 checksum as message
communication error detection.
C = 0 CRC-32 Off. The message has no CRC-32 checksum
C = 1 CRC-32 On. The message has CRC-32 checksum
I flag:
If I is set then the SubMessage Number field (see below) indicates
the total number of SubMessage segments that compose the entire
message. If it is not set then the SubMessage Number field indicates
the sequence number of this SubMessage segment within the whole
message.
SubMessage Number:
Wang, et. al., Expires May 2004 [Page 9]
Internet Draft GRMP V1 Nov. 2003
When a message is segmented because it exceeds the MTU of the link
layer, each segment will include a submessage number to indicate its
position. Alternatively, if it is the first submessage in a sequence
of submessages, the I flag will be set and this field will contain
the total count of submessage segments.
Length:
The length in octets for the whole GRMP message, including the
message header and CRC-32 checksum if any.
2. GRMP Message Body
Every GRMP message body should begin with a CE identifier and an FE
identifier, indicating the CE and the FE the message communicates.
Therefore, the GRMP message body has following uniform data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Identifier | FE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CE Identifier:
The CE identifier the GRMP message communicates with. An CE
identifier is assigned by CE manager during ForCES pre-association
phase. Two CE identifiers are reserved for special purposes as
follows:
0x0000 Reserved
0xffff Reserved for possible broadcasting operations in the
future.
FE Identifier:
The FE identifier the GRMP message communicates with. An FE
identifier is assigned by FE manager during ForCES pre-association
phase. Two FE identifier is reserved for special purposes as follows:
0x0000 Reserved
0xffff Representing all existing FEs in a NE. It can be used
for message broadcasting.
Message Body:
In this document, the Message Body specifically denotes the part of
GRMP message body that excludes the CE and FE identifier fields. Note
that the message body can possibly be empty for some messages such as
GRMP ACK message. Also note that every message body has its own
responsibility to be 32bits aligned. Pads of zero may be used by
messages if necessary.
Wang, et. al., Expires May 2004 [Page 10]
Internet Draft GRMP V1 Nov. 2003
3. CRC-32 Checksum
This is an optional part in GRMP message. It is the CRC-32 checksum
of data including GRMP message header and GRMP message body. It can
be turned on or off by setting the C flag in the message header.
3.3. GRMP Message Encapsulation
GRMP packets may be transported via any suitable medium. Packet
encapsulations defined for GSMP protocols as in RFC 3293 [11] can
also be applied to GRMP.
When the CEs and FEs are separated beyond a single hop, GRMP
RECOMMENDS using an RFC2914 compliant L4 protocol with adequate
reliability, security and congestion control (e.g. TCP, SCTP) for
transport purposes.
To support the CE broadcasting messages, the GRMP encapsulation
needs to map the FE broadcast identifier (that is 0xffff) into
specific broadcast protocols or methods in the transport layer.
Depending on the different transport layers GRMP broadcasting
messages may be mapped into that like IP broadcasting, Ethernet
broadcasting, bus broadcasting, or even just the method to duplicate
and distribute the message to individual FEs. (To be finished).
By using CRC-32 and GRMP ACK message (defined below), GRMP is
supplied with a built-in protocol error control mechanism. When GRMP
message is encapsulated in a medium that does not supply sufficient
error control mechanism, the GRMP built-in error control mechanism
can be applied. Note that even in the case the GRMP built-in error
control needs to be applied, it is still RECOMMENDED not to use
error-control when GRMP messages are packet redirection messages (see
Section 4.7), so as to gain efficiency for CE and FE communications
and lower the fail over probability from DoS attacks. Because GRMP
built-in error control mechanism is specific to individual messages,
to turn it on or off for individual messages is possible in GRMP.
3.4. Common Data Format in GRMP Messages
3.4.1. ACK Message Data Format
Section 3.2 on the Result field has described in which case a GRMP
ACK message should be generated and sent as a response to message
senders.
A GRMP ACK message has following data 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| SubVer| Message Type | Result| Code |
Wang, et. al., Expires May 2004 [Page 11]
Internet Draft GRMP V1 Nov. 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C|I| Reserved| SubMeg Num | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Identifier | FE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 Checksum(Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the fields above keep the same as the message that requires the
ACK message except following field:
Message Type:
ACK message has the message type with value 0.
Result:
ACK message has one of following Result values:
Value Description
9(Success) Default value, indicating the message
has been received and processed
successfully.
15(Failure) Indicating a failure in receiving or
processing the message.
Others Reserved
Code:
The meaning is the same as the Code field defined in GRMP message
header.
C flag:
Choose to use CRC-checksum or not.
CRC-32 checksum:
Can be optionally turn on or off via the C flag.
Length:
The length of whole ACK message, in octets.
FE Identifier:
In most cases, the field is the same as the message to acknowledge.
When in the case the acknowledged message is a broadcast message, the
field will be filled with the specific FE identifier that sends the
ACK message.
3.4.2. TLV Data Format
A Type-Length-Value (TLV) is expressed in GRMP using following data
format:
Wang, et. al., Expires May 2004 [Page 12]
Internet Draft GRMP V1 Nov. 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the length is the length for the whole TLV data format
expressed in octets. The Value field can possibly be empty. In this
case, the length should be 4 (octets).
3.4.3. List Data Format
Several same type of elements can be represented by an element list.
In GRMP, a list is described in following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Type | Number of Elements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ First Element ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Last Element ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Element Type:
Value Description
0 Default value, the element type does not have to be
explicitly defined, instead it should be assigned by the
context of the protocol message where the list is.
Others Reserved, all undefined values will be interpreted as the
default value
Number of Elements:
Number of elements followed in this list. Note that in order to keep
the consistency of protocol data format, the number is allowed to be
zero. In this case, there is no element followed.
First Element, ... Last Element:
The elements listed. Note that the length of an element should be 32
bits aligned. Pad will be added if necessary. Also note that, except
the element length information is included in the element itself, all
elements should keep the same length. Elements that have length
information inside are elements like TLVs, lists, etc.
3.4.4. AE Address Data Format
Addressable Entity (AE) Address has following TLV data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Length |
Wang, et. al., Expires May 2004 [Page 13]
Internet Draft GRMP V1 Nov. 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address of AE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type:
This AE Address type.
Value Description
1 IPv4 address
2 IPv6 address
3 Ethernet MAC address
4 Bus backplane slot address
(to be finished)
Others Reserved
Length:
Length for this whole data format in octets. Every address type
should be responsible for allocation of the exact address length. Pad
may be needed in the address value field.
3.4.5. Object Class and the Data Format
GRMP relies on ForCES FE model to manage most of the objects. GRMP
also has many managed objects that FE model cannot define because it
may be out of FE model scope. GRMP should also support vendor-
specific object management. An Object Class Tag acting as a prefix to
object types is used to distinguish these different classes of
objects in GRMP. The tag is defined as follows:
+-+-+-+-+-+
| ObjClass|
+-+-+-+-+-+
Object Class:
Value Description
0 Objects defined inside GRMP protocol
1 - 15 Objects defined by ForCES FE model, the number
represents the model version.
16 Objects defined by general vendors, that is
vendors that are not in the specific
manufacturer list (see below)
17 - 30 Objects reserved to be defined by some specific
vendors or manufacturers; the number can also
be used as the vendor identifier.
31 Reserved
A complete object identifier can then be formed by using the object
class prefix along with specific object types, as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| Object Type |
Wang, et. al., Expires May 2004 [Page 14]
Internet Draft GRMP V1 Nov. 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that, generally objects defined inside GRMP protocol are the
objects that are essential for the protocol to take actions, and are
out of scope of ForCES FE model. Examples of these managed objects
are that for GRMP slave management such as failover policies, DoS
protection policies, etc.
4. GRMP Messages
4.1.FE Management Messages
4.1.1. FE Join Request Message
This message is sent from an FE that is just mounted or that was
fail over and is restarted and going to rejoin in the NE. Before the
message is sent to a CE by the FE, a process in the FE is needed to
associate the FE to the CE and for the FE to have the following
entities ready:
1. The associated CE identifier;
2. An FE identifier assigned to this FE;
3. The connection status of the FE with other FEs (Optional).
These entities can possibly be acquired by one of the following
methods:
1. The FE goes into pre-association phase again, where an FE manager
manages the process;
2. The FE runs a layer-2 or other discovery protocol at Fr reference
point of ForCES framework [3];
3. Manually setup from FE manager console; This actually also makes
the FE work at pre-association phase;
4. The FE is possibly able to use its history information; This only
applies to an FE that has just failed and is ready to restart.
According to ForCES framework, these processes are out of ForCES
protocol, therefore are not included in this document. But in GRMP
scope, something related to the process, like a FE failover and
rejoin policy, still can be set by a CE to the FE to tell what
methods the FE should take in case it goes failure and wants to
restart. See Section 4.6.5 for details of the policy.
A security exchange process SHOULD be applied to setup a secure
transport connection between CE and FE to authenticate the CEs and
FEs to defend against possible man-in-the-middle or replay attacks if
CEs and FEs are not physically "all-in-one-box" [2]. IPsec [12] and
TLS [13] are security protocols GRMP RECOMMENDS to use for this
security exchange when GRMP protocol is encapsulated in an IP based
medium. ForCES framework has described steps of the security exchange
process when using IPsec or TLS. They are mirrored in GRMP as below:
Wang, et. al., Expires May 2004 [Page 15]
Internet Draft GRMP V1 Nov. 2003
For using TLS with GRMP, security handshake steps can be as:
1) An FE is associated with a CE.
2) The FE establishes a TLS connection with the CE and negotiates a
cipher suite.
3) The FE gets the CE certificate, validates the signature, checks
the expiration date, and checks if the certificate has been revoked.
4) The CE gets the FE certificate and performs the same validation
as the FE in step 3).
5) If any of the check fails in step 3) or step 4), the endpoint
must generate an error message and abort.
6) After successful mutual authentication, a TLS session is
established between CE and FE.
7) The FE sends a FE join request message to the CE.
8) The FE and CE use TLS session for further communication.
For using IPsec with GRMP in the way of manual key management, steps
can be as:
1) During an FE is associated to a CE, SA parameters are also
associated manually.
2) The FE sends a FE join request message to the CE. This message
and all others that follow are afforded security service according to
the manually configured IPsec SA parameters.
For using IPsec with GRMP in the way of automatic key management,
IKE and Kerberos can be used for that purpose. Other automatic key
distribution techniques such as may be used as well. Following steps
constitute the security handshake using IKE with IPsec in GRMP:
1) During an FE is associated with a CE, IPsec policy is also
associated.
2) The FE kicks off IKE process and tries to establish an IPsec SA
with the CE. The FE gets the CE certificate as part of the IKE
negotiation. The FE validates signature, checks the expiration date,
checks if the certificate has been revoked.
3) The CE gets the FE certificate and performs the same check as the
FE in step 2).
4) If any of the check fails in step 2) or step 3), the endpoint
must generate an error message and abort.
5) After successful mutual authentication, IPsec session is
established between the CE and FE.
6) The FE sends a FE join request message to CE.
7) The FE and CE use the IPsec session for further communication.
Note that, if CEs and FEs are physically deployed in "all-in-one-
box", the security process as described above MAY not need to be
applied.
FE join request message has message data format as follows:
Wang, et. al., Expires May 2004 [Page 16]
Internet Draft GRMP V1 Nov. 2003
Message Direction: FE to CE
Message Header:
Message Type = 16
Result = [ NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason:
Value Description
0 Reason unavailable
1 Rejoin, because it was failover and is restarted
2 Rejoin, because it has left
Others Reserved
4.1.2. FE Leave Request Message
Message Direction: FE to CE
Message Header:
Message Type = 18
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason:
Value Description
0 Reason unavailable
9 Leave, because Failover
Others Reserved
In order to avoid possible "JOIN" or "LEAVE" flooding attack from an
impersonation FE, the FE join message is not responded and accepted
by a CE immediately when it gets the request message. Instead, the
CE will further verify it via its knowledge or via querying the FE
for more information such as the capabilities. Only when thinking
the FE is qualified, the CE then send a FE action manipulate message
(see Section 4.1.5) to the FE to accept it, or else, CE can send a
FE action manipulate message to reject it, or even to ignore the
request message by no response to it if an impersonation FE has been
considered by the CE.
4.1.3. FE Topology Query and Response Messages
Wang, et. al., Expires May 2004 [Page 17]
Internet Draft GRMP V1 Nov. 2003
CE should maintain the information of whole FE topology in a NE so
that it can configure FEs from the NE scope to implement specific IP
services. One way for CE to obtain the FE topology is by the CE
sending FE topology query messages to individual FEs to collect the
information. CE may also achieve the FE topology via means other than
the ForCES protocol means.
1. FE Topology Query Message
This message is sent from a CE to a FE to query the FE topology
information of this FE.
FE topology query message has following format:
Message Direction: CE to FE
Message Header:
Message Type = 20
Result = [Don't care], meaning this message will always be
responsed either by FE topology response message
when succeed, or by a GRMP ACK message when
failed or erred.
Message Body:
The message body for this message is empty.
2. FE Topology Response Message
This is a message for an FE to response the FE topology query
message.
Message Direction: FE to CE
Message Header:
Message Type = 21
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of FE Connections ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FE Connection:
It is the element of the list of FE connections, and describes the
interconnection state of the FE to other FEs. It is composed of
another list as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of Connected FEs with their Ports ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et. al., Expires May 2004 [Page 18]
Internet Draft GRMP V1 Nov. 2003
A connected FE with its port is expressed as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connected FE Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Connected FE Port Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FE Port Address is a physical port address that is expressed in
AE Address TLV data format as defined in Section 3.4.4.
As a result, an FE connection is described by a list of connected FE
ports. This implies that an FE connection can be linked to more than
one other FEs. For example, a bus backplane connection of FEs can be
treated as a connection that has connected all FEs mounted in the
backplane together.
4.1.4. FE Capability Query and Response Messages
CE is always interested in knowing capabilities of FEs so that it
can deploy FE resources properly. CE knows capabilities of an FE by
sending FE capability query messages to the FE. The FE replies to the
query by sending FE capability response messages back to the CE.
Note that capability representation is quite complex and differs
from different vendors. GRMP supports different capability
representations by defining capability as objects, and these objects
can then be defined inside GRMP, by ForCES model, or by vendors, as
described in Section 3.4.5.
1. FE Capability Query Message
Message Direction: CE to FE
Message Header:
Message Type = 22
Result = [Don't Care]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | FE Capability Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The Queried FE Capability type
Value Description
0 All FE Capability that the FE initially has. In this
case, the followed FE capability tag field is empty.
1 All FE Capability that the FE currently has. It
excludes all resources that have been used. In this
case, the followed list is also empty.
Wang, et. al., Expires May 2004 [Page 19]
Internet Draft GRMP V1 Nov. 2003
2 FE capability specified by the followed capability tag
Others
Reserved
FE Capability Tag:
FE Capability Tag has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| FE Capability Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class
The same as defined in Section 3.4.5.
FE Capability Type:
The capability type defined by different class.
Current version of GRMP defines following capability types:
Object Class = 0 (GRMP class)
FE Capability Type Description
0x001 FE Supported GRMP Version
0x002 FE Supported object classes
0x003 FE Memory Space
Others Reserved
2. FE Capability Response Message
Message Direction: FE to CE
Message Header:
Message Type = 23
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FE Capability TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The same as that defined in FE Capability Query Message.
FE Capability TLV:
The TLV Type field is FE capability tag that is defined as above. The
TLV value field is FE capability description. If capability types
belong to the object classes defined in ForCES FE model or vendors,
the capability description should follow the definitions there.
FE capability descriptions for GRMP defined capability types (see
above) are as follows:
Wang, et. al., Expires May 2004 [Page 20]
Internet Draft GRMP V1 Nov. 2003
1. For FE Supported GRMP Version
This capability tells CE about current supported GRMP versions in
the FE. The format is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of GRMP Versions ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRMP version:
As an element of the list, it has the format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| SubVer| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. For FE Supported Object Classes
This capability description tells CE about current supported object
classes in the FE. It is told by sending CE the supported object
class IDs that is defined in Section 3.4.5.
This capability description has following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of Supported Object Class IDs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class ID:
As an element of the list, it has the format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of Object Class is defined in Section 3.4.5. Note that
the ForCES FE model version information is also included in the
object class field.
3. FE Memory Space
FE memory space capability description has following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total FE Memory Space |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Available FE Memory Space |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The memory space is expressed in bytes.
Wang, et. al., Expires May 2004 [Page 21]
Internet Draft GRMP V1 Nov. 2003
4.1.5. FE Action Manipulate Message
This message is sent from a CE to an FE. Currently defined actions
for an FE are as follows:
FE Add:
To add an FE into the NE is to accept the FE and let it up.
Therefore, this message can also act as a response of approval to FE
join request message sent by the FE.
FE Delete:
To delete an FE from the NE is to remove the FE from the NE and to
let the FE down. This is actually to take the FE out of the NE,
therefore this message can also act as a response of approval to FE
leave request message sent by the FE. Note that an FE can actually
leave an NE without CE approval or even without notifying the CE via
sending the FE leave request message. In this case, CE will take it
as an abnormal FE failover events.
FE join reject:
To reject an FE to join is to reject the request sent by an FE join
request message. This is a response to the FE join request message.
FE Up:
To command the FE into up state and let it ready for further
functioning.
FE Down:
To command the FE into down state. When the FE goes into the down
state, all configured information may be lost.
FE Active:
To command the FE into active state. This is only used after an FE
has been set to inactive state.
FE Inactive:
To command the FE into inactive state. In this state, the FE will
stop taking any forwarding functions, but the configured information
is still maintained.
Message Direction: CE to one FE or (broadcast) to all FEs in an NE
Message Header:
Message Type = 24
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et. al., Expires May 2004 [Page 22]
Internet Draft GRMP V1 Nov. 2003
Type:
Value Description
1 FE Add.
2 FE Delete.
3 FE Join reject
9 FE Up
10 FE Down
11 FE Active
12 FE Inactive
Others Reserved
4.1.6. FE Attribute Manipulate Message
This message is used to manipulate FE attributes such as to add,
delete, and modify FE attributes.
FE attributes concern FE layer operations such as DoS protection
policy, CE failover policy, etc. In GRMP, FE attributes allow to be
defined by different object classes such as GRMP class, ForCES FE
model class, and vendor class. Note that some FE attributes like
statistics attributes can not be manipulated, instead can only be
queired.
Message Direction: CE to FE
Message Header:
Message Type = 26
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
For FE attribute add and delete operations, FE attribute operations
has following message body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FE Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For FE attribute modify operations, FE attribute operations has
message body as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FE Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Old FE Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et. al., Expires May 2004 [Page 23]
Internet Draft GRMP V1 Nov. 2003
Type:
Value Description
1 FE Attribute Add
2 FE Attribute Delete
3 FE Attribute Modify
Others Reserved
FE Attribute TLV:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FE Attribute Tag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FE Attribute Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FE Attribute Tag has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| FE Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class:
The same as defined in Section 3.4.5.
FE Attribute Type:
Defined by different object class.
FE Attribute Value:
If attribute types belong to that defined in ForCES FE model or by
vendors, the value format should follow the definitions there.
Old FE Attribute TLV:
This TLV indicates the old value of the FE attribute to be modified.
By telling the old value, modification can be properly made when a FE
attribute has more than one value instance. We define that if the
value part of the TLV is empty, it means the attribute only has one
value and there is no need to tell the old value to modify it.
An attribute in an FE may be associated with many value instances.
In order to correctly manipulate these kinds of FE attributes, we
define following rules:
1. For an FE attribute add message, if there is no attribute value
followed in the attribute TLV, it is to add a new attribute. If there
is a value followed, it is to add a new value instance to the
attribute. If the attribute does not exist, it will first create the
attribute and then to add the value.
2. For an FE attribute delete message, if there is no attribute
value associated with the attribute TLV in the message, it is to
delete the attribute totally from the FE, all values associated with
the attribute will then be deleted. If we only want to delete a value
Wang, et. al., Expires May 2004 [Page 24]
Internet Draft GRMP V1 Nov. 2003
instance from the attribute, the specific value should be assigned in
the attribute TLV.
3. For an FE attribute modify message, to modify an FE attribute is
usually to change the attribute value. Modification is performed by
first deleting the old attribute value instance and then adding a new
value instance. Therefore, attribute modify operation usually needs
to have the value assigned. The only exception is that the attribute
only has one value instance. In this case, the old attribute value
does not have to be assigned.
Current version of GRMP defines following FE attribute types that can
be manipulated by this message:
Object Class = 0 (GRMP class)
FE Attribute Type Description
0x001 DoS protection policy
0x002 DoS attack alert policy
0x003 CE failover or leave policy
0x004 FE failover and rejoin policy
0x005 FE heartbeat policy
0x006 GRMP protocol version assignment
(All these GRMP defined FE attributes are for GRMP slave management.
Section 4.6 specifically describes the values and the functions of
these attributes.)
0x010 Subscribe/Unsubscribe for FE event report
Others Reserved
The FE Attribute for FE to subscribe/unsubscribe an FE event report
has following value data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | FE Event Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action:
0 Unsubscribe for an FE event report
1 Subscribe for an FE event report
Others Reserved
FE Event Tag:
The FE event report tag. Note that some FE event reports will always
be active, while others need to be subscribed before they can send
reports to CE. See Section 4.1.8 for detailed definition for
individual FE event reports.
4.1.7. FE Attribute Query and Response Messages
FE attribute query message is sent from a CE to an FE to query the
FE attribute values. The FE replies to this message with an FE
Wang, et. al., Expires May 2004 [Page 25]
Internet Draft GRMP V1 Nov. 2003
attribute response message. All defined FE attributes should be able
to be queried. These attributes include FE statistics. FE attributes
on statistics can only be queried and cannot be manipulated.
1. FE Attribute Query Message
Message Direction: CE to FE
Message Header:
Message Type = 28
Result = [Don't Care]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FE Attribute Tag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the FE Attribute Tag is the same as defined in Section 4.1.6.
2. FE Attribute Response Message
Message Direction: FE to CE
Message Header:
Message Type = 29
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FE Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FE Attribute TLV has the same data format as defined in Section 4.1.6.
Apart from GRMP defined FE attributes described in Section 4.1.6,
which can be manipulated, so can also be queried, GRMP defines
following FE attribute types, which can only be queried:
Object Class = 0 (GRMP class)
FE Attribute Type Description
0x011 Current Transaction Identifier Information
Others Reserved
FE attribute on current transaction identifier information has the
following value format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier of CE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier of FE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et. al., Expires May 2004 [Page 26]
Internet Draft GRMP V1 Nov. 2003
Transaction Identifier of CE is the transaction identifier in the
latest message FE received from CE. It should be generated by the CE.
Transaction Identifier of FE is the transaction identifier that FE
generated for the latest message sent to CE. It should be generated
by the FE.
This attribute is often used when an FE is failover and is been
restarted. In this case, by querying the remained transaction
identifier information in the FE, a CE can gain knowledge of the FE
regarding its status before failover and facilitate the
reconfiguration of the FE.
4.1.8. FE Event Report Message
This message is sent from an FE to a CE asynchronously to report on
just happened events in the FE. These events also include events that
happen in LFBs in the FE. Note that some events will always send
reports to CE when they happen, but others only send reports to CE
when they are subscribed by a CE. An event definition should state if
the event needs subscription or not.
Message Direction: FE to CE
Message Header:
Message Type = 30
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FE Event Tag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FE Event Description ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FE Event Tag has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| FE Event Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class:
The same as defined in Section 3.4.5.
FE Event Type:
Defined by different object class.
FE Event Description:
If FE event types belong to ForCES FE model or vendor class, the
value format should follow the definitions there.
Wang, et. al., Expires May 2004 [Page 27]
Internet Draft GRMP V1 Nov. 2003
Current version of GRMP defines following FE Event types:
Object Class = 0 (GRMP class)
FE Event Type Description
0x001 FE status event
0x002 LFB status event
0x003 FE heartbeat
0x004 FE DoS attack alert
0x005 FE capability change
Others Reserved
1. FE Status Event
This event will always sends a report message to CE if it happens.
It has following event description format in the event TLV:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FE Status Tag | Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FE Status Tag
Value Description
1 FE Up
2 FE Down or Leave
3 FE Active
4 FE Inactive
5 FE failover
Others Reserved
Code:
To further indicate the reason for the event, such as reason for
failover. See Appendix A for detailed value definitions.
2. LFB Status Event
This event report does need subscription by CE. It has following
description format in the event TLV:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Status Tag| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LFB Status Tag
Value Description
1 LFB Up
2 LFB Down
3 LFB Active
4 LFB Inactive
Wang, et. al., Expires May 2004 [Page 28]
Internet Draft GRMP V1 Nov. 2003
5 LFB failover
Others Reserved
Code:
To further indicate the reason for the event, such as reason for
failover. See Appendix A for detailed value definitions.
LFB Tag:
To indicate the type of the LFB, see Section 4.2.1 for the detailed
definition.
LFB Instance ID:
The instance identifier for this LFB.
3. FE Heartbeat
This event report does not need subscription by CE, whether to
enable the event report is decided by the FE heartbeat policy defined
in Section 4.6.6. There is no event description in this event TLV.
Note that for this event report message, the Result field in the
message header is RECOMMENDED to set to "NoAck"(See Section 3.2) in
order to reduce the traffic between FE and CE.
4. FE DoS Alert
This event report does not need subscription by CE, whether to
enable the event report is decided by the FE DoS alert policy defined
in Section 4.6.3. When it has been enabled and the FE has detected a
possible DoS attack in the FE, the event report is sent to the CE.
The event description is a TLV format that describes the possible
information of attackers, as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attacker Information Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Attacker Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Current defined attacker information types are as follows:
Attacker Information Type Description
1 IP header
2 TCP header
3 UDP header
Others Reserved
Attacker information is that like a whole IP header, TCP header, or
UDP header.
5. FE Capability Change
Wang, et. al., Expires May 2004 [Page 29]
Internet Draft GRMP V1 Nov. 2003
This event report does not need subscription by CE. It reports to CE
on the change of FE capabilities. The description in the event TLV is
as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ New FE Capability TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Old FE Capability TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FE capability TLV is the same as defined in Section 4.1.4.
4.2.LFB Management Messages
4.2.1. LFB Action Manipulate Message
This message is sent from a CE to an FE to command the FE to take
actions to LFBs. Defined actions for LFBs are as follows:
LFB Add:
To add an LFB into the FE LFB topology as well as to add some LFB
attributes to the LFB and let the LFB Up.
LFB Delete:
To delete an LFB from the FE LFB topology.
LFB Modify:
Here, to modify an LFB is defined only to modify its connection
state with other LFBs. If the LFB attributes are to be modified, LFB
attribute manipulate message (see Section 4.2.3) should be instead
used.
LFB Up:
To command a LFB that is already in the FE LFB topology to go into
Up state and ready for functioning.
LFB Down:
To command a LFB that is already in the FE LFB topology to go into
Down state. When the LFB is in the down state, all configured
information may be lost.
LFB Active:
To command a LFB that is already in the FE LFB topology to go into
Active state. This is only used after an LFB has been set to inactive
state.
LFB Inactive:
To command a LFB that is already in the FE LFB topology to go into
Inactive state. In this state, the LFB will stop taking any functions,
but the configured information is still maintained.
Wang, et. al., Expires May 2004 [Page 30]
Internet Draft GRMP V1 Nov. 2003
Note that LFB action manipulations highly rely on the FE
capabilities and LFB capabilities. For instance, some LFBs may not be
able to be added, deleted, or modified because they only have static
connection states with other LFBs, while some others may have partial
flexibility to configure their connection state. Depending on the
queried capability information, CE is responsible for proper action
manipulations to LFBs.
FE action manipulation message has following format:
Message Direction: CE to FE
Message Header:
Message Type = 32
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
It has different data format according to the different action types.
For LFB Delete, Up, Down, Active, and Inactive actions, the LFB
action body is as following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For LFB Modify actions, the LFB action body has the format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Single LFB Topology Description ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For LFB Add actions, the LFB action body has the format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |T|A| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Single LFB Topology Description (Optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of LFB Attribute TLVs (Optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Wang, et. al., Expires May 2004 [Page 31]
Internet Draft GRMP V1 Nov. 2003
Value Description
1 LFB Add
2 LFB Delete
3 LFB Modify
9 LFB Up
10 LFB Down
11 LFB Active
12 LFB Inactive
Others Reserved
T Tag:
Only for add action.
Value Description
0 Message does not include the LFB topology description
field
1 Message includes the LFB topology description field
A Tag:
Only for add action.
Value Description
0 Message does not include the LFB attribute list field
1 Message includes the LFB attribute list field
LFB Tag:
An LFB Tag has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| LFB Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class:
The same as defined in Section 3.4.5.
LFB Type:
Defined by different object class.
LFB Instance ID:
The instance identifier of the LFB.
Single LFB Topology Description:
Topology description for this LFB only. It refers to the datapath
connection status of the LFB with other LFBs.
(To be finished)
LFB Attribute TLV:
As an element of the list of LFB Attribute TLVs, this field has the
data format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Attribute Tag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et. al., Expires May 2004 [Page 32]
Internet Draft GRMP V1 Nov. 2003
~ LFB Attribute Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LFB Attribute Tag:
LFB Attribute Tag has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| LFB Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class:
The same as defined in Section 3.4.5. Note that the object class in
an LFB attribute tag does not have to be the same as the object class
in the LFB tag. This means, for instance, even it is the LFB defined
by ForCES FE model, its attributes can still possibly be extendedly
defined by other classes such as vendors.
LFB Attribute Type:
Defined by different object class.
LFB Attribute Value:
If attribute types belong to that defined in ForCES FE model or by
vendors, the value format should follow the definitions there.
4.2.2. LFB Topology Query and Response Messages
A CE sends a LFB topology query message to an FE to query single LFB
topology information of some LFBs in the FE, or the whole FE LFB
topology that includes all LFBs. The FE replies to the message by
sending back an LFB topology response message.
1. LFB Topology Query Message
Message Direction: CE to FE
Message Header:
Message Type = 34
Result = [Don't Care]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of LFBs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The Queried LFB topology type
Value Description
Wang, et. al., Expires May 2004 [Page 33]
Internet Draft GRMP V1 Nov. 2003
0 Whole FE LFB topology, that comprises all LFBs in the
topology in the FE. In this case, the followed list
field is empty.
1 Topology about several LFBs that are listed in the
followed LFB list.
Others Reserved
An LFB in the List of LFBs is expressed as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LFB Tag is the same as defined in Section 4.2.1.
2. LFB Topology Response Message
Message Direction: FE to CE
Message Header:
Message Type = 35
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of LFB Topology Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The queried LFB topology type, the same as that in the LFB topology
query message above.
List of LFB Topology Information:
Element of the List has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Single LFB Topology Description ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Single LFB Topology Description:
The same as that defined in Section 4.2.1.
4.2.3. LFB Attribute Manipulate Message
This message is used to manipulate LFB attributes such as to add,
delete, or modify LFB attributes.
Wang, et. al., Expires May 2004 [Page 34]
Internet Draft GRMP V1 Nov. 2003
LFB attributes include all attributes concerning LFB layer
operations such as LFB parameters, rules, etc. In GRMP, LFB
attributes allow to be defined by GRMP class, ForCES FE model class,
and vendor class, as described in Section 4.2.1. The manipulated LFB
attributes do not include the attributes that cannot be added, or
changed, like LFB statistics attributes, LFB capabilities, etc.
LFB attribute manipulate message has following format:
Message Direction: CE to FE
Message Header:
Message Type = 36
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of LFB Attribute Operations ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LFB Tag and LFB Instance ID:
The operated LFB tag and its instance identifier. LFB tag format is
same as defined in Section 4.2.1.
The element of the list of LFB attribute operations has different
data format according to different operations, as:
For LFB attribute add and delete operation, Element of the list has
following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(Add,Del) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ LFB Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For LFB attribute modify operation, Element of the list the data
format is as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(Modify) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ LFB Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Old LFB Attribute TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Value Description
Wang, et. al., Expires May 2004 [Page 35]
Internet Draft GRMP V1 Nov. 2003
1 LFB Attribute Add
2 LFB Attribute Delete
3 LFB Attribute Modify
Others Reserved
LFB Attribute TLV:
It has the same definition as in Section 4.2.1.
Old LFB Attribute TLV:
It has the same data format as LFB attribute TLV. This TLV indicates
the old value of the LFB attribute. By telling the old value,
modification can be properly made when a LFB attribute has more than
one value instance. We define that if the value part of the old TLV
is empty, it means the attribute only has one value instance and
there is no need to tell the old value to modify it.
An attribute in an LFB may be associated with many value instances.
For example, a routing table attribute for a packet forwarder LFB
usually has many routing rules as its attribute values. In order to
correctly manipulate these kinds of LFB attributes, we define
following operation rules:
1. For an LFB attribute add operation, if there is no attribute
value followed in the attribute TLV, it means to add a new attribute
to the LFB. If there is a value in the TLV, it means to add the value
as a new instance to the attribute. If the attribute did not exist,
the operation will first create the attribute and then add the value
to it.
2. For an LFB attribute delete operation, if there is no attribute
value assigned in the attribute TLV in the message, it means to
delete the attribute totally from the LFB, all values associated with
the attribute will also be deleted. If we only want to delete some
value instance from the attribute, the specific value should be
explicitly assigned in the attribute TLV.
3. For an LFB attribute modify operation, to modify an LFB attribute
is usually to change the attribute value. Modification is performed
by first deleting the old attribute value instance and then adding a
new value instance. Therefore, attribute modify operation usually
needs to have the old value assigned. The only exception is that the
attribute only has one value instance. In this case, there is no need
to tell the old value.
4.2.4. LFB Attribute Query and Response Messages
LFB attribute query message is sent from a CE to an FE to query the
LFB attribute values. The LFB replies to this message with an LFB
attribute response message. All LFB attributes defined should be able
to be queried. Note that LFB attributes include LFB capabilities and
LFB statistics.
Wang, et. al., Expires May 2004 [Page 36]
Internet Draft GRMP V1 Nov. 2003
1. LFB Attribute Query Message
Message Direction: CE to FE
Message Header:
Message Type = 38
Result = [Don't Care]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of LFB Attribute Tags ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Element of list of LFB attribute tags has data format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Attribute Tag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LFB Attribute Tag is the same as defined in Section 4.2.1.
2. LFB Attribute Response Message
Message Direction: FE to CE
Message Header:
Message Type = 39
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Tag | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of LFB Attribute TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As an element of the list above, LFB Attribute TLV is the same as
defined in Section 4.2.1.
4.3.Datapath Management Messages
GRMP datapath management messages are used to manage datapaths in an
FE LFB topology. Datapaths connect LFBs together. By using datapath
management messages, GRMP protocol is able to configure, modify, or
query the LFB topology. LFB action manipulate message in Section
4.2.1 and LFB topology query and response messages in Section 4.2.2
also can manage LFB topology. The difference between the two kinds of
topology management is that datapath management manages the LFB
Wang, et. al., Expires May 2004 [Page 37]
Internet Draft GRMP V1 Nov. 2003
topology from the perspective of datapaths, while LFB management
messages manage the LFB topology from the perspective of LFBs. To
interactively use these two approaches may make LFB topology
management more simple and precise.
Note that datapath management in a LFB topology highly relies on the
FE and LFB capabilities. For instance, datapaths from some LFBs may
not allow to be changed because of their static connection states
with other LFBs, while other LFBs may only have partial flexibility
to configure their connection state. Depending on the queried
capability information, ForCES protocol application layer is
responsible for proper datapath manipulations in a LFB topology.
4.3.1. Datapath Manipulate Message
Currently defined datapath manipulating operations are datapath add,
delete, and modify operations.
Message Direction: CE to FE
Message Header:
Message Type = 48
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Datapath Description ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Value Description
1 Datapath Add
2 Datapath Delete
3 Datapath Modify
Others Reserved
Datapath Description:
Description of the datapath regarding its interconnection state with
LFBs.
(To be finished)
4.3.2. Datapath Query and Response Messages
The datapath query message is sent from CE to FE to query connection
status of some datapaths, or all datapaths in a LFB topology. To
query all datapath connection status is exactly to query the FE LFB
topology.
1. Datapath Query Message
Wang, et. al., Expires May 2004 [Page 38]
Internet Draft GRMP V1 Nov. 2003
Message Direction: CE to FE
Message Header:
Message Type = 50
Result = [Don't Care]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of Datapath Identifiers ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Value Description
1 query status of some datapaths.
2 query status of all datapaths(LFB topology
query). In this case, there is no followed
Datapath Identifiers.
Others Reserved
Datapath Identifier:
An Identifier to identify the datapaths.
(To be finished)
2. Datapath Query Response Message
Message Direction: FE to CE
Message Header:
Message Type = 51
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
To response the Datapath query on SomeDpath, AllDpath, or ErrDpath,
the message body has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of Datapath Descriptions ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The same as in the query message.
Datapath Description:
As an element of the list, this is the same as defined in Section
4.3.1.
Wang, et. al., Expires May 2004 [Page 39]
Internet Draft GRMP V1 Nov. 2003
4.4. CE Informing Messages
In the ForCES architecture, CE is mainly controlled by ForCES
protocol application layer. As a slave, FE only has right to request
CE for some information. CE itself may send some information as its
event reports to FE. CE Informing messages manage these operations.
4.4.1. CE Query request and Response Messages
An FE may need to query a CE for some information. The query may be
invoked at the FE side via a state change in the FE, a console
command, or via other means. In this case, the CE will decide by
itself if a response is sent back or not. FE may also send other
requests such as join or leave request to CE, which is especially
addressed in Section 4.1.1.
CE information queried by FE is represented by CE attributes with
their values.
1. CE Query Request Message
Message Direction: FE to CE
Message Header:
Message Type = 64
Result = [ NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Attribute Tag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CE Attribute Tag has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| CE Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class:
The same as defined in Section 3.4.5. Note that the ForCES FE model
does not define CE attributes, therefore object classes apply to CE
attributes are only GRMP class and vendor class.
CE Attribute Type:
Defined by different object class.
2. CE Query Response Message
Message Direction: CE to FE
Message Header:
Wang, et. al., Expires May 2004 [Page 40]
Internet Draft GRMP V1 Nov. 2003
Message Type = 65
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Attribute Tag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CE Attribute Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CE Attribute Tag is the same as that defined in the above CE query
request message.
CE Attribute Value:
If CE Attribute types belong to that defined by vendors, then the
value format should follow the definitions there.
For current GRMP class, defined CE attribute types and values that
can be queried are as follows:
Object Class = 0 (GRMP class)
CE Attribute Type Description
(To be finished)
4.4.2. CE Event Report Message
In some cases, CE would like to send some information to one FE or
to all FEs in the NE to report some events happened in the CE. The CE
event report message is used for CE to make the reports. Note that,
different form FE event report message, CE events do not have to be
subscribed by FE, CE itself will decide whether to send them.
Message Direction: CE to FE
Message Header:
Message Type = 66
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
FE Identifier = [ one FE Identifier | 0xffff] (when it is
0xffff, this message is a broadcast
message to all FEs.)
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Event Tag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CE Event Description ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CE Event Tag has following format:
Wang, et. al., Expires May 2004 [Page 41]
Internet Draft GRMP V1 Nov. 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ObjClass| CE Event Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Class
The same as defined in Section 4.4.1.
CE Event Type:
Defined by different object class.
CE Event Value
If FE event types belong to that defined in vendors, the value
format should follow the definitions there.
Current version of GRMP defines following CE Event types:
Object Class = 0 (GRMP class)
CE Event Type Description
0x001 CE status event
0x002 CE heartbeat
Others Reserved
1. CE status Event
When this event happens, the CE event report message will be sent to
a FE or all FEs to report its working status. The event has following
event description format in the above CE event TLV:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CE Status Tag | Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CE Status Tag
Value Description
1 CE Up
2 CE Down or Leave
3 CE Active
9 CE Inactive
10 CE failover
Others Reserved
Code:
To further indicate the reason for the event, such as reason for
failover. See Appendix A for detailed value definitions.
2. CE Heartbeat
This event report message is sent to an FE or all FEs as a heartbeat
signal from the CE. The event has no event description in the CE
event TLV. Note that for this event report message, the Result field
in the message header is RECOMMONDED to set to "NoAck" in order to
Wang, et. al., Expires May 2004 [Page 42]
Internet Draft GRMP V1 Nov. 2003
reduce the traffic between FE and CE. Also note that an FE can be set
by a CE via setting FE heartbeat policy (See Section 4.6.6) not to
care about CE heartbeat signal. This means CE has the right not to
use the CE heartbeat mechanism for CE failover detection. In this
case, the CE does not need to send any CE heartbeat to the FE.
4.5.Managed Object (MO) Management Messages
ForCES protocol should support network management tools like SNMP in
the way that:
1. The ability for a management tool (e.g. SNMP) to be used to read
(but not change) the state of FE SHOULD NOT be precluded.
2. It MUST NOT be possible for management tools (e.g. SNMP, etc) to
change the state of a FE in a manner that affects overall NE behavior
without the CE being notified.
GRMP defines Managed Object(MO) management messages to support
network management tools in above way. A MO is an object defined by
some network management tool, such as the object defined by Object
Identifier in SNMP MIBs. MO management messages work in the way as
follows:
1. Query of MOs resident in an FE can be directly implemented by
network management tools.
2. Change of MOs resident in an FE can only be made via a CE. To do
this, the high touch LFBs in the FE will redirect all network
management protocol messages like SNMP messages concerning MO changes
to the CE, then the CE will use the MO management messages described
in this section to change values of MOs in the FE. Of course, if
necessary, query of the MOs can also be made via the CE.
3. MOs resident in a CE can be directly queried or changed by the CE
with CE high touch capability. Before the CE can do this, network
management messages still need to be redirected from FEs to the CE.
A MO is defined in GRMP as having the data format as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO value TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A MO Identifier is defined as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MO Class | Reserved | Length of MO Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO Type ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MO Class:
Wang, et. al., Expires May 2004 [Page 43]
Internet Draft GRMP V1 Nov. 2003
Currently defined MO Classes are:
Value Description
0x00 - 0x1f Reserved
0x21 - 0x2f for SNMP MIB defined MOs, the last 4 bits
represents the SNMP version number
Others Reserved
MO Type:
The managed object type. In SNMP, it is represented by an Object
Identifier [9].
A MO value TLV has the following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MO Value Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MO value type and MO value should follow the definitions where
the MO type is defined.
4.5.1. MO Get Message
This message is sent from a CE to an FE to get the values of some
MOs. A MO response message to the CE is required from the FE.
Message Direction: CE to FE
Message Header:
Message Type = 80
Result = [Don't Care]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A MO identifier is defined as before.
4.5.2. MO Set Message
This message is sent from a CE to an EE to set values of some MOs.
Note that the MO set message also requires a MO response message
from the FE.
Message Direction: CE to FE
Message Header:
Message Type = 82
Result = [Don't Care]
Wang, et. al., Expires May 2004 [Page 44]
Internet Draft GRMP V1 Nov. 2003
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO value TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MO identifier and MO value TLV are defined as before.
4.5.3. MO Response Message
This message is sent from an FE to a CE to response for MO get
message or MO set message.
Message Direction: FE to CE
Message Header:
Message Type = 81
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MO value TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MO identifier and MO value are the same as defined before.
4.6.GRMP Slave Management
4.6.1. GRMP Slave Model
A GRMP slave is defined in GRMP as a functional module inside an FE,
which is used to generate, receive, interpret and process all GRMP
messages. A GRMP slave should work under the control of CE and
according to the information in the FE. A GRMP Slave module is
connected to CE via a link connection. The connection is established
during ForCES pre-association phase. GRMP slave module is constructed
when GRMP protocol is launched in a FE and before it sends first
message to a CE. As a result, GRMP slave module does not belong to
ForCES FE model so cannot be defined in the model, though the module
may be connected via a datapath to some LFBs in FE model to perform
functions like packet redirections. Therefore, GRMP slave should be
defined and managed by GRMP protocol directly.
GRMP protocol models the GRMP slave as in Figure 1.
To GRMP Master From GRMP Master
A |
Wang, et. al., Expires May 2004 [Page 45]
Internet Draft GRMP V1 Nov. 2003
CE | |
- - - - - - - | - - - - - - - - | - - - - - -
- - - - - - - | - - - - - - - - | - - - - - -
FE - - - - - |- - - - - - - - V- - - - -
| +-------------+ +-------------------+ |
GRMP | Scheduler |<---+ |Message Interpreter|
Slave +-------------+ | +-------------------+ |
Module Data ^ ^ Control +---+ ^ | || |
| Channel| | Channel | | | | |
+----+ +-----+ +---|-+ | || |
| | | V | V | |
+-----------+ +------------+ | +----------+|| |
||Redirection| |Ctrl.& Other| +-|GRMP Slave| | |
|Msg. Gen. | |Msg. Gen. | |Policy ||| |
|+-----------+ +------------+ +----------+ | |
- - -A - - - -/\ - - - - - - - || | -
| || |
- - -| - - - - || - - - - - - - || |- -
ForCES | \/ \/ |
FE Model | V
Packets from LFB Packets to LFB
Figure 1. GRMP Slave Model
In this model, all messages sending to CE are put into two different
channels: the data channel, which is only for packet redirection
messages; the control channel, which is for other GRMP messages.
Messages on the two channels use one link connection to a CE via a
scheduler. The scheduler should be managed by CE by setting some
scheduling policies to it. This policy can be set either at the
scheduler starting time or on the fly during its runtime. In this way,
the CE can control the traffic over the two message transmission
channels dynamically, providing a means to that as DoS attack
protection. GRMP slave also accepts other policies sent by CE, such
as FE or CE failover policies, heartbeat policy, etc.
Note that there is also a GRMP master module on CE side. This module
is usually managed by the protocol application layer and is out of
scope of ForCES protocol.
All GRMP slave policies and attributes are managed in the way as FE
attributes (that belongs to GRMP object class). CE can add, delete,
or modify these policies via FE attribute manipulate message (Section
4.1.6); CE can also query the policy status via FE attribute query
message (Section 4.1.7). The definitions for these FE attribute types
have been presented in Section 4.1.6. Followed sections describe the
value formats for these attributes.
4.6.2. DoS Protection Policy
Wang, et. al., Expires May 2004 [Page 46]
Internet Draft GRMP V1 Nov. 2003
As described above, DoS protection policy setup is performed by
setting the scheduler policies in the GRMP slave. This is to protect
DoS attacks coming from FE Fi/f reference points in the ForCES
framework [3]. By dynamically setting the scheduler policy, CE can
control the communication channels so as not to be affected by
attackers. CE can also setup some other operations such as dropping
or blocking of some kind of packets that are considered from
attackers by configuring some high touch LFBs in the FE. For instance,
a high touch filter LFB may be used to filter doubted packets so that
they are not redirected to CE. GRMP also set an FE DoS attack alert
mechanism in GRMP slave module for DoS attack protection (See next
section).
Following Section 4.1.6 on FE attribute TLV format, the attribute
Value for DoS Protection Policy has the data format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| CCP | Reserved | BW Lower Limit| BW Upper Limit|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| DCP | Reserved | BW Lower Limit| BW Upper Limit|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C, D Tag:
Control channel, Data channel priority
0 - Normal priority
1 - High Priority
Note that the function of the priority here is different from that
of the priority flag in GRMP message headers. This priority is only
for the message transmission priority between CE and FE, while the
priority in message header is for CE or FE to process the message
when it arrives at CE or FE. Priority in GRMP message header has no
effect on protecting DoS attacks for attackers are also able to set
the priorities.
CCP, DCP:
Control channel, Data channel congestion control policy
000 - No policy
001 - Cache to wait
002 - Drop immediately
Others - Reserved
BW Lower Limit, BW Upper Limit:
Lower Limit and Upper Limit for Control channel and Data channel
Bandwidth. They are represented in the percentage of link capacity
connecting the CE and the FE. The precision is 1 percent. If the
lower limit and upper limit are set the same, that means the channel
should use this exact bandwidth.
It is RECOMMENDED that a lower limit for control channel bandwidth
be always set to avoid possible complete block of the control channel
before DoS attack protection mechanism can work.
Wang, et. al., Expires May 2004 [Page 47]
Internet Draft GRMP V1 Nov. 2003
We define that if the DoS protection policy is not set by a CE, the
default policy for the scheduler in GRMP slave is set to first-come-
first-served discipline.
4.6.3. DoS Attack Alert Policy
This policy is sent from CE to FE for the FE to decide when FE
should send a DoS attack alert event report to CE (See Section 4.1.8).
FE decides the DoS attack alert state by monitoring the status and
statistics of the scheduler in GRMP slave.
DoS attack alert policy has the following attribute value format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Overload Time Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Policy:
Value Description
0 No policy, FE will not report DoS attack alert
event.
1 Policy based on monitoring the continuous
overload time in the data channel in GRMP slave
model. Here, overload is defined as the status
that data occupy upper limit of allowed
bandwidth in a channel.
Others Reserved
Overload Time Threshold:
Continuous overload time threshold expressed in milliseconds.
4.6.4. CE Failover or Leave Policy
CE failover or leave policy is used by FE when its associated CE has
been detected in failure, when a CE has report its leave event, or
when a FE has detected failure of the connection to CE.
CE failover or leave policy has following attribute value format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy | SP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of Alternative CE Identifiers (Optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Policy:
Value Description
Wang, et. al., Expires May 2004 [Page 48]
Internet Draft GRMP V1 Nov. 2003
0 Graceful restart policy. The FE will
continuously do what it can. If the CE still
has not been restarted or a new CE has not been
found after a time limit, the FE will go down
completely.
1 FE should go down to stop functioning
immediately.
2 FE should go inactive to temporarily stop
functioning. If the CE still has not been
restarted or a new CE has not been found after
a time limit, the FE will go down completely.
Others Reserved
SP:
To indicate how to find a new CE
Value Description
0 Just wait for failed CE to restart. In this
case, there is no list of alternative CEs
followed.
1 Try to find out an alternative CE to substitute
current CE. The followed list of alternative
CEs tells the searchable CEs and the order for
the FE to search for a substitute CE.
Others Reserved.
Time Limit:
The time limit associated with every policy, expressed in
milliseconds. A value of zero represents infinite time limit.
List of Alternative CE Identifiers:
It is only used for the policy that needs to find a substitute CE.
FE will find out the proper substitute CE by trying the CEs in the
list one by one.
The element of the list has format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We define that the order of CEs in the list is the order the FE
should search to find an alternative CE to substitute current
failover one.
4.6.5. FE Failover and Rejoin Policy
This policy is applied to an FE to indicate the FE how it will do in
case it goes failover and is then going to restart to rejoin the NE.
The policy has following value format:
Wang, et. al., Expires May 2004 [Page 49]
Internet Draft GRMP V1 Nov. 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Policy:
Value Description
0 No policy, CE just restart the FE from scratch.
In this case, the FE should go to pre-
association phase again before it can send FE
join request message to a CE.
1 FE should try its best to search the
information before failover to find out
something like the former associated CE
identifier and the FE connection status with
other FEs. If these information can be found,
the FE will not go into pre-association phase,
instead, it will use these information to
establish association with a CE by itself.
After association is established, the FE can
then send FE join request message to the CE.
After CE get the join request, it will use FE
query messages to query the FE remained
information. In this process, query of last
used transaction identifier of the FE (See
Section 4.1.7) is helpful for CE to decide the
FE status before failover. Other queries such
as LFB topology and attribute query are also
helpful.
Others Reserved
4.6.6. FE Heartbeat Policy
The FE heartbeat policy is assigned by a CE to an FE, specifying the
heartbeat generating and receiving policies of the FE. Several CEs
may assign different heartbeat policies to the same FE.
FE heartbeat policy has attribute value format as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SndPlcy|RcvPlcy| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Send Policy:
Policy to send heartbeat to CE.
Value Description
0 Disable heartbeat in the FE
Wang, et. al., Expires May 2004 [Page 50]
Internet Draft GRMP V1 Nov. 2003
1 Enable heartbeat in the FE, the heartbeat
interval should be followed then.
Receive Policy:
Policy to receive heartbeat from CE.
Value Description
0 Do not care about heartbeat signals from the CE,
the CE failover should detected by other means.
1 Care about heartbeat signals from the CE. If the
FE does not receive heartbeat from the CE for a
period designated in the followed time limit
field, the CE failover is considered.
Others Reserved
Time Limit:
The period FE takes to decide the CE failover. If there is no
heartbeat received from the CE for this period long, a CE failover is
considered by the FE. The time limit is expressed in milliseconds.
Heartbeat Interval:
The interval of heartbeats generated by the FE, expressed in
milliseconds.
4.6.7. GRMP Version Assignment
This is to assign the working GRMP version to an FE. Before this
assignment, CE should use an FE capability query message to query the
information on the FE supported GRMP versions (See Section 4.1.4).
GRMP version assignment has the FE attribute value as following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| SubVer| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version, SubVer:
The version and subversion of GRMP protocol the FE should use.
4.7.Packet Redirection Messages
These GRMP messages are used to transfer data packets between a CE
and an FE. These data packets are that from datapaths in FE model, or
that generated by CE and should be put into datapaths in FE model.
Usually these packets are packets related to high-touch operations in
CE, or network control packets need to be generated by CE. Deciding
which should be put to packet redirection is made by related LFB
functions on FE side, or by ForCES protocol application layer on CE
side. By properly configuring LFBs in FE, a packet can be mirrored to
CE instead of purely redirected to CE, i.e., the packet is duplicated
Wang, et. al., Expires May 2004 [Page 51]
Internet Draft GRMP V1 Nov. 2003
and one is redirected to CE and the other continues its way in the
LFB topology.
There are two messages related to packet redirection, one for
packets from CE to FE, the other for packets from FE to CE. They have
quite same data format except with different message types.
Message Direction: CE to FE or FE to CE
Message Header:
Message Type = 84 for CE to FE
= 86 for FE to CE
Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ], it
is RECOMMENDED to use NoAck for transport efficiency.
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Packet Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirected Packet Data:
The whole redirected packet data, including the packet header if any.
4.8.GRMP Batch Messages
GRMP Batch message packs several GRMP message bodies into one single
message. These sub messages should meet following conditions:
1. Are sent from the same CE to the same FE.
2. Do not need explicit message responses.
Such messages include FE or LFB action manipulate messages,
attribute manipulate messages, etc. Usually, a batch message is used
by a CE to send messages to a FE, though GRMP does not exclude the
use of a batch message from FE to CE.
Message Direction: CE to FE or FE to CE
Message Header:
Message Type = 88 for CE to FE, = 90 for FE to CE
Result = [ NoAck | NoSuccessAck | AckAll | SuccessAck ]
Message Body:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ List of GRMP Message Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As an element of the list, a GRMP Message Packet has following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et. al., Expires May 2004 [Page 52]
Internet Draft GRMP V1 Nov. 2003
| Message Type |P| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Body ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type:
Message type of the message packet. It is the same as message types
defined by GRMP individual messages.
P flag:
This message priority flag, defined as in GRMP message header. Note
that priority flag in the batch message header is different from this
one and can still be effective. The batch message header priority
flag refers to the priority to process the whole batch message, while
the priority flags in the individual message packets refer to the
priority to process the individual messages.
Length:
Length of the whole GRMP message packet.
Message Body
The individual single message body. It has the same data format as
general individual GRMP messages.
We define that the order for a receiver to execute the messages in
the batch message follows the order of the messages in the message
packet list. And we define that the error control for a batch message
is provided based on the batch message being treated as a single
message, a sub message can be successfully executed only when all
other sub messages can be successfully executed.
GRMP batch message can be used in many cases to facilitate
operations for CE and FE. For example, the batch message can be used
by ForCES protocol application layer to perform QoS configurations.
According to ForCES framework, QoS parameters will be mapped into
configurations of FE LFBs associated with the topology and the
attribute setup, e.g, a Diffserv PHB configuration may be mapped to
the configuration of LFBs like classifiers, markers, meters, shapers,
queues, and schedulers along with their topology and attributes [14].
By setting these LFBs simultaneously by use of the batch message, a
PHB can be properly deployed on the fly.
5. Security Considerations
The security of GRMP protocol to be transported over TCP/IP has been
addressed in Section 4.1.1, where IPsec and TLS have been RECOMMENDED
to do authentication and to defend against possible man-in-the-middle
or replay attacks. The security to defend DoS attack has been
addressed in Section 4.6. The security to defend FE join and leave
flooding attack is addressed in Section 4.1.2. If GRMP protocol
applies to "all-in-one-box" deployment of CEs and FEs, GRMP MAY rely
Wang, et. al., Expires May 2004 [Page 53]
Internet Draft GRMP V1 Nov. 2003
on the physical security of the box to defend man-in-the-middle
snooping and impersonation attacks to GRMP control channel, and
security mechanisms for this purpose MAY be turned off, though in
this case DoS protection mechanism is still needed.
6. IANA Considerations
Following name spaces are considered:
- GRMP Message Type Name Space
- Code Name Space
- Object Class Name Space
- FE Capability Type Defined by GRMP Class Name Space
- FE Attribute Type Defined by GRMP Class Name Space
- FE Event Type Defined by GRMP Class Name Space
- CE Attribute Type Defined by GRMP Class Name Space
- CE Event Type Defined by GRMP Class Name Space
- Managed Object (MO) Class Name Space
7. References
7.1. Normative References
[1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[2] H. Khosravi, T. Anderson, et. al., "Requirements for Separation
of IP Control and Forwarding", <draft-ietf-forces-requirements-
10.txt>, July 2003.
[3] L. Yang, et. al, "Forwarding and Control Element Separation
(ForCES) Framework", <draft-ietf-forces-framework-10.txt>, Oct. 2003.
[4] A. Doria, et al., "General Switch Management Protocol (GSMP) V3",
RFC 3292, June 2002.
7.2. Informative References
[5] A. Pras, et. al., "On the Difference between Information Models
and Data Models", RFC 3444, Jan. 2003.
[6] L. Yang, et al., "ForCES Forwarding Element Functional Model",
work in progress, <draft-ietf-forces-model-01.txt>, Oct. 2003.
[7] W. Wang, "Topology Representation for ForCES FE Model", work in
progress, <draft-wang-forces-model-topology-00.txt>, Aug. 2003.
[8] W. Wang, "A Control Scheme and Management Protocol for Open
Programmable QoS IP Routers", Proceedings of SCI 2003, July 2003.
Wang, et. al., Expires May 2004 [Page 54]
Internet Draft GRMP V1 Nov. 2003
[9] R. Presuhn, et. al., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", RFC 3418, Dec. 2002.
[10] A. Doria, "GSMPv3 Base Specification", work in progress,
<draft-ietf-gsmp-v3-base-spec-02>, June 2003.
[11] A. Doria, et. al., "General Switch Management Protocol (GSMP)
Packet Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] Dierks, T. and C. Allen, "The TLS Protocol, version 1.0", RFC
2246, January 1999.
[14] Y. Bernet, et. al., "An Informal Management Model for Diffserv
Routers", RFC3290,May 2002.
[15] R, Nait Takourout, "Pre Association Phase Protocol (PAP)", work
in progress, <draft-nait-forces-pap-00.txt>, June 2003.
8. Appendix A Definitions for Code Value
Value Description
0x101 Do not understand the message meaning
0x102 There is an error in the message
0x103 The received message is incomplete
0x103 Can not implement the operation
0x104 Can not implement the operation because of
insufficient resources
0x110 CE an FE disconnected.
0x111 Failover owing to hardware.
0x112 Failover owing to GRMP slave error
0x113 Failover owing to LFB error
(to be finished)
Others Reserved
9. Acknowledgments
The authors would like to thank Avri Doria very much for her help
with information on the integration of GRMP with GSMP and her
invaluable comments on this document. Lei Shi et al. have contributed
to the experiments related to this document.
The research project that the work of GRMP protocol is based on has
been sponsored by NSF(60273061), National 863 Project(2002AA121064),
ZJNSF(RC02063), and SRF for ROCS by SEM, P.R.China.
10. Authors' Addresses
Weiming Wang
Wang, et. al., Expires May 2004 [Page 55]
Internet Draft GRMP V1 Nov. 2003
Department of Information and Electronic Engineering
Hangzhou University of Commerce
149 Jiaogong Road
Hangzhou, 310035, P.R.China
Phone: +86-571-88057712
Email: wangwm@hzcnc.com;
Yunfei Guo
Hi-Tech Research and Development (863) Program of China
1 Sanlihe Road
Beijing, 100044, P.R.China
Phone: +86-10-68338852
Email: gyf@htrdc.com;
Guangming Wang
Hangzhou University of Commerce
149 Jiaogong Road
Hangzhou, 310035, P.R.China
Phone: +86-571-88071024
Email: gmwang@mail.hzic.edu.cn;
Ligang Dong
Hangzhou University of Commerce
149 Jiaogong Road
Hangzhou, 310035, P.R.China
Phone: +86-571-88071024
Email: donglg@mail.hzic.edu.cn;
Wang, et. al., Expires May 2004 [Page 56]