Subject: RFC2514 v1.1

From: Kaj Tesink <[email-masked]>
Date: Mon, 11 Oct 1999 12:01:40 -0400

hi all, a quick status update on this.

a) the frame relay wg has requested an additional
    enumerated value in AtmConnKind in order to accommodate
    the FR/ATM interworking case. in addition, a proprietary
    interworking case should be recognized.

    because of document interdependencies RFC2514 needs to
    be revised quickly to make everything work.

    there has been discussion on how to accommodate this change
    and it seems workable.
    the change proposed by Ken Rehbehn is attached (i may use a REFERENCE 
clause
    instead of the [ref])

b) if we change 2514 anyway then we just as well accommodate any
    other nits that may be outstanding.
    one thing that Gary Hanson flagged is to add the GFR traffic type
    (proposed text invited).

please holler if you have any comments on these proposed changes
or if there are any other minor issues that should be accommodated
while we're on it.

kaj

>From: "Rehbehn, Kenneth" <[email-masked]>
>To: "'Kaj Tesink'" <[email-masked]>
>Subject: FR/ATM IWF Support Change for ATM MIB TC
>Date: Tue, 5 Oct 1999 14:55:57 -0400
>Importance: high
>X-Mailer: Internet Mail Service (5.5.2448.0)
>
>Kaj:
>
>Thank you for your help in this process.  Could you please start the process
>to update RFC 2514 with the additional codepoints needed to support FR/ATM
>PVC Service IWF?
>
>To help move things faster I have provided a redefined AtmConnKind in the
>attached file.
>
>Please advise when you think a new RFC will be published.  In addition to
>RFC 2514v2, the FR/ATM PVC Service IWF MIB needs to undergo IESG review
>before that MIB or the Frame Relay Service MIB can be published as RFCs.
>
>Cheers,
>Ken
>
>---------------------------------------------------------------
>Ken Rehbehn                              Phone: +1-301-296-2325
>Visual Networks                            Fax: +1-301-296-2302
>2092 Gaither Rd              EMail: [email-masked]
>Rockville, MD  20850              http://www.visualnetworks.com
>
>
>

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

                        Modification to RFC 2514

The following changes are required in RFC 2514, "Definitions of
Textual Conventions and OBJECT-IDENTITIES for ATM Management".

The support for cross-connection to ATM interworking functions
enables co-existance with the FR/ATM Service IWF.  A proprietary
enumerated value is included to cover implementation-specific
cross-connect tables.  An enumeration may be required in the future
to support a CES IWF.  However, no CES endpoint MIB exists today and
so this case has not been included.

1)  Modify the following TEXTUAL-CONVENTION:

     AtmConnKind ::= TEXTUAL-CONVENTION
             STATUS  current
             DESCRIPTION
                 "The type of call control used for an ATM
                 connection at a particular interface. The use
                 is as follows:
                    pvc(1)
                       Virtual link of a PVC. Should not be
                       used for an PVC/SVC (i.e., Soft PVC)
                       crossconnect.
                    svcIncoming(2)
                       Virtual link established after a
                       received signaling request to setup
                       an SVC.
                    svcOutgoing(3)
                       Virtual link established after a
                       transmitted or forwarded signaling
                       request to setup an SVC.
                    spvcInitiator(4)
                       Virtual link at the PVC side of an
                       SVC/PVC crossconnect, where the
                       switch is the initiator of the Soft PVC
                       setup.
                    spvcTarget(5)
                       Virtual link at the PVC side of an
                       SVC/PVC crossconnect, where the
                       switch is the target of the Soft PVC
                       setup.
                    atm2frServiceIWF(6)
                       Virtual link at the ATM side of a
                       FR/ATM Service IWF crossconnect,
                       where the IWF is the target of the
                       ATM PVC segment.  The
                       frAtmIwfConnectionTable crossconnect
                       table described in [4] connects the
                       frame relay to ATM segments.
                    atm2proprietaryIWF(7)
                       Virtual link at the ATM side of a
                       ATM to proprietary IWF, where the
                       IWF is the target of the ATM PVC
                       segment.  The crossconnect table is
                       implementation-specific and beyond
                       the scope of this MIB.

                 For PVCs, a pvc virtual link is always cross-
                 connected to a pvc virtual link.

                 For SVCs, an svcIncoming virtual link is always cross-
                 connected to an svcOutgoing virtual link.

