New ifType for X.25

["Dean D. Throop" <[e-mail]>]

The following proposes some additional iftypes for X.25.
All comments are welcome.


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


               Additional SNMP ifTypes for X.25

                        August 9, 1993


                        Dean D. Throop

                   Data General Corporation
                       62 Alexander Dr.
               Research Triangle Park, NC 27709

                     [e-mail]






Status of this Memo

This document is an Internet Draft.  Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts).

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time.  It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."

Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.

1.  Introduction

This document defines three additional enumerations for
ifType.  These new types allow more flexibility in
representing X.25.  The new types can be used in place of ddn-
x25(6) and rfc877-x25(5).  This also defines a type for llc2.








D. Throop         Invalid after February 1,94         [Page 1]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


1.1.  Revision History

August 9 1993

Initial release.













































D. Throop         Invalid after February 1,94         [Page 2]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


2.  The Network Management Framework

The Internet-standard Network Management Framework consists of
three components.  These components give the rules for
defining objects, the definitions of objects, and the protocol
for manipulating objects.

The network management framework structures objects in an
abstract information tree.  The branches of the tree name
objects and the leaves of the tree contain the values
manipulated to effect management.  This tree is called the
Management Information Base or MIB.  The concepts of this tree
are given in RFC 1155 "The Structure of Management
Information" or SMI [1].  The SMI defines the trunk of the
tree and the types of objects used when defining the leaves.
RFC 1212, "Towards Concise MIB Definitions" [3], defines a
more concise description mechanism that preserves all the
principals of the SMI.

The core MIB definitions for the Internet suite of protocols
can be found in RFC 1213 [4] "Management Information Base for
Network Management of TCP/IP-based internets".

RFC 1157 [2] defines the SNMP protocol itself.  The protocol
defines how to manipulate the objects in a remote MIB.

The tree structure of the MIB allows new objects to be defined
for the purpose of experimentation and evaluation.

3.  Object Definitions

The definition of an object in the MIB requires an object name
and type.  Object names and types are defined using the subset
of Abstract Syntax Notation One (ASN.1) [5] defined in the SMI
[1].  Objects are named using ASN.1 object identifiers,
administratively assigned names, to specify object types.  The
object name, together with an optional object instance,
uniquely identifies a specific instance of an object.  For
human convenience, we often use a textual string, termed the
descriptor, to refer to objects.

Objects also have a syntax that defines the abstract data
structure corresponding to that object type.  The ASN.1
language [5] provides the primitives used for this purpose.
The SMI [1] purposely restricts the ASN.1 constructs which may





D. Throop         Invalid after February 1,94         [Page 3]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


be used for simplicity and ease of implementation.

4.  Experience with Existing Definition

RFC 1213 defines the core set of managed objects for use with
Internet Protocols.  One of those objects is ifType which
defines the type of an interface in the interface table.
There currently are two enumerations for X.25 interfaces: ddn-
x25(4) and rfc877-x25(5).  The ddn-x25(4) enumeration
identifies an X.25 interface which uses an algorithm for
mapping IP addresses to X.121 addresses.  The rfc877-x25
enumeration identifies an X.25 interface that uses a lookup
table to map IP addresses to X.121 addresses.

Experience has shown these enumerations do not always allow an
SNMP Agent to represent the managed system.  These definitions
have the following short comings:

    Can't represent an X.25 interface that  doesn't  carry
    IP  traffic.   Both types imply IP traffic so there is
    no way to imply the interface doesn't carry  IP  traf-
    fic.


    Can't  represent  a system that uses both address map-
    ping mechanisms over the same interface.


    Does not allow control of X.25 separate  from  the  IP
    encapsulation running over it.  Some systems allow the
    IP interface to X.25 to be configured up or down inde-
    pendent from the X.25 service itself.


















D. Throop         Invalid after February 1,94         [Page 4]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


5.  New Definitions

This document defines the following new values for ifType:

    x25ple(33),
    miox25(34), and
    iso88022llc(35).


The ifType value x25ple(33), defines an X.25 Packet Level
entity interface with no implied upper layer services.

The ifType value miox25(34), defines a Multiprotocol
Interconnect over X.25 interface as defined in RFC 1356 [9].

The ifType value iso88022llc(35), defines a Link Level Control
protocol interface.  (This is the protocol used for the Link
Level when carrying X.25 packets on an Ethernet in place the
LAPB [7] protocol used on Sync lines.)

