Subject: DS3 MIB SendCode: Can't specify which DS1 to loop?

From: Jason Perreault <[email-masked]>
Date: Thu, 15 Jan 1998 18:41:51 -0500

The ds3 MIB SendCode supports an option to loop DS1 
channels, but don't see any object in the MIB to specify which
DS1 to loop. Can someone clarify for me how this should
work?

Also Dave Fowler has confirmed to me that association of 
DS1-interface-to-DS3-channel is no longer represented in the 
MIB, now that the Fractional Tables are deprecated. Is this 
a problem? 

Thanks,
Jason

> -----Original Message-----
> From:	Jason Perreault [SMTP:[email-masked]]
> Sent:	Friday, January 09, 1998 9:43 AM
> To:	[email-masked]
> Subject:	ds1 mapping to ds3 channel?
> 
> 
> I don't see how the current MIB drafts represent 
> to which ds3 channel a higher-layer ds1 interface 
> is ifStack-ed. (Contrast to ds0 MIB, wherein each
> ds0 interface is explicitly mapped to a DS1 channel 
> number via dsx0Ds0Number.)
> 
> I'm only recently subscribed to the list, if there is a
> discussion archive for this in relation to deprecation
> of the Fractional tables, please point me to it.
> 
> Thanks,
> 
> Jason
> 
> 
> 
>

---

From: Dave Fowler <[email-masked]>
Date: Fri, 23 Jan 1998 15:53:47 -0500

Jason Perreault wrote:
> 
> Dave,
> 
> My comments marked [JJP].
> 
> > From: Dave Fowler [SMTP:[email-masked]]
> > Sent: Friday, January 23, 1998 2:01 PM
> > To:   Jason Perreault
> > Cc:   James Watt
> > Subject:      Re: DS3 MIB SendCode: Can't specify which DS1 to loop?
> >
> > My thoughts on this are as follows:
> >
> > We could create a ds1Number in the ds1 MIB like this:
> >
> >           dsx1Ds1Number OBJECT-TYPE
> >               SYNTAX  INTEGER(0..28)
> >               MAX-ACCESS  read-write
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object indicates the channel number of the
> >                       ds1/e1 on its ds3/e3.  A value of 0 indicates
> > that
> >                       this ds1/e11 is not on a ds3/e3."
> >               ::= { dsx1ConfigEntry xx }
> >
> > I like this option as it is consistent with ds0.
> >
> > [JJP]  I think this is more appropriate if ds1 ifStacking  on ds3
> > is a dynamic thing, in which case the ds1 is configured with
> > a channel number prior to stacking to force a specific mapping
> > (ifStacking is rejected if that channel is already in use), else it
> > is set to zero prior to stacking as a hint that any channel is
> > acceptable, and if stacking succeeds, takes on the value of
> > the actual channel to which it was assigned. BUT -- after considering
> > James' comments, I am uncertain whether channelized DS3
> > ought to permit such a fine degree of configuration....?

I'm thinking that either a DS3 is channelized or not.  If it is, then is
has 28 DS1s.
You take the information in the ifStackTable to tell which DS3
is your parent and combine it with an entry in the above table to tell
which one of 28
you are.  I think this object should be read-only.

I've heard an argument that suggest putting this info in ds1 mib is
better in case the
parent in not a DS3....  (Circuit Emulation??)

> >
> > We could create a table with the following object:
> >
> >           dsx3Ds1ConfigTable OBJECT-TYPE
> >               SYNTAX  SEQUENCE OF Dsx3Ds1Entry
> >               MAX-ACCESS  not-accessible
> >               STATUS  current
> >               DESCRIPTION
> >                       "This table provides information about the ds1s
> >                       within a ds3.
> >           dsx3Ds1ConfigEntry OBJECT-TYPE
> >                SYNTAX  Dsx3Ds1Entry
> >                MAX-ACCESS  not-accessible
> >                STATUS  current
> >                DESCRIPTION
> >                               "An entry in the DS3 DS1 config table."
> >               INDEX   { ifIndex, dsx3Ds1ChannelNumber }
> >               ::= { dsx3Ds1ConfigTable 1 }
> >
> >           Dsx3Ds1ConfigEntry ::=
> >                SEQUENCE {
> >                    dsx3Ds1ChannelNumber    INTEGER,
> >                    dsx3Ds1IfIndex          INTEGER,
> >               }
> >           dsx3Ds1ChannelNumber OBJECT-TYPE
> >               SYNTAX  INTEGER(1..28)
> >               MAX-ACCESS  not-accessible
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object indicates the value of the channel
> > number for
> >                       this ds1 on the ds3."
> >               ::= { dsx3ds1ConfigEntry 1 }
> >
> >           dsx3Ds1IfIndex OBJECT-TYPE
> >               SYNTAX  InterfaceIndex
> >               MAX-ACCESS  read-write
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object indicates the value of ifIndex for
> >                       this ds1 on the ds3."
> >               ::= { dsx3ds1ConfigEntry 1 }
> >
> > This option is also fine with me.  I am unsure which is better, but
> > certainly the second one
> > is looking suspiciously similar to the Fractional Table.  However, I
> > am
> > not reusing the
> > fractional table as it has implications about stacking that should be
> > avoided.
> >
> > [JJP]  I think this approach is more appropriate if ds1/ds3 stacking
> > is "static" and the channel associations remain fixed, they just need
> > to be exposed to the user. This is probably sufficient for the vast
> > majority
> > of channelized ds3 implementations. Should dsx3Ds1IfIndex be
> > read-only?
> > This table isn't meant to configure ds1/ds3 stacking, is it?
> > Compliances
> > should permit MIN-ACCESS of read-only.

