1 FIPA Iterated Contract Net Interaction Protocol
The FIPA Iterated Contract Net Interaction Protocol (IP) is an extension of the basic FIPA Contract Net IP (see [FIPA00029]), but it differs by allowing multi-round iterative bidding.
The representation of this IP is given in Figure 1 which is based on extensions to UML1.x. [Odell2001]. This protocol is identified by the token fipa-iterated-contract-net as the value of the protocol parameter of the ACL message.
Figure 1: FIPA Iterated Contract Net Interaction Protocol
1.1 Explanation of the Protocol Flow
As with the FIPA Contract Net IP, the Initiator issues m initial call for proposals with the cfp act (see [FIPA00037]). Of the n Participants that respond, k are propose messages (see [FIPA00037]) from Participants that are willing and able to do the task under the proposed conditions and the remaining j are from Participants that refuse.
Of the k proposals, the Initiator may decide this is the final iteration and accept p of the bids (0 ≤ p ≤ k), and reject the others. Alternatively the Initiator may decide to iterate the process by issuing a revised cfp to l of the Participants and rejecting the remaining k-l Participants. The intent is that the Initiator seeks to get better bids from the Participants by modifying the call and requesting new (equivalently, revised) bids. The process terminates when the Initiator refuses all proposals and does not issue a new cfp, the Initiator accepts one or more of the bids or the Participants all refuse to bid.
Any interaction using this interaction protocol is identified by a globally unique, non-null conversation-id parameter, assigned by the Initiator. The agents involved in the interaction must tag all of its ACL messages with this conversation identifier. This enables each agent to manage its communication strategies and activities, for example, it allows an agent to identify individual conversations and to reason across historical records of conversations.
In the case of 1:N interaction protocols or sub-protocols the Initiator is free to decide if the same conversation-id parameter should be used or a new one should be issued. Additionally, the messages may specify other interaction-related information such as a timeout in the reply-by parameter that denotes the latest time by which the sending agent would like to have received the next message in the protocol flow.
1.2 Exceptions to Interaction Protocol Flow
At any point in the IP, the receiver of a communication can inform the sender that it did not understand what was communicated. This is accomplished by returning a not-understood message. As such, Figure 1 does not depict a not-understood communication as it can occur at any point in the IP. The communication of a not-understood within an interaction protocol may terminate the entire IP and termination of the interaction may imply that any commitments made during the interaction are null and void. However, since this IP broadcasts to more than one Participant, multiple responses are also possible. Each response, then, must be evaluated separately – and some of these responses might be not-understood. However, terminating the entire IP in this case might not be appropriate, as other Participants may be continuing with their sub-protocols.
At any point in the IP, the initiator of the IP may cancel the interaction protocol by initiating the meta-protocol shown in Figure 2. The conversation-id parameter of the cancel interaction is identical to the conversation-id parameter of the interaction that the Initiator intends to cancel. The semantics of cancel should roughly be interpreted as meaning that the initiator is no longer interested in continuing the interaction and that it should be terminated in a manner acceptable to both the Initiator and the Participant. The Participant either informs the Initiator that the interaction is done using an inform-done or indicates the failure of the cancellation using a failure.
Figure 2: FIPA Cancel Meta-Protocol
This IP is a pattern for a simple interaction type. Elaboration on this pattern will almost certainly be necessary in order to specify all cases that might occur in an actual agent interaction. Real world issues such as the effects of cancelling actions, asynchrony, abnormal or unexpected IP termination, nested IPs, and the like, are explicitly not addressed here.
2 References
[FIPA00029] FIPA
Contract Net Interaction Protocol Specification. Foundation for Intelligent
Physical Agents, 2000.
http://www.fipa.org/specs/fipa00029/
[FIPA00037] FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00037/
[Odell2001] Odell,
James, Van Dyke Parunak, H. and Bauer, B., Representing Agent Interaction
Protocols in UML. In: Agent-Oriented Software Engineering, Ciancarini, P.
and Wooldridge, M., Eds., Springer, pp. 121-140, Berlin, 2001.
http://www.fipa.org/docs/input/f-in-00077/
3 Informative Annex A — ChangeLog
3.1 2002/11/01 - version G by TC X2S
Page 1, Figure 1: The not-understood communication was removed
Page 1, Figure 1: To conform to UML 2, the protocol name was placed in a boundary, x is removed from the diamonds (xor is now the default) and the template box was removed
Page 1, line 42: Reworked and expanded the section description of the IP
Page 1, line 57: Added a new section on Explanation of Protocol Flow
Page 1, line 57: Reworked and expanded the section on Exceptions of Protocol Flow to incorporate a meta-protocol for cancel
Page 1, line 57: Added a paragraph explaining the not-understood communication and its relationship with the IP