Computer networking session protocols: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(New page: While the Session Layer was considered one of the less important parts of the obsolescent Open Systems Interconnection Reference Model, '''session-layer protocols''' have been found to...)
 
imported>Howard C. Berkowitz
(Linked to VoIP)
Line 1: Line 1:
While the Session Layer was considered one of the less important parts of the obsolescent [[Open Systems Interconnection Reference Model]], '''session-layer protocols''' have been found to be useful in specific functions, such as deciding which end of a session talks and which end listens, and when it is necessary to have a generic function that manages end-to-end records rather than characters.
While the Session Layer was considered one of the less important parts of the obsolescent [[Open Systems Interconnection Reference Model]], '''session-layer protocols''' have been found to be useful in specific functions, such as deciding which end of a session talks and which end listens, and when it is necessary to have a generic function that manages end-to-end records rather than characters. A major application is in [[Voice over Internet Protocol]], as well as in various file and printer sharing mechanisms.


==Understanding the role of the Session Layer==
==Understanding the role of the Session Layer==

Revision as of 16:36, 10 May 2008

While the Session Layer was considered one of the less important parts of the obsolescent Open Systems Interconnection Reference Model, session-layer protocols have been found to be useful in specific functions, such as deciding which end of a session talks and which end listens, and when it is necessary to have a generic function that manages end-to-end records rather than characters. A major application is in Voice over Internet Protocol, as well as in various file and printer sharing mechanisms.

Understanding the role of the Session Layer

Session layer protocols that went outside the local environment had been rare. The early and practical examples came not from OSI standards, but from Sun Microsystems and Microsoft.

With any appreciable Windows in your environment, NetBIOS tends to be necessary unless you have been stringent on requiring IETF-compliant services everywhere. If you have UNIX systems, especially in clusters, RPC to support NFS is likely. When VoIP or Integrated Multimedia Services are present, SIP is a necessity.

Remote Procedure Call (RPC), for example, tended to be client-server on a LAN. That it used a variable range of UDP port numbers was not an issue for firewalls, because the traffic did not go through a firewall.

Remote Procedure Call

Introduced in UNIX systems and originally a Sun Microsystems protocol, the rights to which were made public, Remote Procedure Call (RPC) is a client-server protocol intended for efficient use across a LAN.[1] It runs over UDP, but does its own error retransmission based on retransmitting the entire application record.

Perhaps the most common RPC application is for the Network File System[2] and other distributed file systems, which indeed may improve efficiency if the communications are secure. Security can come from encryption, or a certainty the NFS environment is "air-gapped" from the outside.

NetBIOS

NetBIOS proper is principally a session-layer protocol used by Microsoft, although there are less frequently used datagram and connection-oriented modes. Its chief use is carrying the Server Message Block protocol for Windows' file and print sharing services, but can also provide a generic remote procedure call service.

While modern NetBIOS runs only over the Internet Protocol, the first version ran directly over the Data Link Layer, and another version ran over Novell Internet Packet Exchange (IPX).

Since IP-based NetBIOS runs over UDP,[3] and gives access to critical system resources, it is wise to close, to the outside world, all externally visible UDP ports except for the Domain Name Service. Exploits on the NetBIOS ports (UDP 136-139) are quite common, as these often run unlocked on Windows machines without firewalls.

Session Initiation Protocol

Another widespread use of session layer functionality is the Session Initiation Protocol (SIP). Among other applications, it carries Voice over Internet Protocol (VoIP) over dynamically created sessions, which are challenging to secure with traditional firewalls.[4]. Conventional firewalls make assumptions about port numbers, but SIP uses a dynamic range. SIP is the dominant protocol found inside the local multimedia border, although it rapidly is becoming the outside standard.

SIP is a multipurpose protocol most commonly used in voice and multimedia communications, which range from the minimal sessions of instant messaging to long telephone calls or streaming video requests [RFC3361]. SIP has some features that are different from other protocols with point-to-point transport protocols. One of the differences between SIP and other session protocols is that it can set up sessions involving more than two parties, such as conference calls. Because it dynamically selects UDP ports, it will not cleanly traverse a firewall, given that the rules that always get SIP through also may let unwanted things pass. Session Border Controllers are more appropriate for doing firewall-like filtering on SIP.

There are other VoIP functions with similar functions, such as ISO H.323, but SIP appears to be dominant. SIP is a basic part if third-generation cellular telephony. IP Multimedia Forum, which is the industry group that pushes "triple play" and multimedia convergence over IP, assumes SIP in its environment. Basic "triple play" is VoIP, television, and Internet access.

The IMS Forum (IP Multimedia Subsystem) is a global, non-profit industry association dedicated to service creation and applications delivery for IMS Architecture Frameworks, in addition to interoperability and certifications of IMS services and solutions. The Forum accelerates the adoption of IMS by creating a community for discussion and resolution of real world implementation and interoperability. In addition, the Forum will provide consultancy to the industry, service providers, and vendors on best practices and approaches for IMS rollouts and interconnectivity.[5]

Other services within the scope of IMS include instant messaging, short message service, location-based services, and other collaborative method. One important feature of SIP is "context awareness" or "presence information", so it can combine messaging and voice, and also cooperate with calendaring applications by indicating such status as "busy", "in transit", "available", "in conference", etc.

Mobile IP

Mobile IP is designed for situations when a user will spend a substantial amount of time in a different location than usually associated with his address. [6]It is not needed in mobility applications when a user dynamically gets a new address and registers it with DNS.

The basic idea of mobile IP is that a user has a home network and home address, and forwarding mechanisms to deliver traffic to her guest network. Obviously, there have to be ways that the now-remote user can tell the home gateway of her present location.

References

  1. Srinivasan, R. (August 1995), RPC: Remote Procedure Call Protocol Specification Version 2., Internet Engineering Task Force, RFC 1831
  2. Shepler, S. et al. (April 2003), Network File System (NFS) version 4 Protocol, Internet Engineering Task Force, RFC 3530
  3. NetBIOS Working Group' (March 1987), Protocol standard for a NetBIOS service on a TCP/UDP transport:Concepts and methods, Internet Engineering Task Force, RFC 1001
  4. Rosenberg J., Schulzrinne, H., et al. (June 2002), SIP: Session Initiation Protocol., Internet Engineering Task Force, RFC 3261
  5. IMS Forum: the Voice of IP Convergence
  6. Perkins, C., ed. (August 2002), IP Mobility Support for IPv4., Internet Engineering Task Force, RFC 3344