NASA-CR-200021 NASA/WVU Software IV & V Facility Software Research Laboratory Technical Report Series NASA-IVV-95-004 . WVU-SRL-95-004 WVU-SCS-TR-95-24 CERC-TR-RN-95-010 Reliable Multicast Protocol Specifications Protocol Operation • ' • ' * ' ! • - - . ^ . _ ..-•*• ..•• : . 'by Jotn R. Callahan, Todd Montgomery, and Brian Whetten DCT - ;JT3TuqpLiULj i JL^ULJUULJ _| luE^y lautduyi uU p fUdDLin DLjaDDDDO'QilSSQQQi 20E J ffl ! (NASA-CR-200021) RELIABLE ;MULTICAST PROTOCOL SPECIFICATIONS PROTOCOL OPERATIONS (West Virginia ,Univ.) 22 p N96-17782 Unclas G3/61 0098253 National Aeronautics and Space Administration West Virginia University https://ntrs.nasa.gov/search.jsp?R=19960011346 2020-04-10T03:12:57+00:00Z
Transcript
NASA-CR-200021
NASA/WVU Software IV & V FacilitySoftware Research LaboratoryTechnical Report Series
Reliable Multicast Protocol Specifications Todd MontgomeryProtocol Operation Brian Whetten
John R. Callahan5 October 1995
The Reliable Multicast Protocol SpecificationProtocol Operation
RMP Library Version: 1.3b (1.3 Beta) ^___..
This appendix contains the complete state tables for RMP NormalOperation, Multi-RPC Extensions, Membership Change Extensions, andReformation Extensions. First the event types are presented.Afterwards, each RMP operation state, normal and extended ispresented individually and its events shown.
Events in the RMP specification are one of several things. (1)Arriving packets, (2) Expired alarms, (3) User events, (4)Exceptional conditions. The specification event types are: ——
•*" ' -. *Event Type DescriptionData Data PacketACK ACK PacketNACK NACK PacketConf Confirm PacketNMD Non-Member Data PacketNMA Non-Member ACK PacketNL New List PacketLCR List Change Request PacketRecStart Recovery Start PacketRecVote Recovery Vote PacketRecACKNL Recovery ACK New List PacketRecAbort Recovery Abort PacketFailure Retransmission timeout on packetTPA Token Pass AlarmCTPA Confirm Token Pass AlarmRTA Random Timeout AlarmMandLv Mandatory Leave AlarmCommitNL Commit New List NotificationJoinReq Application request to join group
Packet Positive Acknowledgements and Fault Detection
Some packets are retransmitted on a scheduled basis until a given setof condition occur that cease that retransmit schedule. This set ofconditions can be considered as a positive acknowledgement for the
Whetten, Montgomery, Callahan RMP 1.3b [Page 1]
RMP Operation Reliable Multicast Protocol 5 October 1995
packet. The different RMP packets and the positive acknowledgementconditions for each are shown in the table below. The packets with(none) as their positive acknowledgement conditions are only sentonce and are not scheduled for any kind of retransmission.
Packet TypeData
ACK
NACKConfirmNon-Member Data (NMD)
Non-Member ACK (NMA)New List (NL)
List Change Request (LCR)
Recovery Start
Recovery Vote
Recovery ACK New ListRecovery Abort
Positive Acknowledgment ConditionsReception of ACK Packet that containspacketReception of ACK, New List, or Confirmpacket with Timestamp >= Timestamp ofpacketReception of requested Packet(s)(none)Reception of Non-Member ACK Packet thatcontains packet(none)Reception of ACK, New List, or Confirmpacket with Timestamp >= Timestamp ofpacketReception of a New List Packetcontaining response to requestCreation of a valid New List Packet orX retransmitsReception of a New List Packet fromReform SiteReception of Null ACK from Reform Site(none)
If a set number of retransmissions, call this value X, for a packetoccur without the positive acknowledgement conditions being met, thena Failure event is generated for that packet. This event is indica-tive of a failure (or blockage) being detected within the protocoloperation (the cause of which being an application failure, a sitefailure, or a communication failure). Failures in RMP are assumed tobe failures that are non-corruptive. All members are assumed to bewell behaved in the presence of failures and not miscreant.
Duplicate Detection and Filtering of Packets
Packets must pass through two devices before they are allowed to beprocessed. The first level is filtering. This level examines thepacket type and TRID. If the TRID is not a valid TRID, then thepacket is dropped. The state of the site is also taken into account.When the site is in the Not In Ring state or the Joining Ring state,it does not have information about the current TRID of the group.Thus filteirng must be down based on packet type and packet contents.For example, as specified below, a site in the Joining Ring statetransitions into the Token Site state upon a New List packet. To
Whetten, Montgomery, Callahan RMP 1.3b [Page 2]
RMP Operation Reliable Multicast Protocol 5 October 1995
filter out possible errant transitions, the filter must drop allother New List packets not meeting the transition criteria.
The second device is duplicate detection. Duplicates are assumed tobe dropped and not processed. Duplicates can be detected based on thepacket type and state of the site. For packets with explicit times-tamps, ACKs and NLs, the timestamp can be used to determine if thepacket is a duplicate. For implicit timestamped packets, Data, NMD,and LCRs, the job is slightly more complicated. Careful track ofsequence numbers from clients as well as group members must be keptfor duplicates to be detected. NMAs, NACKs and Confirm packets arenever checked for being duplicates. During reformation, duplicatesare allowed to be processed (as long as they are part of reformation.Data, NMD, ACK, NL, and LCR packets are still put through duplicatedetection). Another exception to the duplicate detection rule is whenthe site is in the Token Site state. Duplicate detection is not doneon any ACK or NL packets that arrive when the site is in the TokenSite state.
Algorithms and Data Structures
Two data structures are used by RMP. The first is the DataQ. This isa FIFO structure that holds Data, NMD, and LCR packets as theyarrive. The second structure is an Ordered FIFO called an OrderingQ.This FIFO is ordered based on timestamps. Each member of the FIFO,called a slot, is assigned a unique timestamp. In this way, the FIFOhas elements which are monotonically increasing. Each slot of theOrderingQ is one of the following types of packets: Data, NMD, ACK,or NL. ACK and NL packets contain explicit timestamps to order themin the OrderingQ. Data, NMD, and LCR packets are given implicittimestamps by the corresponding ACK or NL that addresses them. There-fore, an ACK with timestamp of 5 which acknowledges 3 packets willimplicitly give 3 Data or NMD packets implicit timestamps of 6, 7,and 8. LCR packets are dropped once a corresponding NL is received.LCRs are never put into the OrderingQ.
In the state tables given below, it is assumed that the addition ofan ACK into the OrderingQ also enqueues empty .slots for each packetacknowledged by the ACK. Each slot in the OrderingQ is assigned astate. There are four possible states for each slot. They are: (1)Packet Missing, (2) Packet Requested, (3) Packet Received, and (4)Packet Delivered. A slot usually starts out as being in the PacketMissing state. Once a NACK is sent for that packet, the state changesto Packet Requested. When the slot is filled by a packet, the statechanges to Packet Received, and, finally, when the packet isdelivered to the application the slot state is changed to PacketDelivered.
Whetten, Montgomery, Callahan RMP 1.3b [Page 3]
RMP Operation Reliable Multicast Protocol 5 October 1995
A few algorithms are provided to specify the operation of the Order-ingQ and DataQ during the protocol operation. The first algorithm isthe Update-OrderingQ algorithm presented below.
Update-OrderingQO :for each (slot in the OrderingQ (starting with lowest timestamp))
If (slot timestamp not equal to last slot timestamp + 1) thenEnQueue as many empty slots to cover missing timestampsfor each (new slot to be Enqueued) Loop
Send NACK for missing timestampMark slot state as Packet Requested
End for.End If.If (slot state is Packet Missing) then
Search DataQ for missing packetIf (packet is found in DataQ) then
Remove packet from DataQPlace packet in OrderingQMark slot as Packet ReceivedAttempt-Packet-Delivery(slot)Update information about packet source
ElseSend NACK for packetMark slot as Packet Requested
End If.Else If (slot state is Packet Committed) then
If (token has been passed enough times to satisfy QoSresiliency requirements) thenMark slot as Packet DeliveredNotify application that QoS resiliency has been metUpdate information about packet source
End If.Else If (slot state is Packet Requested) then
Search DataQ for missing packetIf (packet is found in DataQ) then
Remove packet from DataQPlace packet in OrderingQMark slot as Packet ReceivedAttempt-Packet-Delivery(slot)Update information about packet source
End If.Else If (slot state is Packet Received) then
Attempt-Packet-Delivery(slot)Update information about packet source
Else If (slot state is Packet Delivered) thenUpdate information about packet source
End If.End for.
Whetten, Montgomery, Callahan RMP 1.3b [Page 4]
RMP Operation Reliable Multicast Protocol 5 October 1995
while (the number of ACK Packets and New Lists Packets in OrderingQis greater than the number of members of the Token Ring) Loop
DeQueue lowest timestamp and discard packetEnd while.End Update-OrderingQ.
As auxillarily algorithm, Attempt-Packet-Delivery, is used byUpdate-OrderingQ to determine if a packet is deliverable and todeliver the packet to the application. The Attemp-Packet-Deliveryalgorithm is presented below.
Attempt-Packet-Delivery( slot ):If (slot is a Data Packet or Non-Member Data Packet) then
If (slot packet has QoS equal to Unordered) thenCommit the packet to the applicationMark slot as Packet Delivered
Else If (slot packet has QoS equal to Source Ordered) thenIf (all of the smaller sequence numbers from that
source have been delivered) thenCommit the packet to the applicationMark slot as Packet Delivered
End If.Else If (slot packet has QoS equal to Totally Ordered) then
If (all of the timestamps smaller than the slotstimestamps have been delivered) thenCommit the packet to the application .......Mark slot as Packet Delivered
End If.Else If (slot packet has QoS equal to K Resilient or
slot packet has QoS equal to MajorityResilient or slot packet has QoS equalto Totally Resilient) then
If (all of the timestamps smaller than the slotstimestamps have been delivered) thenCommit the packet to the applicationMark slot as Packet Committed
End If.End If.
Else If (slot is a New List Packet)If (all of the timestamps smaller than the slots timestamps have
been delivered) thenCommit the New List and notify applicationMark slot as Packet Delivered
End If.Else if (slot is an ACK Packet) then
Mark slot as Packet DeliveredEnd If.End Attempt-Packet-Delivery.
Whetten, Montgomery, Callahan RMP 1.3b [Page 5]
RMP Operation Reliable Multicast Protocol 5 October 1995
These two algorithms describe the behavior desired for packets to beordered and delivered. The last algorithm presented is the Pass-Tokenalgorithm. This algorithm describes how a Token Site is to fill passthe token through either a NL or an ACK. The algorithm is presentedbelow.
Pass-Token():for each (member of the DataQ)
If (member is a List Change Request Packet and request canbe granted and packet is eligible) then
Generate a New List Packet for requestSend New List PacketExit Loop
Else If (member is a Data Packet or a Non-Member Data Packetand is eligible to be acknowledged) thenGenerate ACK Packet containing as many Data Packetsand Non-Member Data Packets as are eligible in the DataQSend ACK PacketExit Loop
End If.End for.If (ACK Packet or New List Packet could not be generated) then
Return to calling routine reporting Token Not PassedElse
Return to calling routine reporting Token PassedEnd If.End Pass-Token.
For an LCR, Data, or NMD packet to be eligible, the sequence numberof the packet must have the expected next value for the source. Nostrict upper bound is placed onthe number of NMD or Data packets anACK may contain, although differing implementations may impose theirown Timits.
Delivery of low QoS packets is also checked as the packet arrives andplaced into the DataQ. If conditions are such that the packet meetsits QoS when it arrives, then the packet may be delivered as well asbeing placed into the DataQ. Thus when the Update-OrderingQ algorithmpulls the packet out of the DataQ, the slot into which it is placedis to be marked as Packet Delivered instead of Packet Received. Thisbehavior is assumed in the state tables presented below. Anotherbehavior assumed in the preceeding algorithms is that the implementa-tion will block packets with resilient QoSs from actual delivery tothe application until the conditions meeting their QoS are met. Thisdoes mean blocking the delivery of other QoSs (Source and TotallyOrdered) that depend on that higher QoS packet.
State Tables and Actions
Whetten, Montgomery, Callahan RMP 1.3b [Page 6]
RMP Operation Reliable Multicast Protocol 5 October 1995
In the tables presented below each state is shown along with theactions and conditions required to transition into the next state.Assume that events not shown are ignored unless they are specificallydiscussed below. The different states of RMP operation are:
TS Token Site StateNTS Not Token Site StateGP Getting Packets StatePT Passing Token StateJR Joining Ring StateLR Leaving Ring StateNIR Not In Ring StateSR Start Recovery StateCNL Created New List StateSV Sent Vote StateACKNL ACK New List StateAR Abort Recovery State
In all states the following behaviors are necessary. All NACK eventsare handled the same way no matter what the current state is. Thedefault action for NACK responses is to examine the OrderingQ andretransmit the requested timestamped packet (either explicit times-tamp or implicit timestamp). NACK policy controls how these are sent,via multicast or unicast, and the timing factors involved. Anotherissue is generation of NMA packets in response to NMD packets. Thedefault behavior is to have the site which generates the ACK contain-ing the NMD to generate an NMA for that NMD and unicast the NMA tothe client. If after this is done, a member of the group sees aduplicate NMD (one that has already been acknowledged and ordered),then the member of the list generates an NMA and unicasts it to theclient. The down side of this is that this may result in NMA implo-sion to the client. This policy may also be changed on an implementa-tion basis to be that the same site always sends the NMA.
It is recommended that implementations differentiate, to the applica-tion, NMA packets that hold replies and NMA packets that do not holdreplies. The default behavior for a client is to periodically send anNMD to the group (via unicast or multicast) until it receives an NMA(holding no reply) for that NMD, notify the application that thegroup has received the message, then wait for another NMA that holdsa reply. If the reply is in the form of multiple NMA packets, theneach should be delivered as they arrive. Missing NMA replies can berequested by sending another NMD (with an increased sequence number),thus causing another message to be delivered to the group. This canbe done repeatedly until a client finally gets its reply. Alterna-tively, a client may mark the Multiple Copies flag of the NMD so thatmultiple copies of the same NMD will be delivered to the applicationas they arrive.
Whetten, Montgomery, Callahan RMP 1.3b [Page 7]
RMP Operation Reliable Multicast Protocol 5 October 1995
Due to the fact that this set of policies does not give any guaran-tees to the client that the desired QoS was met, the application isfully responsible for the response policy that it will use. For exam-ple, if clients built for an application need to know when the QoS ismet for the NMD, then the group must send a NMA with a response whenthat QoS is met and the NMD delivered to the application.
Whetten, Montgomery, Callahan RMP 1.3b [Page 8]
RMP Operation Reliable Multicast Protocol 5 October 1995
Token Site State Table (current state is TS). Events not mentionedhave no action and cause no transition. The sequence of actions areexecuted _before_ the conditions are checked.
Action(s)place packet in DataQPass-Tokenplace packet in DataQPass-Tokenplace packet in DataQPass-Tokenplace packet in DataQPass-Tokenplace packet in DataQPass-Tokenplace packet in DataQPass-TokenUnicast Confirm toSourceUnicast Confirm toSourceMulticast RecStartUnicast RecVote toReform SiteGenerate Null ACKMulticast Null ACKUnicast Confirm tolast Token Site
EventData
i
Data
NMD
NMD
LCR
LCR
ACK
NL
FailureRecStart
TPA
CTPA
Condition (s)Token Passed
'.Token Passed
Token Passed
! Token Passed
Token Passed
'.Token Passed
Named TokenSiteNamed TokenSite(none)(none)
(none)
(none)
NextStatePT
TS
PT
TS
PT
TS
TS
TS
SRSV
PT
TS
Whetten, Montgomery, Callahan RMP 1.3b [Page 9]
RMP Operation Reliable Multicast Protocol 5 October 1995
Passing Token State Table (current state is PT). Events not mentionedhave no action and cause no transition. The secfuence of actions areexecuted before the conditions are checked.
NextEvent Condition(s) StateData (none) PT
NMD (none) PT
LCR (none) PT
NL '.named Token Site NTS
NL named Token Site PTOrderingQ consistentToken passed
NL named Token Site TSOrderingQ consistent'.Token passed
NL named Token Site GP!OrderingQ consistent
ACK 'named Token Site NTS
ACK named Token Site PTOrderingQ consistentToken passed
ACK named Token Site TSOrderingQ consistent'.Token passed
ACK named Token Site GP!OrderingQ consistent
Conf Timestamp >= NTSLast token passTimestamp
Failure (none) SRRecStart (none) SV
Action(s)place packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd NL to OrderingQUpdat e-Order ingQPass-TokenAdd NL to OrderingQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd ACK to OrderingQUpdat e-Order ingQPass-TokenAdd ACK to OrderingQUpdate-OrderingQUpdate-OrderingQ
Multicast RecStartUnicast RecVote toReform Site
Whetten, Montgomery, Callahan RMP 1.3b [Page 10]
RMP Operation Reliable Multicast Protocol 5 October 1995
Not Token Site State Table (current state is NTS). Events not men-tioned have no action and cause no transition. The sequence ofactions are executed before the conditions are checked.
NextEvent Condition(s) StateData (none) NTS
NMD (none) NTS
LCR (none) NTS
NL !named Token Site NTS
NL named Token Site PTOrderingQ consistentToken passed
NL named Token Site TSOrderingQ consistent!Token passed
NL named Token Site GP!OrderingQ consistent
ACK !named Token Site NTS
ACK named Token Site PTOrderingQ consistentToken passed
ACK named Token Site TSOrderingQ consistent"Token passed
ACK named Token Site GP!OrderingQ consistent
Failure (none) SRRecStart (none) SV
CommitNL NL does not contain LRsite
Action(s)place packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd NL to OrderingQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd ACK to OrderingQUpdate-OrderingQMulticast RecStartUnicast RecVote toReform SiteSchedule MandLv
Whetten, Montgomery, Callahan RMP 1.3b [Page 11]
RMP Operation Reliable Multicast Protocol 5 October 1995
Getting Packets State Table (current state is GP). Events not men-tioned have no action and cause no transition. The sequence ofactions are executed before the conditions are checked.
Action(s)place packet in DataQUpdate-OrderingQPass-Tokenplace packet in DataQUpdate-OrderingQPass-Tokenplace packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQPass-Tokenplace packet in DataQUpdat e-Order ingQPass-Tokenplace packet in DataQUpdat e-Order ingQplace packet in DataQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd ACK to OrderingQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd NL to OrderingQUpdate-OrderingQMulticast RecStartUnicast RecVote toReform Site
Whetten, Montgomery, Callahan RMP 1.3b [Page 12]
RMP Operation Reliable Multicast Protocol 5 October 1995
Not In Ring State Table (current state is NIR). Events not mentionedhave no action and cause no transition. The sequence of actions areexecuted _before_ the conditions are checked.
NextEvent Condition(s) State Action(s)JoinReq (none) JR Multicast LCR to join ringNMA NMA holds reply NIR Deliver reply to application
Joining Ring State Table (current state is JR) . Events not mentionedhave no action and cause no transition. The sequence of actions areexecuted _before_ the conditions are checked.
NextEvent Condition(s) State Action (s)NL named Token Site TS Add NL to OrderingQ
Update-OrderingQFailure (none) TS Generate NL to form
own Token Ring
Leaving Ring State Table (current state is LR) . Events not mentionedhave no action and cause no transition. The sequence of actions areexecuted _before_ the conditions are checked.
NextEvent Condition (s) State Action(s) __,NL Exit condition met NIR (none)NL !Exit condition met LR (none)ACK Exit condition met NIR (none)ACK !Exit condition met LR (none)MandLv (none) NIR (none)
NOTE: Exit condition is that a number of Token Passes has occurred inthe group equal to the number of people in the group when the sitetransitioned into LR.
Whetten, Montgomery, Callahan RMP 1.3b [Page 13]
RMP Operation Reliable Multicast Protocol 5 October 1995
Start Recovery State Table (current state is SR). Events not men-tioned have no action and cause no transition. The sequence ofactions are executed before the conditions are checked.
NextEvent Condition(s) StateData (none) SR
NMD (none) SR
LCR (none) SR
ACK (none) SR
NL (none) SR
Failure packet is CNLRecStart'.only site
Failure packet is NIRRecStartonly siteList is invalid
Failure packet is TSRecStartonly siteList is valid
RecVote incorrect Info ARRecVote Vote MaxTSP > SR
MaxTSPRecVote Vote MaxTSP <= SR
MaxTSPRecVote OrderingQ consistent CNL
Vote from each siteEach Voter synched
RecAbort correct Info ARRecStart incorrect Info AR
Action(s)place packet in DataQUpdate-OrderingQUpdate SynchTSPplace packet in DataQUpdate-OrderingQUpdate SynchTSPplace packet in DataQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQUpdate SynchTSP and MaxTSPAdd NL to OrderingQUpdate-OrderingQUpdate SynchTSP and MaxTSPCreate New ListMulticast New List
Create New ListCommit New List
Create New ListCommit New ListMulticast New List
Multicast RecAbortUpdate MaxTSP
Update source vote
Create New ListMulticast New List
(none)Multicast RecAbort
NOTE: incorrect Info means that the Token Ring Version, New TokenRing ID, or Reform Site information in the packet is incorrect. Anyupdate to the value of MaxTSP or SynchTSP for the Reform Site promptsa restart of the RecStart packet. Each Voter is synched if the votefrom that voter has its SynchTSP set to the MaxTSP of the currentreformation.
Whetten, Montgomery, Callahan RMP 1.3b [Page 14]
RMP Operation Reliable Multicast Protocol 5 October 1995
Created New List State Table (current state is CNL). Events not men-tioned have no action and cause no transition. The sequence ofactions are executed before the conditions are checked.
NextEvent Condition(s) StateData (none) CNL
NMD (none) CNL
LCR (none) CNL
RecACKNL incorrect Info ARRecACKNL !A11 sites have ACKed CNLRecACKNL All sites have ACKed PT
List is valid
RecACKNL All sites have ACKed NIRList is invalid
Failure packet is NL ARList is valid
Failure packet is NL NIRList is invalid
RecAbort correct Info ARRecStart incorrect Info ARRecVote correct Info CNL
Action(s)place packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQMulticast RecAbortMark source as ACKedAdd NL to OrderingQCommit NLMulticast Null ACKAdd NL to OrderingQCommit NLMulticast RecAbort
Add NL to OrderingQCommit NL(none)Multicast RecAbortUnicast ReformationNL to voting site
NOTE: Reformation NL is generated in the SR state. This NL is notadded to the OrderingQ or committed by the Reform Site until it ispositive that all the Slave Sites have it. This is shown as havingACKs from all those involved in Reformation. Valid lists are liststhat pass the Minimum Size Requirements as set forth by the members.Invalid lists fail to meet these requirements.
ACK and NL packets that are not duplicates arriving in this state areto cause warnings. The ring should not be sending them because thesynchronization point for the group has already been chosen andshould not be changed.
Whetten, Montgomery, Callahan RMP 1.3b [Page 15]
RMP Operation Reliable Multicast Protocol 5 October 1995
Sent Vote State Table (current state is SV). Events not mentionedhave no action and cause no transition. The sequence of actions areexecuted before the conditions are checked.
NextEvent Condition(s) StateData (none) SV
NMD (none) SV
LCR (none) SV
ACK (none) SV
NL !Reformation NL SV
NL Reformation NL NIRIsite in list
NL Reformation NL NIRList is invalid
NL Reformation NL ACKNLList is valid
RecStart correct Info SV
RecStart incorrect Info ARFailure packet is RecVote ARRecAbort correct Info AR
Action(s)place packet in DataQUpdate-OrderingQUpdate RecVoteplace packet in DataQUpdate-OrderingQUpdate RecVoteplace packet in DataQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQUpdate RecVoteAdd ACK to OrderingQUpdate-OrderingQUpdate RecVote(none)
NOTE: Each time a Slave Site receives a RecStart from the ReformSite, the Slave Site is to restart its retransmission schedule forits RecVote. This is needed so that updates to the MaxTSP andSynchTSP of the reformation do not cause a Slave Site to prematurelyinitiate abortion of a reformation. Every time a Slave Site updatesit RecVote, the site must also restart its retransmit schedule on theRecVote packet. A Reformation NL is a New List that meets the follow-ing critieria: (1) Version number is correct with current Reforma-tion, (2) The current Token Site and the next Token Site are thecurrent Reform Site, (3) The Timestamp of the NL must be in the rangeSynchTSP+1 to MaxTSP+1 of the current Reformation, (4) The operationtype of the NL must be a reformation operation, and (5) The new TRIDof the NL must be equal to the TRID of the reformation.
It is practically impossible at this step of reformation to tell the
Whetten, Montgomery, Callahan RMP 1.3b [Page 16]
RMP Operation Reliable Multicast Protocol 5 October 1995
difference between a viable reformation NL and an incorrect one.
Whetten, Montgomery, Callahan RMP 1.3b [Page 17]
RMP Operation Reliable Multicast Protocol 5 October 1995
ACK New List State Table (current state is ACKNL). Events not men-tioned have no action and cause no transition. The sequence ofactions are executed before the conditions are checked.
Action(s)place packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQUnicast RecACKNL toReform SiteMulticast RecAbort
Add Reformation NLto OrderingQCommit Reformation NLAdd NL to OrderingQUpdate-OrderingQAdd Reformation NLto OrderingQCommit Reformation NLAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd Reformation NLto OrderingQCommit Reformation NLAdd NL to OrderingQUpdate-OrderingQPass-TokenAdd Reformation NLto OrderingQCommit Reformation NLAdd NL to OrderingQUpdate-OrderingQAdd ACK to OrderingQUpdate-OrderingQAdd Reformation NLto OrderingQCommit Reformation NLAdd ACK to OrderingQUpdate-OrderingQAdd Reformation NL
whetten, Montgomery, Callahan RMP 1.3b [Page 18]
RMP Operation Reliable Multicast Protocol 5 October 1995
packet is RecACKNL ARcorrect Info ARincorrect Info AR
to OrderingQCommit Reformation NLAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd Reformation NLto OrderingQCommit Reformation NLAdd ACK to OrderingQUpdate-OrderingQPass-TokenAdd Reformation NLto OrderingQCommit Reformation NLAdd ACK to OrderingQUpdate-OrderingQMulticast RecAbort(none)Multicast RecAbort
Whetten, Montgomery, Callahan RMP 1.3b [Page 19]
RMP Operation Reliable Multicast Protocol 5 October 1995
Abort Recovery State Table (current state is AR). Events not men-tioned have no action and cause no transition. The sequence ofactions are executed before the conditions are checked.
NextEvent Condition(s) StateData (none) AR
NMD (none) AR
LCR (none) AR
NL Old Version AR
NL Reformation NL ARVersion is oflast attempt
ACK (none) AR
RTA (none) SRRecStart correct Version SV
RecStart incorrect Version ARRecVote incorrect Version ARRecACKNL incorrect Version AR
Action(s)place packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQplace packet in DataQUpdate-OrderingQAdd NL to OrderingQUpdate-OrderingQMulticast RecAbort
NOTE: A correct version at this stage is a version greater than thelast known version. Fill the RecAbort packet in with data in theincoming packet. A NL that qualifies as a Reformation NL is any NLthat has an operation type dealing with Reformation and has a versionhigher than the last known version.
Authors' Addresses:
Brian WhettenUniversity of California BerkeleyBerkeley, CAEmail: [email protected]
Todd MontgomeryWest Virginia UniversityMorgantown, WVEmail: [email protected]
John R. CallahanWest Virginia UniversityMorgantown, WV
Whetten, Montgomery, Callahan RMP 1.3b [Page 20]
RMP Operation Reliable Multicast Protocol 5 October 1995
![Pacifier : High-Throughput, Reliable Multicast …ychu/publications/ton12...knowledge, BMCC [13], a multicast protocol for mobile ad hoc networks, was the first protocol to consider](https://static.documents.pub/doc/80x56/5f12262073070360334f6159/paciier-high-throughput-reliable-multicast-ychupublicationston12-knowledge.jpg)