For Soft PVCs, an spvcInitiator is either cross-connected to
an svcOutgoing or an spvcTarget, and an spvcTarget is either
cross-connected to an svcIncoming or an spvcInitiator."
         SYNTAX   INTEGER {
            pvc(1),
            svcIncoming(2),
            svcOutgoing(3),
            spvcInitiator(4),
            spvcTarget(5),
            atm2frServiceIWF(6),
            atm2proprietaryIWF(7)
            }

2) Add the following reference:

    [4]  Rehbehn, K., Nicklass, O., and G. Mouradian, "Definitions of
         Managed Objects for Monitoring and Controlling the Frame
         Relay/ATM PVC Service Interworking Function, RFC xxxFRATMMIBxxx,
         October 1999

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies (formerly Bellcore)
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Mon, 11 Oct 1999 10:54:55 -0700

Kaj,

whether a VC is used for FR/ATM interworking seems
to me to be orthogonal to whether it's a Soft PVC, PVC,
or SVC.

I would advocate a new MIB object (if needed) for
this information.

Mike

 >Date: Mon, 11 Oct 1999 12:01:40 -0400
 >To: [email-masked]
 >From: Kaj Tesink <[email-masked]>
 >Subject: RFC2514 v1.1
 >Cc: [email-masked]
 >
 >--=====================_240628355==_.ALT
 >Content-Type: text/html; charset="us-ascii"
 >
 ><html>
 >hi all, a quick status update on this.<br>
 ><br>
 >a) the frame relay wg has requested an additional<br>
 >&nbsp;&nbsp; enumerated value in AtmConnKind in order to 
 >accommodate<br>
 >&nbsp;&nbsp; the FR/ATM interworking case. in addition, a
 >proprietary<br>
 >&nbsp;&nbsp; interworking case should be recognized.<br>
 ><br>
 >&nbsp;&nbsp; because of document interdependencies RFC2514 needs to<br>
 >&nbsp;&nbsp; be revised quickly to make everything work.<br>
 ><br>
 >&nbsp;&nbsp; there has been discussion on how to accommodate this
 >change<br>
 >&nbsp;&nbsp; and it seems workable.<br>
 >&nbsp;&nbsp; the change proposed by Ken Rehbehn is attached (i may use a
 >REFERENCE clause<br>
 >&nbsp;&nbsp; instead of the [ref])<br>
 ><br>
 >b) if we change 2514 anyway then we just as well accommodate any <br>
 >&nbsp;&nbsp; other nits that may be outstanding.<br>
 >&nbsp;&nbsp; one thing that Gary Hanson flagged is to add the GFR traffic
 >type<br>
 >&nbsp;&nbsp; (proposed text invited).<br>
 ><br>
 >please holler if you have any comments on these proposed changes<br>
 >or if there are any other minor issues that should be accommodated<br>
 >while we're on it.<br>
 ><br>
 >kaj<br>
 ><br>
 ><br>
 >&nbsp;<br>
 ><br>
 ><br>
 ><br>
 ><blockquote type=cite cite>From: &quot;Rehbehn, Kenneth&quot;
 >&lt;[email-masked]&gt;<br>
 >To: &quot;'Kaj Tesink'&quot; &lt;[email-masked]&gt;<br>
 >Subject: FR/ATM IWF Support Change for ATM MIB TC<br>
 >Date: Tue, 5 Oct 1999 14:55:57 -0400 <br>
 >Importance: high<br>
 >X-Mailer: Internet Mail Service (5.5.2448.0)<br>
 ><br>
 >Kaj:<br>
 ><br>
 >Thank you for your help in this process.&nbsp; Could you please start the
 >process<br>
 >to update RFC 2514 with the additional codepoints needed to support
 >FR/ATM<br>
 >PVC Service IWF?<br>
 ><br>
 >To help move things faster I have provided a redefined AtmConnKind in
 >the<br>
 >attached file.<br>
 ><br>
 >Please advise when you think a new RFC will be published.&nbsp; In
 >addition to<br>
 >RFC 2514v2, the FR/ATM PVC Service IWF MIB needs to undergo IESG
 >review<br>
 >before that MIB or the Frame Relay Service MIB can be published as
 >RFCs.<br>
 ><br>
 >Cheers,<br>
 >Ken<br>
 ><br>
 >---------------------------------------------------------------<br>
 >Ken
 >Rehbehn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Phone: +1-301-296-2325<br>
 >Visual
 >Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Fax: +1-301-296-2302<br>
 >2092 Gaither
 >Rd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >EMail: [email-masked]<br>
 >Rockville, MD&nbsp;
 >20850&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 ><a href="http://www.visualnetworks.com/" eudora="autourl">http://www.visualnetworks.com</a><br>
 ><br>
 ><br>
 ><br>
 ></blockquote><br>
 >-------------------------------------------------------------------------------<br>
 ><br>
 ><br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Modification to RFC 2514<br>
 ><br>
 >The following changes are required in RFC 2514, &quot;Definitions 
 >of<br>
 >Textual Conventions and OBJECT-IDENTITIES for ATM Management&quot;.<br>
 ><br>
 >The support for cross-connection to ATM interworking functions<br>
 >enables co-existance with the FR/ATM Service IWF.&nbsp; A
 >proprietary<br>
 >enumerated value is included to cover implementation-specific<br>
 >cross-connect tables.&nbsp; An enumeration may be required in the
 >future<br>
 >to support a CES IWF.&nbsp; However, no CES endpoint MIB exists today and
 ><br>
 >so this case has not been included.<br>
 ><br>
 ><br>
 >1)&nbsp; Modify the following TEXTUAL-CONVENTION:<br>
 ><br>
 >&nbsp;&nbsp;&nbsp; AtmConnKind ::= TEXTUAL-CONVENTION<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >STATUS&nbsp; current<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >DESCRIPTION<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >&quot;The type of call control used for an ATM<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >connection at a particular interface. The use<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >is as follows:<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >pvc(1)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link of a PVC. Should not be<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >used for an PVC/SVC (i.e., Soft PVC)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >crossconnect.<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >svcIncoming(2)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link established after a<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >received signaling request to setup<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >an SVC.<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >svcOutgoing(3)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link established after a<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >transmitted or forwarded signaling<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >request to setup an SVC.<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >spvcInitiator(4)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link at the PVC side of an<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >SVC/PVC crossconnect, where the<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >switch is the initiator of the Soft PVC<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >setup.<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >spvcTarget(5)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link at the PVC side of an<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >SVC/PVC crossconnect, where the<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >switch is the target of the Soft PVC<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >setup.<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >atm2frServiceIWF(6)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link at the ATM side of a<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >FR/ATM Service IWF crossconnect, <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >where the IWF is the target of the<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >ATM PVC segment.&nbsp; The <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >frAtmIwfConnectionTable crossconnect <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >table described in [4] connects the <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >frame relay to ATM segments.<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >atm2proprietaryIWF(7)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >Virtual link at the ATM side of a<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >ATM to proprietary IWF, where the<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >IWF is the target of the ATM PVC<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >segment.&nbsp; The crossconnect table is<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >implementation-specific and beyond <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >the scope of this MIB.<br>
 ><br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >For PVCs, a pvc virtual link is always cross-<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >connected to a pvc virtual link.<br>
 ><br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >For SVCs, an svcIncoming virtual link is always cross-<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >connected to an svcOutgoing virtual link.<br>
 ><br>
 >For Soft PVCs, an spvcInitiator is either cross-connected to<br>
 >an svcOutgoing or an spvcTarget, and an spvcTarget is either<br>
 >cross-connected to an svcIncoming or an spvcInitiator.&quot;<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SYNTAX&nbsp;&nbsp; INTEGER
 >{<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
 >pvc(1),<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >svcIncoming(2),<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >svcOutgoing(3),<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >spvcInitiator(4),<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >spvcTarget(5),<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >atm2frServiceIWF(6),<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 >atm2proprietaryIWF(7)<br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
 ><br>
 ><br>
 >2) Add the following reference:<br>
 ><br>
 >&nbsp;&nbsp; [4]&nbsp; Rehbehn, K., Nicklass, O., and G. Mouradian,
 >&quot;Definitions of <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Managed Objects for Monitoring
 >and Controlling the Frame <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Relay/ATM PVC Service
 >Interworking Function, RFC xxxFRATMMIBxxx, <br>
 >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; October 1999<br>
 ><br>
 ><br>
 ><br>
 ><br>
 ><br>
 ><br>
 ><br>
 ><br>
 ><br>
 ><div>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/</div>
 ><br>
 ><div>Kaj Tesink</div>
 ><div>Telcordia Technologies (formerly Bellcore)</div>
 ><div>Email&nbsp; [email-masked]</div>
 ><div>Tel&nbsp;&nbsp;&nbsp; 732.758.5254</div>
 ><div>Fax&nbsp;&nbsp;&nbsp; 732.758.2269</div>
 ><div>Postal 331 Newman Springs Rd</div>
 ><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Red Bank, NJ 07701</div>
 ><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USA</div>
 ><br>
 ><div>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/</div>
 ><br>
 ></html>
 >
 >--=====================_240628355==_.ALT--
 >

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 19 Oct 1999 11:22:24 -0400

