3.1.2.  Novell IPX Stack

ipx PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
      hasChildren(0),
      addressRecognitionCapable(1)
    }

    DESCRIPTION
       "Novell IPX"
    CHILDREN
       "Children of IPX are defined by the 8 bit packet type field.  The
       value is encoded into an octet string as [ 0.0.0.a ], where 'a'
       is the single octet of the packet type field.

       Notice that in many implementations of IPX usage of the packet
       type field is inconsistent with the specification and
       implementations are encouraged to use other techniques to map
       inconsistent values to the correct value (which in these cases is
       typically the Packet Exchange Protocol).  It is beyond the scope
       of this document to describe these techniques in more detail.

       Children of IPX are encoded as [ 0.0.0.a ], and named as 'ipx a'
       where a is the packet type value.  The novell echo protocol is
       referred to as 'ipx nov-echo' OR 'ipx 2'."
    ADDRESS-FORMAT
       "4 bytes of Network number followed by the 6 bytes Host address
       each in network byte order."
    REFERENCE
       "The IPX protocol is defined by the Novell Corporation

       A complete description of IPX may be secured at the following
       address:
              Novell, Inc.
              122 East 1700 South
              P. O. Box 5900
              Provo, Utah 84601 USA
              800 526 5463
              Novell Part # 883-000780-001"
    ::= {
        ether2       0x8137,       -- [0.0.129.55]
           snap         0x8137,       -- [0.0.129.55]

           ianaAssigned 1,            -- [0.0.0.1]   (ipxOverRaw8023)
        llc          224,          -- [0.0.0.224]
           802-1Q       0x8137,       -- [0.0.129.55]
        802-1Q       0x020000e0,   -- 1Q-LLC [2.0.0.224]
           802-1Q       0x05000001    -- 1Q-IANA [5.0.0.1]
                                      -- (ipxOverRaw8023)
    }

nov-rip PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell Routing Information Protocol"
    REFERENCE
       "Novell Corporation"
    ::= {
        ipx 0x01,       -- when reached by IPX packet type
        nov-pep 0x0453  -- when reached by IPX socket number
    }

nov-echo PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell Echo Protocol"
    REFERENCE
       "Novell Corporation"
    ::= { ipx 0x02 }

nov-error PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell Error-handler Protocol"
    REFERENCE
       "Novell Corporation"
    ::= { ipx 0x03 }

nov-pep PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Novell Packet Exchange Protocol.  This is really a null protocol
       layer as all IPX packets contain the relevant fields for this
       protocol.  This protocol is defined so that socket-based decoding
       has a point of attachment in the decode tree while still allowing

       packet type based decoding also."
    CHILDREN
       "Children of PEP are defined by the 16 bit socket values.  The
       value is encoded into an octet string as [ 0.0.a.b ], where 'a'
       and 'b' are the network byte order encodings of the MSB and LSB
       of the socket value.

       Each IPX/PEP packet contains two sockets, source and destination.
       How these are mapped onto the single well-known socket value used
       to identify its children is beyond the scope of this document."
    REFERENCE
       "Novell Corporation"
    ::= {
     -- ipx 0x00     ** Many third party IPX's use this value always
     ipx 0x04        -- Xerox assigned for PEP
     -- ipx 0x11     ** Novell use this for PEP packets, often
    }

nov-spx PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
    hasChildren(0)
 }
    DESCRIPTION
       "Novell Sequenced Packet Exchange Protocol.  This protocol is an
       extension of IPX/PEP as it shares a common header."
    CHILDREN
       "Children of SPX are defined by the 16 bit socket values.  The
       value is encoded into an octet string as [ 0.0.a.b ], where 'a'
       and 'b' are the network byte order encodings of the MSB and LSB
       of the socket value.

       Each IPX/SPX packet contains two sockets, source and destination.
       How these are mapped onto the single well-known socket value used
       to identify its children is beyond the scope of this document."
    REFERENCE
       "Novell Corporation"
    ::= {
     ipx 0x05 -- Xerox assigned for SPX
    }

