The OSI Model and SharePoint

The OSI Model and SharePoint

The OSI model is the standard when it comes to routing, switching, and broad-spectrum application services, along with supporting conventional networked services. It spans the entire network computing infrastructure to provide a standard by which network and application engineers, as well as SharePoint architects can communicate pertinent information back and forth between each other leveraging a common standard. Although selected layers may prove to abstract for a SharePoint architect to be particularly concerned about, they nonetheless provide a positive insight into the network and application architecture that fabricate the backbone of how SharePoint operates and functions at a multiplicity of levels.

Layer 1 The Physical Layer

The first layer of the OSI model is the physical layer. Relative to SharePoint, the physical layer deals with the actual data rates and physical connectors while erect the inclusive collaboration environment. At the physical layer, there is the defining of how the actual bits that SharePoint creates (at a very high level, translated to a very low level) is converted into voltage and transmitted across a physical medium. This is a very granular level that SharePoint architects rarely see, since it will determine the transmission medium including whether it is a thinnet, thicknet, or Unshielded Twisted Pair (UTP) that SharePoint will employ. The overall concept, at a high level, is how SharePoint will function at the physical link in a networked environment.

There are several network devices that define the physical layer, such as:

  • Hubs
  • Repeaters
  • Multiplexers
  • Network Interface Cards

Along with these physical devices, there are several protocols that operate at this level, such as:

  • ATM
  • BRI
  • X.23
  • PRI
  • E1
  • E3
  • 10BaseT
  • 100BaseT
  • 10Base2
  • 10Base5
  • OC-3
  • OC-12
  • DS1
  • DS3

Layer 2 The DataLink Layer

The DataLink layer contracts predominantly with topology and frame handling. In this, there are certain other things defined such as the physical network addressing, line discipline, notification of network errors, delivery of frames in ordered pairs, and network data flow control. SharePoint architects will have relatively no interaction with the DataLink layer, since it is either handled by network engineers or through automation provided by network devices.

The DataLink layer will bestow the workings of certain resolution protocols such as the Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP) which interrelate with the two sub-layers that the DataLink supplies, the Media Access Control layer (MAC) and the Logical Link Control (LLC) layer. MAC interacts with the Physical layer in that it provides physical addresses for resolution to transpire. The MAC address are 12 hexadecimal digits, the first 6 that defined by the IEEE, and the latter six defined by the vendor, all burned into Read Only Memory (ROM) of the arbitrary machine. The LLC talks up in the OSI model by instantiating a uniform interface that procures independent LAN media access to procure flow control and sequencing services.

The network devices that exist at the DataLink Layer of the OSI model are:

  • Bridges
  • Switches

The protocols that exist at the DataLink layer are:

  • SLIP
  • PPP
  • RARP
  • IARP
  • SNAP
  • BAP
  • CHAP
  • LCP
  • LZS
  • MLP
  • Frame Relay
  • HDLC
  • BPDU
  • LAPD
  • ISL
  • MAC
  • Ethernet
  • Token Ring
  • L2F
  • L2TP
  • ISDN

Layer 3 Network Layer

The Network Layer of the OSI model defines the injected information of the sent packets and frames so that they can be properly routed throughout the network to the correct destination sets. For SharePoint architects this is typically where content routers can be inserted. As well, securing routers is imperative to collaboration environments since compromising the router can eventually lead to concessions with the aggregate collaboration environment.

The Network Layer is fundamentally accountable for next-hop resolution and addressing, which build the principals of routing and switching. As broad network problems arise they are also resolved at this level, such as when there is network congestion (if multiple packet injections institutes a traffic bottleneck) that occurs that is affecting normal operations. After the segment are received from the Transport Level of the OSI model, it is pieced into Maximum Transmission Units (MTUs), which will consecutively classify the thresholds for the sized packets that are allowed to cross an arbitrary network medium. After the packet is sent, it is moreover reassembled at this level.

As well, the Network Level also has several duties related to the subnet, including how information packets are routed from the source to the destination, using an arbitrary set of routing logic that is up to the network architect to decide on, and the related node metrics.

The devices that operate at the network layer are:

  • Routers

The protocols that can execute at the network layer are:

  • IP
  • DHCP
  • OSPF
  • IPX
  • ICMP
  • RIP
  • ISIS
  • ZIP
  • DDP
  • X.25

Layer 4 The Transport Layer

The transport layer provides the essential transport services for end-to-end data movement, along with establishing the entail connections that are needed for the data transport to occur by establishing a logical link between the two. In essence, the transport layer is responsible for all activities related to the massaging of data between two endpoints by assimilating data from the Session Layer and breaking it into lesser units and passing it to the network layer, and then assuring that the data is routed correctly. SharePoint architects tend to have very little interaction with this layer since it is mostly automated by the appropriate network devices and for adjustments requires an understanding of the Cisco IOS. The transport layer provides another layer of abstraction in order to accommodate for changes to the physical network.

