When multiple sub-layers exist below the network layer, each sub-layer can be represented by its own row in the ifTable with its own ifType, with the ifStackTable being used to identify the upward and downward multiplexing relationships between rows. Section 3.1.1
of RFC 2863
provides more discussion, and 3.1.2
provides guidance for defining interface sub-layers. More recent experience shows that those guidelines were phrased in a way that is now too restrictive, since at the time [RFC 2863
] was written, MIB modules were the dominant data model.
This document clarifies that the same guidance also applies to YANG modules.
Some ifTypes may define sub-types. For example, the tunnel(131) ifType defines sub-types known as "tunnelTypes", where each tunnelType can have its own MIB and/or YANG module with protocol-specific information, but there is enough in common that some information is exposed in a generic IP Tunnel MIB corresponding to the tunnel(131) ifType.
For requests that involve multiple sub-layers below the network layer, requests MUST
include (or reference) a discussion of the multiplexing relationships between sub-layers, ideally with a diagram. Various well-written examples exist of such definitions, including Section 3.4.1
of RFC 3637
, Section 3.1.1
of RFC 4087
, and Section 3.1.1
of RFC 5066
Definers of sub-layers and sub-types should consider which model is more appropriate for their needs. A sub-layer is generally used whenever either a dynamic relationship exists (i.e., when the set of instances above or below a given instance can change over time) or a multiplexing relationship exists with another sub-layer. A sub-type can be used when neither of these is true but where one interface type is conceptually a subclass of another interface type, as far as a management data model is concerned.
In general, the intent of an interface type or sub-type is that its definition should be sufficient to identify an interoperable protocol. In some cases, however, a protocol might be defined in a way that is not sufficient to provide interoperability with other compliant implementations of that protocol. In such a case, an ifType definition should discuss whether specific instantiations (or profiles) of behavior should use a sub-layer model (e.g., each vendor might layer the protocol over its own sub-layer that provides the missing details) or a sub-type model (i.e., each vendor might subclass the protocol without any layering relationship). If a sub-type model is more appropriate, then the data model for the protocol might include a sub-type identifier so that management software can discover objects specific to the sub-type. In either case, such discussion is important to guide definers of a data model for the more specific information (i.e., a lower sub-layer or a sub-type), as well as the designated expert, who must review requests for any such ifTypes or sub-types.
Another design decision is whether to reuse an existing ifType or tunnelType value, possibly using a sub-type or sub-layer model for refinements, or to use a different value for a new mechanism.
If there is already an entry that could easily satisfy the modeling and functional requirements for the requested entry, it should be reused so that applications and tools that use the existing value can be used without changes. If, however, the modeling and functional requirements are significantly different enough such that having existing applications and tools use the existing value would be seen as a problem, a new value should be used.
For example, originally different ifType values were used for different flavors of Ethernet (ethernetCsmacd(6), iso88023Csmacd(7), fastEther(62), etc.), typically because they were registered by different vendors. Using different values was, however, seen as problematic because all were functionally similar, so [RFC 3635
] then deprecated all but ethernetCsmacd(6).
As another example, a udp(8) tunnelType value was defined in [RFC 2667
] with the description "The value UDP indicates that the payload packet is encapsulated within a normal UDP packet (e.g., RFC 1234
)." The Teredo tunnel protocol [RFC 4380
] was later defined and encapsulates packets over UDP, but the protocol model is quite different between [RFC 1234
] and Teredo. For example, [RFC 1234
] supports encapsulation of multicast/broadcast traffic, whereas Teredo does not. As such, it would be more confusing to applications and tools to represent them using the same tunnel type, and so [RFC 4087
] defined a new value for Teredo.
In summary, definers of new interface or tunnel mechanisms should use a new ifType or tunnelType value rather than reuse an existing value when key aspects such as the header format or the link model (point-to-point, non-broadcast multi-access, broadcast-capable multi-access, unidirectional broadcast, etc.) are significantly different from existing values, but they should reuse the same value when the differences can be expressed in terms of differing values of existing objects other than ifType/tunnelType in the standard YANG or MIB module.