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