>I would advocate a new MIB object (if needed) for

hi mike,

can you clarify whether you agree or disagree with the proposed solution?
note that the proposed solution is one of 'minimal pain' where we only
need to extend one TC and avoid the need to revise 2515.
the porposed solution simply tries to respond to a need identified by
the FR work.

kaj

 > >------------------------------------------------------------------------ 
>------
>  >
>  >
>  >                        Modification to RFC 2514
>  >

Kaj Tesink

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Tue, 19 Oct 1999 10:14:37 -0700

Kaj,

 >Date: Tue, 19 Oct 1999 11:22:24 -0400
 >To: "Michael H. Grobelch" <[email-masked]>
 >Subject: Re: RFC2514 v1.1 
 >Cc: [email-masked], [email-masked]
 >

I believe adding atm2frServiceIWF and atm2proprietaryIWF to
AtmConnKind is broken. 

The purpose/use of a VC is orthogonal to the kind of VC it is.
It is quite possible to use Soft PVCs, SVCs, or PVCs for frame-relay.

We have a product that can use PVCs or Soft PVCs for network/service
interworking. I don't see why SVCs couldn't be used either. 

If there is a need to associate this information with a VCL quickly (without
thinking about identifying a lot of other usages of VCs), perhaps
add an object to do so -- in this example, a table, it could allow for
growth:

              atmVclFrameRelayIwfTable OBJECT-TYPE
                  SYNTAX       SEQUENCE OF AtmVclFrameRelayEntry
                  MAX-ACCESS   not-accessible
                  STATUS       current
                  DESCRIPTION
                      "Per-VCL objects for Frame Relay/ATM interworking ."
                  ::= {  ? 1 }
 
              atmVclFrameRelayIwfEntry OBJECT-TYPE
                  SYNTAX       AtmVclFrameRelayIwfEntry
                  MAX-ACCESS   not-accessible
                  STATUS       current
                  DESCRIPTION
                      "An entry with information about  ATM Vcl
                      Frame Relay Interworking."
                  AUGMENTS { atmVclEntry }
                  ::= { atmVclFrameRelayIwfTable 1 }
 
              AtmVclFrameRelayIwfEntry ::=
                  SEQUENCE {
                      atmVclFrameRelayIwfType        INTEGER,
                      }

              atmVclFrameRelayIwfType   OBJECT-TYPE
                  SYNTAX       INTEGER {
                           notFrameRelayIwf(1),

                           frameRelayIwfService(2)

                         atm2proprietaryIWF(3)
                              Virtual link at the ATM side of a
                              ATM to proprietary IWF, where the
                              IWF is the target of the ATM PVC
                              segment.  The crossconnect table is
                              implementation-specific and beyond
                              the scope of this MIB.
                     }
                  MAX-ACCESS   read-create
                  STATUS       current
                  DESCRIPTION
                      "Indicates whether Frame Relay Interworking uses this VCL."
                  DEFVAL { notFrameRelayIwf }
                  ::= { atmVclFrameRelayIwfEntry 1 }

I don't see why such a solution has to go into 2515. Perhaps it could
go into the Frame Relay/ATM IWF MIB, or the supplemental ATOMMIB?
Also, shouldn't there be an enumeration for network interworking?

Mike