Subject: DS1 Channelization

From: Dave Fowler <[email-masked]>
Date: Tue, 03 Feb 1998 16:35:30 -0500

Gary,

One of the questions you raised is how to tell if a DS1 is channelized. 
The latest DS1 and DS3 drafts contains such a object
(dsx1/dsx3Channelization).  It sounds like you would find it useful for
this to be read-write with MIN-ACCESS or read-only.  I'm in favour of
that for the applications you mention.

You are the only person so far that has mentioned a desire to channelize
DS3s  directly into DS0s.  I am unsure that is is possible given my
understanding of the ANSI T1 standards.  Do you know a reference I could 
examine?

At the moment, I am favouring leaving the channelization object in the
DS1 and DS3 MIBs.  Is that acceptable for you?  Any other comments from
the list?

Regards,
David

> 
> When is a ds1 channelized?
> --------------------------
> 
> When you say "Whenever a DS1 is channelized", I note that we cannot
> assume that this means ANY framed ds1 (running at 1544000 or 2048000).
> 
> I agree with you that dynamic creation of ds0s does NOT make sense, but
> ONLY IF it is known apriori that a ds1 is channelized.  In many cases,
> it IS known apriori whether a ds1 is or is not channelized.  However, in
> other cases, such as for structured vs. unstructured circuit emulation
> over ATM, it is not, and it instead becomes a configuration option that
> needs to be addressed in either a standard or an implementation-specific
> manner.
> 
> In cases where the ds1 is NEVER channelized, I agree that the agent
> should never be expected to create the ds0s, since their presence in
> the ifTable would be an unnecessary waste of resources and an obstacle
> to managers that need to walk over them.
> 
> In cases where the ds1 is ALWAYS channelized, I think it would be
> important to mention explicitly in the DS0-MIB that a ds1 ifEntry for
> a framed DS1 or E1 circuit would NEVER appear alone in an ifTable, but
> would ALWAYS be accompanied by the appropriate number of corresponding
> ds0 ifEntries, all of which are created (and given previously unused
> ifIndex values) by the agent at the same time that the ds1 ifEntry is
> created.
> 
> In cases where the manager must be able to turn channelization on and off
> it would be my preference to have a standard object available that has
> the read-write semantics of controlling and reporting whether a ds1 is
> currently channelized or not.  For those ds1 interfaces that are fixed by
> implementation to be always channelized, this object would be read-only.
> For those ds1 interfaces that are fixed by implementation to be never
> channelized, this object would not exist.
> 
> Such an object could either be put directly in the dsx1ConfigTable of the
> DS1-MIB, although since it would relate to the existence/non-existence of
> ds0 ifEntries, such an object could also be put in the DS0-MIB instead of
> the DS1-MIB.  The latter approach would allow it to be used to control not
> only the channelization of ds1 ifEntries down to ds0 ifEntries, but also
> the channelization of higher aggregates (e.g, ds3 ifEntries) directly down
> to ds0 ifEntries.
> 
> Here is some proposed ASN.1 for such a table, using the latter approach
> of putting it in the DS0-MIB:
> 
> First, expand the comments for the DS0 Config Group to include a new
> table:
> 
>           -- The DS0 Config Group
> 
>           -- Implementation of this group is mandatory for all
>           -- systems that use a DS0 Interface.
> 
>           -- The DS0 Config Group consists of two tables:
>           --    DS0 Configuration
>           --    DS0 Channelization Control
> 
> Second, add the new table:
> 
>           dsx0ChanControlTable OBJECT-TYPE
>               SYNTAX  SEQUENCE OF Dsx0ChanControlEntry
>               MAX-ACCESS  not-accessible
>               STATUS  current
>               DESCRIPTION
>                       "The DS0 Channelization Control table."
>               ::= { ds0 3 }
> 
>           dsx0ChanControlEntry OBJECT-TYPE
>               SYNTAX  Dsx0ChanControlEntry
>               MAX-ACCESS  not-accessible
>               STATUS  current
>               DESCRIPTION
>                       "An entry in the DS0 Channelization Control table.
>                       There is an entry in this table corresponding to
>                       each ifEntry that is itself capable of direct
>                       channelization down to the individual ds0(81)
>                       ifEntry level."
>               INDEX   { ifIndex }
>               ::= { dsx0ChanControlTable 1 }
> 
>           Dsx0ChanControlEntry ::=
>               SEQUENCE {
>                   dsx0ChannelizationEnabled  TruthValue
>           }
> 
>           dsx0ChannelizationEnabled OBJECT-TYPE
>               SYNTAX  TruthValue
>               MAX-ACCESS  read-write
>               STATUS  current
>               DESCRIPTION
>                       "This object controls whether the given interface is
>                       channelized down to the individual ds0(81) level.
>                       This can be applied to ds1(18) interfaces that are
>                       capable of such channelization.  It can also apply to
>                       interfaces of higher DS0 aggregation, such as ds3(30),
>                       if there is no intervening ds1(18) ifEntry layer.
> 
>                       For interfaces where the DS0 channelization is always
>                       enabled, this object may be read-only.  For interfaces
>                       which never utilize DS0 channelization, this object
>                       should not exist."
>               ::= { dsx0ChanControlEntry 1 }
> 
> Third, add conformance information regarding the new table and objects:
> - The dsx0ChanControlTable would be mandatory for those agents that
>   support DS0 channelization.
> - The dsx0ChannelizationEnabled object would be a mandatory object.
> 
> If this is acceptable, it would answer my original question of how a
> management entity can "request" the agent to dynamically channelize a
> particular ds1 ifEntry in a standard way, for those cases in which it
> is appropriate to do so.
> 
> 

