China
Africa
Explore chapters and articles related to this topic
Development of Standards, Codes, and Regulations
Published in Robert D. Hunter, for Engineers, 2017
Following the invention of the Internet protocols by Vinton G. Cerf and Robert E. Kahn (Cerf and Kahn 1974), it became possible to automatically interconnect existing packet switching networks using the TCP/IP protocols. Later on it fell to the IETF to set the standards for the rapid expansion of the Internet. The speed of standard setting required made conventional SDO methods impractical. The IETF standards setting has little in the way of extensive review and due process that is demanded of SDOs. The guiding principles of standard setting call for one engineer from each organization. There is no formal voting in the IETF; it operates on “rough consensus and running code” (Alvestrand 2004). There is relatively little representation of users. The “rough consensus” allows for more rapid standard setting than in a conventional SDO. The IETF does all of its business on the Web so there are no publication delays. Internet standards are called Requests for Comments or RFCs. A proposed standard will not be considered unless two working embodiments have been demonstrated. All business is conducted in a single language (English), which also speeds things up considerably. Most of all, the “instant” communication of all of the participants helps speed standard setting.
Standardization
Published in Saad Z. Asif, 5G Mobile Communications Concepts and Technologies, 2018
If a standards action is approved, notification is sent to the RFC (Request for Comments) Editor and copied to the IETF with instructions to publish the specification as an RFC by IESG. IETF produces RFCs describing research and methods applicable to the working of the Internet and Internet-connected systems. The RFCs are submitted to communicate new concepts and information. The IETF adopts some published RFCs as Internet standards. The IETF RFCs are particularly used in the transport of voice, video, and data services over the Internet.
Effects of Security Knowledge, Self-Control, and Countermeasures on Cybersecurity Behaviors
Published in Journal of Computer Information Systems, 2023
Countermeasure refers to an action or procedure taken against an unwanted action or situation. The Internet Security Glossary of IETF RFC36 describes countermeasure as ”an action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken.” Following guidelines provided in Straub and Welke,11 D’Arcy et al.23 used the term ”security countermeasures” to describe security-related mechanisms adopted to mitigate threats and vulnerabilities arising from workers’ usage of IS resources, including the Internet. Hovav and D’Arcy12 further delineated security countermeasures as procedural and technical countermeasures with SETA programs as an example of the former and computer monitoring as an example of the latter.
Minimum and maximum packets’ delays determination for communication flows’ delays jitters computation
Published in Australian Journal of Electrical and Electronics Engineering, 2023
To calculate the maximum and minimum delays of a PDU in a node using the model as represented by Equation (5), we need L, the maximum length in bits of a PDU; Cout, the bit rate (in bps) of an output port; and σ, the maximum size of traffic in bits that can arrive in a burst to an input port. Utilising the extended Ethernet frame which is illustrated in Figure 4 as our PDU, L = 7 +1 +6 +6 +4 +2 +1500 +4 = 1530 bytes = 1530 × 8 bits = 12,240 bits. Similarly, we choose Cout = 10 ×106 bps (the basic Ethernet rate). A value for σ is, however, not yet available in literature, as there is no general agreement on how bursty traffic should be characterised and quantified (that is, how a numerical value should be assigned to σ) (Yoshida et al. 2021). In this context, Sven, Ales, and Stanislav (2008) have averred that traffic burstiness metrics have not yet been defined and that schemes to monitor traffic burstiness are not yet well comprehended; hence, there has been no general agreement in literature on a quantifiable definition of data traffic burstiness (Ryousei et al. 2006; Shan et al. 2020). Therefore, we resorted to utilising the recommendations that are contained in IETF’s (Internet Engineering Task Force’s) RFC 2544 (Requests for Comments 2544) (Request For Comments 2544, 2018) with regard to burstibility tests of nodal devices. This particular RFC recommends burst sizes of 1024, 256, 64 and 16 frames when testing the burstibility of nodal devices.
A metaprotocol-based Internet of Things architecture
Published in Automatika, 2022
L. Milić, L. Jelenković, I. Magdalenić
An essential part of the system are “metaprotocol nodes”, i.e. nodes that actively use the metaprotocol. Depending on their role, such nodes can be very simple (resource-constrained nodes) that can only send or receive simpler metaprotocol messages, or they can be more complex. For example, in addition to its original function of using its sensors and/or actuators, a node may also be used to forward unmodified messages, or modify messages before forwarding them, possibly using a different underlying transmission protocol. Another node may be even more sophisticated, using rules to manipulate, store, retrieve messages, perform operations on a collection of messages, use security features, etc. These node complexities can be related to RFC 7228 [31] and its classes. When the most resource-constrained nodes are mentioned, they can be considered as Class 0, but in this architecture, the modelled metaprotocol nodes can be Class 0, 1, 2, or “above”. The complexity of a node does not affect its metaprotocol communication, only the operations it supports.