Internet Draft Weiming Wang Expiration: March 2004 Hangzhou Univ. of Commerce File: draft-wang-forces-grmp-00.txt Yunfei Guo Working Group: ForCES Hi-Tech R&D Guangming Wang Hangzhou Univ. of Commerce September 2003 General Router Management Protocol (GRMP) Version 1 draft-wang-forces-grmp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines the General Router Management Protocol (GRMP) Version 1. This protocol is based on an open programmable router architecture defined in the ForCES requirements in RFC xxxx and in the ForCES framework. GRMP protocol is designed to meet all the requirements for the ForCES protocol at Fp reference point in the ForCES architecture, where the ForCES protocol acts as a base protocol and ForCES FE model acts as a data model for this protocol. Table of Contents Abstract...........................................................1 1. Introduction....................................................3 2. Definitions.....................................................4 3. GRMP Protocol Overview..........................................6 3.1. GRMP Message Organizing....................................6 Internet Draft GRMP V1 Sept. 2003 3.2. Message Format.............................................7 3.3. GRMP Message Encapsulation................................11 3.4. Common Data Format in GRMP Messages.......................12 3.4.1. GRMP ACK message data format.........................12 3.4.2. TLV Data Format......................................12 3.4.3. List data format.....................................13 3.4.4. AE Address Data Format...............................14 3.4.5. Object Class and its Data Format.....................14 3.4.6. PkfID Data Format....................................15 4. GRMP Messages..................................................16 4.1. FE Management Messages....................................16 4.1.1. FE Join Request Message..............................16 4.1.2. FE Leave Request Message.............................18 4.1.3. FE Topology Query and Response Messages..............19 4.1.4. FE Capability Query and Response Messages............21 4.1.5. FE Action Manipulate Message.........................25 4.1.6. FE Attribute Manipulate Message......................27 4.1.7. FE Attribute Query and Response Messages.............30 4.1.8. FE Event Report Message..............................31 4.2. LFB Management Messages...................................34 4.2.1. LFB Action Manipulate Message........................34 4.2.2. LFB Topology Query and Response Messages.............39 4.2.3. LFB Attribute Manipulate Message.....................40 4.2.4. LFB Attribute Query and Response Messages............42 4.3. Datapath Management Messages..............................43 4.3.1. Datapath Manipulate Message..........................44 4.3.2. Datapath Query and Response Messages.................46 4.4. CE Informing Messages.....................................48 4.4.1. CE Query request and Response Messages...............48 4.4.2. CE Event Report Message..............................50 4.5. Managed Object (MO) Management Messages...................52 4.5.1. MO Get Message.......................................53 4.5.2. MO Set Message.......................................54 4.5.3. MO Response Message..................................54 4.6. GRMP Slave Management.....................................54 4.6.1. GRMP Slave Model.....................................54 4.6.2. DoS Protection Policy................................56 4.6.3. DoS Attack Alert Policy..............................58 4.6.4. CE Failover or Leave Policy..........................58 4.6.5. FE Failover and Rejoin Policy........................60 4.6.6. FE Heartbeat Policy..................................60 4.6.7. GRMP Version Assignment..............................61 4.7. Packet Redirection Messages...............................61 4.8. GRMP Batch Messages.......................................62 5. Security Considerations........................................64 6. IANA Considerations............................................64 7. References.....................................................65 7.1. Normative References......................................65 7.2. Informative References....................................65 8. Appendix A Definitions for Reason and Code Value..............66 9. Acknowledgments................................................66 Wang, et. al., Expires Mar. 2004 [Page 2] Internet Draft GRMP V1 Sept. 2003 10. Authors' Addresses............................................67 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 one or more Forwarding Elements (FEs) connected into an FE topology. Each FE is modeled with multiple Logical Functional Blocks (LFBs) that are connected into a complex FE LFB topology. A set of protocols used in ForCES to the management and operations of the CEs and FEs. [2] has defined the ForCES architectural requirements and [3] has defined the ForCES framework. General Router Management Protocol (GRMP) Version 1 defined in this document is intend to be as a ForCES protocol, which acts at the Fp reference point in the ForCES framework. 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 act as slaves. Slaves only have right to send to masters request or query, response, and report messages. While masters can send command messages to slaves as well as request or query, response, and 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 while ForCES FE model [6] acts as a data model. That is, GRMP only defines basic management messages, while many of managed data are defined in the associated ForCES FE model. Most of the data types and functional descriptions relating to specific IP services such as routing service conforming to RFC 1812, QoS configurations, high-tough capabilities like NAT and firewall should be expressed by Logical functional Blocks(LFBs) defined by ForCES FE model and their specific LFB topologies. GRMP application layer is responsible to configure the LFBs and the LFB topologies so as to implement specific IP services and QoS deployment. GRMP is developed separately from General Switch Management Protocol (GSMP) protocol [4] [10] since current base specification version of GSMP did not support some of the basic functionality needed by GRMP. 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, GRMP is willing to work with the GSMP group to integrate this with GSMP. Wang, et. al., Expires Mar. 2004 [Page 3] Internet Draft GRMP V1 Sept. 2003 2. Definitions 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 Wang, et. al., Expires Mar. 2004 [Page 4] Internet Draft GRMP V1 Sept. 2003 may use anything from a static configuration to a pre-association 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 by this document 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 Block - See Logical Functional Block (LFB). FE LFB Topology - Representation on how LFBs in an FE are interconnected via datapaths. FE Block Topology - See FE LFB Topology. Wang, et. al., Expires Mar. 2004 [Page 5] Internet Draft GRMP V1 Sept. 2003 Packet Flow Identifier (PkfID) [7][8] - Identifier to mark a datapath in FE model. PkfIDs are composed of PkfSIDs and PkfGIDs(see below). Packet Flow Single Identifier (PkfSID) - A kind of PkfIDs, which is used to identify a single datapath connection in FE LFB topology. Packet Flow Group Identifier (PkfGID) - A kind of PkfIDs, which is used to identify a group of datapaths that usually come from or go to the same LFB in FE model. 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 Object Identifiers defined in SNMP MIBs [9]. 3. GRMP Protocol Overview 3.1. GRMP Message Organizing GRMP protocol is composed of protocol messages. GRMP organizes these messages according to different object types the messages manage in ForCES architecture, as follows: 1. FE management messages This type of messages is for the management of FE layer operation. That is, 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. 2. 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. 3. Datapath management messages This type of messages is for the management of datapaths in an FE. It takes datapathes as the managed objects. 4. CE Informing messages This type of messages takes CE as the operated object, and ask CE to send some informaton. Because CE acts as a master in ForCES protocol, allowed operations to CE from FE are only that like CE query, CE event report, etc. 5. GRMP slave management In GRMP, the GRMP slave part is treated as a module inside an FE. This module is outside of FE model scope. Management to a GRMP slave is that like DoS protection policy, CE or FE failover policy, etc. Wang, et. al., Expires Mar. 2004 [Page 6] Internet Draft GRMP V1 Sept. 2003 But this kind of management does not take specific GRMP messages, in stead, it uses FE management messages. 6. Managed Object(MO) management messages In order to meet ForCES requirement of supporting network management tools like SNMP, GRMP provides the management messages. This type of messages takes a Managed Object (MO) defined in some specific network management tools as its managed objects. Operations of MOs are that like MO get, MO set, and MO response. There is another GRMP message that is defined out of scope of management purposes. This is GRMP ACK(acknowledge) message, which is mainly for communication control and error control purpose between CE and FE. From perspective the message communication types 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. 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. For every type of GRMP managed objects like FEs, LFBs, CEs, GRMP has be designed to allow this GRMP itself, different versions of ForCES FE model, and general vendors, or manufacturer-specific vendors to define the object operations, attributes, and other management. This makes GRMP protocol quite scalable and easy to be compatible with different vendors. 3.2. Message Format All GRMP messages have the following message format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ GRMP Message Header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GRMP Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 Checksum(Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1. GRMP Message Header GRMP Message Header is as follows: Wang, et. al., Expires Mar. 2004 [Page 7] Internet Draft GRMP V1 Sept. 2003 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 GRMP version 1 is set to SubVer: Sub version of the protocol. Sub version of current GRMP Version 1 is set value 0. Message Type: Value Description 0 - 15 reserved 16 - 31 for FE management messages 32 - 47 for LFB management messages 48 - 63 for Datapath management messages 64 - 79 for CE informing messages 0thers for other messages Result: Acts as an indicator for the system to use to facilitate communications and reduce traffic between CE and FE. It indicates if the receiver of a message needs to send an extra GRMP ACK(acknowledge) Message (see Section 3.4.1. for ACK message definition) to the sender of the message. The Result field possibly has 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 received, 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 received it. Wang, et. al., Expires Mar. 2004 [Page 8] Internet Draft GRMP V1 Sept. 2003 9(ReNoSuccessAck) This value is only used by ACK message itself to indicate it is an ACK message and is to reply to "NoSuccessAck". 10(ReAckAll) This value is only used by ACK message to indicate it is an ACK message and is to reply to "AckAll". 12(PeSuccessAck) This value is only used by ACK message to indicate it is an ACK message and is to reply to "SuccessAck". Others Reserved, and all undefined value will be taken as 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. For any other messages, different values of Result field can be applied. Code: This field is only used in GRMP response messages or in GRMP ACK message. In other messages, this field is always set 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. The Code field encoding space is assigned as follows: 0x000-0x0ff Reserved 0x100-0x17f Defined by GRMP protocol 0x180-0x1bf Defined by ForCES FE model 0x1c0-0x1ff Defined by ForCES FE model See Appendix A for Code value definitions by GRMP. 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. But for response messages, the transaction identifier is set to the value the same as that of the message it responses to. For messages that do not require explicit response, the transaction Wang, et. al., Expires Mar. 2004 [Page 9] Internet Draft GRMP V1 Sept. 2003 identifier still needs to be set, because it is possible that the messages may still want to get some ACK messages from receivers. To facilitate the distinguish of messages from CE or from FE, the transaction identifier generated by CE or by FE is set differently in GRMP by limiting that to different number space 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 in some cases complicate the processing of messages. 2. In the case a FE is fail over and is to restart, CE can check the FE transaction identifier to gain its knowledge on the information remained in the FE, so as to speed the restart process (See Section 4.1.7). By using different transaction identifier space, CE can 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 bit is used for receivers 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: 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 all GRMP message, including the message header and optional CRC-32 checksum. Wang, et. al., Expires Mar. 2004 [Page 10] Internet Draft GRMP V1 Sept. 2003 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 with. 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: 0x00 Reserved 0xff Reserved for possible operation towards all CEs, like possible broadcasting message to all CEs 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: 0x00 Reserved 0xff Representing all existing FEs in a NE. It can be used for broadcasting message to all FEs. Message Body: In this document, the Message Body specifically denotes the part of GRMP message body that excludes the CE and FE identifier part. 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 truncate the body in length in times of 4 octets. Pads may be used for every message format if necessary. 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 Wang, et. al., Expires Mar. 2004 [Page 11] Internet Draft GRMP V1 Sept. 2003 GRMP packets may be transported via any suitable medium. Because of the compatibility with GSMP protocol, packet encapsulations defined for GSMP protocols such as that defined in RFC 3293 [11] can also be applied to GRMP. 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; otherwise the built-in error control can be optionally turned off. 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. 3.4. Common Data Format in GRMP Messages 3.4.1. GRMP 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 a message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|C|I| Reserved| SubMeg Num | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Identifier | FE Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the fields in GRMP ACK message including the message type field, the P flag and C flag, all keep the same as the message that requires the ACK message except the Result, Code and Length fields. The Result and Code fields are set according to that defined in Section 3.2. Note GRMP ACK is defined never to use CRC-32 Checksum. As a result, GRMP ACK message does not have a specific message type and it is not included in general GRMP management messages. It is more a message working at GRMP implementation layer than a message at GRMP application layer. 3.4.2. TLV Data Format Wang, et. al., Expires Mar. 2004 [Page 12] Internet Draft GRMP V1 Sept. 2003 A Type-Length-Value (TLV) is expressed in GRMP using following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 is should be 4 (octets). 3.4.3. List data format Several same 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 is defined by GRMP protocol or by the context of the protocol message where the list is. 1 Elements are PkfIDs 2 Elements are AE addresses 3 Elements are TLV bodies 4 Elements are other lists Others Reserved In GRMP, in most cases, the element type for a list does not have to be assigned and is set to default value. Note that except the length information of an element is included in the element itself, the element length should keep the same. Elements that have length information inside are that like TLVs, other lists, PkfIDs, etc. Number of Elements: Number of elements followed in this list. Note that the number is allowed to be zero. In this case, there is no element followed. Wang, et. al., Expires Mar. 2004 [Page 13] Internet Draft GRMP V1 Sept. 2003 3.4.4. AE Address Data Format Addressable Entity (AE) Address has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 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 done) Others Reserved Length: Length for this whole data format. Every address type should be responsible for the exact address length. Pad may be needed in the address value field. 3.4.5. Object Class and its Data Format GRMP relies on ForCES FE model to manage many objects. GRMP itself also has many managed objects that FE model cannot define because it is out of FE model scope. GRMP should also support vendor-specific object management. An Object Class Tag is used to distinguish these different classes of objects in GRMP. It is defined as follows: +-+-+-+-+-+ | ObjClass| +-+-+-+-+-+ Object Class: Value Description 0 Objects defined by GRMP 1 - 15 Objects defined by ForCES FE model, the number represents the model version. 16 Objects defined by general vendors, that is if vendors are not in the specific manufacturer list(see below), they should use this class. 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 Wang, et. al., Expires Mar. 2004 [Page 14] Internet Draft GRMP V1 Sept. 2003 Note that generally objects defined by GRMP 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. If necessary, GRMP may also define a minimal set of objects for general routers that is defined by ForCES requirements. In this way, GRMP may implement basic router management tasks in case an FE model software module cannot be loaded in an FE by administrators. This is only a consideration space for GRMP and has not been made by current document. 3.4.6. PkfID Data Format A PkfID is an identifier assigned by CE to FE to describe a datapath or a datapath group, as defined in Section 2. PkfIDs comprise PkfSIDs and PkfGIDs. 1. PkfSID data format A PkfSID is expressed by 4 octets (32bits) with first bit set to 0 to distinguish it from PkfGIDs (see below), the data format is as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PkfSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. PkfGID data format A PkfGID appears in two different expressions as below: PkfGID[M:N] - Representing a group of datapaths assigned with PkfGID name, the individual datapaths being assigned numbers from M to N contiguously. PkfGID[M] - Representing a single datapath within a PkfGID named datapath group, the datapath being in the M numbered place. In GRMP protocol, a PkfGID name is assigned 2 octets (16bits), with first bit set to 1 to distinguish it from PkfSID, and second bit as a tag to indicate it is a PkfGID[M] or a PkfGID[M:N], as below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|G| PkfGID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, G=0 - PkfGID[M] G=1 - PkfGID[M:N]. Numbering in a datapath group is expressed by 16bits data. As a result, a PkfGID[M] is expressed as: Wang, et. al., Expires Mar. 2004 [Page 15] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PkfGID | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While a PkfGID[M:N] is expressed by using 64bits as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| PkfGID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M | N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 an 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. 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 discovery protocol at Fr reference point of ForCES framework; 3. Manually setup from an FE manager console, this actually also makes the FE work at pre-association phase; 4. The FE uses its history information; this only applies to a fail- over FE. According to ForCES framework, these processes are out of ForCES protocol, therefore they 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 should the FE take in case it goes failover and wants to restart to rejoin in the NE. See Section 4.6.5. for details of the policy. According to ForCES requiement, a security exchange process is most probably needed before FE join message can be sent. IPsec [12] and TLS [13] security protocols are security protocols to use RECOMMENDED by ForCES framework and also by this GRMP protocol, when GRMP Wang, et. al., Expires Mar. 2004 [Page 16] Internet Draft GRMP V1 Sept. 2003 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: For using TLS with GRMP, security handshake steps may 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, 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), 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 may 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 can be used for that purpose. Other automatic key distribution techniques such as Kerberos 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. FE join request message has message data format as follows: Wang, et. al., Expires Mar. 2004 [Page 17] Internet Draft GRMP V1 Sept. 2003 Message Direction: FE to CE Message Header: Message Type = 16 Result = [ NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Identifier | Reason| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Identifier: Identifier of the FE asking to join. Reason: The reason to ask joining. This field value has been uniformly defined in Appendix A. Code: Some specific code to further indicate the reason, such as reason for just failover. The code value is uniformly defined in Appendix A. According to ForCES framework, 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 get the request message. Instead, the CE will further query the FE for more information such as the capabilities and the topology. 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 when thinking it is not qualified CE can send a FE action manipulate message to reject it. Therefore FE action manipulate message actually acts as a response to the join request, though in data format the message is not a response message. 4.1.2. FE Leave Request Message Message Direction: FE to CE Message Header: Message Type = 18 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Identifier | Reason| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Identifier Identifier of the FE requesting to leave. Reason: Wang, et. al., Expires Mar. 2004 [Page 18] Internet Draft GRMP V1 Sept. 2003 The reason to ask leaving. This field value has been uniformly defined in Appendix A. Code: Some specific code to further indicate the reason, such as reason for failover. The code value is uniformly defined in Appendix A. 4.1.3. FE Topology Query and Response Messages CE should maintain the information of whole FE topology so that it can configure FEs from the whole NE range to implement some specific IP service. CE forms whole FE topology information by sending FE topology query messages to individual FEs to collect the single individual FE topology of all FEs. A whole FE topology in an NE can actually be formed from single individual FE topology of all FEs in the NE. Note that, here topology of one single individual FE means the connection status of the one FE to other FEs. 1. FE Topology Query Message This message is sent from a CE to a FE to query the single individual FE topology of the FE itself, several other FEs, or even all FEs in the NE. To query all FEs for topology is exactly to query the whole FE topology. In GRMP protocol, CE can query one FE to get topology information of other FEs, this is because in GRMP, FEs can also be able to maintain whole FE topology information if they like to and if necessary, just by receiving topology information in FE action manipulate (broadcast) messages (See Section 4.1.5). FEs can also choose not to maintain the FE topology information. 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Identifiers ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The Queried FE topology type Value Description Wang, et. al., Expires Mar. 2004 [Page 19] Internet Draft GRMP V1 Sept. 2003 0 Whole FE topology. That is the topology comprises all FEs in an NE. In this case, the followed list of FE identifiers is not needed and is set empty. 1 Single individual topology of one FE or several FEs. Others Reserved List of FE identifiers have the list data format as defined in Section 3.4.3., which can be mirrored as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element Type | Number of Elements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ First FE Identifier Element ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Last FE Identifier Element ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Element Type is set to default value (=0), indicating the list element type is predefined by this protocol message, that is, FE identifier element here. As an element, FE identifier element has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that, in this document, list data format as defined in Section 3.4.3 and as used in this place is often used. In order to precise the document, the list format itself will not be explained anymore every time the list is used; instead, only data format of its element is described. 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Single Individual FE Topology Descriptions ~ Wang, et. al., Expires Mar. 2004 [Page 20] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Same as that in FE topology query message. A Single Individual FE Topology Description (as an element of the list) has format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Connections ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Identifier: The FE identifier of the single individual FE topology. FE Connection: The connection status of this FE. It is an element of the list of FE connections, and is composed of another list as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Connected FEs with their Ports ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Therefore, an FE connection is described by a list of connected FE ports, so the list element number (the port number) can be more than two. 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. A connected FE with its port is expressed as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connected FE Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 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. During an FE join request process, a CE may only be interested in querying for the single individual FE topology of the FE that sends join request. In this case, the FE topology response message only contains one single individual FE topology description, which is just for the FE itself. 4.1.4. FE Capability Query and Response Messages Wang, et. al., Expires Mar. 2004 [Page 21] Internet Draft GRMP V1 Sept. 2003 CE is always interested in knowing capabilities of FEs so that it can deploy the 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 the different capability representations by defining capability as objects, and these objects can then be defined by GRMP itself, ForCES model, and vendors as defined 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Capability Tags ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 list 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. 2 FE capabilities specified by the list of capability tags Others Reserved An FE capability tag as the element in the list has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Capability Tag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Capability Tag: FE Capability Tag has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ObjClass| FE Capability Type | Wang, et. al., Expires Mar. 2004 [Page 22] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Class This is defined in Section 3.4.5.. It means a FE capability type can be defined by GRMP itself, different versions of ForCES FE model, or vendors. Among these, GRMP and ForCES FE model defined types are essential for GRMP protocol. FE Capability Type: The capability type defined by different class. In GRMP defined FE capability class, current version 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 Port Capability 0x004 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Capability TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The same as that defined in FE Capability Query Message. FE Capability TLV: As an element of the list, it has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Capability Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FE Capability Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Capability Tag: The same as defined in FE Capability Query Message. Wang, et. al., Expires Mar. 2004 [Page 23] Internet Draft GRMP V1 Sept. 2003 FE Capability Description The 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 current version GRMP defined capability types (see above) are as follows: 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 Port Capability FE Port Capability Description has following data format: Wang, et. al., Expires Mar. 2004 [Page 24] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Single Port Capacity Descriptions ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As an element of the list, a single port capability description has the data format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Physical Address of the Port ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port Type: The port type. Value Description (to be done) The Physical Address of the Port has the AE address data format defined in Section 3.4.4. Bandwidth: The bandwidth capacity of the port, expressed in bit per second(bps). 4. 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. 4.1.5. FE Action Manipulate Message This message is sent from a CE to one FE or in a broadcast way to all FEs in the NE to command one of the FEs to take an action and to notify other FEs the action. If an FE whose FE identifier is the same as that listed in the message body, the FE is the one that should take the action, or else, the FE is only notified of the action happened to other FE in the NE. Currently defined actions for an FE are as follows: FE Add: To add an FE in the NE is to add the single individual FE topology of the FE to the whole FE topology and then to let the FE up. This is Wang, et. al., Expires Mar. 2004 [Page 25] Internet Draft GRMP V1 Sept. 2003 actually to accept the FE as a member of the NE, 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 whole FE topology 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 CE actually has no right to reject an FE to leave, therefore, an FE leave request is always approved. FE Modify: To modify an FE is only to change its topology, that is to modify its connection status with other FEs. 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 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 ] FE Identifier = [an FE Identifier | 0xff], when it is 0xff, this message is a broadcast message that is sent to all FEs in this NE. Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | FE Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Single Individual FE Topology Description (Optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 26] Internet Draft GRMP V1 Sept. 2003 Type: Value Description 1 FE Add. 2 FE Delete. 3 FE Modify 4 FE Join reject 9 FE Up 10 FE Down 11 FE Active 12 FE Inactive Others Reserved FE Identifier: The FE Identifier that is going to take the action. Single Individual FE Topology Description: The Single Individual FE topology description of this specific FE. This description has exactly the same data format as defined in FE topology response message in Section 4.1.3. Note that this data field only applies to FE add and modify actions. For other FE actions, this field is empty. 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 include all attributes concerning FE layer operations such as FE policies like DoS protection policy, CE failover policy, etc. In GRMP, FE attributes are allowed to be defined by different object classes such as GRMP class, ForCES FE model class, and vendor class. The manipulated FE attributes do not include the FE attributes that can be queried but cannot be added, or changed, like the statistics attributes, capabilities. Note that GRMP treats FE registering for event reports as a kind of manipulable FE attributes to let GRMP application layer able to register for some interested event reports from the FE. Message Direction: CE to FE Message Header: Message Type = 26 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Attribute Operations ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 27] Internet Draft GRMP V1 Sept. 2003 For FE attribute add and delete operations, element of the list of FE attribute operations has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FE Attribute TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For FE attribute modify operations, element of the list of FE attribute operations has data format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FE Attribute TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Old FE Attribute TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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: This is defined in Section 3.4.5. This means FE attribute types can include that defined by GRMP itself, different versions of ForCES FE model, and vendors. Among these, GRMP and ForCES FE model defined types are essential for GRMP protocol. 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: It has the same data format as FE attribute TLV. This TLV indicates the old value of the FE attribute to be modified. Note that the value Wang, et. al., Expires Mar. 2004 [Page 28] Internet Draft GRMP V1 Sept. 2003 part of the TLV can be empty, meaning the attribute only has one value; to modify it there is no need to tell the old value. An attribute in an FE may be associated with many value instances. In order to correctly manipulate these kinds of FE attributes, we define that: 1. For an FE attribute add message, if there is no attribute value followed in the attribute TLV, it means to add a new attribute. If there is a value, it is to add a new value instance to the attribute. If the attribute did not exist, it will first be created then the value added. 2. For an FE attribute delete message, if there is no attribute value associated with the attribute TLV in the message, it means to delete the attribute totally from the FE, all values associated with the attribute are also deleted. If we only want to delete some value instance from the attribute, the specific value should be designated 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. A specific section on GRMP slave management has been presented in this document in Section 4.6. Therefore, the values and the functions of these attributes are described there. See there for more details.) 0x010 Register for FE event report Others Reserved The FE Attribute for register for FE event report has following value data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 29] Internet Draft GRMP V1 Sept. 2003 | FE Event Tag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Event Tag: The event report tag to register. See Section 4.1.8 for detailed FE event tag definition. 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 attribute response message. All defined FE attributes should be able to be queried. These attributes include that for FE statistics. FE attributes on statistics can only be queried and cannot be added or deleted. 1. FE Attribute Query Message Message Direction: CE to FE Message Header: Message Type = 28 Result = [Don't Care] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Attribute Tags ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An FE Attribute Tag as an element in the list has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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: CE to FE Message Header: Message Type = 29 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Attribute TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 30] Internet Draft GRMP V1 Sept. 2003 As an element of the list, FE Attribute TLV has the same data format as defined in Section 4.1.6. Attribute classes include GRMP class, ForCES model class, and vendor class. For GRMP class, apart from FE attributes defined in Section 4.1.6, which can be manipulated so can also be queried, current version GRMP has defined 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 faiover 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. Because GRMP has defined transaction identifier generated by FE differently from that by CE (See Section 3.2), CE can recall the history information of the FE more easily. 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 some may only send reports to CE when they are registered by the CE. Event definitions should state if the event needs registering or not. Message Direction: FE to CE Message Header: Message Type = 30 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Wang, et. al., Expires Mar. 2004 [Page 31] Internet Draft GRMP V1 Sept. 2003 Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of FE Event TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Event TLV: As an element of the list, it has data format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Event Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FE Event Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Event Tag has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ObjClass| FE Event Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Class: This object class ID is defined in Section 3.4.5. It means FE event types can include that defined by GRMP itself, different versions of ForCES FE model, and vendors. Among these, GRMP and ForCES FE model defined types are essential for GRMP protocol. FE Event Description: If FE event types belong to that defined in ForCES FE model or vendors, the value format should follow the definitions there. For an FE LFB event, there is usually an LFB tag and LFB instance identifier in the description field to designate the LFB. 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 port change 0x005 FE memory change 0x006 FE DoS attack alert Others Reserved 1. FE status Event This event is a no register event, it will always sends a report message to CE if it happens. The event has following event description format in the TLV: Wang, et. al., Expires Mar. 2004 [Page 32] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FE Status Tag | Reserved | Reason| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FE Status Tag Value Description 1 FE Up 2 FE Down or Leave 3 FE Active 5 FE Inactive 6 FE failover Others Reserved Reason: The reason for the event. This field value has been uniformly defined in Appendix A. Code: Some specific code to further indicate the reason, such as reason for failover. The code value is uniformly defined in Appendix A. 2. LFB status Event This event is a no register event. It has following description format in the TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Status Tag| Reserved | Reason| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LFB Status Tag Value Description 1 LFB Up 2 LFB Down 3 LFB Active 5 LFB Inactive 6 LFB failover Others Reserved Reason: The reason for the event. This field value has been uniformly defined in Appendix A. Code: Some specific code to further indicate the reason, such as reason for failover. The code value is uniformly defined in Appendix A. LFB Tag: Wang, et. al., Expires Mar. 2004 [Page 33] Internet Draft GRMP V1 Sept. 2003 Tag to indicate the type of the LFB. This field is the same as defined in Section 4.2.1. See there for detailed definition. LFB Instance ID: The instance identifier for this LFB. 3. FE Heartbeat This event is a register event, only when CE registers to a FE then the FE will send the report. This event has no event description in the 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 is a register event. When it has been registered by a CE 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. 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. Several actions to several different LFBs can be included in one LFB action manipulate message. Currently defined actions for an LFB are as follows: LFB Add: To add an LFB into the FE. To completely add an LFB to FE is to add the single individual LFB topology of the LFB to the whole FE LFB topology, and to add associated attributes to the LFB. But it is also Wang, et. al., Expires Mar. 2004 [Page 34] Internet Draft GRMP V1 Sept. 2003 allowed by this message to partly add something of the LFB, like only the topology part or only the attribute part. LFB Delete: To delete an LFB from the FE. The FE will then remove the LFB from the whole FE LFB topology, and then destroy the LFB. If only some attributes of the LFB are to be deleted, LFB attribute manipulate message (see Section 4.2.3) should be instead used. LFB Modify: In this LFB action manipulate message, to modify an LFB is defined only to modify its topology, that is to substitute the LFB topology with the new one. If LFB attributes are to be modified, LFB attribute manipulate message (see Section 4.2.3) should be instead used. LFB Up: To command the LFB to go into up state and ready for functioning. LFB Down: To command the LFB to go into down state. When the LFB is in the down state, all configured information will be lost. LFB Active: To command the LFB to go into active state. This is only used after an LFB has been set to inactive state. LFB Inactive: To command the FE to go into inactive state. In this state, the LFB will stop taking any functions, but the configured information is still maintained. LFB topology representation in GRMP is based on PkfIDs [7]. To represent topology of LFBs, PkfIDs should be first assigned to the datapaths that connect the LFBs ingresses and egresses together. Figure 1 is an example of FE LFB topology represented by PkfIDs. Meter Mux +--+ PkfSID2 +--+ PkfGID1[1] | 1|------------>|1 | PkfSID5 +->| | PkfSID4 | |--+ | | 2|--+ +->|2 | | | +--+ | +--+ | +--+ | | +->| |-+ | | | PkfSID3 +--+ | +---+ | | Marker | +---+ +---+ | 1|-|-+ +->|1 | | | | | | | |PkfGID2 | |Pkf PkfSID1| | | PkfGID1[2:5] | |[1:5] | |SID6 ------>| 2|-|-----------------------------\|2 1|-------\|1 |----> | ~|-|-----------------------------/|~ ~|-------/|~ | | 5| | |5 5| |5 | Wang, et. al., Expires Mar. 2004 [Page 35] Internet Draft GRMP V1 Sept. 2003 | | |<=PkfGID1[1:5] | | | | | | | | | | +---+ +---+ +---+ Classifier Queues Scheduler Figure 1. An FE LFB topology represented by PkfIDs In the Figure, single datapaths are represented by PkfSIDs, while datapath groups are represented by PkfGIDs. FE action manipulation message has following format: Message Direction: CE to FE Message Header: Message Type = 32 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFB Action Body ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element of the list of LFB action body 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For LFB Modify actions, the LFB action body has format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Single Individual LFB Topology Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For LFB Add actions, the LFB action body has format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |T|A| Reserved | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | Wang, et. al., Expires Mar. 2004 [Page 36] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Single Individual LFB Topology Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFB Attribute TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 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 LFB topology description field 1 Message includes LFB topology description field A Tag: Only for add action. Value Description 0 Message does not include LFB attribute List Field 1 Message includes LFB attribute List field LFB Tag: An LFB Tag has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ObjClass| LFB Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Class: This is defined as before. It means LFB types can include that defined by GRMP itself, different versions of ForCES FE model, and vendors, according to the different requirements. Among these, GRMP and ForCES FE model defined LFB types are essential for GRMP protocol. Current version of GRMP defines none of GRMP class LFB types. LFB Instance ID: The instance identifier of the LFB. Single Individual LFB Topology Description: Topology description for this LFB only. It refers to the datapath connection status of the LFB with other LFBs. Wang, et. al., Expires Mar. 2004 [Page 37] Internet Draft GRMP V1 Sept. 2003 The single individual LFB topology description of is also based on PkfIDs. By listing out all PkfIDs in the ingresses and egresses of the LFB, the single individual topology of the LFB is then easily represented. If a PkfID on the LFB has not been assigned by other GRMP messages before, this is also a process to assign a new PkfID to a datapath in the FE. As a result, a single individual LFB topology description has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFB Ingress PkfIDs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFB Egress PkfIDs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Elements of List of LFB Ingress PkfIDs and LFB egress PkfIDs are all PkfIDs, whose data format has be defined in Section 3.4.6. Note that a PkfID can be a PkfSID, a PkfGID[M], or a PkfGID[M:N], representing a single datapath, a single datapath in a datapath group, or simply a datapath group. LFB Attribute TLV: As an element of the list of LFB Attribute TLVs, it has data format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Attribute Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LFB Attribute Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LFB Attribute Tag: LFB Attribute Tag has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ObjClass| LFB Attribute Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Class: This is defined as before. It means LFB attribute types can include that defined by GRMP itself, different versions of ForCES FE model, and vendors. Among these, GRMP and ForCES FE model defined types are essential for GRMP protocol. Note that the object class in an LFB attribute do not have to be the same as the object class in the LFB tag. This means even it is a GRMP or ForCES FE model defined LFB, its attributes can be extendedly defined by others such as vendors. In this way, GRMP can enhance its salability and compatibility. LFB Attribute Value: Wang, et. al., Expires Mar. 2004 [Page 38] Internet Draft GRMP V1 Sept. 2003 If attribute types belong to that defined in ForCES FE model or by vendors, the value format should follow the definitions there. Current version of GRMP defines none of GRMP class LFB attributes. 4.2.2. LFB Topology Query and Response Messages A CE sends a LFB topology query message to an FE to query single individual 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 0 Whole FE LFB topology, that comprises all LFBs in the FE. In this case, the list field followed 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 ] Wang, et. al., Expires Mar. 2004 [Page 39] Internet Draft GRMP V1 Sept. 2003 Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFB Topology Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The Queried LFB topology type, same as in the LFB topology query message. List of LFB Topology Information: Element of the List has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Single Individual LFB Topology Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Single Individual LFB Topology Description: This is the same as 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. LFB attributes include all attributes concerning LFB layer operations such LFB parameters, rules, etc. In GRMP, LFB attributes are allowed to be defined by different object classes like 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. One LFB attribute manipulate message can manipulate several LFB attributes for several different LFBs. LFB attribute manipulate message has following format: Message Direction: CE to FE Message Header: Message Type = 36 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFB Attribute Operations ~ Wang, et. al., Expires Mar. 2004 [Page 40] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ According to different LFB attribute operations, the element of the list has different format: For LFB attribute add and delete operation, Element of the list has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LFB Attribute TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For LFB attribute modify operation, Element of the list the data format is as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LFB Attribute TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Old LFB Attribute TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Value Description 1 LFB Attribute Add 2 LFB Attribute Delete 3 LFB Attribute Modify Others Reserved 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 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 to be modified. Note that the value part of the TLV can be empty, meaning the attribute only has one value; to modify it, there is no need to tell the old value. An attribute in an LFB may be associated with many value instances. For example, a routing table attribute for a packet forwarder LFB Wang, et. al., Expires Mar. 2004 [Page 41] Internet Draft GRMP V1 Sept. 2003 usually has many routing rules as its attribute values. In order to correctly manipulate these kinds of LFB attributes, we define that: 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 an 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 associated with 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 designated 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 defined LFB attributes should be able to be queried. Note that GRMP also defines LFB capabilities and statistics as LFB attributes, which is a little different from FE attributes, where FE capabilities are especially addressed. 1. LFB Attribute Query Message Message Direction: CE to FE Message Header: Message Type = 38 Result = [Don't Care] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFBs with Attribute Tags ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element of list of LFBs with attribute tags is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 42] Internet Draft GRMP V1 Sept. 2003 ~ List of LFB Attribute Tags ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element of list of LFB attribute tags has 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFBs with Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element of list of LFBs with attributes has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. In GRMP, every datapath is assigned a PkfID so as to uniquely represent it. The assignment is done either by LFB (add or modify) action manipulate message or by datapath (add) manipulate message described in this Section. By using datapath management messages, GRMP protocol is able configure, modify, or query the LFB topology. LFB action manipulate message and LFB topology query and response messages described before can also manage LFB topology. The difference between the two kinds of topology management is that datapath management messages manage the LFB topology from the perspective of datapaths, while LFB management messages manage LFB topology from the perspective of LFBs. They have Wang, et. al., Expires Mar. 2004 [Page 43] Internet Draft GRMP V1 Sept. 2003 different advantages to use. To interactively use these two approaches cab make LFB topology management more simple and precise. 4.3.1. Datapath Manipulate Message Currently defined datapath manipulate operations are datapath add, datapath delete, and datapath modify operations. Message Direction: CE to FE Message Header: Message Type = 48 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Datapath Operations ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element of the list of datapath operations has different data format according to different operation types: For Datapath Delete operation, the data format is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(Delete) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Datapath PkfID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For Datapath Add or Modify operations, the data format is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(Add or Mod)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Datapath Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Value Description 1 Datapath Add 2 Datapath Delete 3 Datapath Modify Others Reserved Datapath PkfID: The PkfID of this datapath. PkfID data format is defined in 2.4.6. Note that a PkfID can be a PkfSID, a PkfGID[M], or PkfGID[M:N], representing a single datapath, a single datapath in a datapath group, or simply a datapath group. Wang, et. al., Expires Mar. 2004 [Page 44] Internet Draft GRMP V1 Sept. 2003 Datapath Description: The connection status description of the datapath. A Datapath Description has two different data formats according to that the described datapath is a single datapath or a datapath group. A single datapath is marked by a PkfSID or a PkfGID[M]. A datapath group is marked by a PkfGID[M:N]. For a PkfSID or PkfGID[M] marked single datapath, the datapath description has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PkfSID or PkfGID[M] for the Datapath | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFBs the Datapath is from ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFBs the Datapath is to ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An LFB as an element of above lists is expressed by the format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a PkfGID[M:N] marked datapath group, datapath description has a little more complex data format as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PkfGID[M:N] for the Datapath Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFBs the Datapath Group is from ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of LFBs the Datapath Group is to ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that it is possible only a part of the datapath group is connected to an LFB, as shown in Figure 1, only PkfGID1[2:5] is connected to queues LFB, PkfGID[1] is connected to another LFB. Therefore, a datapath group may be divided into several branches then be connected some LFBs. A branch of a datapath group still can be represented by a PkfGID, only with connection numbering (that is the M and N parameters) being changed. Therefore, following data format is used as an element in the above lists to describe an LFB associated with branch datapaths of the datapath group [7]: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Tag | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Branch PkfGIDs ~ Wang, et. al., Expires Mar. 2004 [Page 45] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, element of the list of Branch PkfGIDs still has PkfGID[M:N] data format only with the M and N parameters changed according to the branch connection status. 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, all datapaths in a LFB topology in the FE, all incorrectly connected datapaths. To query all datapath connection status is exactly to query the FE LFB topology. The datapath query message can also be used to query some spare PkfIDs for CE to use. The FE replies to the query message by a datapath response message. 1. Datapath Query Message Message Direction: CE to FE Message Header: Message Type = 50 Result = [Don't Care] Message Body: According to different query types, the message format is a little different as follows: To query status of some datapaths, the format is as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type(SomeDpath)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of PkfIDs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, the list of PkfIDs lists out all PkfIDs of the queried datapaths. To query all datapath status, the format is as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(AllDpath)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To query status of all datapaths is exactly to query the whole FE LFB topology, only with the LFB topology being represented from the perspective of datapaths. To query all datapaths that are incorrectly connected, the format is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(ErrDpath)| Reserved | Wang, et. al., Expires Mar. 2004 [Page 46] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is used to query all datapaths that have incorrect status such as a datapath that comes from one LFB but goes to no place. This error may happen when there is a LFB that used to work there but currently goes down or is removed by CE owing to some reason. To query a number of spare PkfIDs, the data format is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(SprPkfID)|G| Reserved | Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, G = 0 - to query spare PkfSIDs = 1 - to query spare PkfGIDs. Number: The number of spare PkfIDs to query. This message is used to query a number of spare PkfIDs in the FE so that they can be used next by CE. A spare PkfID means an PkfID identifier space that still has not been used in the FE. This function may be used in such a scenario: a CE may have been maintaining a complex LFB topology, in which many PkfIDs have been used, and the PkfIDs may have also been changed (deleted, modified) all the time, therefore the CE may become reluctant to maintain the PkfIDs used. In this case, it is convenient for CE to use this spare PkfID query function to fetch some unused PkfIDs from the FE for next use instead of maintaining PkfIDs by CE itself. While in an FE, in order to maintain the LFB topology, the FE has to maintain a used PkfID database, and it is easy for the FE to find some spare PkfIDs based on this database. To summary, the type value defined in this message is as follows: Type Description 1 SomeDpath, query status of some datapaths. 2 AllDpath, query status of all datapaths(LFB topology query) 3 ErrDpath, query all error datapaths 4 SprPkfID, query a number of spare PkfIDs Others Reserved 2. Datapath Query Response Message Message Direction: FE to CE Message Header: Message Type = 51 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Wang, et. al., Expires Mar. 2004 [Page 47] Internet Draft GRMP V1 Sept. 2003 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 exactly the same as defined in Section 4.3.1. To response the query of spare PkfIDs, the message body has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Spare PkfIDs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As an element of the list, a spare PkfID has the same data format as a general PkfID which is defined in Section 3.4.6. 4.4. CE Informing Messages In ForCES architecture, CE is mainly by ForCES protocol application layer. As a slave, FE only has right to request to CE for some information, and CE may also like to send some information as CE event report to FE. CE Informing messages manages these matters. 4.4.1. CE Query request and Response Messages An FE may need to query a CE for some information. In this case, the FE only has right to send a query request message to CE. 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 described 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 Wang, et. al., Expires Mar. 2004 [Page 48] Internet Draft GRMP V1 Sept. 2003 Message Header: Message Type = 64 Result = [ NoAck | NoSuccessAck | AckAll | SuccessAck ], it differs from general query message, in that it is actually a request message, so the response is not assured. Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of CE Attribute Tags ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A CE Attribute Tag as an element in the list has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Attribute Tag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CE Attribute Tag has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ObjClass| CE Attribute Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Class: This is as defined before. It means the CE attributes are allowed to be defined by many classes. But note that the ForCES FE model does not define any attributes in CEs, therefore object classes apply to CE attributes only have GRMP class and vendor class. Among these, GRMP class is essential for GRMP protocol. 2. CE Query Response Message Message Direction: CE to FE Message Header: Message Type = 65 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of CE Attribute TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CE Attribute TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Attribute Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CE Attribute Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 49] Internet Draft GRMP V1 Sept. 2003 CE Attribute Tag is same as defined in the CE query request message above. CE Attribute Value: If CE Attribute types belong to that defined by vendors, 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 done) Others Reserved 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 event 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 cannot be registered by a FE, CE itself will decide to send them or not. Message Direction: CE to FE Message Header: Message Type = 66 Result = [NoAck | NoSuccessAck | AckAll | SuccessAck ] FE Identifier = [ An FE Identifier | 0xff], when it is 0xff, this message is a broadcast message to all FEs. Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of CE Event TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CE Event TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Event Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CE Event Description ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CE Event Tag has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ObjClass| CE Event Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 50] Internet Draft GRMP V1 Sept. 2003 Object Class This is as defined before. It means CE events can be defined by different classes. However, note that the ForCES FE model does not define any CE event, object classes applied to CE events only have GRMP class and vendor class. Among these, GRMP class is essential for GRMP protocol. CE Event Type: The CE event type defined by different object classes. 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 Evebt Type Description 0x001 CE status event 0x003 CE heartbeat Others Reserved 1. CE status Event This event will send a event report message to a FE or all FEs to report its working status. The event has following event description format in the CE event TLV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |CE Status Tag | Reserved | Reason| 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 Reason: The reason for the event. This field value has been uniformly defined in Appendix A. Code: Some specific code to further indicate the reason, such as reason for failover. The code value is uniformly defined in Appendix A. 2. CE Heartbeat Wang, et. al., Expires Mar. 2004 [Page 51] Internet Draft GRMP V1 Sept. 2003 This event report message sends to an FE or all FEs as a heartbeat signal from the CE. The event has no event description in the 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 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 According to ForCES requirements and framework definitions, 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 meet above requirement. 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. To perform this, it is necessary for CE to configure some LFBs that has high touch capability in the FE. 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. 2. MOs resident in a CE can be directly queried or changed by the CE with the CE high tough capability. Before the CE can do this, network management messages are still needed 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: Wang, et. al., Expires Mar. 2004 [Page 52] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MO Class | Reserved | Length of MO Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MO Type ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MO Class: Currently defined MO Classes are: Value Description 0x00 Reserved for GRMP itself 0x01 - 0x0f Reserved for ForCES model 0x10 - 0x1f Reserved for vendors 0x21 - 0x2f for SNMP MIB defined MOs, the last 4 bits represents the SNMP version number Others Reserved MO Type: The managed object type that is represented in different ways in different MO classes. In SNMP, it is represented by an Object Identifier [9]. A MO value TLV has 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 for the CE to get the values of some MOs. A response to the CE is required from the FE. Message Direction: CE to FE Message Header: Message Type = 80 Result = [Don't Care] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of MO Identifiers ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A MO identifier is defined as above. Wang, et. al., Expires Mar. 2004 [Page 53] Internet Draft GRMP V1 Sept. 2003 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 response from the FE. Message Direction: CE to FE Message Header: Message Type = 82 Result = [Don't Care] Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of MOs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element of the list of MOs has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MO Identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MO value TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MO identifier and MO value TLV are as defined above. 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of MOs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ List of MOs is the same is defined above. 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 and interpret all GRMP messages. A GRMP slave should work under the control of CE and according to Wang, et. al., Expires Mar. 2004 [Page 54] Internet Draft GRMP V1 Sept. 2003 information in the FE. A GRMP Slave module is connected to CE via a link connection. The connection is established via 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 so as 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 2. To GRMP Master From GRMP Master A | 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 Figure 2. GRMP Slave Model In this model, all GRMP messages sending to CE are put to 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 is should be managed by CE by setting some scheduling policies to it. This policy setting can be 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 like DoS attack protection. GRMP slave also accept other policies sent by CE, such as FE or CE failover policies, heartbeat policy, etc. Wang, et. al., Expires Mar. 2004 [Page 55] Internet Draft GRMP V1 Sept. 2003 Note that there is also a GRMP master module on CE side. This module is usually managed by GRMP application layers, therefore it is out of scope of ForCES protocol. We will not discuss GRMP master management in this document. All GRMP slave policies and other attributes are managed in the way that they are treated 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 are as follows: 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 version assignment 4.6.2. DoS Protection Policy As described above, DoS protection policy setup is performed by setting the scheduler policies in GRMP slave. This is to protect DoS attacks coming from FE Fi/f reference points in ForCES framework. 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 tough LFBs in the FE. For instance, a high tough 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). The DoS protection policy setup is performed via GRMP FE attribute manipulate message. It is treated as a FE attribute defined by GRMP object class. Therefore, we just need to describe the attribute value format here. Following Section 4.1.6 on FE attribute TLV format, the attribute Value for DoS Protection Policy has following data format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| CBT | CCP | Reserved |D| DBT | DCP | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lower Limit of Ctl. Channel BW| Upper Limit of Ctl. Channel BW| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lower Limit of Data Channel BW| Upper Limit of Data Channel BW| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 56] Internet Draft GRMP V1 Sept. 2003 C: Control channel priority 0 - Normal priority 1 - High Priority D: 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 the GRMP message header. 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. CBT: Control channel bandwidth type 000 - Any available bandwidth 001 - Use Bandwidth assigned by the followed field Others - Reserved DBT: Data channel bandwidth type 000 - Any available bandwidth 001 - Use Bandwidth assigned by the followed field Others - Reserved CCP: Control channel congestion control policy 000 - No policy 001 - Cache to wait 002 - Drop immediately Others - Reserved DCP: Data channel congestion control policy 000 - No policy 001 - Cache to wait 002 - Drop immediately Others - Reserved Lower Limit and Upper Limit for Control Channel Bandwidth: The bandwidth expressed in percentage of whole link capacity. If the lower limit and upper limit is set the same, that is exactly this bandwidth to use. Lower Limit and Upper Limit for Data Channel Bandwidth: Wang, et. al., Expires Mar. 2004 [Page 57] Internet Draft GRMP V1 Sept. 2003 The bandwidth expressed in percentage of whole link bandwidth. If the lower limit and upper limit is the same, that is exactly this bandwidth to use. These bandwidth limits can be changed on the fly by CE according to current channel status. It is RECOMMENDED that a lower limit for control channel bandwidth be always set so as to avoid possible complete block of the control channel before DoS attack protection mechanism can work. 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 following attribute value format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Policy | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Continuous Overload Time Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Policy: Value Description 0 No policy, FE will not report DoS attack alert event. No field is followed in the value format then. 1 Policy based on monitoring the continuous overload time in the data channel in above GRMP slave model. Here, overload is defined as the status that data occupies upper limit of allowed bandwidth in a channel. Others Reserved Continuous Overload Time Threshold: If the continuous overload time is over the threshold, a DoS attack is considered. 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 58] Internet Draft GRMP V1 Sept. 2003 | Policy | SP| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ List of Alternative CE Identifiers (Optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Policy: Value Description 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 59] Internet Draft GRMP V1 Sept. 2003 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 find, 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. CEs may assign different heartbeat policies to the same FE. FE heartbeat policy has attribute value format as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SndPlcy|RcvPlcy| Reserved | Wang, et. al., Expires Mar. 2004 [Page 60] Internet Draft GRMP V1 Sept. 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Send Policy: Policy to send heartbeat to CE. Value Description 0 Disable heartbeat in the FE 1 Enable heartbeat in the FE, the heartbeat interval should be assigned 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 Wang, et. al., Expires Mar. 2004 [Page 61] Internet Draft GRMP V1 Sept. 2003 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-tough 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 GRMP application layer on CE side. 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. Message Body: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Redirected Packet Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirected Packet Data: The whole redirected packet data, including the packet header if any. Though theoretically packet redirection message can ask for GRMP ACK message as a response, in order to achieve more efficiency, it is RECOMMENDED NOT to ask GRMP ACK messages, as such the Result field is RECOMMENDED to set to "NoAck". 4.8.GRMP Batch Messages GRMP Batch message packs several GRMP message bodies into one single message. These 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 event report messages, FE or LFB action manipulate messages, attribute manipulate messages, etc. 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang, et. al., Expires Mar. 2004 [Page 62] Internet Draft GRMP V1 Sept. 2003 ~ List of GRMP Message Packets ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As an element of the list, a GRMP Message Packet has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 priority flag in batch message header can still be effective and is different from this one. The priority in the batch message header refers to the priority to process the whole batch message. 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. GRMP batch message can be used in many cases to facilitate operations for CE and FE. GRMP batch message can also be especially used by GRMP application layer to efficiently perform QoS configurations such as to configure QoS parameters. According to ForCES framework, QoS parameters should be mapped into configurations of FE LFBs associated with the topology and the attribute setup. For example, a Diffserv PHB configuration may be mapped to configuration of LFBs like classifiers, markers, meters, shapers, queues, and schedulers along with their topology and attributes [14]. By setting these LFBs simultaneously at a blow, a PHB then can be quickly lunched on the fly. Therefore, for GRMP to support QoS configurations, an application model shown as in Figuure 3 may be applied. -------------------------- |Diffserv | RSVP | ... | -------------------------- | QoS Application Layer | -------------------------- | V Wang, et. al., Expires Mar. 2004 [Page 63] Internet Draft GRMP V1 Sept. 2003 -------------------------- | GRMP APIs for QoS Cfg. | -------------------------- | V -------------------------- | GRMP Master | -------------------------- | V ----------------------------- | GRMP Slave | ----------------------------- |Classi-| Meter |Schedu-| | |fier | |ler |...| ----------------------------- | FE resources | ----------------------------- Figure 3. GRMP QoS Application Model In this model, some common QoS configurations are transferred into GRMP protocol messages for FE resource configurations by using some GRMP APIs. These GRMP APIs are in fact composed of GRMP batch messages, in which all required configurations of an FE for the QoS configuration are included. In some cases, QoS configurations are not so complex as thought. For example, to configure bandwidth parameters of QoS may only need to configure attributes of schedulers in an FE. In this case, QoS APIs is not necessary to be used. 5. Security Considerations The Security of GRMP control channel over TCP/IP has been addressed in Section 4.1.1, where IPsec and TLS have been recommended. The security to defend DoS attack has been addressed in 4.6.2. The security to defend FE join and leave flooding attack is addressed in Section 4.1.1. If GRMP protocol applies to "all-in-one-box" deployment of CEs and FEs, GRMP MAY rely on the physical security of the box to defend man-in-the-middle snooping and impersonation attacks to GRMP control channel, and GRMP protocol mechanisms for this May be turned off, though in this case DoS protection is still needed. 6. IANA Considerations Following name spaces are considered in this GRMP version: - GRMP Message Type Name Space - Result Name Space Wang, et. al., Expires Mar. 2004 [Page 64] Internet Draft GRMP V1 Sept. 2003 - Code Name Space - Reason 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 - LFB Type Defined by GRMP Class Name Space - LFB Attribute 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", RFC xxxx, Aug. 2003. [3] L. Yang, et. al, "Forwarding and Control Element Separation (ForCES) Framework", , Aug. 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, , Aug. 2003. [7] W. Wang, "Topology Representation for ForCES FE Model", work in progress, , Aug. 2003. [8] W. Wang, "A Control Scheme and Management Protocol for Open Programmable QoS IP Routers", Proceedings of SCI 2003, July 2003. [9] R. Presuhn, et. al., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC 3418, Dec. 2002. [10] A. Doria, "GSMPv3 Base Specification", work in progress, , June 2003. [11] A. Doria, et. al., "General Switch Management Protocol (GSMP) Packet Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002. Wang, et. al., Expires Mar. 2004 [Page 65] Internet Draft GRMP V1 Sept. 2003 [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, , June 2003. 8. Appendix A Definitions for Reason and Code Value 1. Reason Field Reason field values defined in current GRMP version: Value Description 0 Reason unavailable 1 Rejoin, because was failover and is restarted 2 Rejoin, because has left 9 Leave, because Failover 10 Leave, because just want to (more to be done) 2. Code Field Code field values defined in current GRMP version: For message interpreting: 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 For failover reason Value Description 0x110 CE an FE disconnected. 0x111 Failover owing to hardware. 0x112 Failover owing to GRMP slave error 0x113 Failover owing to LFB error (more to be done) 9. Acknowledgments Wang, et. al., Expires Mar. 2004 [Page 66] Internet Draft GRMP V1 Sept. 2003 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. The research project that work of GRMP protocol is based on has been sponsored by NSF(60273061), National 863 Project(2002AA121064), ZJNSF(RC02063), and SRF for ROCS by SEM, P.R.China. 10. Authors' Addresses Weiming Wang Department of Information and Electronic Engineering Hangzhou University of Commerce 149 Jiaogong Road Hangzhou, 310035, P.R.China Phone: +86-571-88057712 Email: wangwm@hzcnc.com; Yunfei Guo Hi-Tech Research and Development (863) Program of China 1 Sanlihe Road Beijing, 100044, P.R.China Phone: +86-10-68338852 Email: gyf@htrdc.com; Guangming Wang Hangzhou University of Commerce 149 Jiaogong Road Hangzhou, 310035, P.R.China Phone: +86-571-88071024 Email: gmwang@mail.hzic.edu.cn; Wang, et. al., Expires Mar. 2004 [Page 67]