IPv6 Maintenance (6man) Ranganai Chaparadza Internet Draft Fraunhofer Fokus Intended status: Standard Razvan Petre Expires: September 2010 Fraunhofer Fokus Shiduan Cheng BUPT Li Xin BUPT Yuhong Li BUPT March 1, 2010 ICMPv6 based Generic Control Protocol (IGCP) draft-chaparadza-6man-igcp-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Chaparadza Expires September 1, 2010 [Page 1] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 1, 2010. Copyright Notice Copyright (c) 2010 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. Abstract This document presents a proposal for a multi-purpose Generic Control Protocol (IGCP) for IPv6 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 is desired. For example, the growing area of self-management, self-organization and autonomic networking introduces functional entities into the node and network architectures that need to exchange control information in order to implement self-adaptive behavior and dynamic network configuration and optimization. In this document, we capture a number of control message exchange types of contexts for which a generic control protocol would be desired. The extensibility of ICMPv6 offers the room for designing such a generic control protocol. In this document, we present our proposal for such a generic control protocol that is based on extending ICMPv6, whose message format is divided into two parts: a Common Part and a Generic Data Part that can be further structured according to some usage context of control messages further encapsulated by the Data Part that need to be parsed and used by entities meant to interpret the Data Part. We also give an example use case, where functional entities residing in different nodes exchange information using the IGCP generic messages. Chaparadza Expires September 1, 2010 [Page 2] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 Table of Contents 1. Introduction ................................................ 3 2. Problem Statement ........................................... 3 2.1. The growing concept of Self-Management .................. 3 2.2. The need for a multi-purpose Generic Control Protocol in IPv6 based networks .............................................. 8 3. The Proposed extension (IGCP) and its application ............ 9 3.1. Generating an IGCP packet ............................... 9 4. Conventions used in this document ........................... 11 5. Message type and format for IGCP ............................ 12 5.1. IGCP Information Exchange Messages ..................... 12 5.1.1. Example usage of the IGCP Information Exchange Messages ........................................................ 16 5.2. IGCP Negotiation Messages .............................. 21 6. Security Considerations ..................................... 23 7. IANA Considerations ........................................ 23 8. Conclusions ................................................ 23 9. References ................................................. 24 10. Acknowledgments ........................................... 25 1. Introduction ICMPv6 [1] is an integral part of the IPv6 architecture and must be completely supported by all IPv6 implementations. It combines functions previously subdivided among different protocols, ICMPv4, IGMP and ARP, and it introduces some simplifications that eliminate obsolete types of messages no longer in use. 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 Context in which some Extension is required to the base ICMPv6 protocol. 2. Problem Statement 2.1. The growing concept of Self-Management Self-Management is a new growing concept for future networks in which Manager Entities (i.e. Decision-making-Elements) are introduced into the node/device architectures and the overall network architecture such that the manager entities can "autonomically" configure and control/regulate and adapt the behaviour of network protocols and mechanisms via the management interfaces of the individual protocols based on dynamic views analyzed by the manager entities. Such views can be goals/policies governing the way the protocols should be Chaparadza Expires September 1, 2010 [Page 3] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 configured and adaptively adjusted, or incidents. 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. We shall refer to the 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 [2][3]. 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). 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 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 [3] 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) [4] introduces "autonomic manager components" 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 hierarchical levels of abstractions for which DEs, MEs, Control-Loops and their associated dynamic adaptive behaviours can be designed. The levels of abstractions are as follows: o Level-1: protocol-level (the lowest level) by which self- management is associated with the network protocol itself (whether monolithic or modular); Chaparadza Expires September 1, 2010 [Page 4] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 talk about autonomic routing (see example instantiation of GANA for realizing autonomic routing in [5]), autonomic forwarding, autonomic fault-management, autonomic configuration management; 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; Level-4: the level of the network's overall functionality and behaviour (the highest level). below 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 Expires September 1, 2010 [Page 5] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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| || intrinsec to a |Peers| intrinsec to a | between Sibling | || Routing Protocol |<--->| Routing Protocol | Decision Elements | || e.g. OSPF || || e.g. OSPF | | |+------------------+| |+------------------+ | +--------------------+ +-----------------------------------------+ Figure 1 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 defined for their needs to communicate with other DEs. Level-4: The "network-level" represents the last level of autonomicity i.e. the highest level of self-manageability (autonomicity). There may exist a logically centralized network-level Decision-Making-Element(s) or the kind of DEs proposed in the 4D network architecture [6] belonging to an isolated "decision cloud" i.e. outside the nodes, which is considered to know (through some means) the objectives, goals or policies to be enforced by the whole network. 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 centralized network-level DME(s) in the "decision Chaparadza Expires September 1, 2010 [Page 6] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 cloud", export "views" such as events and state information to the centralized DME(s). This may happen in order for the 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 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 working co- operatively to self-organize and manage the network without the presence of a "specially instrumented" logically centralized network- level DME(s) in an isolated "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 and management operations that must work in harmony with autonomous self-management at node-level. The second case implies that the nodes need to be designed in such a way as to have the possibility for the nodes themselves to self-organize and perform "intrinsic" management-which can only be achieved to a certain extent due to resource limitations of the nodes and the problem of longer convergence time with some distributed decision-making algorithms. In GANA: 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 [5] an instantiation case for autonomic management and control of IPv6 routing protocols and mechanisms is illustrated. The GANA can be viewed as a holistic architectural Reference Model for autonomic network engineering and self-management. It is holistic in the sense of the four levels of abstraction of functionality at which inter-working control-loops for self-management can be introduced. Moreover, it is meant to also address what may simply be called "intrinsic management within a node/device and collaboratively among network devices" as well as depicting "boundaries and constraints" for this type of intrinsic management. This means that the issues that require centralization of some of the autonomic Chaparadza Expires September 1, 2010 [Page 7] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 decision-making processes of the network should be captured by such a 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. At the same time, these types of DEs must allow for some "network-intrinsic management and decision-making-processes" to take place harmoniously at a lower level within the network nodes 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" with the nodes. We refer the reader to [7] 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. 2.2. The need for a multi-purpose Generic Control Protocol in IPv6 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 extensions to the current ICMPv6 protocol in order to address the requirements outlined below. The extension (IGCP) should capture the parts that must be generic in the additional types of messages while identifying the items that must be mandatrory in those additional 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). In the case of Manager Entities such as the GANA DEs, residing in two or more nodes/devices, the entities may require to: o Negotiate the way their Managed Entities (MEs) e.g. Protocols should be configured. The need to negotiate can be in the case of lack of a centralized co-ordinator and the Peer DEs need to self- organise. o Solicit for Capabilities of the peer or peers based on the features supported by the protocols and mechanisms i.e. the associated MEs's Capabilities. o Self-Advertise Capabilities to peers on the link or selected peers by policy. Chaparadza Expires September 1, 2010 [Page 8] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 o Exchange Trust related info. This could be done by the Node_DE (autonomically control the behaviour of the whole node) or also at lower level DEs within the node. o Expose Views to peer DEs, such as detected incidents, mis- behaviours, etc, which can be used by the peers for managing the configuration of their associated MEs. o Request Views from peer DEs. 3. The Proposed extension (IGCP) and its application For all the requirements for control information exchange listed above, we propose to introduce some generic ICMPv6 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 is allowed by the fields defined later, 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 defined according to the specific needs of specific types of functional entities that need to exchange control information (e.g. different types of DEs in the case of the GANA based network). An example of how the Data field can be used is presented later. ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and for other internet-layer functions, such as diagnostics and control information exchange [1]. In [1] six ICMPv6 message types are defined. Other protocols have introduced new ICMPv6 message types, such as for example Neighbour Discovery for IPv6 (NDv6) [8]. IPv6 nodes on the same link use NDv6 to discover each other's presence, determine each other's link-layer addresses, find routers and maintain reachability information about the paths to active neighbours [8]. 3.1. Generating an IGCP 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: Selectively combining Hop-By-Hop Options Header; Routing Header (this may require Chaparadza Expires September 1, 2010 [Page 9] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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. Use of ND events as triggers to the generation of an IGCP packet e.g. the Node-DE may listen for such events and generate IGCP. Chaparadza Expires September 1, 2010 [Page 10] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 __ ___ -- --- ------/ \--------/ \------ -----/ \---- +----/ +-------------------------+ \-- +---+ | 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 2 DEs communicating using IGCP. 4. Conventions used in this document In the future revision. Chaparadza Expires September 1, 2010 [Page 11] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 5. Message type and format for IGCP We propose three new types of generic ICMPv6 messages for addressing the requirements outlined earlier, namely: ({Information Request}, {Information Offer} and {Information ReceiptACK}) and two new messages for addressing the first need from the list provided earlier ({Negotiation Offer}, {Negotiation Reply}). ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages have message Types from 0 to 127 and informational messages have message Types from 128 to 255. The processing rules defined in [1] for an error message are different compared to an informational message. All the proposed new messages presented here are informational messages. 5.1. IGCP Information Exchange Messages In [9] 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 ICMPv6 messages for facilitating the exchange of generic control information: {Information Request}, {Information Offer} and {Information ReceiptACK} messages, that share the same general format presented in below. Chaparadza Expires September 1, 2010 [Page 12] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 3 Information Request/Offer/ReceiptACK Messages. Type ICMPv6 message type. Code For Information Request it can be used to further distinguish between different categories of information: capabilities, views regarding incidents and policies, etc. For Information Offer: o 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. o 1 - Indicates a successful reply to an Information Request message. o 2 - Indicates that no confirmation is needed (no Information ReceiptACK message should be sent in response). o 3 - Indicates that the receiver of an Information Request message refuses to provide the requested information (maybe because of Chaparadza Expires September 1, 2010 [Page 13] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 prohibiting local policies) o 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: o 1 - Indicates that the information was successfully received and processed. o 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 ICMPv6 checksum Sender_Id A 32-bit field used to identify the sender functional entity e.g. a GANA DE. The identifier must be unique among all the functional entities inside a node. (e.g. according to GANA there can be more than one DE inside a node). Receiver_Id This field is similar to the Sender_Id, but it is used for identifying the receiver (e.g. a GANA DE) inside the node. 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. IDs and Group-ID need to be discovered in a similar fashion to the way Neighbor Discovery (ND) 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 Chaparadza Expires September 1, 2010 [Page 14] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 defined according to the specific needs of specific types of functional entities that need to exchange control information (e.g. different types of DEs in the case of the GANA based network). An example of how the Data field can be used is presented in following. The messages described above provide just the basic fields that can be used by any functional entity (e.g. a GANA DE) intending to exchange control information. The Data part of the message can 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, views (e.g. regarding incidents in the network or links 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 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. Chaparadza Expires September 1, 2010 [Page 15] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 5.1.1. Example usage of the IGCP Information Exchange Messages IGCP is meant to be used by any functional entities intending to exchange control messages for the requirements outlined earlier. Here we focus on one example of a usage case of IGCP. In the following paragraphs, we give a concrete example of how the Information Offer message can be used by two GANA DEs residing on different nodes in order to exchange control information. The 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. 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 re-seting some parameters such as those defined by the Management Information Base (MIB) for the target protocol, FUNC_LEVEL_RM_DEs from different nodes in the network need to exchange control information. They need to encapsulate the 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 new messages are introduced and their structure and fields are described below. Here we illustrate how the Data field can be specially tailored for exchanging link state information. The FUNC_LEVEL_RM_DE is responsible for autonomically managing and controlling the behaviour of all the routing protocols of a node e.g. OSPF (refer to [5], [7] for more detailed information on the description of the FUNC_LEVEL_RM_DEs). This is realized in a distributed manner and the FUNC_LEVEL_RM_DEs residing on different routers exchange information in order to take the most appropriate decisions for the overall network. Three kinds of messages are introduced for facilitating the information exchange between FUNC_LEVEL_RM_DEs and their structure is presented below. The Hello message (below) 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 topological databases. The synchronization is performed by using Link State Exchange messages (Figure 5). 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 Chaparadza Expires September 1, 2010 [Page 16] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 will send 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 7) to all its neighboring 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 4 Hello Message. Chaparadza Expires September 1, 2010 [Page 17] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 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 5 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). Chaparadza Expires September 1, 2010 [Page 18] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 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 6 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 Expires September 1, 2010 [Page 19] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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 7 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 6) are present in the message. Chaparadza Expires September 1, 2010 [Page 20] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 5.2. IGCP Negotiation Messages The {Negotiation Offer} and {Negotiation Reply} messages have the same structure presented as in Figure 8. 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 | NegType | SessionId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SeqNum | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 Negotiation Offer/Reply Messages. Sender_Id A 32-bit field used to identify the sender functional entity e.g. a GANA DE. The identifier must be unique among all the functional entities inside a node. (e.g. according to GANA there can be more than one DE inside a node). Receiver_Id This field is similar to the Sender_Id, but it is used for identifying the receiver (e.g. destination DE) inside the destination node. 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 (e.g. DEs) inside the node can be part of a specific group. This field should be used for identifying the group of functional entities (e.g. DEs) for which the message is addressed. Chaparadza Expires September 1, 2010 [Page 21] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 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. SessionId An 8-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. SeqNum The 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. 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. The Negotiation Offer and Negotiation Reply messages (Figure 8) presented in the previous section are meant to be generic messages for facilitating the negotiation process between two or more functional entities (e.g. GANA DEs). 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 step, as illustrated in Figure 9. Chaparadza Expires September 1, 2010 [Page 22] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 Functional Functional Entity 1 Entity 2 | | | Negotiation Offer 1 | |------------------------->| | Negotiation Reply 1 | |<-------------------------| | | | | | Negotiation Offer 2 | |------------------------->| | Negotiation Reply 2 | |<-------------------------| | | Figure 9 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. 6. Security Considerations In the future revision. 7. IANA Considerations In the future revision. 8. 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 IPv6 networks, thanks to the extensibility of the ICMPv6 protocol upon which the IGCP protocol framework is built. The growing concept of self-management and autonomic networking, which can be applied to existing networking paradigms would benefit from such a multi-purpose control protocol as the network's decision-making-elements that dynamically adapt and regulate protocol behaviors require exchanging control information. Chaparadza Expires September 1, 2010 [Page 23] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 9. References [1] Conta A., Deering S., Gupta M. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [2] EC funded- FP7-EFIPSANS Project: http://efipsans.org/ [3] 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, December 2007. [4] 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 Annual Review of Communications, Volume 61, December 2008. [5] Retvari G., Nemeth F., Chaparadza R., Szabo R., "OSPF for Implementing Self-adaptive Routing in Autonomic Networks: a th Case Study", in proceedings of the 4 IEEE International Workshop on Modeling Autonomic Communication Environments (MACE2009), October 2009, Venice, Italy. [6] Greenberg A. et al, "A clean slate 4D approach to network control and management", ACM SIGCOMM Computer Comm. Review, vol 35(5), pp.41-54,2005. [7] Chaparadza R., Papavassiliou S., Kastrinogiannis T., Vigoureux M., Dotaro E., Davy A., Quinn K., Wodczak M., Toth A., Liakopoulos A., Wilson M., "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 produced by FIA. [8] Narten T., Nordmark E., Simpson W., Soliman H. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [9] Crawford M., Haberman B. "IPv6 Node Information Queries", RFC 4620, August 2006. Chaparadza Expires September 1, 2010 [Page 24] Internet-Draft ICMPv6 based Generic Control Protocol March 2010 10. Acknowledgments The authors acknowledge the EC for funding the FP7 EFIPSANS project (INFSO-ICT-215549) from which the ideas expressed in this draft emerged. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Ranganai Chaparadza Fraunhofer Fokus Berlin, Germany Email: ranganai.chaparadza@fokus.fraunhofer.de Razvan Petre Fraunhofer Fokus Berlin, Germany Email: razvan.petre@fokus.fraunhofer.de Shiduan Cheng Beijing University of Posts and Telecommunications Beijing, China Email: chsd@bupt.edu.cn Li Xin Beijing University of Posts and Telecommunications Beijing, China Email: cplalx@gmail.com Yuhong Li Beijing University of Posts and Telecommunications Beijing, China Email: hoyli@bupt.edu.cn Chaparadza Expires September 1, 2010 [Page 25]