Subject: Support for "split" unidirectional flows in ATM-MIBs

From: Gary Hanson <[email-masked]>
Date: Wed, 13 Jan 1999 10:30:51 -0800 (PST)

Hi atommibers,

David Horton's recent question about unidirectional connections
reminded me about an issue that may be worth resolving in the
ATM-MIB, ATM-TC-MIB, and ATM2-MIB, which is support for what I
would call "split" unidirectional flows.

One example of this is what I would call a "chained" connection.
When a manager wants to configure a unidirectional connection from
VCL1 on ATM interface 1 to VCL2 on ATM interface 2, and another
from that same VCL2 on ATM interface 2 to VCL3 on ATM interface 3,
how would the ATM-MIB be used to represent this type of "chained"
VCC (i.e., one which goes from one ATM port to another, gets looped
back in that second port, and then goes to a third port)?

         ____________________
        |                    |
        |     ATM Switch     |
        |                    |
   VCL1 |  I/F 1      I/F 2  |  VCL2  
O--->---|--->------------>---|--->---O
        |           +----<---|---<---O
        |           |        |
        |           v        |
        |           | I/F 3  |  VCL3
        |           +---->---|--->---O
        |                    |
        |____________________|

To justify the need for this type of chained connection, consider
its usefulness during EMI testing, when a cell stream can flow out
each ATM port in turn, travelling down and back one meter of cable
attached to each port, all without external equipment attached.

I have also heard of other cases where users have wanted to solve
various topological problems in their networks by configuring one
VCL (or VPL) that crossconnects to two different VCLs (or VPLs) in
the ingress and egress directions.

While these topologies may thus be useful, the ATM-MIB does not seem
to support them, since there exists neither a way to indicate that a
bidirectional VCL is to be used by two different cross-connects (one
for ingress and one for egress), nor any way to indicate that an
inherently bidirectional cross-connect uses only the ingress or the
egress bandwidth (but not both) of a VCL.

