In a message dated 14 Sept 2004 12:49:39 -0400 Sanjaya Choudhury wrote:
> Hi! I will appreciate if somebody can help me [with] the following
> questions:
>
> Q1:The description associated with "ipv4InterfaceIfIndex" implies
> that it is same as the IF-MIB table's ifIndex of the _lower
> layer_" interface on which IPv4 is being configured. Is this
> interpretation correct?
If you mean "lower layer" in the sense used in the ifStackTable then
the answer is no. ipv4InterfaceIfIndex (or ipv6InterfaceIfIndex) is
supposed to point to whatever layer delivers packets to the IPv4 (or
IPv6) protocol machine. Typically this would be a layer at the top
of the ifStackTable, although that will in fact be a layer 2
interface that resides below the IP layer.
To make this clear, let's consider the case of a 10GBASE-W Ethernet
interface. This interface will use the WAN Interface Sublayer, and
according to RFC 3637, the layering model embodied in the ifStackTable
(and ifInvStackTable) will look like this:
_____________________________ _
| LLC Layer | |
+-----------------------------+ |
| MAC Layer | |
+-----------------------------+ > 1 ifEntry
| Reconciliation Sublayer | | ifType: ethernetCsmacd(6)
+-----------------------------+ |
| Physical Coding Sublayer | |
+-----------------------------+ +
| Path Layer | > 1 ifEntry
+-----------------------------+ + ifType: sonetPath(50)
| Line Layer | |
+-----------------------------+ |
| Section Layer | > 1 ifEntry
+-----------------------------+ | ifType: sonet(39)
| Physical Medium Layer | |
----------------------------- -
It is possible, via the MAU-MIB (RFC 3636), to dynamically switch a MAU
between 10GBASE-W and 10GBASE-X operation, if the underlying MAU hardware
supports that capability. When that switch is made, the lower layers in
the above diagram are destroyed, or at least disconnected from the upper
layer. In that case the ethernetCsmacd(6) - which is the sublayer that
delivers IP packets -- is all that remains. From this example I think
it is clear why the only logical place for ipv4InterfaceIfIndex (or
ipv6InterfaceIfIndex) to point is the ethernetCsmacd(6), and not one of
the lower sublayers.
If you consider cases that involve multiplexing or inverse multiplexing you
will come to the same conclusion.
It _is_ true that ipv4InterfaceIfIndex (or ipv6InterfaceIfIndex) will point
to a layer 2 interface that is "below" the IP layer. However, the IP layer
(if I understand the designers' intent) is _not_ represented as a separate
layer in the ifStackTable.
> Q2:A row in the "ipv4InterfaceTable" represents the IPv4 attributes
> associated with a existing layer2/lower_layer interface. Is this
> interpretation correct?
Yes, subject to the above.
> Q2.1 [If Q2 assumption is correct] All the lower layer interfaces
> that are capable of IPv4 will show up in the "ipv4InterfaceTable"
> without user intervention. Is this assumption correct ?
> Q.2.2 [If Q2 assumption is correct] An entry in the
> "ipv4InterfaceTable" _does not_ represent an IPv4 interface, rather
> a[n] IPv4 capable interface [...] is this assumption correct?
This has been my understanding. Perhaps the IP MIB design team members can
confirm.
> Q3. [If Q1 & Q2 are correct] Why not represent each entry in the
> "ipv4InterfaceTable" as an IPv4 Interface (with its own index
> -shared with MIB-II IPv4 or from its own space), where user explicitly
> decides to create an interface on a specific lower layer interface?
In other words, why not include IPv4 and IPv6 layers in the ifStackTable, and
allow them to be dynamically manipulated.
Partly, the reason is historical. When the MIB-II was first invented, there
was no ifSTackTable, and there were no per-interface IP statistics. The
ifStackTable came later, when it because clear that it was needed to represent
things like Frame Relay and X.25 virtual circuits. Per-interface statistics
postdate that.
It would be possible to do the type of manipulations you want, but an auxiliary
MIB module would be needed to do it. For an example of how that might be done
see RFC 3201.
Mike Heard
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
