Internet DRAFT - draft-wang-forces-grmp

draft-wang-forces-grmp





   Internet Draft                                          Weiming Wang 
   Expiration: Dec  2004                       Zhejiang Gongshang Univ. 
   File: draft-wang-forces-grmp-02.txt                       Yunfei Guo 
   Working Group: ForCES                                    Hi-Tech R&D 
                                                         Guangming Wang 
                                                            Ligang Dong 
                                               Zhejiang Gongshang Univ. 
                                                              June 2004 
         
         
            General Router Management Protocol (GRMP) Version 1 
                                       
         
                       draft-wang-forces-grmp-02.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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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                         June 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]