nov-sap PROTOCOL-IDENTIFIER
    PARAMETERS {
     tracksSessions(1)
    }
    ATTRIBUTES {
     hasChildren(0)
    }

    DESCRIPTION
       "Novell Service Advertising Protocol.  This protocol binds
       applications on a particular host to an IPX/PEP or IPX/SPX socket
       number.  Although it never truly acts as a transport protocol
       itself it is used to establish sessions between clients and
       servers and barring well-known sockets is the only reliable way
       to determine the protocol running over a given socket on a given
       machine."
    CHILDREN
       "Children of SAP are identified by a 16 bit service type.  They
       are encoded as [ 0.0.a.b ], where 'a' is the MSB and 'b' is the
       LSB of the service type.

       Children of SAP are named as 'nov-sap a' where 'a' is the service
       type in hexadecimal notation.  The novell NCP protocol is
       referred to as 'nov-sap ncp' OR 'nov-sap 0x0004'."
    DECODING
       "The first packet of any session for a SAP based application
       (almost all IPX/PEP and IPX/SPX based applications utilize SAP)
       is sent to the SAP server(s) to map the service type into a port
       number for the host(s) on which the SAP server(s) is(are)
       running.  These initial packets are SAP packets and not
       application packets and must be decoded accordingly.

       Having established the mapping, clients will then send
       application packets to the newly discovered socket number.  These
       must be decoded by 'remembering' the socket assignments
       transmitted in the SAP packets.

       In some cases the port mapping for a particular protocol is well
       known and SAP will always return the same socket number for that
       application.

       Such programs should still be declared as children of nov-sap as
       described under CHILDREN above.  How an implementation detects a
       client which is bypassing the SAP server to contact a well-known
       application is beyond the scope of this document.

       The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
       the probe can (and should) monitor nov-sap activity to correctly
       track SAP-based connections."
    REFERENCE
       "A list of SAP service types can be found at
          ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-
       numbers"
    ::= { nov-pep 0x0452 }

ncp PROTOCOL-IDENTIFIER

    PARAMETERS {
     tracksSessions(1)
    }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Netware Core Protocol"
    CHILDREN
       "Children of NCP are identified by the 8 bit command type field.
       They are encoded as [ 0.0.0.a ] where 'a' is the command type
       value.

       Children of NCP are named as 'ncp a' where 'a' is the command
       type in decimal notation.  The NDS sub-protocol is referred to as
       'ncp nds' OR 'ncp 104'."
    DECODING
       "Only the NCP request frames carry the command type field.  How
       the implementation infers the command type of a response frame is
       an implementation specific matter and beyond the scope of this
       document.

       The tracksSessions(1) PARAMETERS bit indicates whether the probe
       can (and should) perform command type inference."
    REFERENCE
       "Novell Corporation"
    ::= { nov-sap 0x0004,
       nov-pep 0x0451 }

nds PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
         "The Netware Directory Services sub-protocol."
    REFERENCE
       "Novell Corporation"
    ::= { ncp 104 }

nov-diag PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell's diagnostic Protocol"
    REFERENCE
       "Novell Corporation"
    ::= {
     nov-sap 0x0017,   -- [ed., this is the right one]
     nov-pep 0x0456

    }

nov-sec PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell security - serialization - copy protection protocol."
    REFERENCE
       "Novell Corporation"
    ::= { nov-pep 0x0457 }

nov-watchdog PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell watchdog protocol."
    REFERENCE
       "Novell Corporation"
    ::= { nov-pep 0x4004 }

nov-bcast PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell broadcast protocol."
    REFERENCE
       "Novell Corporation"
    ::= { nov-pep 0x4005 }

3.1.3.  The XEROX Protocol Stack

idp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
      hasChildren(0),
      addressRecognitionCapable(1)
    }
    DESCRIPTION
       "Xerox IDP"
    CHILDREN
       "Children of IDP are defined by the 8 bit value of the Packet
       type field.  The value is encoded into an octet string as [
       0.0.0.a ], where 'a' is the value of the packet type field in
       network byte order.

       Children of IDP are encoded as [ 0.0.0.a ], and named as 'idp a'
       where a is the packet type value.  The XNS SPP protocol is
       referred to as 'idp xns-spp' OR 'idp 2'."

    ADDRESS-FORMAT
       "4 bytes of Network number followed by the 6 bytes Host address
       each in network byte order."
    REFERENCE
       "Xerox Corporation, Document XNSS 028112, 1981"
    ::=  {
       ether2  0x600,     -- [ 0.0.6.0 ]
       snap    0x600,
       802-1Q  0x600      -- [ 0.0.6.0 ]
    }

