The dsx1FracTable - "Logical If" or "End Point".

radnet <radnet@radmail.rad.co.il> Mon, 03 July 1995 13:05 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06290; 3 Jul 95 9:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06286; 3 Jul 95 9:05 EDT
Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa06285; 3 Jul 95 9:05 EDT
Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA26292 for <trunk-mib@cisco.com>; Mon, 3 Jul 1995 05:57:49 -0700
Received: from radmail.rad.co.il by fennel.acc.com (4.1/SMI-4.1) id AA28625; Mon, 3 Jul 95 05:57:26 PDT
Received: from radnet ([192.114.32.45]) by radmail.rad.co.il with SMTP id AA22117 (5.67b/IDA-1.5 for <trunk-mib@saffron.acc.com>); Mon, 3 Jul 1995 15:59:57 +0300
Date: Mon, 03 Jul 1995 15:59:57 +0300
Message-Id: <199507031259.AA22117@radmail.rad.co.il>
X-Sender: radnet@radmail.rad.co.il
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: trunk-mib@acc.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: radnet <radnet@radmail.rad.co.il>
Subject: The dsx1FracTable - "Logical If" or "End Point".
X-Mailer: <PC Eudora Version 1.4b22>

Dear fellows,

The ATM Forum works on the definition of the "Circuit Emulation Service -
Interoperability Specification" ATMF94-0033R7. As a part of this 
specification the "CES MIB" was defined. It is based on RFC1573,
RFC1406 and RFC1407 and defines a different model for CONNECTION
management than that of the ATM MIB and FR MIB. 

Wouldn't it be preferable to change slightly or to expand the meaning of  
the dsx1FracTable from RFC 1406 by adoption of the "End Point concept". It 
could have enabled a definition of Trunk based Connection management in 
accordance with the already defined models. (Especially, when we are dealing 
with the InterWorking Function with ATM.)


The detailed explaination of the problem  is attached:
-------------------------------------------------------------------------

1.  RFC 1573 provides a solution for the presentation and management of  
"multiple sub-layers beneath the internetwork-layer" including possibility 
of multiplexing of the sub-layers. I would like to emphasize a number of points:
     - It does not intend to define a model for presentation and management 
of  Layer 2 DATA CONNECTIONS between the sub-layers. 
     - It "recommends" to have all virtual circuits reference a single 
conceptual row in the ifTable.
	- It does not define instruments for dynamic creation/deletion of the 
ifTable rows. (An entry of ifStackTable has  RowStatus object, but all 
Interfaces must be known in advance.) 

2. In accordance with the said above, RFC 1604 - "Frame Relay Service MIB" 
and RFC 1695 - "ATM Management objects" introduce additional concepts of 
"End Point" and "Connection between the End Points" enabling creation, 
presentation and management of  point-to-point and multicast Layer 2 data 
connections (virtual circuits).

3. RFC 1406 - "DS1/E1 MIB" chose a different approach for virtual circuit 
definition: it sees a group of DS1 channels, which are used for the same 
application (i.e. virtual circuit) as "a logical interface, i.e. , an entry 
in the interfaces table from the Internet-standard MIB". The dsx1FracTable 
defines dynamic mapping from each DS1 channel to an associate logical 
interface, known in advance.

4. Finally, ATMF94-0033R7 has based its solution on RFC1406 and expanded the 
meaning the logical interface above, defining it as a CES IWF. As was 
mentioned in (1) above:
- This attitude is conceptually different from the original intention of RFC 
1573.
- All possible CES Interfaces must be known in advance (during configuration 
time).

5. The main problem is that  the CES IWF management model must link the two 
different existing models (that of ATM and that of DS1). ATMF94-0033R7 uses 
the ifTable of RFC 1573 to define connection between a group of DS1 channels 
and an ATM interface. But ,actually, the connection exists between a group 
of DS1 channels and an ATM virtual channel (VP/VC or "End Point") inside the 
ATM interface, which isn't presented via the  ifTable of RFC 1573. 
Therefore, the exact connection definition is done by means of the 
atmDS1E1CESConfTable, including a SINGLE ATM End Point READ-ONLY definition 
as a part of CES Interface description. 


 I would like to consider the following issues:

1. Wouldn't it have been preferable to change slightly or to expand the 
meaning of  the dsx1FracTable from RFC 1406? It could have enabled a 
definition of CES IWF management model in accordance with the already 
defined models. Especially, when we are dealing with the InterWorking 
Function with ATM.

2. Creation and Deletion of "End Points" (i.e the "Logical Interfaces" from 
RFC1604) during the runtime is a crucial feature of any network equipment. 
It is highly desirable and prevailing to define this mechanism by means of 
MIB. How are these "Logical Interfaces" could be defined using the 
dsx1FracTable from the Trunk MIB?

------------------------------------------------------------------

Thanks,
Orit Levin
Senior Software Engineer
Radnet Ltd.
8 Hanechoshet St.
Tel-Aviv 69710,
Israel

Tel   : +972-3-6459585
Fax   : +972-3-6480582
E-mail: radnet@radmail.rad.co.il