Subject: Provisioning the C2 byte

From: "Nolish, Kevin" <[email-masked]>
Date: Wed, 25 Apr 2001 16:50:51 -0400

Marconi defined an extension mib for sonet.  One of the
items that we added was the ability to provision the C2
byte.  We have hardware that allows dsx1 tributaries to
be carried in STS-1 paths either by VT mapping or by
mapping the dsx1s into dsx3 via M13 multiplexing and then
carrying the dsx3 in the STS-1 path.

Why our customers care is that some have relatively new
ADMs connected to our equipment that understand VT mapping,
while others have equipment that was designed to mate
existing M13 gear into sonet rings.

Here's another data point on this issue.

Kevin Nolish
724-742-6989
<mailto:[email-masked]>

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 26 Apr 2001 09:54:22 -0400

kevin, irene, others,

since we are collecting 2558 implementation experience:
a) do you consider this function a critical omission
    that should be fixed. if there is a groundswell
    of support for this we should consider adding it;
    however, proprietary extensins might just do fine...
b) if your answer on a) is yes, what would be your
    simple fix

kaj

>Here's another data point on this issue.

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

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

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

---

From: "Nolish, Kevin" <[email-masked]>
Date: Thu, 26 Apr 2001 10:43:39 -0400

Well, we found at Marconi that we needed the functionality to support
mulitservice equipment.

What we do in our current MIB for C2 is to have a table indexed by the
ifIndex of the Sonet Path.  One of the columns in the table is:

foreSonetPathTxSignalLabel OBJECT-TYPE
	SYNTAX	Integer32
	MAX-ACCESS	read-write
	STATUS	current
	DESCRIPTION
	"This variable controls the transmit path payload. The default value
for ATM is 0x13 (19 decimal). Changing the value of this variable attempts
to change the payload and if successfull will change the transmitted C2
label to reflect the new payload.  Use the C2 variable in the diagnostics
table if you wish to change the C2 value for diagnostic purposes without
actually changing the transmitted payload type."
	DEFVAL { 19 }
	::= { foreSonetPathConfigEntry 3 }

Basically, it's an integer that holds the C2 value.  You change it and the
transmitted signal label changes and you reconfigure all of the objects
stacked, either directly or indirectly, upon the sonet path object.  The
diagnostics table is another proprietary extension.  That table has an entry
that allows the C2 value to be changed without changing the actual traffic
provisioned on the interface.  We use it for PLM and UNEQ-P error injection.

My personal bias is that all other things being equal, I'd rather be able to
provision things using a standard mib as opposed to using vendor proprietary
mibs.  I'd rather see a standard mib be a superset of needed functionality,
with columns read-only for equipment that doesn't support the functionaly.  

On the other hand, there's a strong case to be made that standard mibs ought
to support the largest common subset of functionality expected across the
vast majority of equipment.  Most equipment isn't multi-service, so it
probably isn't needed.

I'm waffling here a bit because this is, fundamentally, an argument about
the scope of the Sonet MIB and the scope of the AtmoMib's charter, and not
simply a technical issue.

Salient Points

1) C2 provisioning is needed for multiservice gear.
   I absolutly need this functionality and have built
   an extension mib because the standard mib doesn't
   support it.

2) It can be implemented as a simple extension mib.
   I have another table that effectively adds columns
   to the sonetPathCurrentTable.

3) There is nothing in the current mib that precludes
   a clean implementation.  In other words,
   the current mib is correct, but not complete with
   regards to multiservice equipment.

I'd like to see it added, but I'm willing to back off in the face of
determined opposition.  If I thought that the mib was broken or made
implementing this feature very difficult, as opposed to the mib simply being
incomplete, I'd press harder.

Besides,  I've got some serious problems with the way that VT configuration
is handled in the Sonet mib and I'd rather pick my battles. :)  I'll submit
something to the list when I have my thoughts in order.

Would it be interesting to the list for me to post a summary of our
proprietary extensions to the Sonet, Dsx3, or Dsx1 mibs?  I can post the
mibs themselves, but I don't think it's polite to drop huge posts on a
discussion list without warning.

Kevin Nolish
724-742-6989

---

From: Glenn McGuire <[email-masked]>
Date: Mon, 30 Apr 2001 15:54:30 -0400

Gee... your MIB variable looks remarkably similar one I had to write for my
organization...

Except I range-limited mine to (0..255)

The problem I face is for packet-over-SONET more than for ATM.  For the
higher speed interfaces, there has been some waffling between using 0xCF
(experimental) and 0x16 (PPP in HDLC-like framing) depending on the stage of
development and which vendor with whom we wish to interoperate.

Both Cisco & Juniper also have a command-line interface to set the path
label on their routers, and all pieces of test gear that I've used allow
setting this.
	-gm

> -----Original Message-----
> From: Nolish, Kevin [mailto:[email-masked]]
> Sent: Thursday, April 26, 2001 10:44 AM
> To: [email-masked]'
> Subject: RE: Provisioning the C2 byte
> 
>