xns-rip PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Routing Information Protocol."
    REFERENCE
       "Xerox Corporation"
    ::= { idp 1 }

xns-echo PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "XNS echo protocol."
    REFERENCE
       "Xerox Corporation"
    ::= { idp 2 }

xns-error PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "XNS error-handler protocol."
    REFERENCE
       "Xerox Corporation"
    ::= { idp 3 }

xns-pep PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)

    }
    DESCRIPTION
       "XNS Packet Exchange Protocol."
    CHILDREN
       "Children of PEP are defined by the 16 bit socket values.  The

       value is encoded into an octet string as [ 0.0.a.b ], where 'a'
       and 'b' are the network byte order encodings of the MSB and LSB
       of the socket value.

       Each XNS/PEP packet contains two sockets, source and destination.
       How these are mapped onto the single well-known socket value used
       to identify its children is beyond the scope of this document."
    REFERENCE
       "Xerox Corporation"
    ::= { idp 4 }

xns-spp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Sequenced Packet Protocol."
    CHILDREN
       "Children of SPP are defined by the 16 bit socket values.  The
       value is encoded into an octet string as [ 0.0.a.b ], where 'a'
       and 'b' are the network byte order encodings of the MSB and LSB
       of the socket value.

       Each XNS/SPP packet contains two sockets, source and destination.
       How these are mapped onto the single well-known socket value used
       to identify its children is beyond the scope of this document."
    REFERENCE
       "Xerox Corporation"
    ::= { idp 5 }

3.1.4.  AppleTalk Protocol Stack

apple-oui PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Pseudo-protocol which binds Apple's protocols to vsnap."
    CHILDREN
       "Children of apple-oui are identified by the ether2 type field
       value that the child uses when encapsulated in ether2.  The value
       is encoded into an octet string as [ 0.0.a.b ], where 'a' and 'b'
       are the MSB and LSB of the 16-bit ether type value in network
       byte order."
    REFERENCE
       "AppleTalk Phase 2 Protocol Specification, document ADPA
        #C0144LL/A."
    ::=   {

     vsnap    0x080007,     --  [ 0.8.0.7 ]
     802-1Q   0x04080007    --  1Q-VSNAP [ 4.8.0.7 ]
    }

aarp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "AppleTalk Address Resolution Protocol."
    REFERENCE
       "AppleTalk Phase 2 Protocol Specification, document ADPA
        #C0144LL/A."
    ::=   {
     ether2    0x80f3,            --  [ 0.0.128.243 ]
     snap      0x80f3,
     apple-oui 0x80f3,
     802-1Q    0x80f3             --  [ 0.0.128.243 ]
    }

atalk PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0),
     addressRecognitionCapable(1)
    }
    DESCRIPTION
       "AppleTalk Protocol."
    CHILDREN
       "Children of ATALK are defined by the 8 bit value of the DDP type
       field.  The value is encoded into an octet string as [ 0.0.0.a ],
       where 'a' is the value of the DDP type field in network byte
       order."
    ADDRESS-FORMAT
       "2 bytes of Network number followed by 1 byte of node id each in
       network byte order."
    REFERENCE
       "AppleTalk Phase 2 Protocol Specification, document ADPA
        #C0144LL/A."
    ::=   {
     ether2     0x809b,   -- [ 0.0.128.155 ]
        apple-oui  0x809b,
     802-1Q     0x809b    -- [ 0.0.128.155 ]
    }

rtmp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION

       "AppleTalk Routing Table Maintenance Protocol."
    REFERENCE
       "Apple Computer"
    ::= {
     atalk   0x01,       -- responses
     atalk   0x05        -- requests
    }

aep PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "AppleTalk Echo Protocol."
    REFERENCE
       "Apple Computer"
    ::= { atalk 0x04 }

nbp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "AppleTalk Name Binding Protocol."
    DECODING
       "In order to correctly identify the application protocol running
       over atp NBP packets must be analyzed.  The mechanism by which
       this is achieved is beyond the scope of this document."
    REFERENCE
       "Apple Computer"
    ::= { atalk 0x02 }

