Subject: Re: Sonet/SDH virtual concatenation MIB

From: Kaj Tesink <[email-masked]>
Date: Wed, 02 Oct 2002 18:11:30 -0400

At 07:27 PM 9/30/2002 +0200, you wrote:
>Kaj,
>Do you know if there's any work to produce a MIB to manage Sonet/SDH 
>virtual concatenation (VC) and possibly the LCAS protocol?

hi yoav, not in 2558rev, but there have been questions about this before.
i copy this to atommib list which is the discussion list for this.
see http://www.ietf.org/html.charters/atommib-charter.html

kaj

>
>Thank you,
>Yoav Cohen.
>
>----------------------------------------------------------------------------------------------------------------
>
>Yoav Cohen                                                    Phone: + 
>972-3-920 2870<?xml:namespace prefix = o ns = 
>"urn:schemas-microsoft-com:office:office" />
>
>Seior Systems Analyst                                   Fax: + 972-3-921 7004
>
>Native Networks Ltd.                                       Email: 
><mailto:[email-masked]>[email-masked]
>
>2 Granit St. P.O.B 7165                                  Web: 
>www.nativenetworks.com
>
>Petah Tikva 49170
>
>Israel.
>
>"Native Networks - The Metro Ethernet Access Company"
>
>---------------------------------------------------------------------------------------------------------------
>

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

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

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

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 2 Oct 2002 21:31:55 -0700 (PDT)

On Wed, 2 Oct 2002, Kaj Tesink wrote:

> At 07:27 PM 9/30/2002 +0200, [Yoav Cohen] wrote:
> >Kaj,

I think it should be possible to represent virtually concatenated
paths with the existing MIB and ifStackTable -- the attached message
that I sent to the AToMMIB list back in January indicates one way
that this might be done.  It assumes that the assignments are done
"behind the scenes" by some unspecified means, which could be
static provisioning or the LCAS protocol.

If you need to manage the LCAS protocol itself, then you would need
a supplemental MIB module of some kind.  If you are interested in
standardizing such a thing, you might consider making a proposal
for a suitable extension of the AToMMIB charter.

Regards,

Mike Heard

Subject: Re: ifStackTable use for SONET virtual concatenation
From: "C. M. Heard" <[email-masked]>
To: CHRIS CHIOTASSO <[email-masked]>
Cc: AToMMIB Mailing List <[email-masked]>, Nevin Jones <[email-masked]>, Chris Murton <[email-masked]>
Date: Tue, 15 Jan 2002 14:19:06 -0800 (PST)

On Thu, 10 Jan 2002, CHRIS CHIOTASSO wrote:
> I have a question on sonet stacking.  I could not find an active sonet
> mib working group so I assume it is disbanded and hope someone in this
> group may be able to help me.

Chris,

The SONET-MIB originated in and is being maintained by the AToMMIB
working group.  An update to that MIB has recently been posted;  see

http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2558bis-00.txt

> We are using virtual concatenation over multiple STS1 paths.  (I'm
> told the official name of this is "high order path").  The
> sonet mib tells me that each STS1 path is it's own ifEntry with type
> sonetPath.  Is there a standard or accepted way of identifying
> the virtual concatenation layer?  Should it be a separate ifEntry?  If
> so what is it's ifType?

The SONET-MIB document is silent on the subject of virtually concatenation;
it is my understanding, however, that the payload labels used for so-called
"higher order" virtually concatenated paths whose the constituents are
ordinary SONET paths at the STS-1 rate or higher are exactly the same as
those used for ordinary SONET paths without virtual concatenation, subject
to the proviso that all components must use the same label.  This suggests
to me that there is no need for an extra ifStackTable layer to represent
the virtual concatenation;  instead, virtual concatenation can be
represented as a sort of inverse multiplexing by stacking the next layer
up on top of multiple SONET paths.  For example, if paths 1 through M are
components  of a virtually concatenated path that carries PPP (with a C2
value (payload label) of 22 decimal (16 hex)), and the other SONET paths
carry VTs, then the ifStackTable might look something like this:

         _____________________________
        |                  |     |    |  >
        |        PPP       |     |    |  |
        |  ifType: ppp(23) | ... |VT K|   > J ifEntries
        |                  |     |    |  |  ifType varies
        |__________________|_____|____|  >
        |       |   |      |   |      |  >
        |       |   |      |   |      |  |
        |Path 1 |...|Path M|...|Path L|   > L ifEntries
        |       |   |      |   |      |  |  ifType: sonetPath(50)
        |_______|___|______|___|______|  >
        |                             |  >
        |                             |  |
        |    Line                     |  |
        |                             |  |
        |_____________________________|  |
        |                             |  |
        |                             |  |
        |    Section Layer            |   > 1 ifEntry
        |                             |  |  ifType: sonet(39)
        |_____________________________|  |
        |                             |  |
        |                             |  |
        |    Physical Medium Layer    |  |
        |                             |  |
        |_____________________________|  >

Note that the ifType of the layer above a sonetPath can be anything
that is carried on a sonet path (sonetVT(51) for VTs, ppp(23) for
PPP over SONET, and so on);  multiplexing or inverse multiplexing
can be represented by the relationships between the layers expressed
by the ifStackTable [RFC2863] and the ifInvStackTable [RFC2864].  It
seems to me that this scheme would work well with the proposal for PPP
over SONET/SDH with virtual concatenation documented in

  http://www.ietf.org/internet-drafts/draft-ietf-pppext-posvcholo-05.txt

Comments would be most welcome from the authors of that document or from
anyone who has implemented SNMP management for virtually concatenated paths.

Regards,

Mike