It should be noted that an agent does not have to support the non-
wildcard protocol identifier over the same base layer. For instance
a token ring only device would not normally support IP over the
ether2 base layer. Nevertheless it should use the ether2 base layer
for defining the wildcard IP encapsulation. The agent MAY also
support counting some or all of the individual encapsulations for the
same protocols, in addition to wildcard counting. Note that the
RMON-2 MIB [RFC2021] does not require that agents maintain counters
for multiple encapsulations of the same protocol. It is an
implementation-specific matter as to how an agent determines which
protocol combinations to allow in the protocolDirTable at any given
time.
4.2. Base Layer Protocol Identifiers
The base layer is mandatory, and defines the base encapsulation of
the packet and any special functions for this identifier.
There are no suggested protocolDirParameters bits for the base layer.
The suggested value for the ProtocolDirDescr field for the base layer
is given by the corresponding "Name" field in the table 4.2 below.
However, implementations are only required to use the appropriate
integer identifier values.
For most base layer protocols, the protocolDirType field should
contain bits set for the 'hasChildren(0)' and '
addressRecognitionCapable(1)' attributes. However, the special
'ianaAssigned' base layer should have no parameter or attribute bits
set.
By design, only 255 different base layer encapsulations are
supported. There are five base encapsulation values defined at this
time. Very few new base encapsulations (e.g. for new media types) are
expected to be added over time.
Table 4.2 Base Layer Encoding Values
--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
-- Ether2 Encapsulation
ether2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the high
order byte and low order byte of the Ethernet-II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
Children of ether2 are named as 'ether2' followed by the type
field value in hexadecimal. The above example would be declared
as:
ether2 0x0800"
ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order."
DECODING
"Only type values greater than 1500 decimal indicate Ethernet-II
frames; lower values indicate 802.3 encapsulation (see below)."
REFERENCE
"The authoritative list of Ether Type values is identified by the
URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
-- LLC Encapsulation
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Logical Link Control (LLC) 802.2 protocol."
CHILDREN
"The LLC Source Service Access Point (SSAP) and Destination
Service Access Point (DSAP) are used to select child protocols.
Each of these is one octet long, although the least significant
bit is a control bit and should be masked out in most situations.
Typically SSAP and DSAP (once masked) are the same for a given
protocol - each end implicitly knows whether it is the server or
client in a client/server protocol. This is only a convention,
however, and it is possible for them to be different. The SSAP
is matched against child protocols first. If none is found then
the DSAP is matched instead. The child protocol is deemed to
start at the first octet after the LLC control field(s).
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
defines NetBios over LLC.
Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.
LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw 802.3
encapsulations). For 802.5 there is no other link layer
protocol.
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
-- Encapsulation
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP Protocol Identifier field (PID) is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
are the high order byte and low order byte of the Ethernet-II
type value.
For example, a protocolDirID-fragment value of:
0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:
snap 0x0800"
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of Organizationally Unique Identifier (OUI) and two octets
of PID. For this encapsulation the OUI must be 0x000000 (see
'vsnap' below for non-zero OUIs)."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }
-- Vendor SNAP over LLC (OUI != 000) Encapsulation
vsnap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that have a
zero OUI value."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the
protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order.
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols
over vsnap.
Children are named as 'vsnap <OUI>', where the '<OUI>' field is
represented as 3 octets in hexadecimal notation.
So the above example would be named:
'vsnap 0x080007'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero and the SNAP
Protocol Identifier is not parsed."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }
-- IANA Assigned Protocols
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic (preventing the any 'well-known'
protocol-identifier macro from being used).
Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'limited extensibility' feature of the
protocolDirTable, and do not need special IANA assignments.
A centrally located list of these enumerated protocols must be
maintained by IANA to insure interoperability. (See section 2.3
for details on the document update procedure.) Support for new
link-layers will be added explicitly, and only protocols which
cannot possibly be represented in a better way will be considered
as 'ianaAssigned' protocols.
IANA protocols are identified by the base-layer-selector value [
0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer
value corresponding to the particular IANA protocol.
Do not create children of this protocol unless you are sure that
they cannot be handled by the more conventional link layers
above."
CHILDREN
"Children of this protocol are identified by implementation-
specific means, described (as best as possible) in the 'DECODING'
clause within the protocol-variant-identifier macro for each
enumerated protocol.
Children of this protocol are encoded as [ 0.0.0.5 ], the
protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ]
where 'a', 'b' are the network byte order encodings of the high
order byte and low order byte of the enumeration value for the
particular IANA assigned protocol.
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the numeric value
of the particular IANA assigned protocol. The above example
would be named:
'ianaAssigned 1' "
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
-- The following protocol-variant-identifier macro declarations are
-- used to identify the RMONMIB IANA assigned protocols in a
-- proprietary way, by simple enumeration.
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
4.3. Encapsulation Layers
Encapsulation layers are positioned between the base layer and the
network layer. It is an implementation-specific matter whether a
probe exposes all such encapsulations in its RMON-2 Protocol
Directory.
4.3.1. IEEE 802.1Q
RMON probes may encounter 'VLAN tagged' frames on monitored links.
The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and
[IEEE802.1D-1998], define an encapsulation layer inserted after the
MAC layer and before the network layer. This section defines a PI
macro which supports most (but not all) features of that
encapsulation layer.
Most notably, the RMON PI macro '802-1Q' does not expose the Token
Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN
header. It is an implementation specific matter whether an RMON
probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-Native
(LLC-N) format, for the purpose of RMON collection.
In order to support the Ethernet and LLC-N formats in the most
efficient manner, and still maintain alignment with the RMON-2 '
collapsed' base layer approach (i.e., support for snap and vsnap),
the children of 802dot1Q are encoded a little differently than the
children of other base layer identifiers.
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not
explicitly identified by this PI macro. Ethernet-encoded vs.
SNAP-encoded TPID fields can be identified by the ifType of the
data source for a particular RMON collection, since the SNAP-
encoded format is used exclusively on Token Ring and FDDI media.
Also, no information held in the TCI field (including the TR-
encap bit) is identified in protocolDirID strings utilizing this
PI macro."
CHILDREN
"The first byte of the 4-byte child identifier is used to
distinguish the particular base encoding that follows the 802.1Q
header. The remaining three bytes are used exactly as defined by
the indicated base layer encoding.
In order to simplify the child encoding for the most common
cases, the 'ether2' and 'snap' base layers are combined into a
single identifier, with a value of zero. The other base layers
are encoded with values taken from Table 4.2.
802-1Q Base ID Values
---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
The generic child layer-identifier format is shown below:
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the
network byte order encodings of the high order byte and low order
byte of the Ethernet-II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.0.0.8.0
defines IP, VLAN-encapsulated in ether2.
Children of this format are named as '802-1Q' followed by the
type field value in hexadecimal.
So the above example would be declared as:
'802-1Q 0x0800'.
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the
SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.2.0.0.240
defines NetBios, VLAN-encapsulated over LLC.
Children are named as '802-1Q' followed by the SAP value in
hexadecimal, with the leading octet set to the value 2.
So the above example would have been named:
'802-1Q 0x020000f0'
Base ID == 4
------------
For payloads encoded with LLC/SNAP (non-zero OUI) headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'vsnap' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are
the 3 octets of the OUI field in network byte order.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.4.8.0.7 defines the Apple-specific set of
protocols, VLAN-encapsulated over vsnap.
Children are named as '802-1Q' followed by the <OUI> value, which
is represented as 3 octets in hexadecimal notation, with a
leading octet set to the value 4.
So the above example would be named:
'802-1Q 0x04080007'.
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier
for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the
network byte order encodings of the high order byte and low order
byte of the enumeration value for the particular IANA assigned
protocol.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.5.0.0.0.1
defines the IPX protocol, VLAN-encapsulated directly in 802.3
Children are named '802-1Q' followed by the numeric value of the
particular IANA assigned protocol, with a leading octet set to
the value of 5.
Children are named '802-1Q' followed by the hexadecimal encoding
of the child identifier. The above example would be named:
'802-1Q 0x05000001'. "
DECODING
"VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]."
REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]."
::= {
ether2 0x8100 -- Ethernet or SNAP encoding of TPID
-- snap 0x8100 ** excluded to reduce PD size & complexity
}
5. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. Acknowledgements
This document was produced by the IETF RMONMIB Working Group.
The authors wish to thank the following people for their
contributions to this document:
Anil Singhal
Frontier Software Development, Inc.
Jeanne Haney
Bay Networks
Dan Hansen
Network General Corp.
Special thanks are in order to the following people for writing RMON
PI macro compilers, and improving the specification of the PI macro
language:
David Perkins
DeskTalk Systems, Inc.
Skip Koppenhaver
Technically Elite, Inc.
7. References
[AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington,
"LAN Emulation over ATM - Version 1.0", AF-
LANE-0021.000, ATM Forum, IBM, January 1995.
[AF-NM-TEST-0080.000] Network Management Sub-working Group, Test
Sub-working Group, A. Bierman, "Remote
Monitoring MIB Extensions for ATM Networks",
AF- NM-TEST-0080.000, ATM Forum, Cisco Systems,
February 1997.
[IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE
Computer Society, "Information technology --
Telecommunications and information exchange
between systems -- Local and metropolitan area
networks -- Common specification -- Part 3:
Media Access Control (MAC) Bridges", ISO/IEC
Final DIS 15802-3 (IEEE P802.1D/D17) Institute
of Electrical and Electronics Engineers, Inc.,
May 1998.
[IEEE802.1Q] LAN MAN Standards Committee of the IEEE
Computer Society, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged
Local Area Networks", Draft Standard
P802.1Q/D11, Institute of Electrical and
Electronics Engineers, Inc., July 1998.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and
Identification of Management Information for
TCP/IP-based Internets", STD 16, RFC1155, May
1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J.
Davin, "Simple Network Management Protocol",
STD 15, RFC1157, May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB
Definitions", STD 16, RFC1212, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for
use with the SNMP", RFC1215, March 1991.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over
ATM Adaptation Layer 5", RFC1483, July 1993.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC1700, October 1994.
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Introduction to Community-based
SNMPv2", RFC1901, January 1996.
[RFC1902] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Structure of Management
Information for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1902,
January 1996.
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Textual Conventions for version 2
of the Simple Network Management Protocol
(SNMPv2)", RFC1903, January 1996.
[RFC1904] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Conformance Statements for version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC1904, January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Protocol Operations for Version 2
of the Simple Network Management Protocol
(SNMPv2)", RFC1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Transport Mappings for Version 2
of the Simple Network Management Protocol
(SNMPv2)"", RFC1906, January 1996.
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB
(RMON-2)", RFC2021, January 1997.
[RFC2074] Bierman, A. and R. Iddon, "Remote Network
Monitoring MIB Protocol Identifiers", RFC2074,
January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC2119,
March 1997.
[RFC2233] McCloghrie, K. and F. Kastenholz, "The
Interfaces Group MIB Using SMIv2", RFC2233,
November 1997.
[RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC2271, January 1998.
[RFC2272] Case, J., Harrington D., Presuhn R. and B.
Wijnen, "Message Processing and Dispatching for
the Simple Network Management Protocol (SNMP)",
RFC2272, January 1998.
[RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC2273, January 1998.
[RFC2274] Blumenthal, U. and B. Wijnen, "User-based
Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)",
RFC2274, January 1998.
[RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie,
"View-based Access Control Model (VACM) for the
Simple Network Management Protocol (SNMP)", RFC
2275, January 1998.
[RFC2570] Case, J., Mundy, R., Partain, D. and B.
Stewart, "Introduction to Version 3 of the
Internet-standard Network Management
Framework", RFC2570, April 1999.
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC2571, April 1999.
[RFC2572] Case, J., Harrington D., Presuhn R. and B.
Wijnen, "Message Processing and Dispatching for
the Simple Network Management Protocol (SNMP)",
RFC2572, April 1999.
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC2573, April 1999.
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based
Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)",
RFC2574, April 1999.
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie,
"View-based Access Control Model (VACM) for the
Simple Network Management Protocol (SNMP)", RFC
2575, April 1999.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser,
"Structure of Management Information Version 2
(SMIv2)", STD 58, RFC2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser,
"Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote
Network Monitoring MIB Protocol Identifier
Macros", RFC2896, August 2000.
8. IANA Considerations
The protocols identified in this specification are almost entirely
defined in external documents. In some rare cases, an arbitrary
Protocol Identifier assignment must be made in order to support a
particular protocol in the RMON-2 protocolDirTable. Protocol
Identifier macros for such protocols will be defined under the '
ianaAssigned' base layer (see sections 3. and 4.2).
At this time, only one protocol is defined under the ianaAssigned
base layer, called 'ipxOverRaw8023' (see section 4.2).
9. Security Considerations
This document discusses the syntax and semantics of textual
descriptions of networking protocols, not the definition of any
networking behavior. As such, no security considerations are raised
by this memo.
10. Authors' Addresses
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Chris Bucci
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Robin Iddon
c/o 3Com Inc.
Blackfriars House
40/50 Blackfrias Street
Edinburgh, EH1 1NE, UK
Phone: +44 131.558.3888
EMail: None
Appendix A: Changes since RFC2074
The differences between RFC2074 and this document are:
- RFC2074 has been split into a reference document
(this document) on the standards track and an informational
document [RFC2896], in order to remove most
protocol identifier macros out of the standards track document.
- Administrative updates; added an author, added copyrights,
updated SNMP framework boilerplate;
- Updated overview section.
- Section 2.1 MUST, SHOULD text added per template
- Section 2.1 added some new terms
- parent protocol
- child protocol
- protocol encapsulation tree
- Added section 2.3 about splitting into 2 documents:
"Relationship to the RMON Protocol Identifier Macros Document"
- Added section 2.4 "Relationship to the ATM-RMON MIB"
- rewrote section 3.2 "Protocol Identifier Macro Format"
But no semantic changes were made; The PI macro syntax
is now specified in greater detail using BNF notation.
- Section 3.2.3.1 "Mapping of the 'countsFragments(0)' BIT"
- this section was clarified to allow multiple
protocolDirParameters octets in a given PI string
to set the 'countsFragments' bit. The RFCversion
says just one octet can set this BIT. It is a
useful feature to identify fragmentation at
multiple layers, and most RMON-2 agents were
already doing this, so the WG agreed to this
clarification.
- Added section 4.3 "Encapsualtion Layers"
- This document ends after the base layer encapsulation
definitions (through RFC2074, section 5.2)
- Added Intellectual Property section
- Moved RFC2074 section 5.3
"L3: Children of Base Protocol Identifiers"
through the end of RFC2074, to the PI Reference [RFC2896]
document, in which many new protocol identifier macros were
added for application protocols and non-IP protocol
stacks.
- Acknowledgements section has been updated
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.