The dsx1FracTable - "Logical If" or "End Point".
radnet <radnet@radmail.rad.co.il> Mon, 03 July 1995 14:42 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07584; 3 Jul 95 10:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07580; 3 Jul 95 10:42 EDT
Received: from hubbub.cisco.com by CNRI.Reston.VA.US id aa09494; 3 Jul 95 10:42 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 HAA02189 for <trunk-mib@cisco.com>; Mon, 3 Jul 1995 07:29:14 -0700
Received: from radmail.rad.co.il by fennel.acc.com (4.1/SMI-4.1) id AA29334; Mon, 3 Jul 95 07:28:28 PDT
Received: from radnet ([192.114.32.45]) by radmail.rad.co.il with SMTP id AA22554 (5.67b/IDA-1.5 for <trunk-mib@saffron.acc.com>); Mon, 3 Jul 1995 16:43:43 +0300
Date: Mon, 03 Jul 1995 16:43:43 +0300
Message-Id: <199507031343.AA22554@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