zip PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "AppleTalk Zone Information Protocol."
    REFERENCE
       "Apple Computer"
    ::= {
     atalk   0x06,
     atp     3
    }

atp PROTOCOL-IDENTIFIER
    PARAMETERS {
     tracksSessions(1)
    }
    ATTRIBUTES {
     hasChildren(0)

    }
    DESCRIPTION
       "AppleTalk Transaction Protocol."
    CHILDREN
       "Children of atp are identified by the following (32 bit)
       enumeration:
         1   asp (AppleTalk Session Protocol)
         2   pap (Printer Access Protocol)
         3   zip (Zone Information Protocol)
       Children of atp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
       and 'd' are the four octets of the enumerated value in network
       order (i.e. 'a' is the MSB and 'd' is the LSB).

       The ZIP protocol is referred to as 'atp zip' OR 'atp 3'."
    DECODING
       "An implementation is encouraged to examine both the socket
       fields in the associated DDP header as well as the contents of
       prior NBP packets in order to determine which (if any) child is
       present.  A full description of this algorithm is beyond the
       scope of this document.  The tracksSessions(1) PARAMETER
       indicates whether the probe can (and should) perform this
       analysis."
    REFERENCE
       "Apple Computer"
    ::= { atalk 0x03 }

adsp PROTOCOL-IDENTIFIER
    PARAMETERS {
     tracksSessions(1)
    }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "AppleTalk Data Stream Protocol."
    CHILDREN
       "Children of adsp are identified by enumeration.  At this time
       none are known."
    DECODING
       "An implementation is encouraged to examine the socket numbers in
       the associated DDP header as well as the contents of prior NBP
       packets in order to determine which (if any) child of ADSP is
       present.

       The mechanism by which this is achieved is beyond the scope of
       this document.

       The tracksSessions(1) PARAMETER indicates whether the probe can

       (and should) perform this analysis."
    REFERENCE
       "Apple Computer"
    ::= { atalk 0x07 }

asp PROTOCOL-IDENTIFIER
 PARAMETERS { }
    ATTRIBUTES {
  hasChildren(0)
 }
    DESCRIPTION
       "AppleTalk Session Protocol."
    CHILDREN
       "Children of asp are identified by the following (32 bit)
       enumeration:
         1   afp (AppleTalk Filing Protocol)
       Children of asp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
       and 'd' are the four octets of the enumerated value in network
       order (i.e. 'a' is the MSB and 'd' is the LSB).

       The AFP protocol is referred to as 'asp afp' OR 'asp 1'."
    DECODING
       "ASP is a helper layer to assist in building client/server
       protocols.  It cooperates with ATP to achieve this; the
       mechanisms used when decoding ATP apply equally here (i.e.
       checking DDP socket numbers and tracking NBP packets).

       Hence the tracksSessions(1) PARAMETER of atp applies to this
       protocol also."
    REFERENCE
       "Apple Computer"
    ::= { atp 1 }

afp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
         "AppleTalk Filing Protocol."
    REFERENCE
       "Apple Computer"
    ::= { asp 1 }

pap PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "AppleTalk Printer Access Protocol."
    REFERENCE

       "Apple Computer"
    ::= { atp 2 }

3.1.5.  Banyon Vines Protocol Stack

vtr PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Banyan Vines Token Ring Protocol Header."
    CHILDREN
       "Children of vines-tr are identified by the 8 bit packet type
       field.  Children are encoded as [ 0.0.0.a ] where 'a' is the
       packet type value.

       The vines-ip protocol is referred to as 'vines-tr vip' OR 'vines-
       tr 0xba'."
    REFERENCE
       "See vip."
    ::= {
     llc          0xBC,      -- declared as any LLC, but really TR only.
     802-1Q       0x020000BC   -- 1Q-LLC [2.0.0.188]
    }

vecho PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Banyan Vines data link level echo protocol."
    REFERENCE
       "See vip."
    ::= {
     ether2      0x0BAF,      -- [0.0.11.175]
     snap        0x0BAF,
     -- vfrp     0x0BAF,
     vtr         0xBB,        -- [ed. yuck!]
     802-1Q      0x0BAF       -- [0.0.11.175]
     }

