UDTP pre-specification

UDTP (Up/Down Trans­port Pro­to­col) is a trans­port lay­er pro­to­col that con­tains mech­a­nisms for ensur­ing trans­mis­sion qual­i­ty with guar­an­teed deliv­ery in pack­et-based net­works with an explic­it­ly orga­nized connection.

• band­width allo­ca­tion with trans­mis­sion laten­cy control;
• ordered deliv­ery of user data;
• guar­an­teed data delivery;
• asym­met­ri­cal (up/down) data transmission;
• mul­ti­plex­ing / de-mul­ti­plex­ing of user data;
• sup­port of for­ward error cor­rec­tion in data transmission;
• data encryp­tion sup­port dur­ing transmission;
• data trans­fer sup­port in the form of a file, stream or message;
• resilience to fail­ures and changes on the net­work level;
• mobile users support;
• sup­port for mul­ti­cast and broad­cast con­nec­tions on both sides;
• no dupli­cates dur­ing data delivery;
• real-time and time-insen­si­tive data trans­fer sup­port in a sin­gle com­mu­ni­ca­tion channel.

UDTP is an inte­grat­ed part of IPv17 net­work mod­el (see Fig­ure 1), which dif­fers from the ref­er­ence mod­el of open sys­tems inter­con­nec­tion (ITU X. 200).

Fig­ure 1. IPv17 net­work model.

IPv17 net­work mod­el con­sists of two lay­ers: data lay­er and com­mu­ni­ca­tion lay­er, each of them con­tains three lev­els and two interfaces.

The dif­fer­ence between IPv17 net­work mod­el and ISO/OSI sev­en-lay­er ref­er­ence mod­el is that the data lay­er at the stage of estab­lish­ing a con­nec­tion defines the par­tic­i­pants of data inter­ac­tion and sets the con­nec­tion para­me­ters required for data trans­mis­sion and the com­mu­ni­ca­tion lay­er main­tains the con­nec­tion with the giv­en parameters.

Network model — data layer, application level

1. per­forms iden­ti­fi­ca­tion, ini­tial­iza­tion, acti­va­tion and deac­ti­va­tion of a net­work application;
2. syn­chro­nizes net­work appli­ca­tions activities;
3. spec­i­fies a type and para­me­ters of trans­mit­ted data.

Network model — data layer, presentation level

The pre­sen­ta­tion lev­el coor­di­nates a trans­ferred data for­mat (e.g. an order of bits trans­mis­sion first of all).

Network model — data layer, session level

1. search­es for participants;
2. iden­ti­fies participants;
3. estab­lish­es a con­nec­tion between data exchange par­tic­i­pants and pro­vides a con­nec­tion support;
4. can tar­iff the connection;
5. defines the FEC set­tings of data exchange in the com­mu­ni­ca­tion link;
6. defines cryp­to­graph­ic para­me­ters the con­nec­tion for data exchange;
7. car­ries out dig­i­tal rights con­trol dur­ing data exchange.

Network model communication layer

The com­mu­ni­ca­tion lay­er imple­ments the data exchange through the trans­fer of data between the par­tic­i­pants, uses for this: net­work, trans­port, phys­i­cal lev­els and a com­mu­ni­ca­tion inter­face (Pro­to­col stack).

Network model — communication layer, network level

The net­work lev­el estab­lish­es, main­tains, and restores, if nec­es­sary, the route of data trans­fer between end sys­tems with regard to the required con­nec­tion type accord­ing to net­work ID (NetID).

The net­work lev­el per­forms rout­ing process­es, for this builds, main­tains, restores and removes the routes for mobile and fixed con­nec­tions in a net­work with a sta­t­ic or dynam­ic topology.

Safe­ty and reli­a­bil­i­ty main­tain routes are pro­vid­ed by a tab­u­lar-unbound method of estab­lish­ing a route, elim­i­nat­ing the need for rout­ing protocols.

Pro­tec­tion of the net­work iden­ti­fi­er NetID from chang­ing, block­ing or delet­ing dur­ing the con­nec­tion life­time is pro­vid­ed by net­work lev­el, for this inserts forced­ly sender net­work iden­ti­fi­er NetID in each pack­et of trans­mit­ted data which was select­ed when estab­lish­ing the connection.

Network model — communication layer, transport level

The trans­port lev­el solves the prob­lem of data trans­fer­ring through the trans­mis­sion medi­um with the para­me­ters that are set at the appli­ca­tion level.

The trans­port lev­el gen­er­ates a deter­min­is­tic access dis­ci­pline to the trans­mis­sion medi­um, imple­ments, accord­ing to the estab­lished con­nec­tion between the end sys­tems, the process of data trans­fer­ring, for this frag­ments trans­mit­ted data into data pack­ets, trans­mits the data pack­ets to the com­mu­ni­ca­tion chan­nel in the form of pack­ets and receives pack­ets from the com­mu­ni­ca­tion chan­nel, process­es the data pack­ets and assem­bles the received data pack­ets in the form of file, stream or message.

 The dis­ci­pline of wired or wire­less com­mu­ni­ca­tion chan­nels of the trans­mis­sion medi­um allows for the data trans­fer settings.

