Network Working Group R. Chaparadza Internet-Draft R. Petre Intended status: Standards Track Fraunhofer Fokus Expires: January 20, 2012 H. Mahkonen Ericsson L. Xin BUPT M. Behringer Cisco Systems July 19, 2011 IP based Generic Control Protocol (IGCP) draft-chaparadza-intarea-igcp-00.txt Abstract This document presents a proposal for a multi-purpose Generic Control Protocol (IGCP) for IP based networks. There is a growing need for a generic control protocol framework that can be further customized to specific usage contexts in which certain types of control information exchange messages and behavior among some functional entities hosted by different nodes or devices is desired. For example, the growing area of self-management, self-organization and autonomic networking introduces functional entities into the node/device and network architectures that need to exchange control information in order to implement self-adaptive behavior by dynamically configuring and optimizing the network. In this Draft we capture a number of control message exchange types of contexts (semantics) that can be selectively applied in the exchange of control information, which can form the basis of a generic control protocol, while at the same time defining the part in the message format that can be further customized according to the needs of specific functional entities designed to use the generic control protocol for exchanging control information. In this Draft, we present our proposal for such a generic control protocol, whose message format is divided into two parts: a Common Part and a Generic Data Part. The Common Part defines a set of a variety of selectable control semantics (e.g. simple one-way control information flow, indications of whether an acknowledgement is needed or not, solicitations for information or push/pull behaviors, negotiations for parameter value settings, etc). The Generic Data Part can be further customized and structured according to some specific use case of conveying control information carried by the Data Part that need to be parsed and used by some entities designed to interpret the Data Part according to their own specific customization and structuring of the Data Part. We also give an example domain of application of the IGCP, namely the domain of autonomic adaptive control of network behaviours, of which we Chaparadza, et al. Expires January 20, 2012 [Page 1] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 illustrate further by providing an example Use Case that customizes the Data Part of the IGCP for use by special functional entities residing in different nodes in exchanging information using the IGCP messages. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 20, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Chaparadza, et al. Expires January 20, 2012 [Page 2] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. The Proposed Solution (IGCP: IP-based Generic Control Protocol) and its application (Usage Scenarios) . . . . . . . 9 4.1. Generating an IGCP message/packet . . . . . . . . . . . . 9 5. Conventions used in this document . . . . . . . . . . . . . . 10 6. Message type and format for IGCP . . . . . . . . . . . . . . . 11 6.1. IGCP Information Exchange Messages . . . . . . . . . . . . 11 6.2. IGCP Negotiation Messages . . . . . . . . . . . . . . . . 14 7. Considerations of Usage in IPv4 Networks . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Example domain of application of IGCP: The growing concept of Self-Management and Adaptive Control . . . . . . . . . . . . . . . . . . . . . . . 23 A.1. The growing concept of Self-Management and Adaptive Control . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. The need for a multi-purpose Generic Control Protocol in IP based networks . . . . . . . . . . . . . . . . . . . 28 A.3. Example Customization of the Data Part of IGCP and Use Case Scenario of the IGCP Information Exchange Messages . 30 Appendix B. Conclusions . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Chaparadza, et al. Expires January 20, 2012 [Page 3] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 1. Requirements notation 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 [RFC2119]. Chaparadza, et al. Expires January 20, 2012 [Page 4] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 2. Introduction The Draft proposes a Generic Control Protocol Framework that is customizable for different types of usage contexts (use cases) in which certain types of control information exchange messages and control behavioral semantics among the involved Functional Entities hosted by different nodes/devices are required. Being "Generic" means having the following properties: 1. Having a Common Part i.e. a Header in the Message Format that defines a set of a variety of control semantics (e.g. simple one- way control information flow, indications of whether an acknowledgement is needed or not, solicitations for information or push/pull behaviors, negotiations for parameter value settings, etc). The control semantics are meant to be diverse and selectable by functional entities exchanging control messages. 2. Having a Generic Data Part as payload part of the Message Format that can be customized and further structured according to the identified requirements for control communication between two or more types of Functional Entities that need to parse and interpret the Data Part in their own way customized for them by design. Chaparadza, et al. Expires January 20, 2012 [Page 5] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 3. Problem Statement The trend in designing protocols for control information exchange between two or more functional entities residing in different nodes/ devices in the network has often resulted in control protocols that are specific only to the needs of the functional entities involved. Multiple control protocols exist today and yet share very similar control semantics and in most cases they are difficult to extend or apply for other requirements for control semantics introduced by the evolving networking paradigms. Different types of a variety of control semantics are often used to design a control protocol, such as (1) simple one-way control information flow with or without requiring acknowledgement of receipt of information by the receiver; (2) solicitations for information or push/pull behaviors by the functional entities involved; (3) negotiations by the entities involved in the process of performing parameter value settings, etc). Some functional entities in network nodes/devices need to exchange control information in order to implement adaptive network behavior and dynamic network configuration and optimization that is co- ordinated by the functional entities collaboratively. Such functional entities can be an application, protocol or some other type of an entity that communicates with other peer entities hosted by other nodes/devices. In the emerging networking paradigms, the growing area of self- management, self-organization and autonomic networking introduces functional entities into the node/device and overall network architectures that need to exchange control information in order to implement adaptive network behavior and dynamic network configuration and optimization that is co-ordinated by the functional entities collaboratively. Such functional entities can be, for example, distributed management components playing the role of "micro-manager elements" embedded in two or more nodes/devices, which co-operatively work together to realize distributed management and adaptive control of resources such as protocols, stacks and mechanisms. This because some degree of intelligence can be introduced or enhanced within a network element e.g. a router by introducing embedded "micro-manager elements" that monitor events reported by local entities such as protocols (for example by accessing a management MIB(s)) and react by adaptively provisioning resources or regulating the behaviour of the managed protocols in order to fulfill some objective (e.g. reducing the amount of control traffic transmitted by the network element). This means the "micro-manager elements" configure, apply policies, monitor and dynamically adapt the behaviour of the Managed Entities (MEs) such as protocols, stacks and mechanisms. The "micro-manager elements" can be developed to operate at a level of abstraction that is above protocol stacks and mechanisms of a device, since such a level of abstraction does not necessarily require changes to existing Chaparadza, et al. Expires January 20, 2012 [Page 6] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 protocols. Such micro-manager elements can be perceived as "Decision-making-Elements" controlling (regulating) or managing (in general sense) some aspects of a node/device and protocols since the control-plane is viewed as a kind of horizontal extension of the management plane within the network itself, outside of the notion of the vertical management plane that involves management systems. The "micro-manager elements" may require the ability to perform the following operations: (a) Negotiating the way their assigned Managed Entities (MEs) e.g. Protocols, Stacks and mechanisms of the node/ device, should be configured or dynamically re-configured. The need to negotiate configuration settings e.g. parameter value settings applies to the case where there is no need to involve a centralized coordinating entity (e.g. Network Management System), and so the peer "manager elements" in nodes/devices need to self-organize certain aspects of the network e.g. the way some protocols must behave according to some policies. (b) Soliciting for Capabilities of the peer manager element or multiple peers based on the features supported by their associated MEs(i.e. capabilities of the managed protocols, stacks and mechanisms--managed resources). (c) Self- Advertising Capabilities of functional entities such as a node/device as a whole to peer "manager elements" hosted by devices on the link, or to selected peers by policy. (d) Exchanging Trust related information/data. (e) Exposing "Views" to peer "manager elements", such as detected incidents, misbehaviors, etc, which can be used by the peers for adaptive (re)-configuration of their associated MEs. (f) Requesting for "Views" from peer "manager elements". A Generic Control Protocol Framework that is extensible, and defines a set of a variety of control semantics that can be selectively used by functional entities intending to communicate or exchange control information, if defined for IP networks, would serve as a "multi- purpose" Generic Control Protocol in IP based networks and would cost-effectively ease the development of adaptive behaviours of diverse types of functional entities. An example of a control protocol that exists today that enables nodes/devices in IP networks to communicate to each other some control information and is extensible is ICMPv6. A number of proposals have emerged recently, regarding information sharing between nodes/devices. For example in [RFC4620] two messages are defined: Node Information Query and Node Information Reply, but they are designed to be used only for discovering information about names and addresses. ICMPv6 messages are subdivided into two classes: Error messages and Information messages. ICMPv6 (like a number of IPv6 protocols) offers some room for Extensibility depending on the need for exchanging Control Related Information and/or Use Case Context in which some Extension is required to the base ICMPv6 protocol. Therefore, ICMPv6 offers a base for developing a Generic "multi-purpose" Control Protocol as an Extension to ICMPv6. But, de-coupling the generic control protocol Chaparadza, et al. Expires January 20, 2012 [Page 7] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 from being an explicit extension to ICMPv6, means the generic multi- purpose control protocol could be developed as a standalone protocol that can be used in both IPv4 and IPv6. Proposal in brief (more details are provided in the next sections): An IP based Generic Control Protocol(IGCP) Framework that is customizable to specific usage contexts in which certain types of control information exchange messages and control behavioral semantics among some Functional Entities hosted by different nodes is desired. Being "Generic" means having the following properties: 1. Having a Common Part i.e. a Header in the Message Format that defines a set of a variety of control semantics (e.g. simple one-way control information flow, indications of whether an acknowledgement is needed or not, solicitations for information or push/pull behaviors, negotiations for parameter value settings, etc). The control semantics are meant to be diverse and selectable by functional entities exchanging control messages. 2. Having a Generic Data Part as payload part of the Message Format that can be customized and further structured according to the identified requirements for control communication between two or more types of Functional Entities that need to parse and interpret the Data Part in their own way customized for them by design. The Data field must be left to be customized and defined according to the specific needs of specific types of functional entities that need to exchange control information. Later, at the end of the Draft, we also give an example domain of application of the IGCP, namely the domain of autonomic adaptive control of network behaviours, of which we illustrate further by providing an example Use Case that customizes the Data Part of the IGCP for use by special functional entities residing in different nodes in exchanging information using the IGCP messages. Chaparadza, et al. Expires January 20, 2012 [Page 8] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 4. The Proposed Solution (IGCP: IP-based Generic Control Protocol) and its application (Usage Scenarios) For all the requirements for control information exchange listed in the problem statement, we propose to introduce some generic IGCP messages that can be used by different types of functional entities requiring communicating with each other across nodes/devices. The IGCP header consists of the first part that can be used for different purposes as allowed by the fields defined later in this draft, and a Data part. The Data part can be further structured according to the identified requirements of different types of functional entities that need to exchange control information. We propose that the Data field be left to be customized and defined according to the specific needs of specific types of functional entities that need to exchange control information. An example of how the Data field can be customized for a particular Use Case Scenario of the IGCP is presented later. 4.1. Generating an IGCP message/packet Entities generating an IGCP packet (e.g. DEs) should reason about: 1. When to generate the IGCP packet. 2. The IP addressing for the IGCP packet: Unicast, Multicast or Anycast. 3. The required forwarding behaviour for the IGCP packet. In IPv6, this may involve selectively combining Hop-By-Hop Options Header; Routing Header (this may require a new Routing-Type to be added to existing ones to support this behaviour), and/or Destination Options Header whenever applicable now and in the future evolution of IPv6. 4. In IPv6 networks, Neighbor Discovery (ND) protocol events may be used as triggers to the generation of an IGCP packet e.g. an entity that could leverage Neighbor Discovery related events may listen for such events and generate an IGCP message to some other peer entities in other nodes/devices in order to send information or update peers. Chaparadza, et al. Expires January 20, 2012 [Page 9] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 5. Conventions used in this document In the future revision. Chaparadza, et al. Expires January 20, 2012 [Page 10] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 6. Message type and format for IGCP We propose three types of generic IGCP messages for addressing the requirements outlined earlier in the problem statement, namely: ({Information Request}, {Information Offer} and {Information ReceiptACK}) and two messages for addressing the need for "negotiations" discussed earlier in the problem statement ({Negotiation Offer}, {Negotiation Reply}). The messages are of a somewhat a similar category to informational messages defined by ICMPv6. 6.1. IGCP Information Exchange Messages In [RFC4620] two messages are defined: Node Information Query and Node Information Reply, but they are designed to be used only for discovering information about names and addresses. We propose three new types of IGCP messages for facilitating the exchange of generic control information: {Information Request}, {Information Offer} and {Information ReceiptACK} messages, that share the same general format presented below Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Id | Receiver_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group_Id | InfoType | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Information Request/Offer/ReceiptACK Messages. Type IGCP message type. Code For Information Request it can be used to further distinguish between different categories of information: capabilities of a functional entity e.g. a node/device , views regarding incidents and policies, etc. For Information Offer: Chaparadza, et al. Expires January 20, 2012 [Page 11] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 * 0 - Indicates that a confirmation is needed (the receiver should send an Information ReceiptACK message in response to this Information Offer message). It means that the Information Offer message is not a response to an Information Request, but that the push model is being used instead. * 1 - Indicates a successful reply to an Information Request message. * 2 - Indicates that no confirmation is needed (no Information ReceiptACK message should be sent in response). * 3 - Indicates that the receiver of an Information Request message refuses to provide the requested information (maybe because of prohibiting local policies) * 4 - Indicates that the InfoType field is unknown to the responder or the Data field could not be decoded accordingly to the InfoType field. For Information ReceiptACK: * 1 - Indicates that the information was successfully received and processed. * 3 - Indicates that the InfoType field presented in the Information Offer is unknown to the responder or the Data field could not be decoded accordingly to the InfoType field. Checksum IGCP checksum. Sender_Id A 16-bit field used to identify the sender functional entity. The identifier must be unique among all the functional entities inside a node since there can be multiple types of a functional entity inside a node/device that use the IGCP, each type of which requires its own customized use of the Data Part of the IGCP. Receiver_Id This field is similar to the Sender_Id, but it is used for identifying the receiver inside the node/device. Group_Id There can be a case when an IGCP message is of interest to more than one functional entity inside a node. For that purpose we envision that different groups of interest can be set up, and different functional entities inside the node can be part of a Chaparadza, et al. Expires January 20, 2012 [Page 12] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 specific group. This field should be used for identifying the group of functional entities for which the message is addressed. IDs and Group-ID need to be discovered, say in a similar fashion to the way Neighbor Discovery (ND) in IPv6 works. InfoType A 16-bit field that indicates the type of information requested in an Information Request or supplied in an Information Offer. Its value in a reply should be always copied from the corresponding received message (for an Information Offer with code different from 0 it should be copied from the corresponding Information Request message and for Information ReceiptACK it should be copied from the Information Offer message). The Information types need to be further researched. Flags There are specific flags for each InfoType defined for Information Requests or Offers. When no flags are defined for a given InfoType, this field must be zero on transmission and ignored on reception, and must not be copied from a Request to a Reply. An example of how the flags can be used is presented later on. Data We propose to keep the data field as "generic" as possible. The Data field must be left to be customized and defined according to the specific needs of specific types of functional entities that need to exchange control information (e.g. different types of functional entities called Decision Elements (DEs) in the case of a GANA based network described in [Chaparadza-FIA-Prague2009]). An example of how the Data field can be used is presented later in this draft. The messages described above provide just the basic fields that can be used by any functional entity intending to exchange control information. The Data part of the message can be customized to have different fields and structure according to the specific needs of the functional entities involved in the information exchange process. The structure of the Data field is determined by the value of the InfoType field. The Information Request message is used for requesting different types of information such as capabilities of functional entities (including protocols and mechanisms), "Views" (e.g. regarding incidents in the network or link state) etc. The Information Offer message is primarily meant to be sent in response to an Information Request message, but there are cases when the push model needs to be used and then the targeted functional entity could send directly an Information Offer message. The sender of an Information Offer Chaparadza, et al. Expires January 20, 2012 [Page 13] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 message can choose to request an acknowledgment or not by using the Code field inside the message. If an acknowledgment is required then the receiver of the Information Offer message must construct and send an Information ReceiptACK message. 6.2. IGCP Negotiation Messages The {Negotiation Offer} and {Negotiation Reply} messages have the same structure presented as in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Id | Receiver_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group_Id | NegType | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SessionId | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Negotiation Offer/Reply Messages. Type IGCP message type. Code Not used set to 0. Sender_Id A 16-bit field used to identify the sender functional entity. The identifier must be unique among all the functional entities inside a node since there can be multiple types of a functional entity inside a node/device that use the IGCP, each type of which requires its own customized use of the Data Part of the IGCP. Receiver_Id This field is similar to the Sender_Id, but it is used for identifying the receiver inside the destination node/device. Chaparadza, et al. Expires January 20, 2012 [Page 14] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 SeqNum The 32-bit sequence number of the negotiation message inside a negotiation session. This field is important for mapping a Negotiation Reply message to the corresponding Negotiation Offer Message. Its value must be set by the sender in a Negotiation Offer message and should be copied by the receiver into the Negotiation Reply message. Group_Id There can be a case when an IGCP message is of interest to more than one functional entity inside a node. For that purpose we envision that different groups of interest can be set up, and different functional entities inside the node can be part of a specific group. This field should be used for identifying the group of functional entities for which the message is addressed. NegType Negotiation Type is a 16-bit field that indicates the negotiation protocol used for the current negotiation session. Its value is set in the Negotiation Offer message by the initiator of a negotiation session and must remain unchanged during the whole session. Flags There are specific flags for each NegType defined for Negotiation Offer or Negotiation Reply. When no flags are defined for a given NegType, this field must be zero on transmission and ignored on reception, and must not be copied from a Request to a Reply. SessionId An 16-bit field used to identify the messages that correspond to a negotiation session. Its value must be set up by the initiator of the negotiation session and this value must remain unchanged during the whole session. Reserved 16 bits of reserved space Data Negotiation data. The Negotiation Offer and Negotiation Reply messages (Figure 2) presented in the previous section are meant to be generic messages for facilitating the negotiation process between two or more functional entities. They provide the basic fields that may be required during the negotiation. The Data field should be used for carrying the additional information necessary in a specific case of negotiation. The negotiation process could be done in more than one Chaparadza, et al. Expires January 20, 2012 [Page 15] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 step, as illustrated in Figure 3. Functional Functional Entity 1 Entity 2 | | | Negotiation Offer 1 | |------------------------->| | Negotiation Reply 1 | |<-------------------------| | | | | | Negotiation Offer 2 | |------------------------->| | Negotiation Reply 2 | |<-------------------------| | | Figure 3: Negotiation Process. The negotiation process can be based on a simple mechanism like in the case of HTTP content negotiation [RFC 2616], [RFC 2295] or more sophisticated negotiation algorithms may be developed when necessary. Chaparadza, et al. Expires January 20, 2012 [Page 16] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 7. Considerations of Usage in IPv4 Networks Fragmentation support discussion in future revision. Chaparadza, et al. Expires January 20, 2012 [Page 17] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 8. Security Considerations In the future revision. Chaparadza, et al. Expires January 20, 2012 [Page 18] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 9. IANA Considerations In the future revision. Chaparadza, et al. Expires January 20, 2012 [Page 19] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 10. Acknowledgements A number of people have contributed to the text and ideas. The list of these people include Shiduan Cheng (BUPT), Yuhong Li (BUPT), Tony Jokikyyny (Ericsson), Jan Melen (Ericsson). In addition to people who have themselves contributed many ideas have come from the EU project consortium [EFIPSANS]. Our apologies to anyone whose name is missing. Chaparadza, et al. Expires January 20, 2012 [Page 20] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 11.2. Informative References [Ballani-Francis-ACM-SIGCOMM-vol37] Ballani, H. and P. Francis, "CONMan: A Step Towards Network Manageability", ACM SIGCOMM Computer Communications Review, Volume 37(4), pages 205-216, 2007. [Chaparadza-FIA-Prague2009] Chaparadza, R., Papavassiliou, S., Kastrinogiannis, T., Vigoureux, M., Dotaro, E., Davy, A., Quinn, K., Wodczak, M., Toth, A., Liakopoulos, A., and M. Wilson, "Creating a viable Evolution Path towards Self-Managing Future Internet via a Standardizable Reference Model for Autonomic Network Engineering", FIA Prague 2009 Conference, Published in the Future Internet Book, 2009. [Chaparadza-IEC-v60-Dec2007] Chaparadza, R., "Evolution of the current IPv6 towards IPv6++ (IPv6 with Autonomic Flavours)", Published by The International Engineering Consortium (IEC) in the Review of Communications, Volume 60, Dec 2007. [Chaparadza-IEC-v61-Dec2008] Chaparadza, R., "Requirements for a Generic Autonomic Architecture (GANA), suitable for Standardizable Autonomic Behaviour Specifications of Decision-Making-Elements (DMEs) for Diverse Networking Enviroments", Published by The International Engineering Consortium (IEC) in the Review of Communications, Chaparadza, et al. Expires January 20, 2012 [Page 21] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Volume 61, Dec 2008. [EFIPSANS] EFIPSANS, "EC funded- FP7-EFIPSANS Project", . [Greeberg-ACM-SIGCOMM-vol35] Greenberg, A., "A clean slate 4D approach to network control and management", ACM SIGCOMM Computer Communications Review, Volume 35(5), pages 41-54, 2005. [Retvari-MACE2009] Retvari, G., Nemeth, F., Chaparadza, R., and R. Szabo, "OSPF for Implementing Self-adaptive Routing in Autonomic Networks: a Case Study", in proceedings of the 4th IEEE International Workshop on Modeling Autonomic Communication Environments (MACE2009), Venice, Italy, Oct 2009. Chaparadza, et al. Expires January 20, 2012 [Page 22] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Appendix A. Example domain of application of IGCP: The growing concept of Self-Management and Adaptive Control A.1. The growing concept of Self-Management and Adaptive Control Self-Management and Adaptive Control is a new growing concept for networks in which so-called Autonomic Manager Entities (i.e. Decision-making-Elements) are introduced into the node/device architectures and the overall network architecture (refer to Figure 4 and Figure 5). The manager entities are required for "autonomically" configuring and controlling i.e. regulating and dynamically adapting the behaviour of network protocols and mechanisms by setting and re- setting parameters(variables) i.e. invoking management operations (in general) exposed by the "management interfaces" of the individual protocols and mechanisms based on some dynamic views analyzed by the manager entities. Such views can be goals and policies governing the way the protocols, stacks and mechanisms should be configured and adaptively adjusted, or incidents observed and processed by the manager entities. Autonomic management and control as the paradigm may be called aims at automating management operations/functions while at the same time ensuring self-adaptation of individual systems and the network through interacting control-loop structures designed to operate at various levels of abstraction of functionality. The notion of "control" is associated with a combination of "observing, supervision/regulating/adapting behaviour of managed entities i.e. something a controller from control-theory does. The manager entities need to be able to communicate with each other some control types of messages depending on their co-operative goal as discussed later in this draft. We shall refer to the Autonomic Manager Entities as Decision-Making-Elements. Recently, an example of an evolvable, standardizable architectural Reference Model for Autonomic Networking and Self-Management within node and network architectures, dubbed the Generic Autonomic Network Architecture (GANA), has emerged [EFIPSANS] [Chaparadza-IEC-v60-Dec2007]. The concept of Autonomicity - realized through control-loop structures operating within network nodes/devices and the network as a whole, is an enabler for advanced and enriched self-manageability of network devices and networks. A central concept of GANA is that of an autonomic Decision-Making-Element ("DME" or simply "DE" in short-for Decision Element). A Decision Element (DE) implements the logic that drives a control-loop over the "management interfaces" of its assigned Managed Entities (MEs) e.g. protocols, stacks and mechanisms. An advanced Decision-making-Element (DE) may exhibit cognitive behaviour. Therefore, in GANA, self-* functionalities such as self-configuration, self-healing, self-optimization, etc, are functionalities implemented by a Decision Element(s). The "generic nature" of GANA lies in the definition of the interfaces and their Chaparadza, et al. Expires January 20, 2012 [Page 23] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 fundamental operations that need to be supported by a Decision Element, the interconnection and relations among the DEs within node and network architectures, as well as the assignment of the types of Managed Entities (MEs) that are managed by their associated DEs, including the fundamental operations that must be supported on the management-interfaces of the individual MEs. In [Chaparadza-IEC-v60-Dec2007] different types of "instantiation" of GANA for autonomic network management and adaptive control of protocols for different types of network environments are illustrated. The Generic Autonomic Network Architecture (GANA) [Chaparadza-IEC-v61-Dec2008] introduces "autonomic manager components/elements" known as Decision-Making-Elements (DMEs or in short - DEs) meant to operate at four different abstraction levels of functionality. These "autonomic manager components" are designed following the principles of "hierarchical", "peering", and "sibling" relationships among each other within a node or network. Moreover, these components are capable of performing autonomic control of their associated Managed-Entities (MEs), as well as co-operating with each other in driving the self-managing features of the Network(s). In GANA, four basic hierarchical levels of abstractions for which DEs, MEs, Control-Loops and their associated dynamic adaptive behaviours can be designed (refer to Figure 4 and Figure 5). The levels of abstractions are as follows: o Level-1: protocol-level (the lowest level) by which self-management is associated with a network protocol itself (whether monolithic or modular). This applies to those kinds of protocols that need to intrinsically embed control-loops similar to the type of control- loops embedded in TCP or OSPF. There is growing opinion, however, that future protocols need to be simpler (i.e. with no decision logic embedded) than todays protocols which have become too hard to manage due undesired emergent behaviour during operation and interaction with other protocols. This means, there is a need to rather implement decision logic at a level higher (i.e. outside the individual protocols)[Refer to sources such as CONMan [Ballani-Francis-ACM-SIGCOMM-vol37], 4D [Greeberg-ACM-SIGCOMM-vol35], etc.] o Level-2: the abstracted function-level (directly above the protocol(s)-level) that abstract some protocols and mechanisms associated with a particular function e.g. routing, forwarding, mobility management, etc-whereby we can reason about autonomic routing (see example instantiation of GANA for realizing autonomic routing in [Retvari-MACE2009]), autonomic forwarding, autonomic fault-management, autonomic configuration management; Chaparadza, et al. Expires January 20, 2012 [Page 24] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 o Level-3: the level of the node/device's overall functionality and behaviour i.e. a node or system as a whole is also considered as level of self-management functionality; o Level-4: the level of the network's overall functionality and behaviour (the highest level). The figure below (Figure 4) illustrates that at node/system level of self-management (autonomic) properties, the lower level Decision-Making-Elements operating at the level of abstracted networking functions become the Managed-Entities of the main Decision-Making-Element (DME) of the system (node). This means the node's main DME has access to the "views" exposed by the lower level DMEs and uses its overall knowledge to influence (enforce) the lower level DMEs to take certain desired decisions, which may in turn further influence or enforce desired behaviours on their associated Managed-Entities, down to the lowest level of individual protocol behaviour. A "Sibling" relationship simply means that the entities are created or managed by the same upper level Decision-Making-Element (DME/DE). Chaparadza, et al. Expires January 20, 2012 [Page 25] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Node X Node Y +--------------------+ +-----------------------------------------+ | | | | |Objectives, Policies| |Objectives, Policies | | from a higher level| | from a higher level | | (Network-Level-DE) | | (Network-Level-DE) | | | | | | | | | | | | | | | | | | | | | |+----- V V V ------+| |+----- V V V ------+ | || Main Decision |Peers| Main Decision | | || Element of the |<--->| Element of the |<-----------+ | || Node (Node-DE) || || Node (Node-DE) | | | |+------------------+| |+------------------+ | | | | | | | V | |+------------------+| |+------------------+ +----------------+| || Decision Element || || Decision Element | |Decision Element|| || of an abstracted |Peers| of an abstracted | |of an abstracted|| || Network Function |<--->| Network Function |<->|Network Function|| || e.g. Routing- || || e.g. Routing- | | | e.g. QoS- || || Management-DE || || Management-DE | | | Management-DE || |+------------------+| |+------------------+ | +----------------+| | | | | | +__ | |+------------------+| |+------------------+ \ | || Decision Element || || Decision Element | Example Interaction| || intrinsic to a |Peers| intrinsic to a | between Sibling | || Routing Protocol |<--->| Routing Protocol | Decision Elements | || e.g. OSPF || || e.g. OSPF | | |+------------------+| |+------------------+ | +--------------------+ +-----------------------------------------+ Figure 4: Hierarchical, Peering, Sibling Relations and Interfaces of DEs in GANA. This means that the entities having a sibling relation can still form other types of peer relationship within the autonomic node or with other entities hosted by other nodes in the network, according to the protocol and communication needs defined for their needs to communicate with other DEs. The GANA Level-4 i.e. the "network-level" represents the last level of autonomicity i.e. the highest level of self-manageability (determined by some associated control-loops for autonomicity). There may exist a logically centralized network-level Decision- Making-Element(s) or the kind of DEs proposed in the 4D network architecture [Greeberg-ACM-SIGCOMM-vol35] belonging to an isolated "overlay decision cloud" outside the nodes/devices (refer to Figure 5), which is considered to know (through some means) the objectives, goals or policies to be enforced by the whole network. Chaparadza, et al. Expires January 20, 2012 [Page 26] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 The objectives, goals or policies may actually require that the main (top-level) DMEs of the nodes of the network that are covered by the logically centralized network-level DME(s) in the "overlay decision cloud", export "views" such as events and state information to the logically centralized DME(s). This may happen in order for the logically centralized DME to influence or enforce the DMEs of the nodes to take certain desired decisions following specific network policies that may in turn have an effect of inductive decision changes on the lower level DMEs of individual nodes/devices i.e. down to protocol level decisions. A distributed network-level control- loop may be implemented following the above set-up, while another case of implementing a distributed control-loop would involve the main Decision-Making Elements of nodes/devices working co- operatively to self-organize and manage the network without the need or intervention of a "specially instrumented" logically centralized higher level network-level DME(s) in an isolated "overlay decision cloud". Such a logically centralized network-level DME(s) would be meant to manage the whole network and should be hosted in a special machine(s) whose resources are only dedicated to network state data analysis, data mining and management operations that must work in harmony with autonomous self-management at node-level down to the protocol-level. The second case implies that the nodes/devices need to be designed in such a way as to have the possibility for the nodes/devices themselves to self-organize and perform "intrinsic" management and control-which can only be achieved to a certain extent due to resource limitations of the nodes/devices and the problem of longer convergence time with some distributed decision-making algorithms. All DEs from an stack with a "vertical view" and a "horizontal view" of interfaces and interworking with each to form the Decision-Plane of the network. The vertical view would replace in the long term, the traditional Management Plane. In the GANA Reference Model: o Lower level DEs expose "views" up the Decision Plane, allowing the upper (slower) control loops to control the lower level (faster) control-loops (lower level DEs). o Changes computed in the upper DEs implementing slower Control- Loops are propagated down the DE hierarchy to the Functions-Level DE(s) implementing the faster control-loops that then arbitrate and enforce the changes to the lowest level Managed Entities (protocols and mechanisms). In [Retvari-MACE2009] an instantiation case for autonomic management and control of IPv6 routing protocols and mechanisms is illustrated. The GANA Reference Model can be viewed as a holistic architectural Chaparadza, et al. Expires January 20, 2012 [Page 27] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Reference Model for autonomic network engineering and self- management. It is holistic in the sense of the four basic levels of abstraction of functionality at which "inter-working nested control- loops for self-management" can be introduced. Moreover, it is meant to also address what may simply be called "intrinsic management control and within a node/device and collaboratively among network devices" as well as depicting "boundaries and constraints" for this type of intrinsic management and control. This means that the issues that require centralization of some of the autonomic decision-making processes of the network should be captured and defined by such the GANA Reference Model. In addition, appropriate interfaces of the kind of Network- level Decision Elements (DEs) that take care of the sophisticated centralized decision-making-processes must be defined by GANA. Network-Level DEs must allow for some "network-intrinsic management and decision-making-processes" to take place harmoniously at a lower level within the network nodes/devices themselves. In GANA, Network-level DEs, which implement the "slower control-loops", need to interact with the lower level (Function-Level DEs) that implement "faster control-loops" within the nodes/devices. We refer the reader to [Chaparadza-FIA-Prague2009] for more information on the subject. DEs operating at a certain level within GANA hierarchy of DEs may need to exchange control information, as described in the next section. A.2. The need for a multi-purpose Generic Control Protocol in IP based networks In IP-based node and network architectures that introduce such manager entities that need to exchange different types of control messages for the purposes outlined below, there is a need to introduce a generic control protocol in order to address the requirements outlined below. The protocol (IGCP) should capture the parts that must be generic in the types of messages while identifying the items that must be mandatory in those types of messages. IGCP can be used by any entities of a node that require to exchange control messages, not just Manager Entities (i.e. DEs) presented by the GANA Reference Model. In the case of Manager Entities such as the GANA DEs, residing in two or more nodes/devices, the entities may require the ability to perform the following operations: (a) Negotiating the way their assigned Managed Entities (MEs) e.g. Protocols, Stacks and mechanisms of the node/device, should be configured or dynamically re-configured. The need to negotiate configuration settings e.g. parameter value settings applies to the Chaparadza, et al. Expires January 20, 2012 [Page 28] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 case where there is no need to involve a centralized coordinating entity (e.g. Network Management System), and so the peer "manager elements" (i.e. DEs) in nodes/devices need to self-organize certain aspects of the network e.g. the way some protocols must behave according to some policies. (b) Soliciting for Capabilities of the peer manager element (DE) or multiple peers based on the features supported by their associated MEs(i.e. capabilities of the managed protocols, stacks and mechanisms--managed resources). (c) Self-Advertising Capabilities of functional entities such as a node/device as a whole to peer "manager elements" (DEs) hosted by devices on the link, or to selected peers by policy. (d) Exchanging Trust related information/data. This could be done by the Node_DE (autonomically manages and controls the behaviour of the whole node) or also at lower level DEs within the node/device. (e) Exposing "Views" to peer DEs, such as detected incidents, mis- behaviours, etc, which can be used by the peers for managing the (re)-configuration of their associated MEs. (f) Requesting for "Views" from peer DEs. Chaparadza, et al. Expires January 20, 2012 [Page 29] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 __ ___ -- --- ------/ \--------/ \------ -----/ \---- +----/ +-------------------------+ \-- +---+ | Other Network-Level-DEs | \- +--+ +--| | \ +-+ | +-------------------------+ +- | | Network-Level- | -+ + +--| QoS-Management-DE |<------+ |- +- | +-------------------------+ | -+ +-- | Network-Level- |<---------+ --/ \--- +---->| Routing-Management-DE | ---/ \-|--- +-------------------------+ ----/ | \------ ------- -----------/ | \--/ \---/ | Node X | Node Y +---------- V ------------+ +-------------------------+ | +---------------------+ | | +---------------------+ | | | Decision Element of | | | | Decision Element of | | | | the Node (Node-DE) |<------------->| the Node (Node-DE) | | | +---------------------+ | | +---------------------+ | | | | | | | | +---------------------+ | | +---------------------+ | | | Decision Element of | | | | Decision Element of | | | | an abstracted | | | | an abstracted | | | | Network Function |<------------->| Network Function | | | | e.g. Routing- | | | | e.g. Routing- | | | | Management-DE | | | | Management-DE | | | +---------------------+ | | +---------------------+ | | | | | | | | +---------------------+ | | +---------------------+ | | | Routing Protocol(s) | | | | Routing Protocol(s) | | | | and Mechanisms | | | | and Mechanisms | | | | of a node |<------------->| of a node | | | | e.g. OSPF | | | | e.g. OSPF | | | +---------------------+ | | +---------------------+ | +-------------------------+ +-------------------------+ Figure 5: DEs communicating using IGCP. A.3. Example Customization of the Data Part of IGCP and Use Case Scenario of the IGCP Information Exchange Messages IGCP is meant to be used by any functional entities intending to exchange control messages for any of the requirements outlined earlier in the problem statement. Here we focus on one example of a Chaparadza, et al. Expires January 20, 2012 [Page 30] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 usage case of IGCP. In the following paragraphs, we give a concrete example of how the Information Offer message can be used for exchanging control information by two GANA DEs residing in different nodes/devices. Here, we focus on the FUNCTION_LEVEL_ROUTING_MANAGEMENT_DEs (FUNC_LEVEL_RM_DEs) that, according to the GANA Model, are sitting on top of their Managed Entities (MEs) i.e. the routing protocols and mechanisms of a node/ device and use specially customized messages to communicate with each other across nodes/devices. In [Retvari-MACE2009] where an instantiation case for autonomic management and control of IPv6 routing protocols and mechanisms is illustrated, it is argued that decision logic designed to operate outside and at a level of abstraction above protocols enables such instrumented decision logic to configure and dynamically adapt the behaviour of protocols based on information about the network and its goals that is not known or available to the individual protocols managed by such decision logic. Therefore, Function-Level-Routing-Management-DE (FUNC_LEVEL_RM_DE) inside a node is responsible for autonomic management and control of the routing protocols and mechanisms of a node by orchestrating the routing protocols, configuring them and applying policies, as well as listening for context changes and incidents and adapting the protocol behaviours. In order to efficiently, autonomically manage and control the Managed Entity (ME) e.g. the OSPF protocol based on context changes and incidents, by setting and resetting some parameters such as those defined by the Management Information Base (MIB) for the target protocol e.g. Timers and link-weights in OSPF, FUNC_LEVEL_RM_DEs in different nodes/devices in the network need to exchange control information. They need to encapsulate the control information into the Data field of the previously described messages. For this example case of control information exchange according to the requirements presented earlier, three messages from the point of view of the customizable Data Part of an IGCP message, are introduced and their structure and fields are described below. Therefore, we illustrate how the Data field can be specially tailored i.e. customized for exchanging link state information that complements link state information exchange intrinsically built into OSPF. The FUNC_LEVEL_RM_DE of a router is responsible for autonomically managing and controlling the behaviour of all the routing protocols and mechanisms of the device e.g. OSPF (refer to [Retvari-MACE2009], [Chaparadza-FIA-Prague2009] for more detailed information on the description of the FUNC_LEVEL_RM_DEs). The adaptive control is realized in a distributed manner as the FUNC_LEVEL_RM_DEs residing on different routers exchange information in order to take the most appropriate decisions for the overall network, such as how to adjust OSPF's timers to control the convergence or use FRR (Fast-Re-Route) to protect destroyed paths. Three kinds of messages that customize the Data Part of the IGCP are Chaparadza, et al. Expires January 20, 2012 [Page 31] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 introduced for facilitating the information exchange between FUNC_LEVEL_RM_DEs and their structure is presented below. The reason why the DEs need to exchange the same types of messages that are exchanged by OSPF is that DEs must detect the state of the network in advance. The FUNC_LEVEL_RM_DE is a kind of controller of OSPF, so it must discover the change of the network before OSPF and decide how to adjust OSPF's running status. Using the same types of messages is for the consistency with OSPF. The FUNC_LEVEL_RM_DEs should discover the failure of the link/node before OSPF finds it and decide what to do with the failure. For example, when a link in the network is disconected, the DEs will discover the failure first because of much higher hello sending frequency. If the DE does nothing with the failure, OSPF will discover and handle the failure in more than 30 seconds, and that is not acceptable if the broken link has a high importance. Rather, the DE will adjust the timer so that OSPF will become more sensitive and discover the failure soon, so the failure will be recovered in an acceptable time. At the same time, DEs should acquire and keep the same cognitive knowledge concerning the network as the OSPF so that they will be able to spot a failure and make a protective remediation decision. From the above we can conclude that DEs need to run a similar protocol as OSPF to detect the state of the network by exchanging the same types of messages that are exchanged by OSPF. The difference is that DEs send hello messages with a much higher frequency to be much more sensitive than OSPF. The reason why the FUNC_LEVEL_RM_DEs do not use BFD (Bi-directional Forwarding Detection) as a usable option is that DEs run a link state detecting protocol similar to OSPF not only for detecting the links' state and discovering failures, but also for keeping the same cognitive knowledge concerning the network as the OSPF. DEs (FUNC_LEVEL_RM_DEs) build a link state database, the database is considered to be the same as OSPF's link state database. DEs use the link state database to calculate the importance of each link, and figure out the damage degree of the network after failures have occurred. Additionally, using an independent hello mechanism would be more general and facilitate the deployment of DEs, so DEs do not use options such as BFD to detect the link state. FUNC_LEVEL_RM_DEs are NOT meant to replace OSPF but they configure OSPF and dynamically re-configure OSPF in trying to adapt the protocol behaviour according to events and incidents detected in the network's operation. The FUNC_LEVEL_RM_DE uses two methods to configure OSPF, one is adjusting OSPF's timers while the other is using FRR (Fast-Re-Route) to replace broken paths with backup routes. When OSPF converges, the DEs will calculate backup route for the important links. If the links are broken, the DE will activate the Chaparadza, et al. Expires January 20, 2012 [Page 32] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 backup route and use it to replace the broken route to guarantee communications(connectivity). When the network converges again, the DE will cancel the backup route and calculate the backup routes for important links again. Neighbouring FUNC_LEVEL_RM_DEs discover each other and establish bidirectional communications by sending and receiving continuous Hello messages. After establishing the communication, they synchronize the link state database with each other by sending Link State Exchange message, so that the FUNC_LEVEL_RM_DEs in the network will have the same link state database. If a link state changes, such as a link failure, the FUNC_LEVEL_RM_DE that detects the change will send a Link State Advertisement message to all its neighboring FUNC_LEVEL_RM_DEs. Receiving the message, the neighboring FUNC_LEVEL_RM_DE will update its local link state database and relay the message to all of its neighboring DE, so that the change of the link state will be known by all the FUNC_LEVEL_RM_DEs in the network. The Hello message (Figure 6) is used for establishing and maintaining connections to the neighbouring FUNC_LEVEL_RM_DEs. Hello messages are sent by each FUNC_LEVEL_RM_DE every Hello_Interval seconds from all router interfaces in order to establish a bidirectional communication with all its FUNC_LEVEL_RM_DEs neighbours. When two FUNC_LEVEL_RM_DEs have established a bidirectional communication, they begin to synchronize their topology databases. The synchronization is performed by using Link State Exchange messages (Figure 7). This process takes place in two steps. First, the two FUNC_LEVEL_RM_DEs involved must negotiate which DE is the Master and which one is the Slave. This is done easily by selecting the FUNC_LEVEL_RM_DE that has the largest value in the Sender_Router_Id field as the master. Once the roles of the DEs have been determined, the asymmetric exchange of information begins. The master DE then sends its database in a sequence of Link State Exchange messages. The messages are sent one at a time and each message is acknowledged by the slave DE (by setting the bit A to one and keeping the same sequence number). The M bit must be set to 1 if there is more than one record in the database. When the master DE transmits its last database record, it will set the M bit to 0 to indicate that there are no more records to be sent. After receiving a message with M bit set to 0, the slave DE begins to send its database to the master DE. When the slave DE sends the last database record it will set also the M bit to 0 and the synchronization process completes. When a link state changes (e.g. in case of a link failure), the FUNC_LEVEL_RM_DE that detects the change will send a Link State Advertisement message (Figure 9) to all its neighboring Chaparadza, et al. Expires January 20, 2012 [Page 33] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 FUNC_LEVEL_RM_DEs. A Link State Advertisement message may contain updates about the changes of more than one link. The sequence number from the advertisement message is compared to the value from the DE's local database. If the sequence number is new, the receiver DE will update the state of the link in the local database and it will issue a new Link State Advertisement message to all other interfaces in order to propagate the updates. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Id | Receiver_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group_Id | InfoType | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Eth_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloType | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hello_Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dead_Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Router_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Hello Message. Sender_Eth_Id Interface identifier of the sender of the Hello message HelloType The type of the Hello message Hello_Interval The time between two consecutive Hello messages, expressed in seconds Dead_Interval The time for the dead interval, expressed in seconds Sender_Router_Id Router identifier of the sender of the Hello message Chaparadza, et al. Expires January 20, 2012 [Page 34] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Id | Receiver_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group_Id | InfoType | Flags |A|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SeqNum | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Link_State_Option (only one) . . (24 octects) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Link State Exchange Message. Flags A: Acknowledgement bit. This bit should be set to zero when sending Link State Exchange messages. If this bit is set to 1 then it indicates that the message is an acknowledgment (see next sub-section for more details). M: If this bit is set to 1 more Link State Exchange messages will follow. When the last Link State Exchange message is sent, this bit must be set to 0 (see next sub-section for more details). All the rest of the bits should be set to zero by any sender of a Link State Exchange message. SeqNum Sequence number of Link State Exchange message Chaparadza, et al. Expires January 20, 2012 [Page 35] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Router_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor_Router_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Interface_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor_Interface_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Link State Option. Sender_Router_Id Router identifier of the sender Neighbour_Router_Id Neighbour Router identifier Sender_Interface_Id Interface identifier of the sender Neighbour_Interface_Id Neighbour Interface identifier Timestamp Timestamp at which this Link State Option was generated Chaparadza, et al. Expires January 20, 2012 [Page 36] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender_Id | Receiver_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group_Id | InfoType | Flags |A|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SeqNum | LSA_Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Link_State_Options . . (at least one) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Link State Advertisement Message. Flags A: Acknowledgement bit. This bit should be set to zero when sending Link State Advertisement messages. If this bit is set to 1 then it indicates that the message is an acknowledgment (see next sub-section for more details). All the rest of the bits should be set to zero by any sender of a Link State Exchange message. SeqNum The sequence number of Link State Advertisement message LSA_Counter This field indicates how many Link State Options (Figure 8) are present in the message. Chaparadza, et al. Expires January 20, 2012 [Page 37] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Appendix B. Conclusions The proposed generic control protocol (IGCP) and its generic Data Part offers an opportunity to accommodate different types of control information exchange contexts in the current and future IP networks. As an example domain of application of IGCP: the growing concept of self-management and autonomic networking, which can be applied to existing networking paradigms and architectures would benefit from such a multi-purpose control protocol as the network's Decision- making-Elements(DEs) defined by the GANA Reference Model presented in brief in this document, that are meant to dynamically (re)-configure, adapt and regulate the behaviour of protocols, stacks and mechanisms require exchanging control information. The IGCP protocol can be used by any types of functional entities intending to exchange control messages. When applied for use in the domain of autonomic networking, by Decision-Elements (DEs) defined by the GANA Model, the Data Part can be customized according to the needs of the different types of Decision Elements. In this draft we illustrated the customization of the Data Part of IGCP for the needs of one specific type of a Decision Element, namely the Function-Level-Routing- Management-DE (FUNC_LEVEL_RM_DE). The customization of the Data Part for the needs of other types of DEs would require the definition of more Internet Drafts accordingly. Chaparadza, et al. Expires January 20, 2012 [Page 38] Internet-Draft IP based Generic Control Protocol (IGCP) July 2011 Authors' Addresses Ranganai Chaparadza Fraunhofer Fokus Razvan Petre Fraunhofer Fokus Heikki Mahkonen Ericsson Li Xin BUPT Michael Behringer Cisco Systems Chaparadza, et al. Expires January 20, 2012 [Page 39]