200 likes | 347 Views
Protocol Converter Synthesis Using Timed Petri Nets. Kevin Camera EE249 Fall 2000 10/24/2000. Motivation. Evolution of heterogeneous, distributed networks Protocol converters act as mediators between otherwise incompatible protocols
E N D
Protocol Converter Synthesis Using Timed Petri Nets Kevin CameraEE249 Fall 200010/24/2000
Motivation • Evolution of heterogeneous, distributed networks • Protocol converters act as mediators between otherwise incompatible protocols • This work improves on previous converter modeling and synthesis methodologies
Services and Protocols • Layer N services provide functions for layer N+1 via service access points • User-based functional specification • Protocol entities (PE) exchange protocol data units (PDU) via lower and upper SAPs • Low-level behavioral specification
Converter Design Approaches • Top-down:service-level conversion • Easy to implement, tends to be “passive” • Bottom-up:protocol-level conversion • Very powerful, very complex
Converter Properties • Safety • Free from deadlock or livelock, and is complete • Liveness • Performs the required functionality • Timeliness • Satisfies the timing of both protocols
Design Criteria • Modeling formalism • CFSM, TPN, etc. • Design approach • Service level, protocol level, or hybrid • Design methodology • Analytic: trial-and-error iterations • Synthetic: systematic, safe generation
Design Criteria (con’t) • Information transfer issues • Direct: no buffers, messages transmitted immediately to each protocol • Indirect: messages stored in non-FIFO buffer, re-ordered, and transmitted • Synchronization issues • Mapping of messages (traces) to ensure compatbility
Design Criteria (con’t) • Timeliness • Internal timing and protocol requirements • Data loss and recovery • Dynamicity • Self-induced, active communication • Concurrency • Complexity
Timed Petri Net Model • Standard Petri net with predicated and timed transitions • New notations • Input/Output actions marked with +/- • Parallel composition: PN1 || PN2 • Trace “schuffling”: t1 t2 • Complement of a trace: ~t
Synthesis Technique • Greatest common service definition • Trace generation and collection • Trace synchronization • Synthesis of Petri Net model
Greatest Common Service • Start with both service descriptions • I/O operations are service primitives • Map equivalent primitives into a service interface converter (SIC) • Remove primitives not mapped in SIC
Trace Generation • Interested in traces of each separate network which contribute to the GCSD • Can be found with following analysis: • Let TN be set of traces at {lower,upper}_N • Find N’, a pruning with contributions to S’N • Find us_N, composition of lower services and communication channel • TN = N’ || us_N
TABP ={ACCEPT –DATA(bit) (+ACK(~bit) –DATA(bit))* +ACK(bit),+DATA(bit) (-ACK(~bit) +DATA(bit))* DELIVER -ACK(bit),+DATA(bit) DELIVER (-ACK(~bit) +DATA(bit))* -ACK(bit),+DATA(bit) (+DATA(bit))* DELIVER -ACK(bit),+DATA(bit) DELIVER (+DATA(bit))* -ACK(bit)} TPE ={SEND +poll (-data SEND) (-data SEND)* -end,+poll SEND (-data SEND) (-data SEND)* -end,(+poll)*,-poll (+data RECEIVE) (+data RECEIVE)* +end,(-poll)*} Example: Trace Generation
Trace Synchronization • For trace sets TN and TM found above: • Prune the protocol components TRN, TRM • Take complements to get TCN • Schuffle the complements (TCN TCM) • 14 rules for ordering data, confirmation, ack, and nack messages safely • (N+m,N-c) (M-m) = (N+m,M-m,N-c)
TCABP = {lower_ABP} ~TCABP ={-DATA(bit) (+ACK(~bit) -DATA(bit))* +ACK(bit),+DATA(bit) (-ACK(~bit) +DATA(bit))* -ACK(bit),-DATA(bit) (-DATA(bit))* +ACK(bit)} TCPE = {lower_ABP} ~TCABP ={-poll (+data SEND) (+data SEND)* +end,(-poll)*,+poll (-data SEND) (-data SEND)* -end, (+poll)*} Example: Trace Synchronization TC = TCABPTCPE
Summary • Hybrid approach • Starts with service specification, but performs all synthesis on protocols • Timed Petri net model • Can incorporate timing in specification • Models concurrency and comes with well-known analysis algorithms • Resulting converter is safe and functional