vip PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0),
     addressRecognitionCapable(1)
    }
    DESCRIPTION

       "Banyan Vines Internet Protocol."
    CHILDREN
       "Children of vip are selected by the one-byte 'protocol type'
       field located at offset 5 in the vip header.  The value is
       encoded as [ 0.0.0.a ], where a is the 'protocol type.'  For
       example, a protocolDirId fragment of:

          0.0.0.1.0.0.11.173.0.0.0.1

         identifies an encapsulation of vipc (ether2.vip.vipc)."
    ADDRESS-FORMAT
       "vip packets have 6-byte source and destination addresses.  The
       destination address is located at offset 6 in the vip header, and
       the source address at offset 12.  These are encoded in network
       byte order."
    REFERENCE
       "Vines Protocol Definition - part# 092093-001, order# 003673

         BANYAN,
         120 Flanders Road,
         Westboro, MA 01581 USA"
    ::= {
     ether2  0x0BAD,
     snap    0x0BAD,
     -- vfrp 0x0BAD,
     vtr     0xBA,        -- [ed. yuck!]
     802-1Q  0x0BAD       -- [0.0.11.173]
    }

varp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Banyan Vines Address Resolution Protocol."
    REFERENCE
       "BANYAN"
    ::= { vip 0x04 }

vipc PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Banyan Vines Interprocess Communications Protocol."
    CHILDREN
       "Children of Vines IPC are identified by the packet type field at
       offset 4 in the vipc header.

       These are encoded as [ 0.0.0.a ] where 'a' is the packet type
       value.  Children of vipc are defined as 'vipc a' where 'a' is the
       packet type value in hexadecimal notation.

       The Vines Reliable Data Transport protocol is referred to as
       'vipc vipc-rdp' OR 'vipc 0x01'."
    DECODING
       "Children of vipc are deemed to start at the first byte after the
       packet type field (i.e. at offset 5 in the vipc header)."
    REFERENCE
       "BANYAN"
    ::= { vip 0x01 }

 -- Banyan treats vipc, vipc-dgp and vipc-rdp as one protocol, IPC.
 -- Vines IPC really comes in two flavours.  The first is used to
 -- send unreliable datagrams (vipc packet type 0x00).  The second
 -- used to send reliable datagrams (vipc packet type 0x01),
 -- consisting of up to four actual packets.
 -- In order to distinguish between these we need two 'virtual'
 -- protocols to identify which is which.