Network model — communication layer, physical level

Phys­i­cal lev­el acti­vates, main­tains and deac­ti­vates a data trans­mis­sion chan­nel. The phys­i­cal lev­el imple­ments access dis­ci­pline to the trans­mis­sion medi­um, deter­mines ten­sion lev­els and syn­chro­nizes changes of ten­sions, sets the trans­mis­sion rate of mes­sages, per­forms error pro­tec­tion meth­ods, encryp­tion meth­ods (if nec­es­sary), mod­u­la­tion meth­ods, and mechan­i­cal con­nec­tions and oth­er sim­i­lar functions.

UDTP basic principles

1. net­work ID – NetID,
2. trans­mis­sion mech­a­nism – NetDMA,
3. a method of data trans­mis­sion qual­i­ty assur­ance – BrD&J.

The data structure of UDTP — NetID

NetID is a user identifier.

With­in IPv17 net­work envi­ron­ment, UDTP takes a net­work iden­ti­fi­er (NetID) from the net­work enti­ty and per­forms NetID reg­is­tra­tion pro­ce­dure in the switch­ing node.

• no attrib­ut­es,
• one attribute, for exam­ple, PIN,
• two attrib­ut­es, that
• two attrib­ut­es and the attrib­ut­es con­fir­ma­tion from an exter­nal source.

Net­work iden­ti­fi­er (NetID) includes the num­ber, name, and alias of a user. The size of net­work ID (NetID) can not be more than 256 octets and may have the fol­low­ing structure:

struct NetID {
  uint64 type:4,
         number:60;
  char[127]  *name;
  char[115]  *nic;
  uint32 crc32;
}

NetDMA data transfer mechanism

Ser­i­al trans­mis­sion using the Net­D­MA is based on the method of dynam­ic time mul­ti­plex­ing with a changed order of the head­er and the body of the data pack­et and it is called “body forward”.

The for­ma­tion of data pack­ets allows stop­ping trans­mis­sion of the pack­et body into the com­mu­ni­ca­tion chan­nel at any point of time main­tain­ing the integri­ty of data deliv­ery. The integri­ty of the data pack­et deliv­ery is based on a ver­i­fi­ca­tion code (CRC-32).

Data packet

The data pack­et is a con­tain­er for data trans­fer. The data pack­et con­sists of a body and a head­er. The pack­et body con­tains the pay­load of the trans­mit­ted data and the head­er con­tains ser­vice infor­ma­tion includ­ing infor­ma­tion about the integri­ty of trans­mit­ted data.

A pack­et trans­mis­sion is car­ried out in two stages. First­ly, a pack­et body is sent into a chan­nel, and then the pack­et head­er with a gap. The head­er con­tains infor­ma­tion about the integri­ty of the trans­fer pack­et body, which includes the length of the trans­mit­ted part of the body and the ver­i­fi­ca­tion code (CRC-32).

The pack­et body has a vari­able length, and the pack­et head­er has a fixed length depend­ing on the type of the header.

Data packets transmission

This para­graph is skipped because it is in a process of patenting.

NetDMA method implementation

Net­D­MA is imple­ment­ed as a dri­ver and uses the DMA device that is avail­able for each proces­sor or micro­con­troller but dif­fers because it uses DMA not only for data trans­fer­ring but also direct­ly for form­ing a data pack­et, free­ing the CPU from this task. This imple­men­ta­tion sig­nif­i­cant­ly reduces the load on the CPU while trans­mis­sion of data packets.

BrD&J mechanism of data transmission quality support

UDTP sup­ports BrD&J mech­a­nism (Bitrate, Delay & Jit­ter) to estab­lish data trans­fer qual­i­ty para­me­ters, includ­ing band­width allo­ca­tion, spec­i­fies the type of delay and main­te­nance the delay vari­a­tion (jit­ter) with­in a pre­de­ter­mined range.

1. band­width allo­ca­tion for the connection
2. set­ting laten­cy con­trol mode while data transfer.

Bandwidth allocation

The band­width allo­ca­tion deter­mines how many bits must be trans­mit­ted per time unit. Band­width should be mea­sured by bps (bit per second).

Type of delay

With­in the trans­mis­sion cycle or with­out regard to the trans­mis­sion cycle.

The first one is used for real-time traf­fic, the oth­er one is used for time-insen­si­tive traffic.

“Time axis”

UDTP cre­ates or uses a “Time axis” for the pur­pose of form­ing a trans­mis­sion rate which is pre­de­ter­mined by an appli­ca­tion. “Time axis” is a trans­fer of a pre­de­ter­mined syn­chro­niz­ing sequence in the form of “Ping” pack­et or “Sync Code” to estab­lish the start­ing point of the trans­mis­sion cycle.

The cycle val­ue is set by Channel_time_loop para­me­ter which is in the con­fig­u­ra­tion file.