The Transport layer is most known for its function related to TCP. The transport layer will subdivide user-buffer datagrams, into network-buffer datagrams, and implement that necessary transport protocols for the data transmission to occur. As stated before, TCP exists at this level, as well as User Datagram Protocol (UDP). Between these two protocols, the largest difference is the concept of speed and reliability. UDP simply makes a handshake with low overhead transmission services and is essentially stateless with no error checking. The TCP protocol however keeps a running tally of the packets being delivered and the order that the packets are sent with granular error checking, sent via sockets. This in essence, means that TCP is a stateful protocol.

Protocols that are used at the transport level are:

  • TCP
  • UDP
  • SPX
  • ATP

Layer 5 The Session Layer

The session layer is mostly responsible for establishing and maintaining the inclusive connection between two network enabled hosts, providing the facilities for preserving the connection during the transport of the data as well as controlling the drop of the connection if it is needed. For SharePoint architects the session layer typically interacts with how relevant SharePoint frames and dropped and managed at the network level. This is not implying anything regarding session stating or viewstates, since this are application specific settings.

The Session Layer does three main actions related to sessions:

  1. Establishes the Session
  2. Maintains the Session
  3. Drops the Session

Involved with the session process are the recognition and identification of the parties involved in the packet inter-exchange so that participation of the session parties can be maintained. To promote the quality of the session (QoS) there is a synchronization check that occurs by injecting checkpoints into the transmitted data streams in order to detect whether a session fails so that the last checkpoint can be reloaded into the session stream for transmission, this provides a rudimentary form of fault-tolerance.

In a networked computing environment, the session layer enables two client machines to establish a germane session to implement conventional data transport as well as time-sharing and file transport between client machines. As opposed to the Transport Layer of the OSI model that can still provide ordinary data transport the session’s layer can also implement dialogue control in order to procure bi-directional traffic control and keep a tally of the clients that are involved in a traffic push.

The protocols that are used in the session layer are:

  • DNS
  • RPC
  • SQL
  • NFS
  • SSL
  • TLS
  • SSH
  • ASP

Layer 6 The Presentation Layer

Layer 6 of the OSI model, the Presentation Layer, is the primary means of representing data in a standard structure that can be translated into sensible data once it is received at the destination. The presentation layer is genuinely where the SharePoint architect will begin to interact with the OSI model since it is where relevant SharePoint frames are converted into the service that build the presentation layer of the application.

During this frame resolution process, there is a translation procedure that occurs between the format that is provided by the network and the format that is parsed by the application. This provides a uniform method of conversion, whereby all data passed through the OSI model can be translated into a common format through the use of protocol conversion, character conversion, data encryption services, graphic commands, and data compression.

Layer 7 The Application Layer

The Application Layer provides the support needed to provide support to services that will generate the user interface from relevant application services. The application layer should not be confused with the tangible user interface, but is instead the application interface that will in turn impart support to the user interface. This is where the ASP.NET framework will reside since it is the service that services the SharePoint framework, but does not actually generate the user interface.

The Application Layer will provide the network access flow, overall flow control, and general error recovery after the transmitted data has reached this level.

The protocols that are used in the Application layer are

  • HTTP
  • NNTP
  • DNS
  • SMTP
  • DNS
  • FTP
  • TFTP
  • SNMP
  • MIME
  • NFS
  • Finger
  • Telnet
  • NCP
  • SET
  • SMB

Algorithms Supported by CryptoCollaboration

Some people have emailed me expressing an interest in CryptoCollaboration, wanting to know the specific encryption algorithms that are going to be supported. For the time being, in order to satisfy the requirements for my dissertation, only secret-key encryption (symmetric) algorithms are going to be in the initial release.


String support will be added shortly afterwords, however it is currently beyond my workload in order to support it.

The following I have already finished coding to compensate for, and are included in the bundled release:

Data Encryption Standard (DES) – 64-bit encryption
RC2 – 128-bit encryption
Rijndael – 256-bit encryption
TripleDES – 192-bit TripleDES encryption

I might be adding others in future releases, but for the time being those are the ones that are going to be supported. If there are situational benefits that mandate other schemes, I would be interested to hear the business case.

I also finished the multi-threading for the encryption/decryption routines in order to optimize file IO operations, which was a pain in the butt. I am probably going to release this source before the actual solution source to get feedback since threading isn’t one of my strong suits. If you know threading pretty well, and have 45 minutes, I would love to run some code by you.

It would also be interesting to see how the general population thinks that the encryption should be invoked. I am using it as a context menu item right now that pops up a progress window post encryption event capture. Here are two little screenshots, even though they really don’t give much away about the actual functionality:

Starting the encryption process on a document:

Encryption Complete Window:

(Yeah, I haven’t gotten it to encrypt the actual filename yet :-) )

The actual settings for encryption are maintained in a hidden menu. I really hate this approach so will be changing it shortly to something else once I think of something that is more clever.