INTERNATIONAL TELECOMMUNICATION UNION			
TELECOMMUNICATION
STANDARDIZATION SECTOR	APC-1316
April 1998
Original: English	

Q.11-14/16 Rapporteur Meeting
STUDY GROUP 16
Cannes France, 14-17 June 1998

SOURCE*:	Orit Levin
TITLE:	Application of the proposed MIBs to Versions 2 and 3 of H.323
PURPOSE: 	Proposal and Discussion

1.	
Introduction
Management Information Base provides a virtual Data Base definition. It is kept in a network entity and defines the parameters to be maintained in order to be conformant with the standard. Today’s common practice is to define MIB together with the protocol definition itself.
 
We believe that standard MIBs should accomplish the Standard in the following sense:
 Should structurally reflect the specifications as close as possible defining the high level “logical” Data Base.
 Should define parameters and concepts as whole as possible and in the same time as close as possible to the existing specification.

H.323 MIB is expected to be standardized together with H.323 version 3. Therefore we believe that the standard H.323 MIBs should support H.323v1, shall efficiently support H.323v2 and shall be upgradable towards H.323v3.

The most crucial part of MIB definition is its decomposition into tables with properly chosen keys. Therefore these issues are addressed first by this contribution. Existing MIB proposals sometimes suffer from 
 Inefficient performance and memory consumption in H.323v2 implementations.
 Inability to upgrade the proposed MIBs to support H.323v3 (such as multiplexing of calls over the same TCP connection). 
For each problem the pitfalls are explained and alternatives are proposed. It should be mentioned that there is always an alternative to define a simple INTEGER index for a MIB table. Sometimes it may be the solution for controversial tables, i.e. the common denominator across different versions, topologies and implementations.

2.	Proposal for tables keys (indexes) modification
2.1	connectionsEntityTable from H225-MIB by VideoServer [1]
The latest proposed key for this table is:
{ h225CallSrcTransportAddressTag  H323TAddressTag,  
h225CallSrcTransportAddress       Taddress,
h225CallId                        H323GlobalIdentifier }

We propose to change the name of the table to h225CallTable since “Entity” concept has different meaning in IETF MIBs.

We propose to add a clarification that in order to support H.323v1 instances, h225CallId field should be filled with default value ZERO of an appropriate type and length. 

2.2	RegistrationTable from RAS-MIB by VideoServer [2]
Currently the proposed key for this table is:
{registrationSrcRasAddressTagH323 TaddressTag,
registrationSrcRasAddress        Taddress}

Standard doesn’t define End Point’s RAS address to be unique. Therefore it is undesirable to base the index of the RegistrationTable on Layer III value, which in some topologies may become ambiguous.

One of the common management features is to manually pre-define some entities (in our case - End Points) with their desired attributes and allowances. In order to achieve this feature the key should be meaningful and of application (i.e. H.323) nature. It becomes especially critical in DHCP environments. Therefore our preferred proposal for the index of registrationTable is:
 
{RegistrationEndpointId  H323ShortEndpointID)
Where H323ShortEndpointID is of SYNTAX
OCTET STRING (size(1..64))

We propose to add to the standard (and the Implementors Guide) a restriction that the 64 low bytes of EndpointId shall be unique. This restriction occurs from the SNMP limitation regarding length of the table keys. 
2.3	RegistrationAliasTable from RAS-MIB by VideoServer [2]
Currently the proposed key for this table is:
{registrationSrcRasAddressTagH323 TaddressTag,
 registrationSrcRasAddress        Taddress,
 registrationAliasTableIndex      Integer32}

Obviously the key of RegistrationAliasTable should be correspondent to the RegistrationTable above. We would like to point out that a field of type H323AliasTag [4] is missing from this table. In our opinion such a field should be among the indexes of this table before the registrationAliasTableIndex:
{registrationEndpointId             H323ShortEndpointID,
 registrationAliasTag               H323AliasTag,
 registrationAliasIndex             Integer32}

2.4	admissionTable from RAS-MIB by VideoServer [2]
Currently the proposed key for this table is:
{ admissionConferenceId             ItuGlobalIdentifier,
admissionRasAddressTag              H323TAddressTag,  
admissionRasAddress                 TAddress,
admissionCRV                        Integer32,
admissionIsGatekeeper               INTEGER}

Our proposal is:
{admissionCallSignalingAddressTagH323  TaddressTag,
admissionSrcCallSignallingAddress      Taddress,
admissionDstCallSignallingAddress      Taddress,
admissionCallId                        H323GlobalIdentifier,
admissionAnswerCall                    Boolean }

In order to support H.323v1 instances, admissionCallId field should be filled with default value ZERO of an appropriate type and length.

Call Signaling Addresses, representing TCP connections, tend to be “more unique” then RAS addresses, representing UDP connections. This provides the required differentiation among distinct calls between the same peers.

We propose to explicitly describe the meaning of the table. Each entry of the table describes a connection from a point of view of the source or the destination of the Call as managed by the Gatekeeper. Therefore the same H.323 Call can be reflected in this table in more then one entry.