-- 
David Fowler                                   email:
[email-masked]
Newbridge Networks Corporation                 voice: (613) 599-3600 
ext.6559
600 March Rd, Kanata, Ontario, Canada K2K 2E6  fax:   (613) 599-3619

---

From: Gary Hanson <[email-masked]>
Date: Tue, 3 Feb 1998 17:34:10 -0800 (PST)

Dave,

My concern is primarily that there are a number of ways that a higher
aggregate circuit can be channelized to lower aggregates, some of
which are standard, and some of which are proprietary.

When it comes to channelizing a DS1 or E1 to DS0, it is straightforward.
However, I think it would be useful if the trunk-mibs helped with the
various other channelizations besides the M13 mux channelization of DS3
to DS1.  Since the DS1-MIB has been extended to support DS2 and E2, I
would think that there may be interest in supporting other variants of
channelization.  (I am not an expert in this area, but I have sent out
some enquiries on what the various standard and proprietary techniques
are, so I may be able to give a more compelling argument in the next
few days.... :-)  I know the variants include at least the following.

For DS3 to DS1:
- DS3 to DS1 (M13 channelization)
- DS3 to DS2 to DS1 (M23 channelization followed by DS1 channelization)

For E3 to E1:
- E3 to E1
- E3 to E2 to E1

It seems to me that the key objective is controlling/reporting whether
a given higher-speed interface is channelized to a lower-speed interface.
If we intend to support all of the above channelization options, the
objects in the latest DS3-MIB and DS1-MIB drafts do not seem sufficient.

By instead providing the channelization objects in the MIB that
corresponds to the given lower-speed interface, two advantages can be
realized:

- Higher-speed interfaces that do not support channelization do not
  have to worry about the channelization MIB object, since it is NOT even
  in the MIB that corresponds to the higher-speed interface.

- A single object can be used to identify ANY conceivable higher-speed
  interface that can be channelized to the given lower-speed interface.
  Thus, if it works for channelizing DS1 to DS0, it also works for DS2
  directly to DS0, and DS3 directly to DS0, and any others for which a
  channelization scheme can be devised, standard or not.

So, if we are ONLY interested in supporting channelization from DS3 to
DS1, E3 to E1, DS1 to DS0, and E1 to DS0, then the current objects
would be acceptable to me, EXCEPT that yes, I would suggest making them
read-write.

However, if we want to increase the flexibility of the MIBs to other
channelization variants, without adversely affecting the level of support
they provide for the four channelizatino variants just mentioned, I would
suggest the following:

- Remove dsx3Channelization from the DS3-MIB, and replace it with an
  object in a new table in the DS1-MIB which indicates channelization
  to the lower-speed interfaces actually supported by the DS1-MIB.  The
  enumeration options would have to include one "disabled" value, but
  two "enabled" values: one for DS3 to DS2 or E3 to E2, and another for
  DS3 to DS1 or E3 to E1.

- Remove dsx1Channelization form the DS1-MIB, and replace it with an
  object in a new table in the DS0-MIB which indicates channelization
  to the lower-speed DS0 interfaces actually supported by the DS0-MIB.
  The enumaration options could either be a TruthValue (as proposed
  earlier) or an "enabled" and "disabled" value (as it currently used
  in the DS1-MIB.

In both cases, the new tables would be indexed by the ifIndex of the
higher-speed interface.  Identification of the lower-speed interfaces
would be immediately available interfaces would be available via the
ifStackTable upon enabling the channelization.  Also, the lower-speed
interfaces would disappear upon disabling the channelization.

If there is interest in this, I would be happy to propose more ASN.1
text for the new table for the DS1-MIB along with a the table already
proposed for the DS0-MIB.

Regards,
Gary

P.S.
Thanks for splitting these threads out.  I should have done that
initially....

---

From: Dave Fowler <[email-masked]>
Date: Thu, 05 Feb 1998 14:18:40 -0500

Gary,

I am unsure what the advantage is of moving channelization around.  
Channelization is the property of the higher speed interface.  Your
proposal indiactes that the indexing of the table would be by the higher
speed interface.  I think it belongs in the higher-speed MIB.

My thoughts are that a generic NM application would expect to check the
channelization of all interfaces of certain types before moving forward
to get more information.  If channelization is off, no further
investigation is required.  So I can't see any case where a new table in
a lower-speed MIB wouldn't be implemented.  (i.e.  Assume that all DS1s
are unchannelized in a particular agent.  It is useful for a network
manager to have this information.  This would require the agent to
implement a portion of the DS0 MIB.  If we leave chennelization in the
DS1 MIB, then no part of DS0 MIB is required. )

