Deepak, Jennifer,
Please allow me to add myself to this discussion.
Jennifer, I have to say that I do not completely agree with your answers but let me assure you at the same time that this topic is a source of much confusion/contention and I don't think there is any definitive answer to it, and I happen to be from that part of community that likes to see things sorted differently.
In the following paragraphs, the names of layers refer to the TCP/IP model, not to the OSI model.
We have a fundamental problem in discovering how shall a protocol be classified into a layer? Very often, it is classified by the services it depends on. Quite logically, they must be provided already by other layers, and within our usual hierarchical models, the services are provided by the lower layers than the layer in which the protocol under dispute is located. That would, for example, place the OSPF (and RIP and EIGRP as well) into the Application Layer. However, a second way to classify a protocol is to classify it by the services it provides itself. Now, the OSPF clearly provides services to Internet layer, but not the usual "transport" service as, say, Ethernet does, but rather it provides control information on how shall the Internet layer operate. This would move the OSPF down to or under the Internet layer, maybe even to the Link layer. Clearly, the OSPF could be encapsulated directly into Link layer frames in a similar fashion to the IS-IS and it would work, so the Internet layer is not really necessary to deliver OSPF packets. Still, the Internet layer provides, for example, the addressing semantics (address formats et al.) used inside the OSPF messages... so even an OSPF placed on the Link layer (that should be agnostic about the Internet layer) needs to be Internet layer specific, at least in the addressing issues. That, in my opinion, moves the OSPF to the Internet layer, not as a user protocol used to transport user data, but rather as a support (or service) protocol used for purposes of the Internet layer itself. And this holds for all routing protocols.
Note that a criterium that discerns protocols based on where are they implemented - wheter in an application (in the userspace) or in the driver (in the kernelspace) cannot be used at all. Opening a raw socket by a privileged process allows you to implement the entire TCP/IP suite solely in userspace. Would that make the IP an Application layer protocol? Surely not.
These are some of the reasons I strongly disagree with the current sorting of routing protocols into layers as described in the Wikipedia. The "Internet Protocol Suite" box at the right side of all three pages about RIP, OSPF and EIGRP is, in my opinion, inconsistent. For example, it places the RIP into the Application layer and the OSPF into the Link layer. According to what criteria? If the criterium is "what is the protocol encapsulated into" then the OSPF should strictly be a Transport layer protocol (it is encapsulated directly into IP) and the RIP is correctly an Application layer protocol. If the criterium is "where is the protocol implemented" then all routing protocols are usually userspace daemons so both RIP and OSPF should have been placed into the Application layer. If the criterium is "what services does the protocol provide" then both OSPF and RIP should have been placed into the Internet layer. This placement would also be consistent with various other RFCs:
- RFC 942 describes an obsolete routing protocol - the Gateway-to-Gateway Protocol and it attributes it to the Internet layer.
- RFC 1122 considers the ICMP that provides, among others, first-hop redirection (i.e. simplified routing) services, also to be in the Internet layer. Also, it contains an important statement: Although ICMP messages are encapsulated within IP datagrams, ICMP processing is considered to be (and is typically implemented as) part of the IP layer.
Thus, I believe that it would be more correct to place all routing protocols - RIP, EIGRP, OSPF - into the Internet layer, because the services they provide are directly and inseparably related to the operations of the Internet layer. Some of the RFCs already seem to imply that.
As I indicated in the very beginning, the sorting of protocols among layers can be a source of flamewars and neverending discussions, and it also stems from the fact that we are trying to stuff the various TCP/IP protocols into OSI RM terminology which can be deceptive, as the TCP/IP and OSI do not relate closely. The strict layering is not considered to be an imperative in the TCP/IP world (see the RFC 3439, Section 3 - Layering Considered Harmful). This is quite a strong departure from rigid layering principle mandated in the OSI world.
I'd love to hear your thoughts on this - I like the topic of this discussion though I accept that we may not arrive at the same conclusion.
Best regards,
Peter