2.5	H245-MIB by VideoServer [3]
 This proposal defines general purpose H.245 MIB without clear correlation with the context of the H.323 Call. Once the multiplexing of calls over the same TCP connection will be enabled, the proposed key for the “root” ControlChannelMasterSlaveTable becomes inadequate.

 This proposal defines “a decomposition” of H.245 instance into a number of flat tables, which are not necessarily insinuated by the H.245 specification. We believe that from structural point of view the MIB should define a “high level” “virtual” Data Base reflecting the Specification only (together with the complete parameters definition according to the Standard).

Currently proposed tables are as follows:
2.5.1	ControlChannelMasterSlaveTable with the following indexes:
 {
              controlChannelSrcAddressTag
                    TDomain,
	        controlChannelSrcTransportAddress
	              TAddress,
              controlChannelDestAddressTag
                    TDomain,
              controlChannelDestTransportAddress
	              Taddress}
One of the fields is
              controlChannelIndex
                    Integer32
As it was stated above, once the multiplexing of calls over the same TCP connection will be enabled, the proposed key becomes inadequate. Today, when H.245 tunneling is used, the meaning of the Transport Address fields can become confusing.
Therefore one of the solutions could be a definition of a “root” H.245/H.323 Call oriented table with the indexes correlated to h225CallTable:
{          h225SrcCallSignallingTransportAddressTag  H323TAddressTag,  
           h225SrcCallSrcTransportAddress              Taddress,
           h225CallId                               ItuGlobalIdentifier }

An alternative approach could be to define a single key h245CallTable with the following index:
         H245CallIndex  Integer32 
This index has the same meaning as controlChannelIndex, but annuls one hierarchy level.
(Such a field should be added to H225CallTable as a pointer to H.245 call related parameters.)
This new h245CallTable should contain per-call H.245 parameters such as:
-	Transport addresses
-	Master-Slave status
-	Capability Exchange parameters
2.5.2	CapExchangeCapabilityTable with the following indexes:
 {           controlChannelIndex
                    Integer32
            capExchangeDirection
                     INTEGER}
   We propose to move the parameters to h245CallTable.   
2.5.3	LogChannelsChannelTable with the following indexes:
{             controlChannelIndex
                    Integer32
              logChannelsChannelNumber
                    Integer32,
	      logChannelsChannelDirection
                    INTEGER}

Instead we propose the following indexes:
{             H245CallIndex
                    Integer32
              logChannelsChannelNumber
                    Integer32
	      logChannelsChannelDirection
                    INTEGER}

One of the proposed fields for this table is:
	      logChannelsIndex
                    Integer32

We propose to annul this field in order to reduce the hierarchy level.
2.5.4	LogChannelsCapabilityG711Table, LogChannelsCapabilityH261Table and LogChannelsCapabilityT120Table with the logChannelsIndex  as the index and “INTEGER” fields for each entry.
All these tables (and possible other “Capability” tables) can be combined into the same new LogChannelsCapabilityTable with the following indexes:
{             H245CallIndex
                    Integer32,
              logChannelsChannelNumber
                    Integer32,
              logChannelsCapabilityType
                                       OBJECT IDENTIFIER}
The common practice to do that is to define an Identifier field (such as logChannelsCapabilityType) and an arbitrary number of Integer fields. The interpretation of the Integer fields is done according to Identifier field value.
2.5.5	LogChannelsH225Table with the logChannelIndex as the index.
We propose to combine this table with the LogChannelsChannelTable above or to define the LogChannelsH225Table as an extension to LogChannelsChannelTable.
2.5.6	MiscRoundTripDelayTable with controlChannelIndex as the index.
If the information defined in this table is of general interest, we propose to define this table as an extension of h245CallTable.
2.5.7	MiscMaintenanceLoopTable with the following indexes:
{           controlChannelIndex
                    Integer32,
            miscMaintenanceLoopDirection
                     INTEGER
            }
If the information defined in this table is of general interest, we propose to define this table as an extension of h245CallTable.

2.5.8	ConferenceTerminalTable with the following indexes:
 {     conferenceConferenceId
                     OCTET STRING (SIZE(1..32)),
	      conferenceTerminalLabel
                    OCTET STRING} 
TerminalLabel is defined in H.245 as
TerminalLabel	::=SEQUENCE
{
		mcuNumber	McuNumber,
		terminalNumber	TerminalNumber,
		...
}
McuNumber	::=INTEGER(0..192)
TerminalNumber	::=INTEGER(0..192)

Therefore our proposal for the indexes of the ConferenceTerminalTable is:
{     conferenceConferenceId
                     OCTET STRING (SIZE(1..32)),
	      conferenceMcuNumber
                    Integer, 
	      conferenceTerminalNumber
                    Integer} 

3.	References
[1] Avc-site\APC-1389 – “H.323 Call Signalling MIB”
[2] Avc-site\Incoming\RasV2Mib.rtf – “H.323 RAS MIB”
[3] Avc-site\APC-1400 – “H.245 MIB”
[4] APC-1349 – An old “H.323 Gatekeeper MIB”