vipc-dgp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
     }
    DESCRIPTION
       "Vines Unreliable Datagram Protocol."
    CHILDREN
       "Children of vipc-dgp are identified by the 16 bit port numbers
       contained in the vipc (this protocol's parent protocol) header.

       These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
       the MSB of the port number in network byte order.

       Children of vipc-dgp are defined as 'vipc-dgp a' where 'a' is the
       port number in hexadecimal notation.

       The StreetTalk protocol running over vipc-dgp would be referred
       to as 'vipc-dgp streettalk' OR 'vipc-dgp 0x000F'.

       The mechanism by which an implementation selects which of the
       source and destination ports to use in determining which child
       protocol is present is implementation specific and beyond the
       scope of this document."
    DECODING
       "Children of vipc-dgp are deemed to start after the single
       padding byte found in the vipc header.  In the case of vipc-dgp

       the vipc header is a so called 'short' header, total length 6
       bytes (including the final padding byte)."
    REFERENCE
       "BANYAN"
    ::= { vipc 0x00 }

vipc-rdp PROTOCOL-IDENTIFIER
    PARAMETERS {
     countsFragments(0)
    }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Vines Reliable Datagram Protocol."
    CHILDREN
       "Children of vipc-rdp are identified by the 16 bit port numbers
       contained in the vipc (this protocol's parent protocol) header.

       These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
       the MSB of the port number in network byte order.

       Children of vipc-dgp are defined as 'vipc-rdp a' where 'a' is the
       port number in hexadecimal notation.

       The StreetTalk protocol running over vipc-rdp would be referred
       to as 'vipc-rdp streettalk' OR 'vipc-rdp 0x000F'.

       The mechanism by which an implementation selects which of the
       source and destination ports to use in determining which child
       protocol is present is implementation specific and beyond the
       scope of this document."
    DECODING
       "Children of vipc-rdp are deemed to start after the error/length
       field at the end of the vipc header.  For vipc-rdp the vipc
       header is a so called 'long' header, total 16 bytes (including
       the final error/length field).

       vipc-rdp includes a high level fragmentation scheme which allows
       up to four vipc packets to be sent as a single atomic PDU.  The
       countsFragments(0) PARAMETERS bit indicates whether the probe can
       (and should) identify the child protocol in all fragments or only
       the leading one."
    REFERENCE
       "BANYAN"
    ::= { vipc 0x01 }

vspp PROTOCOL-IDENTIFIER

    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
         "Banyan Vines Sequenced Packet Protocol."
    CHILDREN
       "Children of vspp are identified by the 16 bit port numbers
       contained in the vspp header.

       These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
       the MSB of the port number in network byte order.

       Children of vspp are defined as 'vspp a' where 'a' is the port
       number in hexadecimal notation.

       The StreetTalk protocol running over vspp would be referred to as
       'vspp streettalk' OR 'vspp 0x000F'.

       The mechanism by which an implementation selects which of the
       source and destination ports to use in determining which child
       protocol is present is implementation specific and beyond the
       scope of this document."
    DECODING
       "The implementation must ensure only those vspp packets which
       contain application data are decoded and passed on to children.
       Although it is suggested that the packet type and control fields
       should be used to determine this fact it is beyond the scope of
       this document to fully define the algorithm used."
    REFERENCE
       "BANYAN"
    ::= { vip 0x02 }

vrtp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Banyan Vines Routing Update Protocol."
    REFERENCE
       "BANYAN"
    ::= { vip 0x05 }

vicp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Banyan Vines Internet Control Protocol."
    REFERENCE

       "BANYAN"
    ::= { vip 0x06 }

3.1.6.  The DECNet Protocol Stack

dec PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC"
    REFERENCE
       "Digital Corporation"
    ::= {
     ether2 0x6000,
     802-1Q 0x6000      -- [0.0.96.0]
    }

lat PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Local Area Transport Protocol."
    REFERENCE
       "Digital Corporation"
    ::= {
     ether2 0x6004,
     802-1Q 0x6004      -- [0.0.96.4]
    }

mop PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Maintenance Operations Protocol."
    REFERENCE
       "Digital Corporation"
    ::= {
     ether2 0x6001,    -- mop dump/load
     ether2 0x6002,    -- mop remote console
     802-1Q 0x6001,    -- [0.0.96.1]  VLAN + mop dump/load
     802-1Q 0x6002     -- [0.0.96.2]  VLAN + mop remote console
    }

dec-diag PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Diagnostic Protocol."

    REFERENCE
       "Digital Corporation"
    ::= {
     ether2 0x6005,
     802-1Q 0x6005     -- [0.0.96.5]
    }

lavc PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Local Area VAX Cluster Protocol."
    REFERENCE
       "Digital Corporation"
    ::= {
     ether2 0x6007,
     802-1Q 0x6007         -- [0.0.96.7]
    }

drp PROTOCOL-IDENTIFIER
    PARAMETERS {
     countsFragments(1)
    }
    ATTRIBUTES {
     hasChildren(0),
     addressRecognitionCapable(1)
    }
    DESCRIPTION
       "DEC Routing Protocol."

    CHILDREN
       "There is only one child of DRP, NSP.  This is encoded as [
       0.0.0.1 ]."
    ADDRESS-FORMAT
       "There are three address formats used in DRP packets, 2-byte
       (short data packet and all control except ethernet endnode &
       router hello messages), 6-byte (ethernet router & endnode hello
       messages) and 8-byte (long data packet).  All of these contain
       the 2-byte format address in the last 2 bytes with the remaining
       bytes being unimportant for the purposes of system
       identification.  It is beyond the scope of this document to
       define the algorithms used to identify packet types and hence
       address formats.

       The 2-byte address format is the concatenation of a 6-bit area
       and a 10-bit node number.  In all cases this is placed in little
       endian format (i.e. LSB, MSB).  The probe, however, will return
       them in network order (MSB, LSB).  Regardless of the address

       format in the packet, the probe will always use the 2-byte
       format.

       For example area=13 (001101) and node=311 (0100110111) gives:
         0011 0101 0011 0111 = 0x3537 in network order (the order the
         probe should return the address in).

         In packets this same value would appear as (hex):

          2-byte  37 35
          6-byte  AA 00 04 00 37 35
          8-byte  00 00 AA 00 04 00 37 35

       Notice that the AA 00 04 00 prefix is defined in the
       specification but is unimportant and should not be parsed.

       Notice that control messages only have a source address in the
       header and so they can never be added into the conversation based
       tables."
    DECODING
       "NSP runs over DRP data packets; all other packet types are DRP
       control packets of one sort or another and do not carry any
       higher layer protocol.

       NSP packets are deemed to start at the beginning of the DRP data
       area.

       Data packets may be fragmented over multiple DRP data packets.
       The countsFragments(1) parameter indicates whether a probe can
       (and should) attribute non-leading fragments to the child
       protocol (above NSP in this case) or not.

       Recognition of DRP data packets and fragments is beyond the scope
       of this document."
    REFERENCE
       "DECnet Digital Network Architecture
         Phase IV
         Routing Layer Functional Specification
         Order# AA-X435A-TK
         Digital Equipment Corporation, Maynard, Massachusetts, USA"
    ::= {
     ether2  0x6003,
     snap    0x6003,
     802-1Q  0x6003     -- [0.0.96.3]
    }

nsp PROTOCOL-IDENTIFIER
    PARAMETERS {

     tracksSessions(1)
    }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "DEC Network Services Protocol."
    CHILDREN
       "Children of NSP are identified by the SCP 8-bit object type.
       Notice that the object type is included only in the session
       establishment messages (connect initiate, retransmitted connect
       initiate).

       Children of NSP are encoded [ 0.0.0.a ] where 'a' is the SCP
       object type.  Children of NSP are named as 'nsp' followed by the
       SCP object type in decimal.  CTERM is referred to as 'nsp cterm'
       OR 'nsp 42'."
    DECODING
       "An implementation is encouraged to examine SCP headers included
       in NSP control messages in order to determine which child
       protocol is present over a given session.  It is beyond the scope
       of this document to define the algorithm used to do this.

       The tracksSessions(1) flag indicates whether the probe can (and
       should) perform this analysis."
    REFERENCE
       "DECnet Digital Network Architecture
         Phase IV
         NSP Functional Specification
         Order# AA-X439A-TK
         Digital Equipment Corporation, Maynard, Massachusetts, USA"
    ::= { drp 1 }

dap-v1 PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Data Access Protocol version 1."
    REFERENCE
       "Digital Corporation"
    ::= { nsp 1 }

dap-v4 PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Data Access Protocol versions 4 and above."
    REFERENCE

       "Digital Corporation"
    ::= { nsp 17 }

nice PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Network Information and Control Exchange protocol."
    REFERENCE
       "Digital Corporation"
    ::= { nsp 19 }

dec-loop PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Loopback Protocol."
    REFERENCE
       "Digital Corporation"
    ::= { nsp 25 }

dec-event PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC Event Protocol."
    REFERENCE
       "Digital Corporation"
    ::= { nsp 26 }

cterm PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "DEC CTERM Protocol."
    REFERENCE
       "Digital Corporation"
    ::= { nsp 42 }

3.1.7.  The IBM SNA Protocol Stack.

sna-th PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "IBM's SNA TH protocol."
    REFERENCE
       "IBM Systems Network Architecture

         Format and Protocol
         Reference Manual: Architectural Logic

         SC30-3112-2

         IBM System Communications Division,
         Publications Development,
         Department E02,
         PO Box 12195,
         Research Triangle Park,
         North Carolina 27709."
    ::= {
     llc        0x04,              -- [0.0.0.4]
     llc        0x08,              -- [0.0.0.8]
     llc        0x0c,              -- [0.0.0.12]
        ether2     0x80d5,            -- [0.0.128.213]
     802-1Q     0x02000004,        -- 1Q-LLC [2.0.0.4]
     802-1Q     0x02000008,        -- 1Q-LLC [2.0.0.8]
     802-1Q     0x0200000c,        -- 1Q-LLC [2.0.0.12]
        802-1Q     0x80d5             -- [0.0.128.213]
    }

3.1.8.  The NetBEUI/NetBIOS Family

-- CHILDREN OF NETBIOS
-- The NetBIOS/NetBEUI functions are implemented over a wide variety of
-- transports.  Despite varying implementations they all share two
-- features.  First, all sessions are established by connecting to
-- locally named services.  Second, all sessions transport application
-- data between the client and the named service.  In all cases the
-- identification of the application protocol carried within the data
-- packets is beyond the scope of this document.]
--
-- Children of NetBIOS/NetBEUI are identified by the following (32 bit)
-- enumeration
--
--      1   smb (Microsoft's Server Message Block Protocol)
--      2   notes (Lotus' Notes Protocol)
--      3   cc-mail (Lotus' CC Mail Protocol)
--
-- Children of NetBIOS/NetBEUI are encoded as [ a.b.c.d ] where 'a', 'b',
-- 'c' and 'd' are the four octets of the enumerated value in network
-- order (i.e.  'a' is the MSB and 'd' is the LSB).
--
-- For example notes over NetBEUI is declared as
--      'notes ::= { netbeui 2 }'
-- but is referred to as
--      'netbeui notes' OR 'netbeui 2'.

netbeui PROTOCOL-IDENTIFIER
    PARAMETERS {
     tracksSessions(1)
    }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Lan Manager NetBEUI protocol."

    CHILDREN
       "See `CHILDREN OF NETBIOS`"
    DECODING
       "NETBEUI provides a named service lookup function.  This function
       allows clients to locate a service by (locally assigned) name.
       An implementation is encouraged to follow lookups and session
       establishments and having determined the child protocol, track
       them.

       How the child protocol is determined and how the sessions are
       tracked is an implementation specific matter and is beyond the
       scope of this document."
    REFERENCE
       "IBM"
    ::= {
     llc        0xF0,          --  [0.0.0.240]
     802-1Q     0x020000F0     --  1Q-LLC [2.0.0.240]
    }

nbt-name PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "NetBIOS-over-TCP name protocol."
    REFERENCE
       "RFC 1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
       SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.'  RFC 1002
       [RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
       A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
    ::= {
     udp     137,
     tcp     137
    }

nbt-session PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION

       "NetBIOS-over-TCP session protocol."
    REFERENCE
       "RFC 1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
       SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.'  RFC 1002
       [RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
       A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
    ::= {

     udp     139,
     tcp     139
    }

nbt-data PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "NetBIOS-over-TCP datagram protocol."
    CHILDREN
       "See `CHILDREN OF NETBIOS`"
    REFERENCE
       "RFC 1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
       SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.'  RFC 1002
       [RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
       A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
    ::= {
     udp     138,
     tcp     138
    }

netbios-3com PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "3COM NetBIOS protocol."
    CHILDREN
       "See `CHILDREN OF NETBIOS`"
    REFERENCE
       "3Com Corporation"
    ::= {
     ether2  0x3C00,
     ether2  0x3C01,
     ether2  0x3C02,
     ether2  0x3C03,
     ether2  0x3C04,

     ether2  0x3C05,
     ether2  0x3C06,
     ether2  0x3C07,
     ether2  0x3C08,
     ether2  0x3C09,
     ether2  0x3C0A,
     ether2  0x3C0B,
     ether2  0x3C0C,
     ether2  0x3C0D,
     802-1Q  0x3C00,
     802-1Q  0x3C01,
     802-1Q  0x3C02,
     802-1Q  0x3C03,
     802-1Q  0x3C04,
     802-1Q  0x3C05,
     802-1Q  0x3C06,
     802-1Q  0x3C07,
     802-1Q  0x3C08,
     802-1Q  0x3C09,
     802-1Q  0x3C0A,
     802-1Q  0x3C0B,
     802-1Q  0x3C0C,
     802-1Q  0x3C0D
    }

nov-netbios PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "Novell's version of the NetBIOS protocol."
    CHILDREN
       "See `CHILDREN OF NETBIOS`"
    REFERENCE
       "Novell Corporation"
    ::= {
     nov-sap 0x0020,  -- preferred encapsulation to use, even though
                      -- the following are typically used also
     -- ipx  0x14,       -- when reached by IPX packet type
     -- nov-pep 0x0455   -- when reached by socket number
    }

burst PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Novell burst-mode transfer"

    REFERENCE

       "Novell Corporation"
    ::= { nov-pep 0x0d05 }