1. between user’s applications;
2. between points that orga­nize the phys­i­cal com­mu­ni­ca­tion channel.

The first mode may be used to per­form “Time axis” syn­chro­niza­tion func­tion between user’s appli­ca­tions when the con­nec­tion is estab­lished by IPv4 and IPv6 infra­struc­ture. The sec­ond mode may be used for estab­lish­ing IPv17 infra­struc­ture connection.

The formation of the “Time axis”

1. to allo­cate band­width for the connection,
2. to set a laten­cy con­trol mode dur­ing data transfer,

for that cycli­cal­ly gen­er­ates a “time axis” syn­chro­niz­ing sequence for the pur­pose of imple­ment­ing the mech­a­nism for band­width allo­ca­tion and laten­cy con­trol with guar­an­teed jit­ter for spec­i­fied limits.

“Time axis” is formed by the peri­od­ic send­ing a spe­cial Ping-packet.

Fig­ure 2. “Time axis” mode of the interface.

Fig­ure 3. “Time axis” mode of the applications.

The allo­ca­tion (reser­va­tion) of band­width is per­formed only dur­ing the data trans­mis­sion at the con­nect­ing moment. Request­ed resources are released upon com­ple­tion of the connection.

The net­work topol­o­gy changes should lead to the restora­tion of the trans­mis­sion chan­nel, with­out a request for the appli­ca­tion to close the channel.

The user’s tran­si­tion between the com­mu­ni­ca­tion nodes (han­dover mode) may result in the reg­is­tra­tion of the net­work iden­ti­fi­er at the oth­er com­mu­ni­ca­tion node, but it is allowed send­ing reg­is­tra­tion data between com­mu­ni­ca­tion nodes.

Client/server relationship

Client/server rela­tion­ship chart is pre­sent­ed (see Fig­ure 4).

Fig­ure 4. Client/server relationship.

UDTP fields

NetID и UDTP

Fig­ure 5. First pack­et – con­nec­tion establishing.

Fig­ure 6. Sec­ond and next pack­ets – data transfer.

Data transfer by UDTP

Data transmission recovery

Data trans­fer may be accom­pa­nied by loss­es. UDTP can imple­ment lost data recov­ery by re-trans­mit­ting of a part of data or orga­niz­ing a ser­vice pack­et with proac­tive FEC error codes. Trans­port pro­to­col deter­mines a recov­ery method.

Re-transmission

UDTP can arrange pack­ets re-trans­mis­sion by accept­ing a con­fir­ma­tion attribute of each received pack­et or of each pack­et with detect­ed losses.

UDTP allows data trans­fer with­out receiv­ing a con­fir­ma­tion attribute of the accept­ed data packet.

Data re-trans­mis­sion uses an aux­il­iary con­nec­tion. Orga­niz­ing of pack­et re-trans­mis­sion allows to stop data trans­mis­sion on the pri­ma­ry con­nec­tion or with­out stop­ping but using a dif­fer­ent trans­mis­sion rate with­in the over­all pre­scribed band­width in the channel.

The size of the data pack­et to repeat is deter­mined by two points that obtained in “Bor­der file” field while receiv­ing ‘i’ and ‘i+1’ data pack­ets. The val­ue of the two points is trans­mit­ted by two head­ers in aux­il­iary and ser­vice connection.

UDTP features

1. a clear indi­ca­tion of the used appli­ca­tion Pro­to­col, miss­ing the port num­ber and there is no pos­si­bil­i­ty to change the num­ber of the Pro­to­col when the con­nec­tion is established;
2. while estab­lish­ing a con­nec­tion it is per­formed a pro­ce­dure of user’s NetID iden­ti­fi­ca­tion, that 
   1. receiv­ing a data pack­et does not allo­cate mem­o­ry to process the connection,
   2. estab­lish­ing the con­nec­tion fix­es the Pro­to­col num­ber, trans­mis­sion rate and NetID that can­not be changed while a data tran­si­tion process
   3. and each data pack­et has an iden­ti­fi­ca­tion field that allows iden­ti­fy­ing pack­ets that are trans­ferred between the end­points of the connection;
3. four threads are cre­at­ed while orga­niz­ing a con­nec­tion: pri­ma­ry, ser­vice, con­trol and sta­tis­ti­cal, up to 32 con­nec­tions can be arranged between the end points;
4. four streams are used for: 
   • data is trans­mit­ted on the pri­ma­ry stream,
   • rep­e­ti­tion is trans­mit­ted on the ser­vice stream,
   • band­width con­trol, coor­di­nat­ing of FEC encod­ing and encryp­tion are per­formed on the con­trol stream,
   • chan­nel load­ing data and con­nec­tion data are trans­mit­ted on the sta­tis­ti­cal stream;
5. direct and return chan­nels are inde­pen­dent of each oth­er and can sup­port dif­fer­ent trans­mis­sion rates;
6. the pro­to­col has a mul­ti-path trans­mis­sion mode which is used either to improve the reli­a­bil­i­ty of trans­mis­sion or to increase bandwidth.