Internet Draft                                         Weiming Wang
   Expiration: Dec 2004                        Zhejiang Gongshang Univ.
   File: draft-wang-forces-grmp-00.txt                      Yunfei Guo
   Working Group: ForCES                                   Hi-Tech R&D
                                                        Guangming Wang
                                                           Ligang Dong
                                               Zhejiang Gongshang Univ.
                                                              May 2004


            General Router Management Protocol (GRMP) Version 1


                       draft-wang-forces-grmp-00.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                         May
2004

      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 Dec 2004                 [Page 2]


Internet Draft                 GRMP V1                         May
2004

   10. Authors' Addresses............................................56

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 Dec 2004                 [Page 3]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 4]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 5]


Internet Draft                 GRMP V1                         May
2004


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 Dec 2004                 [Page 6]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 7]


Internet Draft                 GRMP V1                         May
2004

        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 Dec 2004                 [Page 8]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 9]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 10]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 11]


Internet Draft                 GRMP V1                         May
2004

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    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 Dec 2004                 [Page 12]


Internet Draft                 GRMP V1                         May
2004

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              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 Dec 2004                 [Page 13]


Internet Draft                 GRMP V1                         May
2004

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   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 Dec 2004                 [Page 14]


Internet Draft                 GRMP V1                         May
2004

               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 Dec 2004                 [Page 15]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 16]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 17]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 18]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 19]


Internet Draft                 GRMP V1                         May
2004

           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 Dec 2004                 [Page 20]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 21]


Internet Draft                 GRMP V1                         May
2004


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 Dec 2004                 [Page 22]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 23]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 24]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 25]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 26]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 27]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 28]


Internet Draft                 GRMP V1                         May
2004

            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 Dec 2004                 [Page 29]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 30]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 31]


Internet Draft                 GRMP V1                         May
2004

         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 Dec 2004                 [Page 32]


Internet Draft                 GRMP V1                         May
2004

   ~                     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 Dec 2004                 [Page 33]


Internet Draft                 GRMP V1                         May
2004

            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 Dec 2004                 [Page 34]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 35]


Internet Draft                 GRMP V1                         May
2004

           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 Dec 2004                 [Page 36]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 37]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 38]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 39]


Internet Draft                 GRMP V1                         May
2004


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 Dec 2004                 [Page 40]


Internet Draft                 GRMP V1                         May
2004

             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 Dec 2004                 [Page 41]


Internet Draft                 GRMP V1                         May
2004

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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 Dec 2004                 [Page 42]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 43]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 44]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 45]


Internet Draft                 GRMP V1                         May
2004

     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 Dec 2004                 [Page 46]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 47]


Internet Draft                 GRMP V1                         May
2004


   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 Dec 2004                 [Page 48]


Internet Draft                 GRMP V1                         May
2004

          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 Dec 2004                 [Page 49]


Internet Draft                 GRMP V1                         May
2004

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    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 Dec 2004                 [Page 50]


Internet Draft                 GRMP V1                         May
2004

           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 Dec 2004                 [Page 51]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 52]


Internet Draft                 GRMP V1                         May
2004

   |  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 Dec 2004                 [Page 53]


Internet Draft                 GRMP V1                         May
2004

   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 Dec 2004                 [Page 54]


Internet Draft                 GRMP V1                         May
2004

   [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.





Wang, et. al.,                Expires Dec 2004                 [Page 55]


Internet Draft                 GRMP V1                         May
2004

10. Authors' Addresses

   Weiming Wang
   Department of Information and Electronic Engineering
   Zhejiang Gongshang University
   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
   Zhejiang Gongshang University
   149 Jiaogong Road
   Hangzhou, 310035, P.R.China
   Phone: +86-571-88071024
   Email: gmwang@mail.hzic.edu.cn;

   Ligang Dong
   Zhejiang Gongshang University
   149 Jiaogong Road
   Hangzhou, 310035, P.R.China
   Phone: +86-571-88071024
   Email: donglg@mail.hzic.edu.cn;






















Wang, et. al.,                Expires Dec 2004                 [Page 56]