chaparadza-6man-igcp-00.txt

Internet DRAFT - draft-chaparadza-6man-igcp

draft-chaparadza-6man-igcp

Last Version:	draft-chaparadza-6man-igcp-00.txt	Tracker Entry
Date:	`06-Mar-2010`
Disposition:	expired

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.

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

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.

Figure 8 Negotiation Offer/Reply Messages.

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]