If others believe it important to support this kind of usage, one
reasonable solution that comes to mind is to extend the ATM-MIB,
ATM-TC-MIB, and ATM2-MIB as follows:

  (a) Add an object to the VPL and VCL table entries to indicate the
      identifier of an additional cross-connection that is supported
      by the VPL or VCL, so that a VPL or VCL can reference one OR
      two cross-connections.

      I would add the following objects to the ATM-MIB:

               atmVplCrossConnectIdentifier2   OBJECT-TYPE
                    SYNTAX         INTEGER (0..2147483647)
                    MAX-ACCESS     read-only
                    STATUS         current
                    DESCRIPTION
                     "This object is instantiated only for a VPL
                      which is cross-connected to other VPLs
                      that belong to the same VPC.

                      If the VPL belongs to a single VPC, this
                      object has the same value (and semantics) as
                      the atmVplCrossConnectIdentifier value in the
                      same atmVplEntry.

                      If the VPL belongs to two different VPCs
                      (i.e., one flowing in the receive direction
                      and one flowing in the transmit direction),
                      then the atmVplCrossConnectIdentifier value
                      refers to the VPC flowing in the receive
                      direction of this VPL, and this object (i.e.,
                      the atmVplCrossConnectIdentifier2 value)
                      refers to the VPC flowing in the transmit
                      direction of this VPL."
                    ::= { atmVplEntry 11 }

               atmVclCrossConnectIdentifier2   OBJECT-TYPE
                    SYNTAX         INTEGER (0..2147483647)
                    MAX-ACCESS     read-only
                    STATUS         current
                    DESCRIPTION
                     "This object is instantiated only for a VCL
                      which is cross-connected to other VCLs
                      that belong to the same VCC.

                      If the VCL belongs to a single VCC, this
                      object has the same value (and semantics) as
                      the atmVclCrossConnectIdentifier value in the
                      same atmVclEntry.

                      If the VCL belongs to two different VCCs
                      (i.e., one flowing in the receive direction
                      and one flowing in the transmit direction),
                      then the atmVclCrossConnectIdentifier value
                      refers to the VCC flowing in the receive
                      direction of this VCL, and this object (i.e.,
                      the atmVclCrossConnectIdentifier2 value)
                      refers to the VCC flowing in the transmit
                      direction of this VCL."
                    ::= { atmVclEntry 16 }

  (b) Add an object to the VP and VC cross-connection table entries
      to indicate whether the cross-connection is bidirectional, is
      unidirectional in the H2L direction or is unidirectional in
      the L2H direction.  Such an object's default would presumably
      be bidirectional, to preserve interoperability with agents
      that don't support the other options.

      I would add the following TEXTUAL-CONVENTION to the
      ATM-TC-MIB:

              AtmConnFlowDirection ::= TEXTUAL-CONVENTION
                      STATUS  current
                      DESCRIPTION
                        "The direction of flow for a given ATM
                        crossconnect.  
                           bothDirections(1)
                              The crossconnect allows bidirectional
                              flow in the L2H (low-to-high) and the
                              H2L (high-to-low) directions, unless
                              unidirectional flow is specified for
                              a virtual link entry on either the low
                              or high side(s) of the crossconnect.
                           onlyL2HDirection(2)
                              The crossconnect allows unidirectional
                              flow in the L2H direction only.
                           onlyH2LDirection(3)
                              The crossconnect allows unidirectional
                              flow in the H2L direction only.
                      SYNTAX   INTEGER {
                         bothDirections(1),
                         onlyL2HDirection(2),
                         onlyH2LDirection(3)
                      }

      I would also add the following objects to the ATM-MIB:

               atmVpCrossConnectFlowDirection OBJECT-TYPE
                    SYNTAX         AtmConnFlowDirection
                    MAX-ACCESS     read-create
                    STATUS         current
                    DESCRIPTION
                     "The direction(s) of flow specifically allowed
                      on this crossconnect.  Note that bidirectional
                      flow specified for the crossconnect is always
                      superceded by unidirectional flow specified
                      for either (or both) VPLs."
                    DEFVAL { bothDirections }
                    ::= { atmVpCrossConnectEntry 12 }

               atmVcCrossConnectFlowDirection OBJECT-TYPE
                    SYNTAX         AtmConnFlowDirection
                    MAX-ACCESS     read-create
                    STATUS         current
                    DESCRIPTION
                     "The direction(s) of flow specifically allowed
                      on this crossconnect.  Note that bidirectional
                      flow specified for the crossconnect is always
                      superceded by unidirectional flow specified
                      for either (or both) VCLs."
                    DEFVAL { bothDirections }
                    ::= { atmVcCrossConnectEntry 14 }

      Finally, I would add the following objects to the ATM2-MIB:

               atmSvcVpCrossConnectFlowDirection OBJECT-TYPE
                   SYNTAX       AtmConnFlowDirection
                   MAX-ACCESS   read-create
                   STATUS       current
                   DESCRIPTION
                    "The direction(s) of flow specifically allowed
                     on this crossconnect.  Note that bidirectional
                     flow specified for the crossconnect is always
                     superceded by unidirectional flow specified
                     for either (or both) VPLs."
                   DEFVAL { bothDirections }
                   ::= { atmSvcVpCrossConnectEntry 8 }

               atmSvcVcCrossConnectFlowDirection OBJECT-TYPE
                   SYNTAX       AtmConnFlowDirection
                   MAX-ACCESS   read-create
                   STATUS       current
                   DESCRIPTION
                    "The direction(s) of flow specifically allowed
                     on this crossconnect.  Note that bidirectional
                     flow specified for the crossconnect is always
                     superceded by unidirectional flow specified
                     for either (or both) VCLs."
                   DEFVAL { bothDirections }
                   ::= { atmSvcVcCrossConnectEntry 10 }

I know that the ATM-TC-MIB draft is in IESG review, but the ATM-MIB
draft is back in Kaj's hands, and the ATM2-MIB is still wide open
for comments.  I'd also settle for any compromise short of getting
a new TEXTUAL-CONVENTION put into the ATM-TC-MIB, in order to allow
standard support of this capability.

Comments?  (Has anybody supported this capability differently?)

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333