I do agreee that we have a problem in the current proposal regarding the
implementation of DS3 -> DS2 -> DS1 interfaces.  You recommendation of
two modes of "ON" for DS3 channelization is good and I think we should
go with that.  This gives implementators the option of representing DS2s
or not.  And if they choose to represent DS2s, then they will be able to
fully desribe the channelization of DS3 on down to DS0.

I haven't heard any other arguments for anything other than the stepwise
channelization of DS3->DS2->DS1->DS0, where DS2 is optional, and so I'm
not planning to include any other changes, except clarifications.

Regards,
David

---

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Feb 1998 12:15:16 -0800 (PST)

Dave,

> speed interface.  I think it belongs in the higher-speed MIB.

Since the other day, when I suggested putting channelization in the lower-
speed MIBs, my understanding has evolved. :-)  I now am led to understand
that noone out there ever demultiplexes anything higher than DS1 (or E1)
to DS0.  Similarily, I now understand that DS2 is an oddity as a physical
interface, and that most DS3 channelization is straight to DS1.  In other
words, no one really bothers with 7 separate channels of DS2 each with
4 separate channels of DS1.  Instead, there is simply 4*7 channels of DS1
directly within DS3.

So, I would agree that putting the channelization control objects in
the lower-speed MIB in order to allow arbitary demultiplexing from
various higher-speed interfaces does not exist in the sense that I had
thought it might.

The only remaining advantage that I can think of for putting such objects
in the lower-speed MIB is to not burden SNMP agent implementations for
interfaces that do not support the channelization.  But this can also be
handled by either making the object have a MIN-ACCESS of not-accessible
(in case we decide that not every agent needs to support it) or to have
it always default to disabled(2) in that case.

> DS1 MIB, then no part of DS0 MIB is required. )

I guess that that is the flip side.  However, I could argue that the
manager can arrive at the same conclusion by getting a noSuchName response
upon checking the channelization control object.  Thus, if the agent does
NOT implement the lower-speed MIB, the noSuchName response would indicate
exactly what you wanted to convey.

I can be swayed either way on this one, since it really now seems to be
more a matter of style of how "I cannot be channelized" is indicated.

> fully desribe the channelization of DS3 on down to DS0.

Slow down, bubba looey...  Maybe I should withdraw my request to have
this supported.  If noone ever (ever) wants to support channelization
from DS3 to DS2, or from DS2 to DS1, or from E3 to E2, or from E2 to E1,
then no changes are needed (other than perhaps clarifications to the
existing DESCRIPTIONs.

If channelization from DS2 to DS1 or E2 to E1 though IS desired, then it
sounds more like we need to add an additional object to the DS1-MIB to
handle that case, since the existing object only covers DS1 to DS0 or E1
to DS0.

> not planning to include any other changes, except clarifications.

One other clarification that came up in a discussion I had:  It would
be helpful to state explicitly that the agent is required to populate
the ifTable and ifStackTable with the appropriate entries when the
channelization control objects are set to enabled(1).  Similarly, the
agent is required to depopulate the ifTable and ifStackTable entries
when the channelization control objects are set to disabled(2).

I guess the question of ifIndex assignment comes up in this context.
Should the agent always pick new values, or can previous values for
the same channel interfaces be re-appropriated?

For example, if the manager toggles the channelization control object
from enabled(1) to disabled(2) back and forth repeatedly, would the
desired agent behavior be to have the ifIndex values continue to march
up the set of positive integers?  Or would the desired behavior be to
have the same ifIndex entries flash into and out of existence?

(If it were possible, I would like the manager application that does
this to be sent a virus via the next HTTP interaction, if this is at
all possible.... :-)

Regards,
Gary

---

From: Dave Fowler <[email-masked]>
Date: Thu, 05 Feb 1998 16:29:24 -0500

All,

DS2 is documented in T1.107 in section 7.  Section 7.2 is called 
DS2 Application: M12 Multiplex Format -- 4 DS1 Channels.

This is where the term dsx1DS2M12 for line type came from.  I figured if
someone actually needs to model a ds2 in this MIB, it would be for this
application.

I can't see any harm in allowing someone to specify channelization of
a DS3 into DS2s.  I expect the common application will not 
represent DS2s, but do DS3->ds1 directly.

In the interests of the editor's time and sanity :-), I will
keep the channelization objects as in the last draft.  I will
change it from a truth value in both MIBs into the following:

For Ds3:  disable(1), enableDs1(2), and enableDs2(3).

For Ds1 MIB  disable(1), enableDs0(2), and enableDs1(3).

Regarding the re-use of ifIndices, the new if-mib provides a
discontinuity variable to allow the same ifIndices to be re-used.
It would be an implementor's decision which to use and I don't think
I need to specify this in the trunk MIBs.

If there are no further comments, I'll try to re-issue the
drafts this weekend.

Regards,
David