Actually, this approach maps the information the other way.  (i.e.
instead of matching
ifIndex with channel number you match channel number with ifIndex.  the
effect is
the same.  Both solutions should be read only.)

> >
> >
> > Regarding chanellized/unchannelized,  the following objects could be
> > added:
> >
> >           dsx1Channelization  OBJECT-TYPE
> >                SYNTAX      INTEGER {
> >                               enabled(1),
> >                               disabled(2)
> >                            }
> >                MAX-ACCESS  read-write
> >                STATUS      current
> >                DESCRIPTION
> >                       "Indicates whether this ds1/e1 is channelized or
> > unchannelized.
> >                        The value of enabled indicates channelized.  "
> >                DEFVAL { enabled }
> >                ::= { dsx1ConfigEntry 19 }
> >
> > I think this would not apply to ds2/e2 and would be indicated in the
> > compliances.
> >
> >           dsx3Channelization  OBJECT-TYPE
> >                SYNTAX      INTEGER {
> >                               enabled(1),
> >                               disabled(2)
> >                            }
> >                MAX-ACCESS  read-write
> >                STATUS      current
> >                DESCRIPTION
> >                       "Indicates whether this ds3/e3 is channelized or
> > unchannelized.
> >                        The value of enabled indicates channelized"
> >                DEFVAL { enabled }
> >                ::= { dsx3ConfigEntry 17 }
> >
> > [JJP]  What is the effect on existing ds1 channels/interfaces if this
> > object is changed from enabled(1) to disabled(2)? Do all the ds1
> > interfaces
> > disappear as a side-effect, or perhaps remain instantiated, but become
> >
> > detached from the ds3 in ifStackTable? Same consideration for ds0s on
> > a channelized ds1.Compliances should permit MIN-ACCESS read-only.

Setting this via SNMP may not be a good idea.  Any votes?
 Regardless of how it is set,
there should be no DS1s for unchannelized DS3 or DS0s for unchannelized
DS1.

> >
> > Regarding Send Code,  I think there is an ommision.  How could the
> > agent
> > know which DS1
> > to use without an object.  How to approach this.  Can you do more than
> > one DS1 at once?
> >
> >
> > I'll assume there is an recommend the following object:
> >
> >           dsx3ds1LoopBitMap  OBJECT-TYPE
> >                SYNTAX      INTEGER(0..536870911)
> >                MAX-ACCESS  read-write
> >                STATUS      current
> >                DESCRIPTION
> >                       "A bit map of the channels on this DS3/E3.  This
> > object is
> >                       used to indicate which DS1s are to have
> > loopbacks
> >                       activated.  This object is used in conjunction
> > with the
> >                       object dsx3SendCode."
> >                DEFVAL { enabled }
> >                ::= { dsx3ConfigEntry 18 }
> >
> > [JJP] The max value is for bits 0-28 set. I assume DS1 has channels
> > 1-28.
> > Is 0 a valid channel number for E3, or should the max integer value be
> > 536870910? If there is no valid channel 0, would it be better to
> > describe
> > channels as having positive numbering, and are mapped to bits via
> > 2^^(channel - 1)? Thus channels 1-28 are associated with bits 0-27
> > respectively, with no unused lower bit in the bitmap.

Yes, it should be bit 0 through bit 27, but this is assuming more than
one
can be set at once.  Does anyone know about the send codes?

> >
> >
> > Anyway, I really want to stop the churn on these documents, so I would
> > appreciate feedback on this stuff right away.  I will be submitting
> > the
> > next version of the internet drafts this weekend.

Regards,
David