6.  Use of existing types

The existing types ddn-x25 and rfc877-x25 should be used to
define interfaces which include both X.25 packet level entity
service and IP over X.25 capability.  These interfaces are
configured and managed as a single entity.

When a system allows separate configuration and control of the
X.25 PLE and the software which performs the encapsulation of
upper layer packet in X.25, that system should provide two
entries in the ifTable.  Those entries should be identified by
the types x25ple and miox25 respectively.

7.  Impact on other Standards

These new definitions also impact already existing standards.
The X.25 MIB (RFC 1382) [8] now applies to interfaces of type
ddn-x25(4), rfc877-x25, and x25ple(33).

The MIOX25-MIB, RFC 1461, now applies interfaces of type ddn-
x25(5), rfc877-x25(5), and miox25(34).









D. Throop         Invalid after February 1,94         [Page 5]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


8.  Other considerations

The ifType value miox25(34) does not attempt to convey how the
upper layer addresses are translated to X.121 addresses.  This
is consistent with RFC 1356.  It is possible to obtain this
information from the MIOX25-MIB.

Systems that use the new ifType values x25ple(33) and
miox25(34) and which assign an IP address for the miox25
service will have an ipAdEntIfIndex which identifies an
interface of type miox25(34).







































D. Throop         Invalid after February 1,94         [Page 6]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


9.  References

[1]  Rose M., and K. McCloghrie, "Structure and Identification
     of Management Information for TCP/IP-based internets",
     STD 16, RFC 1155, Performance Systems International,
     Hughes LAN Systems, May, 1990.

[2]  Case, J., M.S. Fedor, M.L. Schoffstall, and J. Davin,
     "Simple Network Management Protocol", STD 15, RFC 1157,
     SNMP Research, Performance Systems International,
     Performance Systems International, MIT Laboratory for
     Computer Science, May, 1990.

[3]  Rose, M. and K. McCloghrie, Editors, "Towards Concise MIB
     Definitions", STD 16, RFC 1212, Performance Systems
     International, Hughes LAN Systems, March, 1991.

[4]  Rose M., Editor, "Management Information Base for Network
     Management of TCP/IP-based internets", STD 17, RFC 1213.
     Performance Systems International, March, 1991.

[5]  "Information processing systems -- Open Systems
     Interconnection -- Specification of Abstract Syntax
     Notation One (ASN.1)", International Organization for
     Standardization.  International Standard 8824, December,
     1987.

[6]  Throop, D., "SNMP MIB extension for Multiprotocol
     Interconnect over X.25", RFC 1461, Data General
     Corporate, May, 1993.

[7]  Throop, D., and F. Baker, "SNMP MIB extension for X.25
     LAPB", RFC 1381, Data General Corporation, Advanced
     Computer Communications, November, 1992.

[8]  Throop, D., Editor, "SNMP MIB extension for the X.25
     Packet Layer", RFC 1382, Data General Corporation,
     November, 1991.

[9]  Malis, A., D. Robinson, R. Ullmann "Multiprotocol
     Interconnect on X.25 and ISDN in the Packet Mode", RFC
     1356, BBN Communications, Computervision Systems
     Integration, Process Software Corporation, August, 1992.







D. Throop         Invalid after February 1,94         [Page 7]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


10.  Authors' Addresses

     Dean D. Throop
     Data General Corporation
     62 Alexander Dr.
     Research Triangle Park, NC 27709

     Phone: [phone]
     EMail: [e-mail]









































D. Throop         Invalid after February 1,94         [Page 8]


Internet Draft     SNMP IfTypes for X.25 MIB          Aug 1993


Table of Contents


 Status of this Memo ....................................    1
1 Introduction ..........................................    1
1.1 Revision History ....................................    2
 August 9 1993 ..........................................    2
2 The Network Management Framework ......................    3
3 Object Definitions ....................................    3
4 Experience with Existing Definition ...................    4
5 New Definitions .......................................    5
6 Use of existing types .................................    5
7 Impact on other Standards .............................    5
8 Other considerations ..................................    6
9 References ............................................    7
10 Authors' Addresses ...................................    8


































D. Throop         Invalid after February 1,94         [Page 9]


Dean Throop		[e-mail]