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