Subject: [IPTEL] TRIP MIB Question

From: "Bob Penfield" <[email-masked]>
Date: Mon, 23 Apr 2001 13:26:28 -0400

The tripPeerEntry object (page 11-12 of draft-zinman-trib-mib-01.txt) only
allows a single tripPeerSupportedProtocol and tripPeerAddressFamily, yet the
TRIP spec provides for multiple Route Types Supported in the OPEN message.
Also, the address family and protocol are joined together in the Route Types
Supported capability info of the OPEN message. Shouldn't there be a list of
TripAppProtocol+TripAddressFamily pairs in the tripPeerEntry object?

Thanks,

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "David Zinman" <[email-masked]>
Date: Wed, 25 Apr 2001 15:15:44 -0400

Bob,

I am going to try to tackle two problems here.

The first is the issue of adding new protocols and address families.
====================================================================

I propose to remove the TC for TripAppProtocol and assign object
identifiers (OIDs) to the protocols. We would have an entry in the
TRIP MIB for TRIP Supported Protocols:

   tripSupportedProtocols  OBJECT IDENTIFIER ::= { trip 100 }

Then each protocol would be defined under this MIB tree branch:

  tripSupProtSIP          OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 }
  tripSupProtH323Q931     OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 }
  tripSupProtH323RAS      OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 }
  tripSupProtH323ANNEXG   OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 }

If a new protocol is used it can be defined by the private enterprise
MIB implementers. Eg:

  myPrivateEntProtocol OBJECT IDENTIFIER ::= { privEntProts 1 }

As protocols are developed it would be easy to add them using this method.

Similarly for address families we would remove the TC for address families
and define another OID:

  tripAddressFamilies    OBJECT IDENTIFIER ::= { trip 101 }

Then each address family would be defined under this MIB tree branch:

  tripAddrFamilyDecimal   OBJECT IDENTIFIER ::= { tripAddressFamilies 1 }
  tripAddrFamilyHex       OBJECT IDENTIFIER ::= { tripAddressFamilies 2 }

New address families could be added into the private enterprise
MIB. Eg:

  myPrivateEntAddrFamily OBJECT IDENTIFIER ::= { privEntAddrFamilies 1 }

Again it would be easy to add more address families.

TripAppProtocol+TripAddressFamily Pairs
=======================================
I propose this solution to the problem of multiple
TripAppProtocol+TripAddressFamily pairs outlined by Bob Penfield:

- Remove tripPeerSupportedProtocol and tripPeerAddressFamily
  from the Peer Table.

- Add a new 'sub' table to the Peer Table called
  tripPeerRouteTypeTable which will have the following
  structure:

tripPeerRouteTypeTable OBJECT-TYPE
  SYNTAX      SEQUENCE OF TripPeerRouteTypeEntry
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The TRIP peer Route Type table. This table contains one
      entry per supported protocol - address family pair."
  ::= { trip x }

tripPeerRouteTypeEntry OBJECT-TYPE
  SYNTAX      TripPeerRouteTypeEntry
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "Entry containing information about the route type that
      the TRIP peer supports."
  INDEX { applIndex,
          tripPeerRemoteAddrInetType,
          tripPeerRemoteAddr,
          tripPeerRtTypeProtocolId,
          tripPeerRtTypeAddrFamilyId }
    ::= { tripPeerRouteTypeTable 1 }

TripPeerRouteTypeEntry ::= SEQUENCE {
    tripPeerRtTypeProtocolId         OBJECT IDENTIFIER,
    tripPeerRtTypeAddrFamilyId       OBJECT IDENTIFIER,
    tripPeerRtTypeSupportedProtocol  OBJECT IDENTIFIER,
    tripPeerRtTypeAddrFamily         OBJECT IDENTIFIER
}

tripPeerRtTypeProtocolId OBJECT-TYPE
  SYNTAX      OBJECT IDENTIFIER
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The identifier of a protocol that this peer is using."
  ::= { tripPeerRouteTypeEntry 1 }

tripPeerRtTypeAddrFamilyId OBJECT-TYPE
  SYNTAX      OBJECT IDENTIFIER
  MAX-ACCESS  not-accessible
  STATUS      current
  DESCRIPTION
      "The identifier of an address family that this peer belongs to."
  ::= { tripPeerRouteTypeEntry 2 }

tripPeerRtTypeSupportedProtocol OBJECT-TYPE
  SYNTAX      OBJECT IDENTIFIER
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "A protocol that this peer is using."
  ::= { tripPeerRouteTypeEntry 3 }

tripPeerRtTypeAddrFamily OBJECT-TYPE
  SYNTAX      OBJECT IDENTIFIER
  MAX-ACCESS  read-only
  STATUS      current
  DESCRIPTION
      "An address family that this peer belongs to."
  ::= { tripPeerRouteTypeEntry 4 }

Or instead, alternatively the table could be indexed by arbitrary
integers and each Protocol/AddressFamily pair would be displayed
as raw integers, NOT as OIDs as described above. Eg:

+--------------+--------------+-------+----------+----------------+
| PeerInetType | PeerInetAddr | index | Protocol | Address Family |
+--------------+--------------+-------+----------+----------------+
|      1       | 192.1.34.55  |   1   |     1    |       1        |
+--------------+--------------+-------+----------+----------------+
|      1       | 192.1.34.55  |   2   |     1    |       2        |
+--------------+--------------+-------+----------+----------------+
|      2       |4e:14:00:72...|   3   |     3    |       2        |
+--------------+--------------+-------+----------+----------------+
|     16       | myDnsName@so |   4   |     2    |       1        |
+--------------+--------------+-------+----------+----------------+
    ...

This way is easier but much less descriptive because the integers
would have to be looked up in all cases to map the protocol and
address families to expressive names.

Cheers,
DZ

---
David Zinman	      Software Designer
SS8 Networks Inc.
Phone: (613)592-2100    Fax: (613)592-9634
mailto:[email-masked]	http://www.ss8.com

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Monday, April 23, 2001 1:26 PM
To: IPTEL List; [email-masked]; [email-masked]
Subject: TRIP MIB Question

Thanks,

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 26 Apr 2001 11:11:08 -0400

David,

I think that is an excellent solution. I'm a bit confused though. Why are
there 4 fields in the
tripPeerRouteTypeEntry sub-table? What is the difference between
"tripPeerRtTypeProtocolId" and
"tripPeerRtTypeSupportedProtocol" ? What is the difference between
"tripPeerRtTypeAddrFamilyId" and "tripPeerRtTypeAddrFamily" ? Please forgive
my MIB ignorance.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "David Zinman" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "IPTEL List"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 25, 2001 3:15 PM
Subject: [IPTEL] RE: TRIP MIB Question