I have been reading about the SCTP, SS7 and SIGTRAN protocol. But I have a few doubts, I would like to know if someone who specializes more in networks can answer it. (I am a security auditor)
Can the SCTP protocol be used in other fields than just telephone communication (landline and mobile)?
Could it be said that the SS7 protocol is similar to the Internet Protocol (IP) but in telephony?
What is the most significant difference between SS7 and SIGTRAN?
Finally, is a PSTN (Public Switched Telephone Network) only for fixed telephony (homes) or also for mobile telephony (Cellular)?
Thank you for your answer,
Can the SCTP protocol be used in other fields than just telephone communication (landline and mobile)?
Yes, it can be used in other fields. SCTP is a protocol in the Transport Layer of the Internet Protocol Suite, that has its own advantages and disadvantages. For example it is used in WebRTC for the Data Channel.
Could it be said that the SS7 protocol is similar to the Internet Protocol (IP) but in telephony?
SS7 is not a single protocol but a set of telephony signalling protocols that includes protocols from all OSI layers so the comparison to a single (IP) protocol is not correct.
What is the most significant difference between SS7 and SIGTRAN?
SIGTRAN is SS7 over IP. The application layer protocols are the same (MAP, ISUP, CAMEL, ...) while the physical to transport layer (1 to 4) protocols are different. In SS7 you have MTP 1, 2 and 3 while in SIGTRAN you have IP, SCTP, M2PA, M2UA, M3UA, SUA protocols.
Finally, is a PSTN (Public Switched Telephone Network) only for fixed telephony (homes) or also for mobile telephony (Cellular)?
According to Wikipedia the PSTN includes the mobile networks.
Originally a network of fixed-line analog telephone systems,
the PSTN is now almost entirely digital in its core network
and includes mobile[1] and other networks, as well as fixed telephones.[1]
Related
I have a doubt about the IoT Protocol Stack .
Searching between papers on google scholar or IEEE about IoT , i find the actual "IoT Protocol Stack" :
IoT Stack
I think it is uncorrect .
The doubt is about the transport layer and application layer.
1) why there is only CoAP on the application layer if there are many others Application Layer Protocol for the IoT , such as : MQTT, XMPP ,AMQP , WebSockets and so on?
2) Why they provide only UDP at the Transport layer if in the upper layer ( Application) there are some important protocol in the environment of the IoT , for example MQTT, that run over TCP ?
The term "IoT" is used with various meanings by different interest groups; so is therefore the term "IoT stack".
What the linked image depicts is the IETF IoT Stack, which is the IETF's idea of what IoT devices should use to deserve that name. CoAP is the application protocol specified by IETF (and used by various others like OMA LwM2M, OCF or Thread), and is in my experience the best suited protocol as it allows full operation on tiny devices (technically: Class 0 according to RFC 7228 – good luck implementing XMPP, WebSockets or similar on those) while still being powerful enough to express all the concepts from the HTTP web.
The image depicting only UDP is probably due to the focus on IoT devices: While CoAP can be transmitted over several transport layers (including TCP and WebSockets, but also SMS in a draft version), those transports are rather used indirectly (eg. by a browser application that uses a gateway to talk to UDP connected devices), the expected scenario for the devices themselves is using CoAP over UDP on a 6LoWPAN network. That doesn't rule out other deployment scenarios (eg. LwM2M uses CoAP over cellular networks a lot, in UDP and TCP transports), but is better seen as typical example for the smallest of devices.
I know that MAC address is used for local routing and error free data transfer, but is it used regardless the transmission medium infrastructure? I know it is used for Ethernet, but is it used for fiber, copper...etc?
Also, do we use MAC address when routing traffic between two adjacent routers? If we do, does that mean we have MAC address over serial connections?
Thanks
MAC addresses are used in most IEEE 802 network technologies, like Ethernet (802.3) and Wifi (802.11), but not all technologies use them. For instance, Fibre Channel use a different and more modern address type, called World Wide Name. It's longer and can be 64-bits or 128-bits.
So, to answer your questions, a router can use MAC addresses if it forwards packets over Ethernet interfaces, regardless of the physical medium. But it could also use other technologies or even label-switching protocols like MPLS. A serial link does not have medium access control and therefore has no MAC layer.
is it used regardless the transmission medium infrastructure? I know it is used for Ethernet, but is it used for fiber, copper...etc?
You mix OSI layer 1 (transmission medium) and layer 2 (Ethernet). If we use Ethernet as our data link layer, Ethernet MAC addresses will be there regardless of transmission medium. More on that on Wikipedia:
https://en.wikipedia.org/wiki/OSI_model
do we use MAC address when routing traffic between two adjacent routers?
Yes, if the router are connected using Ethernet. Even if we use a back-to-back cable to connect two routers.
does that mean we have MAC address over serial connections?
For the most of serial connections we do not use Ethernet, but use other layer 2 protocols, like ppp, Frame-Relay or HDLC. Note, that all of those protocols use their own addressing, but it is just one or two bytes, not 6 as in the Ethernet MACs. More on those protocols on Wikipedia:
https://en.wikipedia.org/wiki/Point-to-Point_Protocol
https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
https://en.wikipedia.org/wiki/Frame_Relay
MQTT and CoAP are being promoted as standard protocols that allow connecting constrained devices to the Internet.
I'm interested in a list of sensors and actuators that support these two protocols either in a native way or through a mesh/gateway.
For CoAP:
Every 6LowPAN sensor mote have a CoAP client,
for example the one running contiki: http://www.contiki-os.org/hardware.html
or OpenWSN, RIOTOS
Also you can use any Arduino: https://github.com/1248/microcoap
One that is worth checking in addition to Julien's List is mBed from ARM
https://mbed.org/
it supports both CoAP and MQTT
CoAP/MQTT and sensors/actuators are two different entities. You can implement any sensors or resources with CoAP and MQTT.
CoAP and MQTT are application layer protocol that uses TCP/UDP to transfer data (for example, sensor readings) over network.
For example in CoAP, all sensors on your hardware are treated as 'resource'. CoAP provides GET, PUT, POST, DELETE interface to manipulate with resource.
It is developers responsibility to attach its custom handlers to above interface. For example, attach read_temperature_sensor_data() to 'GET' interface, attach set_clock_time() to 'PUT' interface etc.
Persistent connection to a mobile device is difficult. Signal conditions can change rapidly, and connectivity types can also change. For instance, I may want to stream audio to my phone as I leave my apartment (WiFi), take a bus (WiMax/LTE), transfer to the subway (intermittent CDMA, sometimes roaming on another carrier), and walk to work (WiMax/LTE and back to WiFi). On this 15-minute trip alone I use at least 4 different IP addresses/networks, and experience all sorts of connectivity issues along the way. However, there is rarely a total loss of connectivity to the Internet, and the times that the signal condition makes connectivity problematic only happen for small periods of time.
I'm looking for a protocol that allows roaming from network to network and is very tolerant of harsh network conditions, while maintaining virtual end-to-end connectivity. This protocol would enable connections between a (usually) mobile device and some sort of proxy server which would relay regular TCP/UDP connections on behalf of the mobile device, over this tolerant protocol.
This protocol would sit around layer 3, and maybe even enable creation of virtual network interfaces that are tunneled through it. Perhaps there is a VPN or SOCKS proxy solution that already meets these needs.
Does such a protocol already exist?
If not, I'm probably going to come up with one, but would rather piggy-back off of existing efforts first.
There are many efforts within the internetworking community to address precisely these "network mobility" concerns.
In particular, Mobile IP (and its IPv6 big sister, Proxy Mobile IPv6) is a broad term for efforts to make IP addresses themselves portable across networks, however I doubt these technologies have reached sufficient maturation/deployment for production use today.
To undertake such mobility without support from the network requires a means of the host announcing to you its new address in an authenticated manner; this is what the Host Identity Protocol is designed for, but it is still at the "experimental" stage of the RFC process. From the abstract of RFC 5201:
HIP allows consenting hosts to securely establish and maintain shared
IP-layer state, allowing separation of the identifier and locator
roles of IP addresses, thereby enabling continuity of communications
across IP address changes.
There are several open-source implementations that are known to interoperate. Without claiming that this is a complete list, nor vouching for any of them (they're just a few picked off a Google search for "Host Identity Protocol implementations"), there is:
OpenHIP for multiple operating systems;
HIPL for Linux;
cutehip for Java;
HIP for inter.net for *BSD/Linux.
I have gone through various udp based P2P Technology like Stun . I have implemented UDP/TCP hole punching recently for implementing p2p.
I found there are other technology as for like ICE,UPnP and teredo
Can any body tell me what is the difference between these technology.
Which one is the latest technology/protocol used for P2P in recent year.
It will good If any can provide comparative analysis on various UDP based P2P protocols.
Any link or suggestion will appreciated.
ICE stands for Interactive Connectivity Establishment. It is a protocol for NAT traversal (i.e., punching holes) supported by the IETF. There has been several reviews and evolutions of the RFC. Some may find the specifications overkill in general or unclear when it comes to performing TCP NAT traversal.
UPnP is a technology helping local devices finding each other and start communicating automatically. It implements IGD for NAT traversal, which allows remote configuration of the NAT/Router (when possible) to redirect WAN traffic to the device. Unfortunately, this method is a huge threat to security, since any application could hijack NATs/routers to let any undesirable traffic come in.
Teredo is not really related to P2P or NAT traveral. If you have an IPv6 device A on a ipv4 LAN (for example), it won't be able to connect using ipv6 to a remote ipv6 enabled device B located on the WAN. Teredo allows A to communicate with B with ipv6 by transporting ipv6 over ipv4. Teredo is massaging the frictions between ipv4 and ipv6, so to speak.
None of these technologies is 'dominating' P2P for now. It is still a boiling environment.