Received: from cnri by ietf.org id aa17308; 14 Oct 96 20:40 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa25767; 14 Oct 96 20:39 EDT Received: from lightning (lightning.BayNetworks.COM [134.177.3.18]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id UAA24882 for ; Mon, 14 Oct 1996 20:20:55 -0400 (EDT) Received: from fedex.engwest.baynetworks.com by lightning (SMI-8.6/SMI-SVR4) id RAA02491; Mon, 14 Oct 1996 17:20:03 -0700 Received: from cbusw1.engwest by fedex.engwest.baynetworks.com (4.1/SMI-4.1) id AA25066; Mon, 14 Oct 96 17:20:19 PDT Received: by cbusw1.engwest (4.1/SMI-4.1) id AA22029; Mon, 14 Oct 96 17:20:15 PDT Date: Mon, 14 Oct 96 17:20:15 PDT From: Faye Ly Message-Id: <9610150020.AA22029@cbusw1.engwest> To: atommib@thumper.bellcore.com Subject: Service Registry Table - reposting Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 13 Hi, This is the last time I am going to post the proposal from Jean-Bernard (IBM) regarding adding the service registry table in the atm2 MIB. We have exchanged a few emails and decided to add a new object which describes the source of the ATM service entry. An ATM service entry can be created by the network manager from SNMP, learned via ILMI or configured through some other mechanism such as the console interface. Please review and comment. -faye ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: service.proposal X-Sun-Content-Lines: 227 TEXT changes ============ 5.3 Supported Functions Update Table 1. MIB Structure and add the following entry to the table: atmSrvcRegTable Y Y Y This table should be supported by Host, Switch and Services. Add new section 5.3.14 ATM Services Registration Table This table contains information used by ATM devices to locate ATM network services. ATM network services such as CIP ARP server or LECS, can be created by the network manager or learned via ILMI. Entries in this table can either be exported to the adjacent devices via ILMI to all or a few ATM interfaces. NOTE: ADD ILMI doc. as reference 22. As an example, let's assume that: - an ATM switch X has three interfaces if1, if2 and if3. - there are two ATM network services offered: a1.a2...aN and b1.b2...bN, (where a1.a2...aN is an object identifier used to identify the first service, and b1.b2...bN is the object identifier for the other service. These services may be CIP ARP servers, LECS server, ...) - The first service is available at the ATM address 'a'. - The second service is available at the ATM address 'b'. - The first service can be used by any device connecting to the switch X. - The second service can be used only by devices that connect to interfaces if1 and if3 on switch X. *------------------* *------------------* Iservice a1.a2...aNI Iservice b1.b2...bNI I I I I I ATM address = a I I ATM address = b I *------------------* *------------------* I I ++++++++++++++++++++++++++++++++++++++++++++ + ATM NETWORK + ++++++++++++++++++++++++++++++++++++++++++++ I *-------------* I switch X I *-+----+----+-* I I I interfaces: if1 if2 if3 The table will contain three entries: - one entry for the "a1.a2...aN", implicitly available to any devices on switch X. - two entries for the "b1.b2...bN" (one for each interface where this service can be explicitly used). The content of the table is: Service Identifier: a1.a2...aN b1.b2...bN b1.b2...bN ATM address: a b b Arbitrary index: m n p Interface: 0 1 3 where m, n and p are arbitrary parameters. When querying the ILMI service registry table, through the ILMI protocol: - the device attached to interface if1 will obtained the address a and b - the device attached to interface if2 will obtained the address a only - the device attached to interface if3 will obtained the address a and b MIB Objects =========== -- Services Registration Table -- -- This table contains a list of ATM network services -- atmSrvcRegTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSrvcRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of all the ATM network services known by this device. The characteristics of these services are made available through the ILMI, using the ILMI general-purpose service registry MIB. These services may be made available to all ATM interfaces (atmSrvcRegIndex = 0) or to some specific ATM interfaces only (atmSrvcRegIndex = ATM interface index)." ::= { atmSrvcRegistryGroup 1 } atmSrvcRegEntry OBJECT-TYPE SYNTAX AtmSrvcRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single service provider that is available to the user-side of an adjacent device through the ILMI." INDEX { atmSrvcRegServiceID, atmSrvcRegAddressIndex, atmSrvcRegIndex } ::= { atmSrvcRegTable 1 } AtmSrvcRegEntry ::= SEQUENCE { atmSrvcRegServiceID OBJECT IDENTIFIER, atmSrvcRegAddressIndex INTEGER, atmSrvcRegIndex ifIndex, atmSrvcRegATMAddress AtmAddress, atmSrvcRegParm1 OCTET STRING, atmSrvcRegSource INTEGER, atmSrvcRegRowStatus RowStatus } atmSrvcRegServiceID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the service identifier which uniquely identifies the type of service at the address provided in the table." ::= { atmSrvcRegEntry 1 } atmSrvcRegAddressIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer to differentiate multiple rows containing different ATM addresses for the same service on the same interface. This number needs NOT to be the same as the corresponding ILMI atmfSrvcRegAddressIndex MIB object." ::= { atmSrvcRegEntry 2 } atmSrvcRegIndex OBJECT-TYPE SYNTAX ifIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM interface where the service defined in this entry can be made available to an ATM device attached to this interface. The value of 0 has a special meaning: when an ATM service is defined in an entry whose atmSrvcRegIndex is zero, the ATM service is available to ATM devices connected to any ATM interface. (default value(s)). When the user-side of an adjacent device queries the content of the ILMI service registry MIB (using the ILMI protocol), the local network-side responds with the ATM services defined in atmSrvcRegTable entries, provided that these entries are indexed by: - the corresponding interface number (atmSrvcRegIndex equal to the number of the interface that the adjacent device is connected to) - zero (atmSrvcRegIndex=0)." ::= { atmSrvcRegEntry 3 } atmSrvcRegATMAddress OBJECT-TYPE SYNTAX AtmAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is the full address of the service. The user-side of the adjacent device may use this address to establish a connection with the service." ::= { atmSrvcRegEntry 4 } atmSrvcRegParm1 OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "An octet string used according to the value of atmSrvcRegServiceID." ::= { atmSrvcRegEntry 5 } atmSrvcRegSource OBJECT-TYPE SYNTAX INTEGER { other(1), -- the source of this entry is unknown viaIlmi(2), -- this entry is learned from ILMI viaNms(3), -- this entry is created by a Network Manager viaConfig(4) -- this entry is created via other kind of -- configuration mechanism such as the console -- interface } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to describe the source of the entry. The entry can be created by the agent via ILMI or other configuration mechanism such as the console interface. Or it can be created by the NMS using SNMP." ::= { atmSrvcRegEntry 6 } atmSrvcRegRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create or destroy an entry from this table." ::= { atmSrvcRegEntry 7 }   Received: from cnri by ietf.org id aa01201; 15 Oct 96 8:02 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa08237; 15 Oct 96 8:02 EDT Received: from tzr1.hirschmann.de (tzr1.hirschmann.de [149.218.20.7]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id HAA12616 for ; Tue, 15 Oct 1996 07:48:36 -0400 (EDT) Received: from pt1.hirschmann.de by tzr1.hirschmann.de (5.65c/1.921207) id AA00789; Tue, 15 Oct 1996 11:53:03 +0100 Received: from klippel by pt1.hirschmann.de (4.1/SMI-4.1) id AA10102; Tue, 15 Oct 96 12:42:28 +0100 Message-Id: <9610151142.AA10102@pt1.hirschmann.de> Comments: Authenticated sender is From: dklippel To: comp.dcom.cell-relay@indiana.edu Date: Tue, 15 Oct 1996 13:36:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: IBM 8285 Address Registration Cc: atommib@thumper.bellcore.com, af-nm@atmforum.com X-Confirm-Reading-To: "dklippel" X-Pmrqc: 1 Return-Receipt-To: "dklippel" Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Hi folks, I have a question concerning the Address Registration MIB: We use an IBM 8285 ATM Workgroup Switch. When I perform a get-next to its atmfAtmAddressTable, following result is printed: atmfAddressStatus.103.20.57.153.153.153.153.153.153.0.0.153.153.1.1.2.0. 161.10.0.128.0 = 1 This is the entry for our ATM Workstation, which is connected to this switch. I interprete this entry as following: - the last 7 bytes define the ESI and the SEL of the ATM Host ESI: 2.0.161.10.0.128 SEL:0 - the 13 bytes before define the Net Prefix 57.153.153.153.153.153.153.0.0.153.153.1.1 That is right so far. But what mean the first two bytes: 103.20 ?? Since the first index defines the ATM Port, what means the second ? The atmfAddressEntry (UNI 3.1) uses following index: atmfAddressPort : INTEGER atmfAddressAtmAddress : AtmAddress --> OCTET STRING(SIZE(8|20)) So the above entry should have a maximum index length of 21. (Port and ATM Address) and not 22. Can anyone help me ? Thanks and best regards, ******************************** Dieter Klippel Richard Hirschmann GmbH & Co. Networking Technology - NEH Development High Speed LAN PO Box 1649 72606 Nuertingen Tel: (49) 7127/14-1627 Fax: (49) 7127/14-1600   Received: from cnri by ietf.org id aa02716; 15 Oct 96 8:46 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa09160; 15 Oct 96 8:46 EDT Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id IAA14526 for ; Tue, 15 Oct 1996 08:32:39 -0400 (EDT) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id IAA11906; Tue, 15 Oct 1996 08:31:07 -0400 Received: from emily.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id IAA18017; Tue, 15 Oct 1996 08:33:06 -0400 Received: by emily.cascade (5.x/SMI-SVR4) id AA10137; Tue, 15 Oct 1996 08:33:04 -0400 Date: Tue, 15 Oct 1996 08:33:04 -0400 From: "Ron M. Parker" Message-Id: <9610151233.AA10137@emily.cascade> To: comp.dcom.cell-relay@indiana.edu, dklippel@pt1.hirschmann.de Subject: Re: AF-NM: IBM 8285 Address Registration Cc: atommib@thumper.bellcore.com, af-nm@atmforum.com X-Sun-Charset: US-ASCII Dieter - This table is dual-indexed (port and address). The "103" is the port identifier. Since the address, itself, is variable length (8 or 20 octets), a length is required to precede it (20 in this case). See RFC1212 for a description of variable length indices in MIB tables. Ron Parker Cascade Communications > From af-bounce@atmforum.com Tue Oct 15 07:59 EDT 1996 > Date: Tue, 15 Oct 1996 04:56:55 -0700 (PDT) > From: "dklippel" > Subject: AF-NM: IBM 8285 Address Registration > To: comp.dcom.cell-relay@indiana.edu > Cc: atommib@thumper.bellcore.com, af-nm@atmforum.com > Mime-Version: 1.0 > Content-Transfer-Encoding: 7BIT > X-Info: [Un]Subscribe or administrative requests should go to info@atmforum.com > X-Atm-Gateway: AF-NM AF-NM > > Hi folks, > > I have a question concerning the Address Registration MIB: > > We use an IBM 8285 ATM Workgroup Switch. When I perform a > get-next to its atmfAtmAddressTable, following result is printed: > > atmfAddressStatus.103.20.57.153.153.153.153.153.153.0.0.153.153.1.1.2.0. > 161.10.0.128.0 = 1 > > This is the entry for our ATM Workstation, which is connected to this > switch. I interprete this entry as following: > > - the last 7 bytes define the ESI and the SEL of the ATM Host > ESI: 2.0.161.10.0.128 > SEL:0 > > - the 13 bytes before define the Net Prefix > 57.153.153.153.153.153.153.0.0.153.153.1.1 > > That is right so far. But what mean the first two bytes: 103.20 ?? > Since the first index defines the ATM Port, what means the second ? > > > The atmfAddressEntry (UNI 3.1) uses following index: > > atmfAddressPort : INTEGER > atmfAddressAtmAddress : AtmAddress --> OCTET STRING(SIZE(8|20)) > > So the above entry should have a maximum index length of 21. > (Port and ATM Address) and not 22. > > Can anyone help me ? > > Thanks and best regards, > > > > > ******************************** > Dieter Klippel > Richard Hirschmann GmbH & Co. > Networking Technology - NEH > Development High Speed LAN > > PO Box 1649 > 72606 Nuertingen > > Tel: (49) 7127/14-1627 > Fax: (49) 7127/14-1600 >   Received: from cnri by ietf.org id aa07931; 15 Oct 96 10:09 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa11236; 15 Oct 96 10:09 EDT Received: from galaxy.npi.stpn.soft.net (mrityu@[204.143.126.27]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id JAA20795 for ; Tue, 15 Oct 1996 09:53:11 -0400 (EDT) Received: (from mrityu@localhost) by galaxy.npi.stpn.soft.net (8.6.12/8.6.9) id SAA15458; Tue, 15 Oct 1996 18:59:40 +0500 Date: Tue, 15 Oct 1996 18:59:39 +0500 (GMT+0500) From: mrityunjay To: dklippel cc: comp.dcom.cell-relay@indiana.edu, atommib@thumper.bellcore.com, af-nm@atmforum.com Subject: Re: AF-NM: IBM 8285 Address Registration In-Reply-To: <9610151142.AA10102@pt1.hirschmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! > > I have a question concerning the Address Registration MIB: > > We use an IBM 8285 ATM Workgroup Switch. When I perform a > get-next to its atmfAtmAddressTable, following result is printed: > > atmfAddressStatus.103.20.57.153.153.153.153.153.153.0.0.153.153.1.1.2.0. > 161.10.0.128.0 = 1 > > This is the entry for our ATM Workstation, which is connected to this > switch. I interprete this entry as following: > > - the last 7 bytes define the ESI and the SEL of the ATM Host > ESI: 2.0.161.10.0.128 > SEL:0 > > - the 13 bytes before define the Net Prefix > 57.153.153.153.153.153.153.0.0.153.153.1.1 > > That is right so far. But what mean the first two bytes: 103.20 ?? > Since the first index defines the ATM Port, what means the second ? > 20 says that the Address length is 20 bytes(and not 8). > > The atmfAddressEntry (UNI 3.1) uses following index: > > atmfAddressPort : INTEGER > atmfAddressAtmAddress : AtmAddress --> OCTET STRING(SIZE(8|20)) > > So the above entry should have a maximum index length of 21. > (Port and ATM Address) and not 22. > > Can anyone help me ? I hope this answer is satisfactory to you. > > Thanks and best regards, > > > > > ******************************** > Dieter Klippel > Richard Hirschmann GmbH & Co. > Networking Technology - NEH > Development High Speed LAN > > PO Box 1649 > 72606 Nuertingen > > Tel: (49) 7127/14-1627 > Fax: (49) 7127/14-1600 > With regards, Mrityunjay ---------------------------------------------- Mrityunjay Kumar Network Programs Inc. Noida, India. Ph: +91-11-8536622 email: mrityu@galaxy.npi.stpn.soft.net ---------------------------------------------   Received: from cnri by ietf.org id aa25992; 15 Oct 96 19:30 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa25839; 15 Oct 96 19:30 EDT Received: from lightning (lightning.BayNetworks.COM [134.177.3.18]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id TAA25789 for ; Tue, 15 Oct 1996 19:12:04 -0400 (EDT) Received: from fedex.engwest.baynetworks.com by lightning (SMI-8.6/SMI-SVR4) id QAA16547; Tue, 15 Oct 1996 16:11:13 -0700 Received: from cbusw1.engwest by fedex.engwest.baynetworks.com (4.1/SMI-4.1) id AA01972; Tue, 15 Oct 96 15:42:14 PDT Received: by cbusw1.engwest (4.1/SMI-4.1) id AA16797; Tue, 15 Oct 96 15:42:13 PDT Date: Tue, 15 Oct 96 15:42:13 PDT From: Faye Ly Message-Id: <9610152242.AA16797@cbusw1.engwest> To: atommib@thumper.bellcore.com Subject: PVP/PVC traps - reposting Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 7 Hi, all, Please review the newest and latest PVP/PVC trap proposal. I have added the trap control mechanism as Keith suggested (taken from the Soft PVC MIB from ATM forum). -faye ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: atm2-trap.proposal X-Sun-Content-Lines: 108 xx. Definition of ATM related traps Two traps are defined to help the network manager to detect the up/down status of the permanent virtual path and links. The current up/down status of the permanent VPL and VCL are indicated by the object atmVplOperStatus and atmVclOperStatus, respectively. Pulling these objects for all the permanent VPLs and VCLs can be a time consuming and resource consuming task. That is why these two traps are defined to provide additinal mechanism to learn the cuurent status of the permanent paths and links. atmPvplChange and atmPvplChange traps are generated just after atmVplOperStatus leaves or enters the up state. In order to avoid the flooding of these two traps in the network due to the link failure, two more objects are added to suppress the traps if necessary. These two objects atmPvplTrapControl and atmPvclTrapControl allow user to disable PVC/PVP traps, send traps if the PVP/PVCs are up or send traps if the PVP/PVCs are down. In addition to these two objects, a new object is provided to the network manager to device a threshold so the agent will send a trap when the number of up/down connections have hit the threshold value. The threshold object atmTrapThreshold applies to all ATM traps. For example, if the value of this object is set to 15, the atmPvplTrapControl is set to upTrap(1) and the atmPvclTrapControl is set to trapAll(4). A atmPvplChange trap is sent to the trap receiver after 15 PVPs have gone up. A atmPvclChange trap is sent to the trap receiver after 15 PVCs have either gone up or down. The VPI/VCI values and OperStatus included in the trap PDU are the last PVP/PVC up/down event. -- Textual convention for trap control AtmTrapControlType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of the trap are generated to the trap receiver. noTrap(1) disable the generation of the traps, upTrap(2) will only generate traps if the connection is up and downTrap(3) vice versa. allTrap(4) will generate both up/down traps for the connection." SYNTAX INTEGER { noTrap(1), upTrap(2), downTrap(3), trapAll(4) } -- Trap control objects atmPvplTrapControl OBJECT-TYPE SYNTAX AtmTrapControlType MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the PVP Link traps." DEFVAL { trapAll } ::= { atm2MIBObjects 14 } atmPvclTrapControl OBJECT-TYPE SYNTAX AtmTrapControlType MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the PVC Link traps." DEFVAL { trapAll } ::= { atm2MIBObjects 15 } atmTrapThreshold OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates number of events occurred before generating an ATM trap to the trap receiver. A value of zero indicates no trap is generated." DEFVAL { 1 } ::= { atm2MIBObjects 16 } -- ATM Traps atmPvplChange NOTIFICATION-TYPE OBJECTS { ifIndex, atmVplVpi, atmVplOperStatus } STATUS current DESCRIPTION "This trap signifies that the agent has detected that the atmVplOperStatus object for the permanent VPL has entered or left the up state. This trap shall not be generated if the cause of the VPL status change is a change in status of the underlying interface layer(s)." ::= { atmTraps 1 } atmPvclChange NOTIFICATION-TYPE OBJECTS { ifIndex, atmVclVpi, atmVclVci, atmVclOperStatus } STATUS current DESCRIPTION "This trap signifies that the agent has detected that the atmVclOperStatus object for the permanent VCL has entered or left the up state. This trap shall not be generated if the cause of the VPL status change is a change in status of the underlying interface layer(s)." ::= { atmTraps 2 }   Received: from cnri by ietf.org id aa25993; 15 Oct 96 19:30 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa25838; 15 Oct 96 19:30 EDT Received: from lightning (lightning.BayNetworks.COM [134.177.3.18]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id TAA25987 for ; Tue, 15 Oct 1996 19:16:47 -0400 (EDT) Received: from fedex.engwest.baynetworks.com by lightning (SMI-8.6/SMI-SVR4) id QAA17218; Tue, 15 Oct 1996 16:15:56 -0700 Received: from cbusw1.engwest by fedex.engwest.baynetworks.com (4.1/SMI-4.1) id AA29121; Tue, 15 Oct 96 11:29:38 PDT Received: by cbusw1.engwest (4.1/SMI-4.1) id AA15031; Tue, 15 Oct 96 11:29:38 PDT Date: Tue, 15 Oct 96 11:29:38 PDT From: Faye Ly Message-Id: <9610151829.AA15031@cbusw1.engwest> To: atommib@thumper.bellcore.com Subject: ATM Traps final posting Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 16 Hi, all, Here comes the PVP/PVC trap proposal again! I have included the trap control mechanism (taken from the Soft PVC MIB done by ATM Forum) in the new proposal. Please review and comment. Note that this trap control mechanism requires inter-MIB objects dependency and this is known to be a bit hard to implement. One way of simplyfying the implementation is to always set the trap threshold to 1 or not to have trap threshold at all. But I leave that to you to decide ... -faye ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: atm2-trap.proposal X-Sun-Content-Lines: 108 xx. Definition of ATM related traps Two traps are defined to help the network manager to detect the up/down status of the permanent virtual path and links. The current up/down status of the permanent VPL and VCL are indicated by the object atmVplOperStatus and atmVclOperStatus, respectively. Pulling these objects for all the permanent VPLs and VCLs can be a time consuming and resource consuming task. That is why these two traps are defined to provide additinal mechanism to learn the cuurent status of the permanent paths and links. atmPvplChange and atmPvplChange traps are generated just after atmVplOperStatus leaves or enters the up state. In order to avoid the flooding of these two traps in the network due to the link failure, two more objects are added to suppress the traps if necessary. These two objects atmPvplTrapControl and atmPvclTrapControl allow user to disable PVC/PVP traps, send traps if the PVP/PVCs are up or send traps if the PVP/PVCs are down. In addition to these two objects, a new object is provided to the network manager to device a threshold so the agent will send a trap when the number of up/down connections have hit the threshold value. The threshold object atmTrapThreshold applies to all ATM traps. For example, if the value of this object is set to 15, the atmPvplTrapControl is set to upTrap(1) and the atmPvclTrapControl is set to trapAll(4). A atmPvplChange trap is sent to the trap receiver after 15 PVPs have gone up. A atmPvclChange trap is sent to the trap receiver after 15 PVCs have either gone up or down. The VPI/VCI values and OperStatus included in the trap PDU are the last PVP/PVC up/down event. -- Textual convention for trap control AtmTrapControlType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of the trap are generated to the trap receiver. noTrap(1) disable the generation of the traps, upTrap(2) will only generate traps if the connection is up and downTrap(3) vice versa. allTrap(4) will generate both up/down traps for the connection." SYNTAX INTEGER { noTrap(1), upTrap(2), downTrap(3), trapAll(4) } -- Trap control objects atmPvplTrapControl OBJECT-TYPE SYNTAX AtmTrapControlType MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the PVP Link traps." DEFVAL { trapAll } ::= { atm2MIBObjects 14 } atmPvclTrapControl OBJECT-TYPE SYNTAX AtmTrapControlType MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the PVC Link traps." DEFVAL { trapAll } ::= { atm2MIBObjects 15 } atmTrapThreshold OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates number of events occurred before generating an ATM trap to the trap receiver. A value of zero indicates no trap is generated." DEFVAL { 1 } ::= { atm2MIBObjects 16 } -- ATM Traps atmPvplChange NOTIFICATION-TYPE OBJECTS { ifIndex, atmVplVpi, atmVplOperStatus } STATUS current DESCRIPTION "This trap signifies that the agent has detected that the atmVplOperStatus object for the permanent VPL has entered or left the up state. This trap shall not be generated if the cause of the VPL status change is a change in status of the underlying interface layer(s)." ::= { atmTraps 1 } atmPvclChange NOTIFICATION-TYPE OBJECTS { ifIndex, atmVclVpi, atmVclVci, atmVclOperStatus } STATUS current DESCRIPTION "This trap signifies that the agent has detected that the atmVclOperStatus object for the permanent VCL has entered or left the up state. This trap shall not be generated if the cause of the VPL status change is a change in status of the underlying interface layer(s)." ::= { atmTraps 2 }   Received: from cnri by ietf.org id aa26965; 15 Oct 96 20:26 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa26763; 15 Oct 96 20:26 EDT Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by thumper.bellcore.com (8.7.6/8.7.3) with ESMTP id KAA25698 for ; Tue, 15 Oct 1996 10:45:32 -0400 (EDT) Received: from D018S108.mch.sni.de (D018S108.mch.sni.de [139.22.92.6]) by thoth.mch.sni.de (8.7.6/8.7.3) with SMTP id QAA01750 for ; Tue, 15 Oct 1996 16:45:26 +0200 (MDT) Received: by D018S108.mch.sni.de id AA06302 (5.65c/IDA-1.4.4 for atommib@thumper.bellcore.com); Tue, 15 Oct 1996 15:45:25 +0100 Date: Tue, 15 Oct 1996 15:45:25 +0100 From: "Dr. T. Betker" Message-Id: <199610151445.AA06302@D018S108.mch.sni.de> To: atommib@thumper.bellcore.com Subject: Re: IBM 8285 Address Registration Content-Type: text "dklippel" asked: [snip] > We use an IBM 8285 ATM Workgroup Switch. When I perform a > get-next to its atmfAtmAddressTable, following result is printed: > > atmfAddressStatus.103.20.57.153.153.153.153.153.153.0.0.153.153.1.1.2.0. > 161.10.0.128.0 = 1 [snip] > That is right so far. But what mean the first two bytes: 103.20 ?? > Since the first index defines the ATM Port, what means the second ? 20 is the length of the atmfAddressAtmAddress index. From RFC1212: | To define the instance identification information, determine which | object value(s) will unambiguously distinguish a conceptual row. The | syntax of those objects indicate how to form the instance-identifier: | | ... | | (3) string-valued, variable-length strings: `n+1' sub- | identifiers, where `n' is the length of the string (the | first sub-identifier is `n' itself, following this, each | octet of the string is encoded in a separate sub- | identifier); | | ... Hope that helps, Thomas +---------------------------------------+----------------------------------+ |Thomas Betker, SNI OEC MW152 | phone: +49-89-636-43387 | |Siemens Nixdorf Informationssysteme AG | fax: +49-89-636-47655 | |D-81739 Muenchen | e-mail: thomas.betker@mch.sni.de | +---------------------------------------+----------------------------------+   Received: from cnri by ietf.org id aa08374; 20 Oct 96 15:36 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa13715; 20 Oct 96 15:36 EDT Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id PAA00862 for ; Sun, 20 Oct 1996 15:19:11 -0400 (EDT) Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA12283; Sun, 20 Oct 1996 15:19:07 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma012260; Sun Oct 20 15:18:42 1996 Received: from thor.ca.newbridge.com (thor.ca.newbridge.com [138.120.100.14]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id PAA16805; Sun, 20 Oct 1996 15:18:41 -0400 Received: from jadzia.newbridge (jadzia [138.120.136.156]) by thor.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id PAA29073; Sun, 20 Oct 1996 15:18:37 -0400 Received: by jadzia.newbridge (SMI-8.6/SMI-SVR4) id PAA21101; Sun, 20 Oct 1996 15:21:41 -0400 Date: Sun, 20 Oct 1996 15:21:41 -0400 From: Dave Fowler Message-Id: <199610201921.PAA21101@jadzia.newbridge> To: atommib@thumper.bellcore.com, faye@baynetworks.com Subject: Re: ATM Traps final posting X-Sun-Charset: US-ASCII Faye, Sorry for getting back late on this issue. I had some actions from Montreal to deal with traps too (or I thoguht I did). Unfortunately, I haven't seen any minutes with action items. A Service Management application is concerned about end-to-end connectivity in a network and not about VPLc or VCLs. We need to include traps for VPCs and VCCs and set the compliances accordingly. There are in fact a number of other objects that I am supposed to propse that are service managment related and it looks like we will want a special compliance section for service mgmt anyway. I will try to cook up objects/text for VPC and VCC traps and post them soon. There's so much IETF stuff to do, I wish I didn't have other work!!! Regards, David > Hi, all > > Here comes the PVP/PVC trap proposal again! > > I have included the trap control mechanism (taken from the Soft PVC MIB > done by ATM Forum) in the new proposal. Please review and comment. > > Note that this trap control mechanism requires inter-MIB objects > dependency and this is known to be a bit hard to implement. One > way of simplyfying the implementation is to always set the trap > threshold to 1 or not to have trap threshold at all. But I leave that > to you to decide ... > > -faye > >   Received: from cnri by ietf.org id aa05429; 21 Oct 96 3:26 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa04290; 21 Oct 96 3:26 EDT Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id DAA14913 for ; Mon, 21 Oct 1996 03:13:59 -0400 (EDT) Received: (kzm@localhost) by foxhound.cisco.com (8.6.12/8.6.5) id AAA25089; Mon, 21 Oct 1996 00:13:14 -0700 From: Keith McCloghrie Message-Id: <199610210713.AAA25089@foxhound.cisco.com> Subject: Re: PVP/PVC traps - reposting To: Faye Ly Date: Mon, 21 Oct 1996 00:13:13 -0700 (PDT) Cc: atommib@thumper.bellcore.com In-Reply-To: <9610152242.AA16797@cbusw1.engwest> from "Faye Ly" at Oct 15, 96 03:42:13 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Faye, > Please review the newest and latest PVP/PVC trap proposal. I have > added the trap control mechanism as Keith suggested (taken from > the Soft PVC MIB from ATM forum). Thanks for taking my suggestion. However, it hasn't come out the way I expected: - in the Soft-PVC MIB, when a failure occurs after a period in which no trap has been sent, then a trap is sent immediately upon the occurence of this new failure, but no further traps are sent until a time interval has expired. With the MIB objects you propose, traps are only sent when the number of failures reaches a threshold, no matter how frequently or infrequently they occur. I suggest the time-based approach is much better. - the Soft-PVC MIB contains a table of currently-failing Soft-PVCs; the table is indexed by the ifIndex, VPI, VCI and leaf-reference and contains a single columnur object: a timestamp of the time the current failure began. (Similarly for Soft-PVPs.) - the trap does not identify any failing connection, rather it identifies the number of connections which are currently failing. The idea being that the NMS can then query the table of currently-failing Soft-PVCs to determine which ones are currently failing. Keith.   Received: from cnri by ietf.org id aa27636; 23 Oct 96 16:27 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa21801; 23 Oct 96 16:27 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id QAA14344 for ; Wed, 23 Oct 1996 16:01:00 -0400 (EDT) Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA21051; Wed, 23 Oct 1996 16:04:47 -0400 Received: from nv-ktesink.cc.bellcore.com by eve (4.1/4.7) id AA18227; Wed, 23 Oct 96 16:08:31 EDT Date: Wed, 23 Oct 96 16:08:31 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9610232008.AA18227@eve> X-Sender: kaj@eve.bellcore.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com From: Kaj Tesink Subject: atm1ng and atmtc mibs next version hi, i'm readying the next versions of the 1695 revision and the atmtc mib to remove (hopefully) the last issues. here's my list of changes sofar. let me know if i forget something. thanks to alan carwile of bay for the help with debugging. kaj ----------------------------------------------- atm1ng - removed a bunch of typos - removed an IMPORT loop (importing from atmtcmib while that one imported from atmmib) - revised the conformance/compliance statement, accommodating pvc <> svc compliance - included chris martin's suggestion on a IndexNext object for the traffic param table. the addition is as follows: atmTrafficDescrParamIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmTrafficDescrParamIndex when creating entries in the atmTrafficDescrParamTable. The value 0 indicates that no unassigned entries are available. To obtain the atmTrafficDescrParamIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next unassigned index." ::= { atmMIBObjects 13 } --------------------------------------------------------- atmtc mib - removed a bunch of typos - removed an IMPORT loop (importing from atmtcmib while that one imported from atmmib) - changed the TimeStamp in atmVorXLastChange to TimeTicks to avoid TC referral to another TC. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from cnri by ietf.org id aa10534; 25 Oct 96 11:53 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa13795; 25 Oct 96 11:53 EDT Received: from lightning (lightning.BayNetworks.COM [134.177.3.18]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id LAA07070 for ; Fri, 25 Oct 1996 11:29:04 -0400 (EDT) Received: from ns1 by lightning (SMI-8.6/SMI-SVR4) id IAA01850; Fri, 25 Oct 1996 08:28:30 -0700 Received: from pobox by ns1 (SMI-8.6/SMI-SVR4) id IAA21839; Fri, 25 Oct 1996 08:28:28 -0700 Received: from [134.177.35.35] (acarwile-mac.corpwest.baynetworks.com [134.177.35.35]) by pobox (SMI-8.6/SMI-SVR4) with ESMTP id IAA10515; Fri, 25 Oct 1996 08:28:26 -0700 for X-Sender: acarwile@sc-mail1.corpwest.baynetworks.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Oct 1996 08:32:29 -0700 To: atommib@thumper.bellcore.com From: Alan Carwile Subject: local vs. remote in atmVclAddrBindTable I'm confused over the interpretation of local vs. remote in the atmVclAddrBindTable. Please respond back to the mailing list regarding the following examples and questions. 1) Given a switch with two ATM interfaces, suppose a VC comes from AtmAddr=A, into if=1 with vpi:vci of 0:33, then cross-connects, and goes out if=2 with vpi:vci of 0:34 toward AtmAddr=B. A ---0:33--- [(1) <-cc-> (2)] ---0:34--- B Will I see the following content? 1, 0, 33, AtmAddrA, remote 1, 0, 33, AtmAddrB, remote 2, 0, 34, AtmAddrA, remote 2, 0, 34, AtmAddrB, remote or will I see the following content? 1, 0, 33, AtmAddrA, local 1, 0, 33, AtmAddrB, remote 2, 0, 34, AtmAddrA, remote 2, 0, 34, AtmAddrB, local In other words, does local/remote refer to whether the AtmAddress is on the "local" side of the cross-connect? Or does it refer to whether it is "inside" the same box (same agent's scope)? 2) As another example... C ---0:50--- [(1) --> D] Given a switch with local LEC (e.g., to reach the agent), and with a call that terminates in this box... Suppose a VC comes in from AtmAddr=C into if=1 with vpi:vci of 0:50, then terminates to AtmAddr=D inside the box. Will I see the following content? 1, 0, 50, AtmAddrC, remote 1, 0, 50, AtmAddrD, local As I look at this MIB table, I would like to see three choices instead of the two choices (local vs. remote). Those choices would be "nearSide", "farSide", and "inside". The BindType would thus indicate the location of the call endpoint, with respect to VCL itself. With such choices, the examples above would have the following content: 1, 0, 33, AtmAddrA, nearSide 1, 0, 33, AtmAddrB, farSide 2, 0, 34, AtmAddrA, farSide 2, 0, 34, AtmAddrB, nearSide and 1, 0, 50, AtmAddrC, nearSide 1, 0, 50, AtmAddrD, inside Are these distinctions captured in other places in the MIBs? One might argue that the existence or non-existence of a cross-connect tells you the call terminates. Yes, but it doesn't tell which endpoints are inside the box...etc. Thanks for your feedback on this... ...Alan --- Alan D. Carwile | Direct Phone: 408 495-1637 Bay Networks, MS SC01-05 | Company Phone: 408 988-2400 4401 Great America Pkwy | Primary email: alan_carwile@BayNetworks.com Santa Clara, CA 95052 | (Note new direct phone number as of 9/3/96)   Received: from cnri by ietf.org id aa10931; 25 Oct 96 12:13 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa14230; 25 Oct 96 12:13 EDT Received: from lightning (lightning.BayNetworks.COM [134.177.3.18]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id LAA09000 for ; Fri, 25 Oct 1996 11:58:52 -0400 (EDT) Received: from ns1 by lightning (SMI-8.6/SMI-SVR4) id IAA03142; Fri, 25 Oct 1996 08:58:18 -0700 Received: from pobox by ns1 (SMI-8.6/SMI-SVR4) id IAA22739; Fri, 25 Oct 1996 08:58:16 -0700 Received: from [134.177.35.35] (acarwile-mac.corpwest.baynetworks.com [134.177.35.35]) by pobox (SMI-8.6/SMI-SVR4) with ESMTP id IAA12560; Fri, 25 Oct 1996 08:58:14 -0700 for X-Sender: acarwile@sc-mail1.corpwest.baynetworks.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Oct 1996 09:02:17 -0700 To: atommib@thumper.bellcore.com From: Alan Carwile Subject: atmConnCastType -- p2pRoot and p2pLeaf The AToM TC MIB defines the AtmConnCastType such that one cannot tell which endpoint initiated an SVC when the SVC is point-to-point. I'd suggest changes to distinguish owner (root) from the other (non-root) endpoint of a point-to-point call. Being able to tell which endpoint initiated a call is useful even in the point-to-point situation. The current definition is: AtmConnCastType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of topology of a connection (point- to-point, point-to-multipoint). In the case of point-to-multipoint, the orientation of this VPL or VCL in the connection. On a host: - p2mpRoot indicates that the host is the root of the p2mp connection. - p2mpLeaf indicates that the host is a leaf of the p2mp connection. On a switch: - p2mpRoot indicates that cells received by the switching fabric from the interface are from the root of the p2mp connection. - p2mpLeaf indicates that cells transmitted to the interface from the switching fabric are to the leaf of the p2mp connection." SYNTAX INTEGER { p2p(1), p2mpRoot(2), p2mpLeaf(3) } I'd propose replacing "p2p" with two enum's -- "p2pRoot" and "p2pOther" for the root and non-root endpoints of point-to-point calls. For a PVC situation, it might be that the root and non-root endpoints are not distinguished in any way. In that case, it might be necessary to have a choice which indicates 'don't know if root or not'. This might stay as "p2p" or get revised to "p2pAny". Thus I propose these enums: p2p -- don't know if ep is owner (root) or not. usually for a pvc ep. p2mpRoot -- current definition p2mpLeaf -- current definition + p2pRoot -- root of a p2p especially for svc, but potentially for pvc also. + p2pLeaf -- leaf of a p2p... Please respond back to the mailing list on this topic. Thanks...Alan --- Alan D. Carwile | Direct Phone: 408 495-1637 Bay Networks, MS SC01-05 | Company Phone: 408 988-2400 4401 Great America Pkwy | Primary email: alan_carwile@BayNetworks.com Santa Clara, CA 95052 | (Note new direct phone number as of 9/3/96)   Received: from cnri by ietf.org id aa17421; 25 Oct 96 15:48 EDT Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa20183; 25 Oct 96 15:48 EDT Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by thumper.bellcore.com (8.7.6/8.7.3) with ESMTP id OAA14936 for ; Fri, 25 Oct 1996 14:23:46 -0400 (EDT) Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id LAA13160; Fri, 25 Oct 1996 11:23:02 -0700 (PDT) From: "Michael H. Grobelch" Message-Id: <199610251823.LAA13160@hubbub.cisco.com> To: atommib@thumper.bellcore.com cc: Alan Carwile , grobelch@cisco.com Subject: Re: atmConnCastType -- p2pRoot and p2pLeaf In-reply-to: Your message of "Fri, 25 Oct 96 09:02:17 PDT." Date: Fri, 25 Oct 96 11:23:01 PDT Alan, I think that your proposal confuses the notion of the Root of a Point-to-multipoint connection, with the initiator of an SVC. AtmConnCastType differentiates among all VCs (permanent, switched, or soft). I believe that what you want can be provided by the proposed AtmConnKind defined in draft-ietf-atommib-atm2TC-04.txt, and used in draft-ietf-atommib-atm1ng-01.txt for objects atmVplConnKind and atmVclConnKind. Mike ---------------------------------------------------------- Michael Grobelch (grobelch@cisco.com) (408)-526-7348 SJ-G >Date: Fri, 25 Oct 1996 09:02:17 -0700 >To: atommib@thumper.bellcore.com >From: Alan Carwile >Subject: atmConnCastType -- p2pRoot and p2pLeaf >Content-Length: 2679 > >The AToM TC MIB defines the AtmConnCastType such that one cannot tell which >endpoint initiated an SVC when the SVC is point-to-point. I'd suggest >changes to distinguish owner (root) from the other (non-root) endpoint of a >point-to-point call. Being able to tell which endpoint initiated a call is >useful even in the point-to-point situation. > >The current definition is: > > AtmConnCastType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The type of topology of a connection (point- > to-point, point-to-multipoint). In the case > of point-to-multipoint, the orientation of > this VPL or VCL in the connection. > On a host: > - p2mpRoot indicates that the host > is the root of the p2mp connection. > - p2mpLeaf indicates that the host > is a leaf of the p2mp connection. > On a switch: > - p2mpRoot indicates that cells received > by the switching fabric from the interface > are from the root of the p2mp connection. > - p2mpLeaf indicates that cells transmitted > to the interface from the switching fabric > are to the leaf of the p2mp connection." > SYNTAX INTEGER { > p2p(1), > p2mpRoot(2), > p2mpLeaf(3) > } > > >I'd propose replacing "p2p" with two enum's -- "p2pRoot" and "p2pOther" for >the root and non-root endpoints of point-to-point calls. > >For a PVC situation, it might be that the root and non-root endpoints are >not distinguished in any way. In that case, it might be necessary to have >a choice which indicates 'don't know if root or not'. This might stay as >"p2p" or get revised to "p2pAny". > >Thus I propose these enums: > p2p -- don't know if ep is owner (root) or not. usually for a pvc ep. > p2mpRoot -- current definition > p2mpLeaf -- current definition >+ p2pRoot -- root of a p2p especially for svc, but potentially for pvc also. >+ p2pLeaf -- leaf of a p2p... > >Please respond back to the mailing list on this topic. >Thanks...Alan > >--- >Alan D. Carwile | Direct Phone: 408 495-1637 >Bay Networks, MS SC01-05 | Company Phone: 408 988-2400 >4401 Great America Pkwy | Primary email: alan_carwile@BayNetworks.com >Santa Clara, CA 95052 | (Note new direct phone number as of 9/3/96) > >   Received: from cnri by ietf.org id aa03809; 28 Oct 96 2:39 EST Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa03216; 28 Oct 96 2:39 EST Received: from madge.com (world.lannet.com [194.90.94.226]) by thumper.bellcore.com (8.7.6/8.7.3) with ESMTP id CAA00490 for ; Mon, 28 Oct 1996 02:20:30 -0500 (EST) Received: from moon.madge.com ([149.49.50.12]) by madge.com (8.7.5/8.7.3) with SMTP id JAA14125 for ; Mon, 28 Oct 1996 09:20:24 +0200 (IST) Received: from smtplink.madge.com by moon.madge.com (4.1/SMI-4.1) id AA05330; Mon, 28 Oct 96 09:20:14 IST Received: from Connect2 Message Router by smtplink.madge.com via Connect2-SMTP 4.00; Mon, 28 Oct 96 09:18:47 -0500 Message-Id: <7C6A743201660C00@smtplink.madge.com> In-Reply-To: Date: Mon, 28 Oct 96 9:18:41 +0200 From: Michele Hallak Bitton ESD-Tel Sender: Michele Hallak Bitton ESD-Tel Return-Receipt-To: Organization: LANNET LTD To: atommib@thumper.bellcore.com Subject: Re: local vs. remote in atmVclAddrBindTable X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Hi! I think that you don't have to implement this table for VP/VC crossconnected at the switch. This table is for VP/VC terminating at the switch/device. Regards Michele > Date: Fri, 25 Oct 1996 08:32:29 -0700 > To: atommib@thumper.bellcore.com > From: Alan Carwile > Subject: local vs. remote in atmVclAddrBindTable > > I'm confused over the interpretation of local vs. remote in > the > atmVclAddrBindTable. Please respond back to the mailing list regarding > the following examples and questions. > > 1) Given a switch with two ATM interfaces, suppose a VC comes from > AtmAddr=A, into if=1 with vpi:vci of 0:33, then cross-connects, and goes > out if=2 with vpi:vci of 0:34 toward AtmAddr=B. > > A ---0:33--- [(1) <-cc-> (2)] ---0:34--- B > > Will I see the following content? > > 1, 0, 33, AtmAddrA, remote > 1, 0, 33, AtmAddrB, remote > 2, 0, 34, AtmAddrA, remote > 2, 0, 34, AtmAddrB, remote > > or will I see the following content? > > 1, 0, 33, AtmAddrA, local > 1, 0, 33, AtmAddrB, remote > 2, 0, 34, AtmAddrA, remote > 2, 0, 34, AtmAddrB, local > > In other words, does local/remote refer to whether the AtmAddress is on > the > "local" side of the cross-connect? Or does it refer to whether it is > "inside" the same box (same agent's scope)? > > 2) As another example... > > C ---0:50--- [(1) --> D] > > Given a switch with local LEC (e.g., to reach the agent), and with a call > that terminates in this box... Suppose a VC comes in from AtmAddr=C into > if=1 with vpi:vci of 0:50, then terminates to AtmAddr=D inside the box. > Will I see the following content? > > 1, 0, 50, AtmAddrC, remote > 1, 0, 50, AtmAddrD, local > > As I look at this MIB table, I would like to see three choices instead of > the two choices (local vs. remote). Those choices would be > "nearSide", > "farSide", and "inside". The BindType would thus indicate the location of > the call endpoint, with respect to VCL itself. With such choices, the > examples above would have the following content: > > 1, 0, 33, AtmAddrA, nearSide > 1, 0, 33, AtmAddrB, farSide > 2, 0, 34, AtmAddrA, farSide > 2, 0, 34, AtmAddrB, nearSide > > and > > 1, 0, 50, AtmAddrC, nearSide > 1, 0, 50, AtmAddrD, inside > > Are these distinctions captured in other places in the MIBs? One might > argue that the existence or non-existence of a cross-connect tells you the > call terminates. Yes, but it doesn't tell which endpoints are inside > the > box...etc. > > Thanks for your feedback on this... > ...Alan > > --- > Alan D. Carwile | Direct Phone: 408 495-1637 > Bay Networks, MS SC01-05 | Company Phone: 408 988-2400 > 4401 Great America Pkwy | Primary email: alan_carwile@BayNetworks.com > Santa Clara, CA 95052 | (Note new direct phone number as of > 9/3/96) > > Michele Hallak Bitton, System Engineer MADGE Networks, ESD e-mail: mhallakb@madge.com voice: 972 3 6458354 fax: 972 3 6487146   Received: from cnri by ietf.org id aa08923; 29 Oct 96 15:46 EST Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa19242; 29 Oct 96 15:44 EST Received: from faline.bellcore.com (faline.bellcore.com [128.96.39.9]) by thumper.bellcore.com (8.7.6/8.7.3) with ESMTP id OAA20123 for ; Tue, 29 Oct 1996 14:59:18 -0500 (EST) Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by faline.bellcore.com (8.7.5/8.7.3) with SMTP id OAA01085 for ; Tue, 29 Oct 1996 14:20:20 -0500 (EST) Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA25437; Tue, 29 Oct 1996 14:24:03 -0500 Received: from by eve (4.1/4.7) id AB16069; Tue, 29 Oct 96 14:27:51 EST Date: Tue, 29 Oct 96 14:27:51 EST X-Station-Sent-From: eve.bellcore.com Message-Id: <9610291927.AB16069@eve> X-Sender: kaj@eve.bellcore.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_846631222==_" To: internet-drafts@CNRI.Reston.VA.US, atommib@thumper.bellcore.com From: Kaj Tesink Subject: Posting X-Attachments: C:\SOURCMIB\ATMTCMIB\IDOCT22.96\ATMTC.RFC; --=====================_846631222==_ Content-Type: text/plain; charset="us-ascii" Hi Cynthia, Please post the attached as Thanks, Kaj ------------------------------------------------- atommibbers, attached is the new version of the atmtc spec. some minor things have been done as per my previous email. i'd like to hear any final comments before submitting this to the NM-AD for processing as a Draft Standard. kaj --=====================_846631222==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ATMTC.RFC" Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management October 22, 1996 Michael Noto (editor) Bell Communications Research noto@cc.bellcore.com Kaj Tesink (editor) Bell Communications Research kaj@cc.bellcore.com 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 2. Introduction This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. This is done through Textual Conventions as defined in RFC1903[1]. It is the purpose of this document to define the set of textual conventions available to ATM MIB modules. When designing MIB modules, it is also often useful to register further properties with object identifier assignments so that they can be further used by other MIB modules. This is done through the OBJECT-IDENTITY macro defined in RFC1902[2]. This document defines OBJECT-IDENTITIES available to ATM MIB modules. Note that for organizational purposes OBJECT IDENTITIES previously defined in RFC1695 have been moved to this specification and no longer appear in the revision of RFC1695[14]. However, the original OBJECT IDENTIFIERs have been preserved. This memo does not specify a standard for the Internet community. Expires 4/22/97 [Page 2] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 3. Definitions ATM-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, Integer32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC mib-2 FROM RFC1213-MIB; atmTCMIB MODULE-IDENTITY LAST-UPDATED "9610220200Z" ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO " Michael Noto Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 908 758 5104 Fax: +1 908 758 4177 E-mail: noto@cc.bellcore.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 908 758 5254 Fax: +1 908 758 4177 E-mail: kaj@cc.bellcore.com" DESCRIPTION "This MIB Module provides Textual Conventions and OBJECT-IDENTITY Objects to be used by ATM systems." ::= { mib-2 37 3 } -- atmMIB 3 -- See [14]. -- The Textual Conventions defined below are organized -- alphabetically Expires 4/22/97 [Page 3] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 AtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The ATM address used by the network entity. The address types are: no address (0 octets), E.164 (8 octets), and NSAP (20 octets). Note: The E.164 address is encoded in BCD format." SYNTAX OCTET STRING (SIZE(0|8|20)) AtmConnCastType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of topology of a connection (point- to-point, point-to-multipoint). In the case of point-to-multipoint, the orientation of this VPL or VCL in the connection. On a host: - p2mpRoot indicates that the host is the root of the p2mp connection. - p2mpLeaf indicates that the host is a leaf of the p2mp connection. On a switch: - p2mpRoot indicates that cells received by the switching fabric from the interface are from the root of the p2mp connection. - p2mpLeaf indicates that cells transmitted to the interface from the switching fabric are to the leaf of the p2mp connection." SYNTAX INTEGER { p2p(1), p2mpRoot(2), p2mpLeaf(3) } AtmConnKind ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The use of call control. The use is as follows: pvc(1) Virtual link of a PVC. Should not be used in an PVC/SVC (i.e., SPVC) crossconnect. Expires 4/22/97 [Page 4] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 svcIncoming(2) Virtual link established after a received signaling request to setup an SVC. svcOutgoing(3) Virtual link established after a transmitted or forwarded signaling request to setup an SVC. spvcInitiator(4) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the initiator of the SPVC setup. spvcTarget(5) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the target of the SPVC setup. An spvcInitiator is always cross-connected to an svcOutgoing, and an spvcTarget is always cross-connected to an svcIncoming." SYNTAX INTEGER { pvc(1), svcIncoming(2), svcOutgoing(3), spvcInitiator(4), spvcTarget(5) } AtmServiceCategory ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The service category for a connection." REFERENCE "ATM Forum Traffic Management 4.0." SYNTAX INTEGER { other(1), -- none of the following cbr(2), -- constant bit rate rtVbr(3), -- real-time variable bit rate nrtVbr(4), -- non real-time variable bit rate abr(5), -- available bit rate ubr(6) -- unspecified bit rate } Expires 4/22/97 [Page 5] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 AtmSigDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies a row in the atmSigDescrParamTable. The value 0 signifies that none of the signalling parameters defined in the atmSigDescrParamTable are applicable." SYNTAX Integer32 AtmSignallingType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of signalling that is used for the identified interface and protocol suite. other: A signalling protocol other than those listed below. Auto-configuration: Indicates that the signalling protocol is to be or has yet to be determined. One such mechanism is via ATM Forum ILMI auto-configuration procedures. ATM Forum UNI 4.0: ATM Forum, Integrated Local Management Interface Specification Version 4.0, July 1996 [12]. ITU-T DSS2: - ITU-T Recommendation Q.2931, Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control (September 1994) [5] - ITU-T Draft Recommendation Q.2961, B-ISDN DSS 2 Support of Additional Traffic Parameters (May 1995) [8] NOTE: Update this reference when the draft matures - ITU-T Draft Recommendation Q.2971, B-ISDN DSS 2 User Network Interface Layer 3 Specification for Point-to-multipoint Call/connection Control (May 1995) [9] Expires 4/22/97 [Page 6] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 ATM Forum UNI 3.0: ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, (1994) [3]. ATM Forum UNI 3.1: ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, (November 1994) [4]. ATM Forum UNI 4.0: ATM Forum, ATM User-Network Interface, Version 4.0 (UNI 4.0) Specification, af-sig-0061.000 (June 1996) [7]. ATM Forum IISP (based on UNI 3.0 or UNI 3.1) : Interim Inter-switch Signaling Protocol (IISP)Specification, Version 1.0, af-pnni-0026.000, (December 1994) [10]. ATM Forum PNNI 1.0 : ATM Forum, Private Network-Network Interface Specification, Version 1.0, af-pnni-0055.000, (March 1996) [6]. ATM Forum B-ICI: ATM Forum, B-ICI Specification, Version 2.0, af-bici-0013.002, (November 1995) [11]." SYNTAX INTEGER { other(1), autoConfig(2), ituDss2(3), atmfUni3Dot0(4), atmfUni3Dot1(5), atmfUni4Dot0(6), atmfIispUni3Dot0(7), atmfIispUni3Dot1(8), atmfIispUni4Dot0(9), atmfPnni1Dot0(10), atmfBici2Dot0(11) } AtmTrafficDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies a row in the Expires 4/22/97 [Page 7] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 atmTrafficDescrParamTable. The value 0 signifies that no row has been identified." SYNTAX INTEGER (0..4294967295) AtmVcIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VCI value for a VCL. The maximum VCI value cannot exceed the value allowable by atmInterfaceMaxVciBits defined in ATM-MIB." SYNTAX INTEGER (0..65535) AtmVpIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VPI value for a VPL or VCL. The value VPI=0 is only allowed for a VCL. For ATM UNIs supporting VPCs the VPI value ranges from 1 to 255. For ATM UNIs supporting VCCs the VPI value ranges from 0 to 255. The maximum VPI value cannot exceed the value allowable by atmInterfaceMaxVpiBits defined in ATM-MIB." SYNTAX INTEGER (0..4095) AtmVorXAdminStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the desired administrative status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect." SYNTAX INTEGER { up(1), down(2) } AtmVorXLastChange ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of MIB II's sysUpTime at the time this virtual link or cross-connect entered its current operational state. If the current state was entered prior to the last re-initialization of the agent then this object contains a zero value." Expires 4/22/97 [Page 8] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 SYNTAX TimeTicks AtmVorXOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the operational status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect. The unknown state indicates that the state of it cannot be determined. The state will be down or unknown if the supporting ATM interface(s) is down or unknown respectively." SYNTAX INTEGER { up(1), down(2), unknown(3) } -- OBJECT-IDENTITIES: -- The following atmTrafficDescriptorTypes has been moved -- from [14]. atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1} -- atmMIBObjects -- See [14]. -- All other and new OBJECT IDENTITIES go here: atmObjectIdentities OBJECT IDENTIFIER ::= {atmTCMIB 1} -- The following values are defined for use as -- possible values of the ATM traffic descriptor type. atmNoTrafficDescriptor OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This identifies the no ATM traffic descriptor type. Parameters 1, 2, 3, 4, and 5 are not used. This traffic descriptor type can be used for best effort traffic." Expires 4/22/97 [Page 9] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 ::= {atmTrafficDescriptorTypes 1} atmNoClpNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the CBR.1 Conformance Definition [13] if Best Effort is No. Indicates the UBR.1 and UBR.2 Conformance Definitions [13] if Best Effort is Yes. This traffic descriptor is for no CLP and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Parameter 4: not used Parameter 5: not used. This traffic descriptor type can be used for best effort traffic." ::= {atmTrafficDescriptorTypes 2} atmClpNoTaggingNoScr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This traffic descriptor is for CLP without tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: peak cell rate in cells/second for CLP=0 traffic Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= {atmTrafficDescriptorTypes 3} atmClpTaggingNoScr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This traffic descriptor is for CLP with tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Expires 4/22/97 [Page 10] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 Parameter 2: peak cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= {atmTrafficDescriptorTypes 4} atmNoClpScr OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the VBR.1 Conformance Definition [13]. This traffic descriptor is for no CLP with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0+1 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used." ::= {atmTrafficDescriptorTypes 5} atmClpNoTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the VBR.2 Conformance Definition [13]. This traffic descriptor is for CLP with Sustained Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used." ::= {atmTrafficDescriptorTypes 6} atmClpTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the VBR.3 Conformance Definition [13]. This traffic descriptor is for CLP Expires 4/22/97 [Page 11] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 with tagging and Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used." ::= {atmTrafficDescriptorTypes 7} atmClpNoTaggingMCR OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the ABR Conformance Definition [13]. The use of the parameter vector for this type: Parameter 1: Peak Cell Rate (PCR) Parameter 2: CDVT (PCR) Parameter 3: Minimum Cell Rate (MCR) Parameter 4: unused Parameter 5: unused." ::= {atmTrafficDescriptorTypes 8} END Expires 4/22/97 [Page 12] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 4. Acknowledgments This document is a product of the AToMMIB Working Group. Expires 4/22/97 [Page 13] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 5. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [3] ATM Forum, "ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification", 1994. [4] ATM Forum, "ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification", November 1994. [5] ITU-T Recommendation Q.2931, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control", September 1994. [6] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (P-NNI 1.0)", af-pnni-0055.000, March 1996. [7] ATM Forum, "ATM User-Network Interface Signalling Specification, Version 4.0 (UNI 4.0)", af-sig-0061.000, June 1996. [8] ITU-T Draft Recommendation Q.2961, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) Support of Additional Traffic Parameters", May 1995. [9] ITU-T Draft Recommendation Q.2971, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User Network Interface Layer 3 Specification for Point-to-multipoint Expires 4/22/97 [Page 14] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 Call/connection Control", May 1995. [10] ATM Forum, "Interim Inter-switch Signaling Protocol (IISP)Specification, Version 1.0", af-pnni-0026.000, December 1994. [11] ATM Forum, "B-ICI Specification, Version 2.0", af-bici- 0013.002, November 1995. [12] ATM Forum, "Integrated Local Management Interface Specification, Version 4.0", af-ilmi-0065.000, July 1996. [13] ATM Forum, "Traffic Management Specification, Version 4.0", af-tm-0056.000, June 1996. [14] Kaj Tesink, "Definitions of Managed Objects for ATM Management", RFC???? (Internet-Draft ), Bellcore, October 1996. Expires 4/22/97 [Page 15] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 6. Security Considerations Security issues are not discussed in this memo. 7. Authors' Addresses Michael Noto Bell Communications Research Room 1E-348 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5104 EMail: noto@cc.bellcore.com Kaj Tesink Bell Communications Research Room 1A-427 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires 4/22/97 [Page 16] draft ATM Textual Conventions and OBJECT-IDENTITIES 10/22/96 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 3 Definitions ........................................... 3 4 Acknowledgments ....................................... 13 5 References ............................................ 14 6 Security Considerations ............................... 16 7 Authors' Addresses .................................... 16 Expires 4/22/97 [Page 17] --=====================_846631222==_ Content-Type: text/plain; charset="us-ascii" _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_846631222==_--   Received: from cnri by ietf.org id aa09635; 29 Oct 96 15:58 EST Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa19530; 29 Oct 96 15:53 EST Received: from faline.bellcore.com (faline.bellcore.com [128.96.39.9]) by thumper.bellcore.com (8.7.6/8.7.3) with ESMTP id PAA20355 for ; Tue, 29 Oct 1996 15:00:58 -0500 (EST) Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by faline.bellcore.com (8.7.5/8.7.3) with SMTP id OAA01080 for ; Tue, 29 Oct 1996 14:20:14 -0500 (EST) Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA25429; Tue, 29 Oct 1996 14:23:45 -0500 Received: from nv-ktesink.cc.bellcore.com by eve (4.1/4.7) id AA16069; Tue, 29 Oct 96 14:27:26 EST Date: Tue, 29 Oct 96 14:27:25 EST X-Station-Sent-From: eve.bellcore.com Message-Id: <9610291927.AA16069@eve> X-Sender: kaj@eve.bellcore.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_846631197==_" To: internet-drafts@CNRI.Reston.VA.US, atommib@thumper.bellcore.com From: Kaj Tesink Subject: Posting X-Attachments: C:\SOURCMIB\SONET.SRC\IDAUG26.96\SONETNG.RFC; --=====================_846631197==_ Content-Type: text/plain; charset="us-ascii" Hi Cynthia, please post the attached as thanks, kaj ------------------------------------------------- atommibbers, attached is the new version of the 1595ng spec. the only changes are the typos pointed out by /cmh plus another typo that i spotted. since i havent heard any more comments i'll assume that this can be send to the NM_AD for processing as a Draft Standard. i'll synchronize with the other trunk mibs. kaj --=====================_846631197==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="SONETNG.RFC" Internet Draft SONET/SDH Objects August 26, 1996 Definitions of Managed Objects for the SONET/SDH Interface Type August 26, 1996 AToM MIB Working Group Kaj Tesink Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 kaj@cc.bellcore.com 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this document is unlimited. Expires 2/26/97 [Page 1] Internet Draft SONET/SDH Objects August 26, 1996 2. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407 [13]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Expires 2/26/97 [Page 2] Internet Draft SONET/SDH Objects August 26, 1996 3. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: 0 RFC 1902 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. 0 RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. 0 RFC 1157 and RFC 1905 which define two versions of the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Expires 2/26/97 [Page 3] Internet Draft SONET/SDH Objects August 26, 1996 4. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI RFC 1902 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions Section 6 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in the SNMPv2 SMI. Expires 2/26/97 [Page 4] Internet Draft SONET/SDH Objects August 26, 1996 5. Overview These objects are used when the particular media being used to realize an interface is a SONET/SDH interface. At present, this applies to these values of the ifType variable in the Internet-standard MIB: sonet (39), sonetPath (50), sonetVT (51) The definitions contained herein are based on the SONET/SDH specifications in ANSI T1.105 and T1.106-1988 [9, 9a, 10] and CCITT G.707, 708, 709, and G.783 [15-18]. 5.1. Use of the ifTable This section specifies how the MIB II interfaces group, as defined in [12], is used for SONET/SDH interfaces. The SONET/SDH layers support several multiplexing possibilities. For example in SONET, an Synchronous Transport Signal 3 (STS- 3) has 3 SONET Paths, and a STS-3c has 1 SONET Path. Another example could be a STS-12 having 4 SONET STS-3c Paths. Similarly, a SONET Synchronous Payload Envelope (SPE) can carry many Virtual Tributaries (VTs), for example, one SONET SPE can carry 28 VT1.5s. It is important to note that an SPE and a VT in SONET is collectively referred to as a Virtual Container (VC) in SDH. Also, an STS is called Synchronous Transport Module (STM) in SDH. Not all SONET/SDH equipment terminate all SONET/SDH layers. For example, an SONET/SDH STE regenerator terminates SONET/SDH Sections only, and is transparent for all layers above that. SONET/SDH Add-Drop multiplexers and Digital Cross Connect Systems terminate SONET/SDH Lines. SONET/SDH Terminal Multiplexers may also terminate SONET/SDH Paths and VTs/VCs. MIB II [6], as extended by [12], accommodates these cases by appropriate use of the MIB II system group, and the interfaces group. The system group can name and describe the type of managed resource. The interfaces group defines which SONET/SDH layers apply, how these layers are configured and multiplexed. This is achieved by proper representation of SONET/SDH Layers by ifEntries as defined in [12], as follows: Expires 2/26/97 [Page 5] Internet Draft SONET/SDH Objects August 26, 1996 _____________________________ | | | | > | | | | | | VT 1 |..........|VT K| > K ifEntries | | | | | |_____________|__________|____| > | | | | > | | | | | | Path 1 |......|Path L| > L ifEntries | | | | | |_______________|______|______| > | | > | | | | Line | | | | | |_____________________________| | | | | | | | | Section Layer | > 1 ifEntry | | | |_____________________________| | | | | | | | | Physical Medium Layer | | | | | |_____________________________| > Use of ifTable for a SONET/SDH port The exact configuration and multiplexing of the layers is maintained in the ifStackTable [12]. 5.2. Use of ifTable for SONET/SDH Medium/Section/Line Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for combined SONET/SDH Medium/Section/Line Layer ====================================================================== ifIndex Interface index. ifDescr SONET/SDH Medium/Section/Line ifType sonet(39) Expires 2/26/97 [Page 6] Internet Draft SONET/SDH Objects August 26, 1996 ifSpeed Speed of line rate for SONET/SDH, (e.g., 155520000 bps). ifPhysAddress The value of the Circuit Identifier. If no Circuit Identifier has been assigned this object should have an octet string with zero length. ifAdminStatus Supports read-only access. The desired administrative status of the interface. ifOperStatus The value testing(3) is not used. This object assumes the value down(2), if the objects sonetSectionCurrentStatus and sonetLineCurrentStatus have any other value than sonetSectionNoDefect(1) and sonetLineNoDefect(1), respectively. ifLastChange sysUpTime at the last change in ifOperStatus. ifName Textual name of the interface or an OCTET STRING of zero length. ifLinkUpDownTrapEnable Set to enabled(1). Supports read-only access. ifHighSpeed Speed of line in Mega-bits per second (e.g., 155 Mbps) ifConnectorPresent Set to true(1). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. 5.3. Use of ifTable for SONET/SDH Paths Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for SONET/SDH Paths ========================================= ifIndex Interface index. ifDescr SONET/SDH Path ifType sonetPath(50) Expires 2/26/97 [Page 7] Internet Draft SONET/SDH Objects August 26, 1996 ifSpeed set to speed of SONET/SDH path (e.g., an STS-1 path has a rate of 50112000 bps.) ifPhysAddress Circuit Identifier or OCTET STRING of zero length. ifAdminStatus Supports read-only access. The desired administrative status of the interface. ifOperStatus This object assumes the value down(2), if the object sonetPathCurrentStatus has any other value than sonetPathNoDefect(1). ifLastChange sysUpTime at the last change in ifOperStatus. ifName Textual name of the interface or an OCTET STRING of zero length. ifLinkUpDownTrapEnable Default value is disabled(2). Just read-only access may be supported. ifHighSpeed Set to rate of SONET/SDH path in Mega-bits per second. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. 5.4. Use of ifTable for SONET/SDH VTs/VCs Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for SONET/SDH VTs/VCs =========================================== ifIndex Interface index. ifDescr SONET/SDH VT/VC ifType sonetVT(51) ifSpeed Set to speed of VT/VC (e.g., a VT1.5 has a rate of 1728000 bps.) Expires 2/26/97 [Page 8] Internet Draft SONET/SDH Objects August 26, 1996 ifPhysAddress Circuit Identifier or OCTET STRING of zero length. ifAdminStatus Supports read-only access. The desired administrative status of the interface. ifOperStatus This object assumes the value down(2), if the object sonetVTCurrentStatus has any other value than sonetVTNoDefect(1). ifLastChange sysUpTime at the last change in ifOperStatus. ifName Textual name of the interface or an OCTET STRING of zero length. ifLinkUpDownTrapEnable Default value is disabled(2). Just read-only access may be supported. ifHighSpeed Set to rate of VT in Mega-bits per second. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. 5.5. SONET/SDH Terminology The terminology used in this document to describe error conditions on a SONET circuit as monitored by a SONET system are from the T1.231 [20]. The terminology used in this document to describe error conditions on a SDH circuit as monitored by a SDH system are from the CCITT G.783 [18]. Only the SONET Performance Monitoring terminology is defined in this document. The definitions for SDH Performance Monitoring terms are similar but not identical, and they can be found in [18]. If the definition in this document does not match the definition in the T1.231 document, the implementer should follow the definition described in this document. In some cases other or additional references are used as compared with the ones cited above. This will be indicated in the text. Section Loss Of Frame Failure (Out of Frame Event, Severely Errored Frame Defect) An Out of Frame (OOF) event (or Severely Errored Frame defect) is the occurrence of four contiguous errored Expires 2/26/97 [Page 9] Internet Draft SONET/SDH Objects August 26, 1996 frame alignment words. A frame alignment work occupies the A1 and A2 bytes of an STS frame, and is defined in T1.105. The SEF defect is terminated when two contiguous error-free frame words are detected. Any implementation of the frame recovery circuitry which achieves realignment following an OOF within the 250 microsecond (two frames) interval implied by this definition is acceptable. An Loss of Frame (LOF) defect is declared when an OOF/SEF defect persists for a period of 3 milliseconds. The LOF defect is terminated when the incoming signal remains continuously in-frame for a period of 1 ms to 3 ms. An LOF failure is declared when the LOF defect persists for a period of 2.5 +/- 0.5 seconds, except when an LOS defect or failure is present. The LOF failure is cleared when the LOS failure is declared, or when the LOF defect is absent for 10 +/- 0.5 seconds. Loss of Signal The Loss of Signal (LOS) defect is declared when no transitions are detected on the incoming signal (before descrambling). The LOS defect is detected upon observing 2.3 to 100 microseconds of no transitions. The LOS defect is cleared after a 125 microsecond interval (one frame) during which no LOS defect is detected. The LOS failure is declared when the LOS defect persists for a period of 2.5 +/- 0.5 seconds, or if LOS defect is present when the criteria for LOF failure declaration have been met. The LOS failure is cleared when the LOS defect is absent for a period of 10 +/- 0.5 seconds. Declaration of LOS failure clears any existing LOF failure. Clearing the LOS failure allows immediate declaration of the LOF failure if conditions warrant. STS-Path Loss of Pointer An Loss of Pointer (LOP) defect is declared when either a valid pointer is not detected in eight consecutive frames, or when eight consecutive frames are detected with the New Data Flag (NDF) set to "1001" without a valid concatenation indicator (see ANSI T1.105). A LOP defect is terminated when either a valid pointer with a normal NDF set to "0110", or a valid concatenation Expires 2/26/97 [Page 10] Internet Draft SONET/SDH Objects August 26, 1996 indicator is detected for three contiguous frames. Incoming STS-Path AIS shall not result in the declaration of a LOP defect. A STS-Path LOP failure is declared when the STS-Path LOP defect persists for a period of 2.5 +/- 0.5 seconds. A STS-Path LOP failure is cleared when the STS-Path LOP defect is absent for 10 +/- 0.5 seconds. VT Loss of Pointer A VT LOP defect is declared when either a valid pointer is not detected in eight consecutive VT superframes, or when eight consecutive VT superframes are detected with the NDF set to "1001" without a valid concatenation indicator. A VT LOP defect is terminated when either a valid pointer with a normal NDF set to "0110", or a valid concatenation indicator is detected for three contiguous VT superframes. Incoming VT-Path AIS shall not result in declaring a VT LOP defect. A VT LOP failure is declared when the VT LOP defect persists for 2.5 +/- 0.5 seconds. A VT LOP failure is cleared when the VT LOP defect is absent for 10 +/- 0.5 seconds. Line Alarm Indication Signal A Line Alarm Indication Signal (L-AIS) is defined in ANSI T1.105. The following criteria are specific to the L-AIS defect: -- Line AIS defect is detected as a "111" pattern in bits 6, 7, and 8 of the K2 byte in five consecutive frames. -- Line AIS defect is terminated when bits 6, 7, and 8 of the K2 byte do not contain the code "111" for five consecutive frames. A Line AIS failure is declared when the Line AIS defect persists for a period of 20.5 +/- 0.5 seconds. A Line AIS failure is cleared when the Line AIS defect is absent for 10 +/- 0.5 seconds. STS-Path Alarm Indication Signal The STS-Path Alarm Indication Signal (AIS) is defined in Expires 2/26/97 [Page 11] Internet Draft SONET/SDH Objects August 26, 1996 ANSI T1.105 as all ones in bytes H1, H2, and H3 as well as all ones in the entire STS SPE. The following criteria are specific to the STS-Path AIS defect: -- STS-Path AIS defect is detected as all ones in bytes H1 and H2 in three contiguous frames. -- The STS-Path AIS defect is terminated when a valid STS Pointer is detected with the NDF set to "1001" (inverted) for one frame, or "0110" (normal) for three contiguous frames. A STS-Path AIS failure is declared when the STS-Path AIS defect persists for 2.5 +/- 0.5 seconds. A STS-Path AIS failure is cleared when the STS-Path AIS defect is absent for 10 +/- 0.5 seconds. VT-Path Alarm Indication Signal The VT-Path Alarm Indication Signal (AIS) is only applicable for VTs in the floating mode of operation. VT-Path AIS is used to alert the downstream VT Path Terminating Entity (PTE) of an upstream failure. Upon detection of a failure, Line AIS, or STS-Path AIS, an STS PTE will generate downstream VT-Path AIS if the STS Synchronous Payload Envelope (SPE) is carrying floating VTs. VT-Path AIS is specified in ANSI T1.105 as all ones in bytes V1, V2, V3, and V4, as well as all ones in the entire VT SPE. The following criteria are specific to VT-Path AIS defect: -- VT-Path AIS defect is detected by a VT PTE as all ones in bytes V1 and V2 in three contiguous VT superframes. -- VT-Path AIS defect is terminated when valid VT pointer with a valid VT size is detected with the NDF set to "1001" (inverted) for one VT superframe, or "0110" (normal) for three contiguous VT superframes are detected. A VT-Path AIS failure is declared when the VT-Path AIS defect persists for 2.5 +/- 0.5 seconds. A VT-Path AIS failure is cleared when the VT-Path AIS defect is absent for 10 +/- 0.5 seconds. Expires 2/26/97 [Page 12] Internet Draft SONET/SDH Objects August 26, 1996 Line Remote Defect Indication Line Remote Defect Indication (RDI) (aka Line FERF) signal is the occurrence of a "110" pattern in bit positions 6, 7, and 8 of the K2 byte in STS-1 #1 of the STS-N signal. Line RDI is defined in ANSI T1.105. The following criteria are specific to Line RDI defect: -- Line RDI defect is a "110" code in bits 6, 7, and 8 of the K2 byte of in STS-1 #1 in five consecutive frames. -- Line RDI defect is terminated when any code other than "110" is detected in bits 6, 7, and 8 of the K2 byte in five consecutive frames. A Line Remote Failure Indication (RFI) failure is declared when the incoming Line RDI defects lasts for 2.5 +/- 0.5 seconds. The Line RFI failure is cleared when no Line RDI defects are detected for 10 +/- 0.5 seconds. STS-Path Remote Defect Indication STS-Path RDI (aka STS-Path FERF) signal shall be generated within 100 milliseconds by the STS PTE upon detection of an AIS or LOP defect. Transmission of the STS-Path RDI signal shall cease within 100 milliseconds when the STS PTE no longer detects STS-Path AIS or STS- Path LOP defect. The STS-Path RDI shall accurately report the presence or absence of STS-Path AIS or STS- Path LOP defects. STS-Path RDI defect is defined in ANSI T1.105. The following requirements are specific to the STS-Path RDI defect: -- STS-Path RDI is detected by all STS PTEs. STS-Path RDI is detected by the upstream STS PTE as a "1" in bit five of the Path Status byte (G1) for five contiguous frames. -- Removal of STS-Path Remote Defect Indication is detected by a "0" in bit 5 of the G1 byte in five contiguous frames. A STS-Path Remote Failure Indication (RFI) failure is declared when the incoming STS-Path RDI defects lasts for 2.5 +/- 0.5 seconds. The STS-Path RFI failure is cleared when no STS-Path RDI defects are detected for 10 +/- 0.5 seconds. Expires 2/26/97 [Page 13] Internet Draft SONET/SDH Objects August 26, 1996 VT-Path Remote Defect Indication VT Path RDI (aka VT Path FERF) signal shall be generated within 100 milliseconds by the VT PTE upon detection of a VT-Path AIS or LOP defect. Transmission of the VT-Path RDI signal shall cease within 100 milliseconds when the VT PTE no longer detects VT-Path AIS or VT-Path LOP defect. The VT-Path RDI shall accurately report the presence or absence of VT-Path AIS or VT-Path LOP defects. VT-Path RDI defect is defined in ANSI T1.105. The following requirements are specific to VT-Path RDI defect: -- VT-Path RDI defect is the occurrence of a "1" in bit 4 of the VT-Path Overhead byte (V5) in five contiguous frames. -- VT-Path RDI defect is terminated when a "0" is detected in bit 4 of the VT-Path Overhead byte (V5) for five contiguous frames. A VT-Path Remote Failure Indication (RFI) (derived) failure is declared when the incoming VT-Path RDI defects lasts for 2.5 +/- 0.5 seconds. The VT-Path RFI failure is cleared when no VT-Path RDI defects are detected for 10 +/- 0.5 seconds. VT-Path Remote Failure Indication The VT-Path RFI signal is only required for the case of byte synch mapped DS1s where the DS1 frame bit is not mapped. The VT-Path RFI is specified in ANSI T1.105, where it is currently called VT path yellow. When provided, the VT-Path RFI signal is used to indicate the occurrence of far-end failures. When the VT-Path RFI is not provided, far-end failures are derived from local timing of the VT-Path RDI defect. The VT-Path RFI failure is declared within 5 ms of detecting the incoming VT-Path RFI Signal. The VT-Path Remote Failure Indication (RFI) failure is cleared within 50 ms of detecting the removal of the incoming VT-Path RFI signal. Coding Violation Coding Violations (CV) are Bit Interleaved Parity (BIP) errors that are detected in the incoming signal. CV counters are incremented for each BIP error detected. That is, each BIP-8 can detect up to eight errors per Expires 2/26/97 [Page 14] Internet Draft SONET/SDH Objects August 26, 1996 STS-N frame, with each error incrementing the CV counter. Section CVs shall be collected using the BIP-8 in the B1 byte located in the Section Overhead of STS-1 #1. Line CVs shall be collected using the BIP-8s in B2 bytes located in the Line Overhead of each STS-1 (since all CVs on an STS-N line are counted together, this is equivalent to counting each error in the BIP-8*N contained in the B2 bytes of the STS-N Line Overhead). Thus, on an STS-N signal, up to 8 x N CVs may occur in each frame. Path CVs shall be collected using the BIP-8 in the B3 byte of the STS-Path Overhead of the STS SPE. VT CVs shall be collected using the BIP-2 in the V5 overhead byte of the floating VT. Errored Seconds At each layer, an Errored Second (ES) is a second with one or more Coding Violations at that layer OR one or more incoming defects (e.g., SEF, LOS, AIS, LOP) at that layer has occurred. Severely Errored Seconds According to [11, 20, 21, 23] at each layer, an Severely Errored Second (SES) is a second with x or more CVs at that layer, or a second during which at least one or more incoming defects at that layer has occurred. The values of x in RFC1595[19] were based on [11] and [21] (see Appendix B). These values have subsequently been relaxed in [20, 23]. In addition, according to G.826 [22] SESs are measured as a percentage of errored blocks. To deal with these sets of definitions this memo defines an object sonetSESThresholdSet that determines the correct interpretation of SES. For backward compatibility, if this object is not implemented the interpretation of Appendix B shall apply. Otherwise, a more recent interpretation is suggested. An agent is not required to support all sets of definitions. Note that if a manager changes the value of this object all SES statistics collected prior to this change shall be invalidated. Severely Errored Framing Seconds A Severely Errored Framing Second (SEFS) is a seconds with containing one or more SEF events. This counter is Expires 2/26/97 [Page 15] Internet Draft SONET/SDH Objects August 26, 1996 only counted at the Section Layer. Unavailable Seconds At the Line, Path, and VT layers, an unavailable second is calculated by counting the number of seconds that the interface is unavailable. At each layer, the SONET/SDH interface is said to be unavailable at the onset of 10 contiguous SESs. The 10 SESs are included in unavailable time. Once unavailable, the SONET/SDH interface becomes available at the onset of 10 contiguous seconds with no SESs. The 10 seconds with no SESs are excluded from unavailable time. With respect to the SONET/SDH error counts at each layer, all counters at that layer are incremented while the SONET/SDH interface is deemed available at that layer. While the interface is deemed unavailable at that layer, the only count that is incremented is UASs at that layer. Note that this definition implies that the agent cannot determine until after a ten second interval has passed whether a given one-second interval belongs to available or unavailable time. If the agent chooses to update the various performance statistics in real time then it must be prepared to retroactively reduce the ES, SES, and SEFS counts by 10 and increase the UAS count by 10 when it determines that available time has been entered. It must also be prepared to reduce the CV count by the number of violations counted since the onset of unavailable time. The agent must be similarly prepared to retroactively decrease the UAS count by 10 and increase the ES and CV counts as necessary upon entering available time. A special case exists when the 10 second period leading to available or unavailable time crosses a 900 second statistics window boundary, as the foregoing description implies that the CV, ES, SES, SEFS, and UAS counts the PREVIOUS interval must be adjusted. In this case successive GETs of the affected sonetPathIntervalSES and sonetPathIntervalUAS objects (and the analogous Line and VT objects also) objects will return differing values if the first GET occurs during the first few seconds of the window. According to ANSI T1.231 unavailable time begins at the _onset_ of 10 contiguous severely errored seconds -- that is, unavailable time starts with the _first_ of the 10 Expires 2/26/97 [Page 16] Internet Draft SONET/SDH Objects August 26, 1996 contiguous SESs. Also, while an interface is deemed unavailable all counters for that interface are frozen except for the UAS count. It follows that an implementation which strictly complies with this standard must _not_ increment any counters other than the UAS count -- even temporarily -- as a result of anything that happens during those 10 seconds. Since changes in the signal state lag the data to which they apply by 10 seconds, an ANSI-compliant implementation must pass the one-second statistics through a 10-second delay line prior to updating any counters. That can be done by performing the following steps at the end of each one second interval. i) Read near/far end CV counter and alarm status flags from the hardware. ii) Accumulate the CV counts for the preceding second and compare them to the ES and SES threshold for the layer in question. Update the signal state and shift the one- second CV counts and ES/SES flags into the 10-element delay line. Note that far-end one-second statistics are to be flagged as "absent" during any second in which there is an incoming defect at the layer in question or at any lower layer. iii) Update the current interval statistics using the signal state from the _previous_ update cycle and the one-second CV counts and ES/SES flags shifted out of the 10-element delay line. This approach is further described in Appendix A. An agent may choose to use this approach in lieu of retroactive adjustments to the counters. In any case, a linkDown trap shall be sent only after the agent has determined for certain that the unavailable state has been entered, but the time on the trap will be that of the first UAS (i.e., 10 seconds earlier). A linkUp trap shall be handled similarly. Unequipped If a Path or VT connection is not provisioned (idle) the SONET equipment will signal this state by transmitting the Path or VT Signal Label as follows: Expires 2/26/97 [Page 17] Internet Draft SONET/SDH Objects August 26, 1996 - byte C2 of the STS Path Overhead equal to 0 for an unequipped Path, - byte V5 of the VT Path Overhead equal to 0 for an unequipped VT. Signal Label Mismatch A Path or VT connection is not correctly provisioned if a received Path or VT Signal Label mismatch occurs. A received Signal Label is considered mismatched if it does not equal either the locally provisioned value or the value 'equipped non-specific' (1 hex). Note that any received non-zero Signal Label is considered a locally provisioned value of 'equipped non-specific'. Only in- service, provisioned Path Terminating equipment can detect mismatched Signal labels. It is considered provisioned if it has been configured for a mapping and has been assigned signals to and from which the mapping takes place. While a Path is unequipped or has mismatched signal labels ES/SES counts continue, but these conditions do not themselves contribute to ES/SES. Circuit Identifier This is a character string specified by the circuit vendor, and is useful when communicating with the vendor during the troubleshooting process. Expires 2/26/97 [Page 18] Internet Draft SONET/SDH Objects August 26, 1996 6. Object Definitions SONET-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32 FROM SNMPv2-SMI DisplayString, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, transmission FROM RFC1213-MIB PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB; -- This is the MIB module for the SONET/SDH Interface objects. sonetMIB MODULE-IDENTITY LAST-UPDATED "9608260000Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO "Kaj Tesink Bell Communications Research Tel: (908) 758-5254 Fax: (908) 758-4196 E-mail: kaj@cc.bellcore.com." DESCRIPTION "The MIB module to describe SONET/SDH interfaces objects." ::= { transmission 39 } -- This is the MIB module for the SONET/SDH objects sonetObjects OBJECT IDENTIFIER ::= { sonetMIB 1 } sonetObjectsPath OBJECT IDENTIFIER ::= { sonetMIB 2 } sonetObjectsVT OBJECT IDENTIFIER ::= { sonetMIB 3 } Expires 2/26/97 [Page 19] Internet Draft SONET/SDH Objects August 26, 1996 -- groups in the SONET/SDH MIB module sonetMedium OBJECT IDENTIFIER ::= { sonetObjects 1 } sonetSection OBJECT IDENTIFIER ::= { sonetObjects 2 } sonetLine OBJECT IDENTIFIER ::= { sonetObjects 3 } sonetFarEndLine OBJECT IDENTIFIER ::= { sonetObjects 4 } sonetPath OBJECT IDENTIFIER ::= { sonetObjectsPath 1 } sonetFarEndPath OBJECT IDENTIFIER ::= { sonetObjectsPath 2 } sonetVT OBJECT IDENTIFIER ::= { sonetObjectsVT 1 } sonetFarEndVT OBJECT IDENTIFIER ::= { sonetObjectsVT 2 } Expires 2/26/97 [Page 20] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Medium group -- SONET/SDH interfaces for some applications may be electrical -- interfaces and not optical interfaces. This group handles -- the configuration information for both optical SONET/SDH -- interfaces -- and electrical SONET/SDH interfaces. sonetMediumTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetMediumEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Medium table." ::= { sonetMedium 1 } sonetMediumEntry OBJECT-TYPE SYNTAX SonetMediumEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Medium table." INDEX { ifIndex } ::= { sonetMediumTable 1 } SonetMediumEntry ::= SEQUENCE { sonetMediumType INTEGER, sonetMediumTimeElapsed Integer32, sonetMediumValidIntervals Integer32, sonetMediumLineCoding INTEGER, sonetMediumLineType INTEGER, sonetMediumCircuitIdentifier DisplayString, sonetMediumInvalidIntervals Integer32, sonetMediumLoopbackConfig BITS } sonetMediumType OBJECT-TYPE SYNTAX INTEGER { sonet(1), sdh(2) } MAX-ACCESS read-only STATUS current Expires 2/26/97 [Page 21] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "This variable identifies whether a SONET or a SDH signal is used across this interface." ::= { sonetMediumEntry 1 } sonetMediumTimeElapsed OBJECT-TYPE SYNTAX Integer32 (1..900) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds, including partial seconds, that have elapsed since the beginning of the current error-measurement period." ::= { sonetMediumEntry 2 } sonetMediumValidIntervals OBJECT-TYPE SYNTAX Integer32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous intervals for which valid data has been stored. A SONET interface must be capable of supporting at least n intervals. The minimum value of n is 4. The default of n is 32. The maximum value of n is 96. The value of this object will be n unless the device was brought online within the last (nx15) minutes, in which case the value will be the number of complete 15 minute intervals the device has been online. In the case where the agent is a proxy, it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which valid data is available." ::= { sonetMediumEntry 3 } sonetMediumLineCoding OBJECT-TYPE SYNTAX INTEGER { sonetMediumOther(1), sonetMediumB3ZS(2), sonetMediumCMI(3), sonetMediumNRZ(4), sonetMediumRZ(5) } Expires 2/26/97 [Page 22] Internet Draft SONET/SDH Objects August 26, 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable describes the line coding for this interface. The B3ZS and CMI are used for electrical SONET/SDH signals (STS-1 and STS-3). The Non-Return to Zero (NRZ) and the Return to Zero are used for optical SONET/SDH signals." ::= { sonetMediumEntry 4 } sonetMediumLineType OBJECT-TYPE SYNTAX INTEGER { sonetOther(1), sonetShortSingleMode(2), sonetLongSingleMode(3), sonetMultiMode(4), sonetCoax(5), sonetUTP(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable describes the line type for this interface. The line types are Short and Long Range Single Mode fiber or Multi-Mode fiber interfaces, and coax and UTP for electrical interfaces. The value sonetOther should be used when the Line Type is not one of the listed values." ::= { sonetMediumEntry 5 } sonetMediumCircuitIdentifier OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This variable contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting. Note that the circuit identifier, if available, is also represented by ifPhysAddress." ::= { sonetMediumEntry 6 } sonetMediumInvalidIntervals OBJECT-TYPE SYNTAX Integer32 (0..96) Expires 2/26/97 [Page 23] Internet Draft SONET/SDH Objects August 26, 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals for which no valid data is available. This includes intervals of which valid data has been lost, e.g., due to restart of the agent." ::= { sonetMediumEntry 7 } sonetMediumLoopbackConfig OBJECT-TYPE SYNTAX BITS { sonetNoLoop(0), sonetFacilityLoop(1), sonetTerminalLoop(2), sonetOtherLoop(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current loopback state of the SONET/SDH interface. The values mean: sonetNoLoop Not in the loopback state. A device that is not capable of performing a loopback on this interface shall always return this value. sonetFacilityLoop The received signal at this interface is looped back out through the corresponding transmitter in the return direction. sonetTerminalLoop The signal that is about to be transmitted is connected to the associated incoming receiver. sonetOtherLoop Loopbacks that are not defined here." ::= { sonetMediumEntry 8 } sonetSESthresholdSet OBJECT-TYPE SYNTAX INTEGER { other(1), bellcore1991(2), ansi1993(3), Expires 2/26/97 [Page 24] Internet Draft SONET/SDH Objects August 26, 1996 itu1995(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "An enumerated integer indicating which recognized set of SES thresholds that the agent uses for determining severely errored seconds and unavailable time. other(1) None of the following. bellcore1991(2) Bellcore TR-NWT-000253, 1991 [21], or ANSI T1M1.3/93-005R2, 1993 [11]. See also Appendix B. ansi1993(3) ANSI T1.231, 1993 [20], or Bellcore GR-253-CORE, Issue 2, 1995 [23] itu1995(4) ITU Recommendation G.826, 1995 [22]. If a manager changes the value of this object then the SES statistics collected prior to this change must be invalidated." ::= { sonetMedium 2 } Expires 2/26/97 [Page 25] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Section group -- this group consists of 2 tables: -- - the SONET/SDH Section Current Table -- - the SONET/SDH Section Interval Table -- the SONET/SDH Section Current Table -- The SONET/SDH Section -- current table contains various statistics -- being collected for the current 15 minute interval. sonetSectionCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetSectionCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Section Current table." ::= { sonetSection 1 } sonetSectionCurrentEntry OBJECT-TYPE SYNTAX SonetSectionCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Section Current table." INDEX { ifIndex } ::= { sonetSectionCurrentTable 1 } SonetSectionCurrentEntry ::= SEQUENCE { sonetSectionCurrentStatus Integer32, sonetSectionCurrentESs PerfCurrentCount, sonetSectionCurrentSESs PerfCurrentCount, sonetSectionCurrentSEFSs PerfCurrentCount, sonetSectionCurrentCVs PerfCurrentCount } sonetSectionCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..6) MAX-ACCESS read-only STATUS current Expires 2/26/97 [Page 26] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "This variable indicates the status of the interface. The sonetSectionCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously. The sonetSectionNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetSectionNoDefect 2 sonetSectionLOS 4 sonetSectionLOF" ::= { sonetSectionCurrentEntry 1 } sonetSectionCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 2 } sonetSectionCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 3 } sonetSectionCurrentSEFSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Expires 2/26/97 [Page 27] Internet Draft SONET/SDH Objects August 26, 1996 Severely Errored Framing Seconds encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 4 } sonetSectionCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 5 } Expires 2/26/97 [Page 28] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Section Interval Table -- The SONET/SDH Section Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetSectionIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetSectionIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Section Interval table." ::= { sonetSection 2 } sonetSectionIntervalEntry OBJECT-TYPE SYNTAX SonetSectionIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Section Interval table." INDEX { ifIndex, sonetSectionIntervalNumber } ::= { sonetSectionIntervalTable 1 } SonetSectionIntervalEntry ::= SEQUENCE { sonetSectionIntervalNumber Integer32, sonetSectionIntervalESs PerfIntervalCount, sonetSectionIntervalSESs PerfIntervalCount, sonetSectionIntervalSEFSs PerfIntervalCount, sonetSectionIntervalCVs PerfIntervalCount, sonetSectionIntervalValidData TruthValue } sonetSectionIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current Expires 2/26/97 [Page 29] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetSectionIntervalEntry 1 } sonetSectionIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 2 } sonetSectionIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 3 } sonetSectionIntervalSEFSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." Expires 2/26/97 [Page 30] Internet Draft SONET/SDH Objects August 26, 1996 ::= { sonetSectionIntervalEntry 4 } sonetSectionIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 5 } sonetSectionIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetSectionIntervalEntry 6 } Expires 2/26/97 [Page 31] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Line group -- this group consists of 2 tables: -- - the SONET/SDH Line Current Table -- - the SONET/SDH Line Interval Table -- the SONET/SDH Line Current Table -- The SONET/SDH Line -- current table contains various statistics -- being collected for the current 15 minute interval. sonetLineCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Line Current table." ::= { sonetLine 1 } sonetLineCurrentEntry OBJECT-TYPE SYNTAX SonetLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Line Current table." INDEX { ifIndex } ::= { sonetLineCurrentTable 1 } SonetLineCurrentEntry ::= SEQUENCE { sonetLineCurrentStatus Integer32, sonetLineCurrentESs PerfCurrentCount, sonetLineCurrentSESs PerfCurrentCount, sonetLineCurrentCVs PerfCurrentCount, sonetLineCurrentUASs PerfCurrentCount } sonetLineCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..6) MAX-ACCESS read-only STATUS current DESCRIPTION Expires 2/26/97 [Page 32] Internet Draft SONET/SDH Objects August 26, 1996 "This variable indicates the status of the interface. The sonetLineCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously. The sonetLineNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetLineNoDefect 2 sonetLineAIS 4 sonetLineRDI" ::= { sonetLineCurrentEntry 1 } sonetLineCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 2 } sonetLineCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 3 } sonetLineCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Expires 2/26/97 [Page 33] Internet Draft SONET/SDH Objects August 26, 1996 Violations encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 4 } sonetLineCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 5 } Expires 2/26/97 [Page 34] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Line Interval Table -- The SONET/SDH Line Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetLineIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Line Interval table." ::= { sonetLine 2 } sonetLineIntervalEntry OBJECT-TYPE SYNTAX SonetLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Line Interval table." INDEX { ifIndex, sonetLineIntervalNumber } ::= { sonetLineIntervalTable 1 } SonetLineIntervalEntry ::= SEQUENCE { sonetLineIntervalNumber Integer32, sonetLineIntervalESs PerfIntervalCount, sonetLineIntervalSESs PerfIntervalCount, sonetLineIntervalCVs PerfIntervalCount, sonetLineIntervalUASs PerfIntervalCount, sonetLineIntervalValidData TruthValue } sonetLineIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current Expires 2/26/97 [Page 35] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetLineIntervalEntry 1 } sonetLineIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 2 } sonetLineIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 3 } sonetLineIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." Expires 2/26/97 [Page 36] Internet Draft SONET/SDH Objects August 26, 1996 ::= { sonetLineIntervalEntry 4 } sonetLineIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 5 } sonetLineIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetLineIntervalEntry 6 } Expires 2/26/97 [Page 37] Internet Draft SONET/SDH Objects August 26, 1996 -- The SONET/SDH Far End Line group. -- This group may only be implemented by SONET/SDH (LTEs) -- systems that provide for a far end block error (FEBE) -- information at the SONET/SDH Line Layer. -- This group consists of two tables: -- SONET/SDH Far End Line Current Table -- SONET/SDH Far End Line Interval Table -- The SONET/SDH Far End Line Current Table -- The SONET/SDH Far End Line Current table contains -- various statistics being -- collected for the current 15 minute interval. -- The statistics are collected from the far end -- block error code (FEBE) -- within the third Z2 byte of the Line Overhead -- in Broadband ISDN applications. -- The definitions are the same as described for -- the near-end information. sonetFarEndLineCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Line Current table." ::= { sonetFarEndLine 1 } sonetFarEndLineCurrentEntry OBJECT-TYPE SYNTAX SonetFarEndLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Line Current table." INDEX { ifIndex } ::= { sonetFarEndLineCurrentTable 1 } SonetFarEndLineCurrentEntry ::= SEQUENCE { sonetFarEndLineCurrentESs PerfCurrentCount, sonetFarEndLineCurrentSESs PerfCurrentCount, sonetFarEndLineCurrentCVs PerfCurrentCount, Expires 2/26/97 [Page 38] Internet Draft SONET/SDH Objects August 26, 1996 sonetFarEndLineCurrentUASs PerfCurrentCount } sonetFarEndLineCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 1 } sonetFarEndLineCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Medium/Section/Line interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 2 } sonetFarEndLineCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Medium/Section/Line interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 3 } sonetFarEndLineCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds Expires 2/26/97 [Page 39] Internet Draft SONET/SDH Objects August 26, 1996 encountered by a SONET/SDH Medium/Section/Line interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 4 } Expires 2/26/97 [Page 40] Internet Draft SONET/SDH Objects August 26, 1996 -- The SONET/SDH Far End Line Interval Table -- The SONET/SDH Far End Line Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetFarEndLineIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Line Interval table." ::= { sonetFarEndLine 2 } sonetFarEndLineIntervalEntry OBJECT-TYPE SYNTAX SonetFarEndLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Line Interval table." INDEX { ifIndex, sonetFarEndLineIntervalNumber } ::= { sonetFarEndLineIntervalTable 1 } SonetFarEndLineIntervalEntry ::= SEQUENCE { sonetFarEndLineIntervalNumber Integer32, sonetFarEndLineIntervalESs PerfIntervalCount, sonetFarEndLineIntervalSESs PerfIntervalCount, sonetFarEndLineIntervalCVs PerfIntervalCount, sonetFarEndLineIntervalUASs PerfIntervalCount, sonetFarEndLineIntervalValidData TruthValue } sonetFarEndLineIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible Expires 2/26/97 [Page 41] Internet Draft SONET/SDH Objects August 26, 1996 STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetFarEndLineIntervalEntry 1 } sonetFarEndLineIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 2 } sonetFarEndLineIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 3 } sonetFarEndLineIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a Expires 2/26/97 [Page 42] Internet Draft SONET/SDH Objects August 26, 1996 SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 4 } sonetFarEndLineIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 5 } sonetFarEndLineIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetFarEndLineIntervalEntry 6 } Expires 2/26/97 [Page 43] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Path group -- this group consists of 2 tables: -- - the SONET/SDH Path Current Table -- - the SONET/SDH Path Interval Table -- the SONET/SDH Path Current Table -- The SONET/SDH Path -- current table contains various statistics -- being collected for the current 15 minute interval. sonetPathCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Path Current table." ::= { sonetPath 1 } sonetPathCurrentEntry OBJECT-TYPE SYNTAX SonetPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Path Current table." INDEX { ifIndex } ::= { sonetPathCurrentTable 1 } SonetPathCurrentEntry ::= SEQUENCE { sonetPathCurrentWidth INTEGER, sonetPathCurrentStatus Integer32, sonetPathCurrentESs PerfCurrentCount, sonetPathCurrentSESs PerfCurrentCount, sonetPathCurrentCVs PerfCurrentCount, sonetPathCurrentUASs PerfCurrentCount } sonetPathCurrentWidth OBJECT-TYPE SYNTAX INTEGER { sts1(1), sts3cSTM1(2), Expires 2/26/97 [Page 44] Internet Draft SONET/SDH Objects August 26, 1996 sts12cSTM4(3), sts24c(4), sts48cSTM16(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that indicates the type of the SONET/SDH Path. For SONET, the assigned types are the STS-Nc SPEs, where N = 1, 3, 12, 24, and 48. STS-1 is equal to 51.84 Mbps. For SDH, the assigned types are the STM-Nc VCs, where N = 1, 4, and 16." ::= { sonetPathCurrentEntry 1 } sonetPathCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..62) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the status of the interface. The sonetPathCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously. The sonetPathNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetPathNoDefect 2 sonetPathSTSLOP 4 sonetPathSTSAIS 8 sonetPathSTSRDI 16 sonetPathUnequipped 32 sonetPathSignalLabelMismatch" ::= { sonetPathCurrentEntry 2 } sonetPathCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Expires 2/26/97 [Page 45] Internet Draft SONET/SDH Objects August 26, 1996 Seconds encountered by a SONET/SDH Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 3 } sonetPathCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 4 } sonetPathCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 5 } sonetPathCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 6 } Expires 2/26/97 [Page 46] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Path Interval Table -- The SONET/SDH Path Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetPathIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Path Interval table." ::= { sonetPath 2 } sonetPathIntervalEntry OBJECT-TYPE SYNTAX SonetPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Path Interval table." INDEX { ifIndex, sonetPathIntervalNumber } ::= { sonetPathIntervalTable 1 } SonetPathIntervalEntry ::= SEQUENCE { sonetPathIntervalNumber Integer32, sonetPathIntervalESs PerfIntervalCount, sonetPathIntervalSESs PerfIntervalCount, sonetPathIntervalCVs PerfIntervalCount, sonetPathIntervalUASs PerfIntervalCount, sonetPathIntervalValidData TruthValue } sonetPathIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible Expires 2/26/97 [Page 47] Internet Draft SONET/SDH Objects August 26, 1996 STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetPathIntervalEntry 1 } sonetPathIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 2 } sonetPathIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 3 } sonetPathIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Path in a particular 15-minute interval in the past 24 hours." Expires 2/26/97 [Page 48] Internet Draft SONET/SDH Objects August 26, 1996 ::= { sonetPathIntervalEntry 4 } sonetPathIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 5 } sonetPathIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetPathIntervalEntry 6 } Expires 2/26/97 [Page 49] Internet Draft SONET/SDH Objects August 26, 1996 -- The SONET/SDH Far End Path group -- This group consists of two tables: -- - SONET/SDH Far End Path Current Table -- - SONET/SDH Far End Path Interval Table -- The SONET/SDH Far End Path Current Table -- The SONET/SDH Far End Path Current table -- contains various statistics -- being collected for the current 15 minute interval. -- The statistics are collected from -- the far end block error code -- (FEBE) within the G1 byte of the Path Overhead. -- The definitions are the same as described for -- the near-end information. sonetFarEndPathCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Path Current table." ::= { sonetFarEndPath 1 } sonetFarEndPathCurrentEntry OBJECT-TYPE SYNTAX SonetFarEndPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Path Current table." INDEX { ifIndex } ::= { sonetFarEndPathCurrentTable 1 } SonetFarEndPathCurrentEntry ::= SEQUENCE { sonetFarEndPathCurrentESs PerfCurrentCount, sonetFarEndPathCurrentSESs PerfCurrentCount, sonetFarEndPathCurrentCVs PerfCurrentCount, sonetFarEndPathCurrentUASs PerfCurrentCount } sonetFarEndPathCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount Expires 2/26/97 [Page 50] Internet Draft SONET/SDH Objects August 26, 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 1 } sonetFarEndPathCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Path interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 2 } sonetFarEndPathCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Path interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 3 } sonetFarEndPathCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Path interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 4 } Expires 2/26/97 [Page 51] Internet Draft SONET/SDH Objects August 26, 1996 -- The SONET/SDH Far End Path Interval Table -- The SONET/SDH Far End Path Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetFarEndPathIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Path Interval table." ::= { sonetFarEndPath 2 } sonetFarEndPathIntervalEntry OBJECT-TYPE SYNTAX SonetFarEndPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Path Interval table." INDEX { ifIndex, sonetFarEndPathIntervalNumber } ::= { sonetFarEndPathIntervalTable 1 } SonetFarEndPathIntervalEntry ::= SEQUENCE { sonetFarEndPathIntervalNumber Integer32, sonetFarEndPathIntervalESs PerfIntervalCount, sonetFarEndPathIntervalSESs PerfIntervalCount, sonetFarEndPathIntervalCVs PerfIntervalCount, sonetFarEndPathIntervalUASs PerfIntervalCount, sonetFarEndPathIntervalValidData TruthValue } sonetFarEndPathIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current Expires 2/26/97 [Page 52] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetFarEndPathIntervalEntry 1 } sonetFarEndPathIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 2 } sonetFarEndPathIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 3 } sonetFarEndPathIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Path interface Expires 2/26/97 [Page 53] Internet Draft SONET/SDH Objects August 26, 1996 in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 4 } sonetFarEndPathIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 5 } sonetFarEndPathIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetFarEndPathIntervalEntry 6 } Expires 2/26/97 [Page 54] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH Virtual Tributary group -- this group consists of 2 tables: -- - the SONET/SDH VT Current Table -- - the SONET/SDH VT Interval Table -- For SDH signals, virtual tributaries are -- called VCs instead of VTs -- A VT1.5 = VC11 -- A VT2 = VC12 -- A VT3 = none -- A VT6 = VC3 -- the SONET/SDH VT Current Table -- The SONET/SDH VT current table -- contains various statistics -- being collected for the -- current 15 minute interval. sonetVTCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH VT Current table." ::= { sonetVT 1 } sonetVTCurrentEntry OBJECT-TYPE SYNTAX SonetVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH VT Current table." INDEX { ifIndex } ::= { sonetVTCurrentTable 1 } SonetVTCurrentEntry ::= SEQUENCE { sonetVTCurrentWidth INTEGER, sonetVTCurrentStatus Integer32, sonetVTCurrentESs PerfCurrentCount, sonetVTCurrentSESs PerfCurrentCount, Expires 2/26/97 [Page 55] Internet Draft SONET/SDH Objects August 26, 1996 sonetVTCurrentCVs PerfCurrentCount, sonetVTCurrentUASs PerfCurrentCount } sonetVTCurrentWidth OBJECT-TYPE SYNTAX INTEGER { vtWidth15VC11(1), vtWidth2VC12(2), vtWidth3(3), vtWidth6VC2(4), vtWidth6c(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that indicates the type of the SONET VT and SDH VC. Assigned widths are VT1.5/VC11, VT2/VC12, VT3, VT6/VC2, and VT6c." ::= { sonetVTCurrentEntry 1 } sonetVTCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..126) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the status of the interface. The sonetVTCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects and failures simultaneously. The sonetVTNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetVTNoDefect 2 sonetVTLOP 4 sonetVTPathAIS 8 sonetVTPathRDI 16 sonetVTPathRFI 32 sonetVTUnequipped 64 sonetVTSignalLabelMismatch" Expires 2/26/97 [Page 56] Internet Draft SONET/SDH Objects August 26, 1996 ::= { sonetVTCurrentEntry 2 } sonetVTCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 3 } sonetVTCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 4 } sonetVTCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 5 } sonetVTCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 6 } Expires 2/26/97 [Page 57] Internet Draft SONET/SDH Objects August 26, 1996 -- the SONET/SDH VT Interval Table -- The SONET/SDH VT Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetVTIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH VT Interval table." ::= { sonetVT 2 } sonetVTIntervalEntry OBJECT-TYPE SYNTAX SonetVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH VT Interval table." INDEX { ifIndex, sonetVTIntervalNumber } ::= { sonetVTIntervalTable 1 } SonetVTIntervalEntry ::= SEQUENCE { sonetVTIntervalNumber Integer32, sonetVTIntervalESs PerfIntervalCount, sonetVTIntervalSESs PerfIntervalCount, sonetVTIntervalCVs PerfIntervalCount, sonetVTIntervalUASs PerfIntervalCount, sonetVTIntervalValidData TruthValue } sonetVTIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 2/26/97 [Page 58] Internet Draft SONET/SDH Objects August 26, 1996 "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetVTIntervalEntry 1 } sonetVTIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 2 } sonetVTIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 3 } sonetVTIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 4 } sonetVTIntervalUASs OBJECT-TYPE Expires 2/26/97 [Page 59] Internet Draft SONET/SDH Objects August 26, 1996 SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 5 } sonetVTIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetVTIntervalEntry 6 } Expires 2/26/97 [Page 60] Internet Draft SONET/SDH Objects August 26, 1996 -- The SONET/SDH Far End VT group -- This group consists of two tables: -- SONET/SDH Far End VT Current Table -- SONET/SDH Far End VT Interval Table -- The SONET/SDH Far End VT Current -- The SONET/SDH Far End VT Current table -- contains various statistics -- being collected for the current 15 minute interval. -- The statistics are collected from -- the far end block error code -- (FEBE) within the G1 byte of the VT Overhead. -- The definitions are the same as described for -- the near-end information. sonetFarEndVTCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End VT Current table." ::= { sonetFarEndVT 1 } sonetFarEndVTCurrentEntry OBJECT-TYPE SYNTAX SonetFarEndVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End VT Current table." INDEX { ifIndex } ::= { sonetFarEndVTCurrentTable 1 } SonetFarEndVTCurrentEntry ::= SEQUENCE { sonetFarEndVTCurrentESs PerfCurrentCount, sonetFarEndVTCurrentSESs PerfCurrentCount, sonetFarEndVTCurrentCVs PerfCurrentCount, sonetFarEndVTCurrentUASs PerfCurrentCount } sonetFarEndVTCurrentESs OBJECT-TYPE Expires 2/26/97 [Page 61] Internet Draft SONET/SDH Objects August 26, 1996 SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 1 } sonetFarEndVTCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH VT interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 2 } sonetFarEndVTCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH VT interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 3 } sonetFarEndVTCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH VT interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 4 } Expires 2/26/97 [Page 62] Internet Draft SONET/SDH Objects August 26, 1996 -- The SONET/SDH Far End VT Interval Table -- The SONET/SDH Far End VT Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetFarEndVTIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End VT Interval table." ::= { sonetFarEndVT 2 } sonetFarEndVTIntervalEntry OBJECT-TYPE SYNTAX SonetFarEndVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End VT Interval table." INDEX { ifIndex, sonetFarEndVTIntervalNumber } ::= { sonetFarEndVTIntervalTable 1 } SonetFarEndVTIntervalEntry ::= SEQUENCE { sonetFarEndVTIntervalNumber Integer32, sonetFarEndVTIntervalESs PerfIntervalCount, sonetFarEndVTIntervalSESs PerfIntervalCount, sonetFarEndVTIntervalCVs PerfIntervalCount, sonetFarEndVTIntervalUASs PerfIntervalCount, sonetFarEndVTIntervalValidData TruthValue } sonetFarEndVTIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current Expires 2/26/97 [Page 63] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetFarEndVTIntervalEntry 1 } sonetFarEndVTIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 2 } sonetFarEndVTIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 3 } sonetFarEndVTIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH VT interface in a Expires 2/26/97 [Page 64] Internet Draft SONET/SDH Objects August 26, 1996 particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 4 } sonetFarEndVTIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 5 } sonetFarEndVTIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for this interval." ::= { sonetFarEndVTIntervalEntry 6 } Expires 2/26/97 [Page 65] Internet Draft SONET/SDH Objects August 26, 1996 -- conformance information sonetConformance OBJECT IDENTIFIER ::= { sonetMIB 4 } sonetGroups OBJECT IDENTIFIER ::= { sonetConformance 1 } sonetCompliances OBJECT IDENTIFIER ::= { sonetConformance 2 } -- deprecated compliance statement sonetCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SONET/SDH interfaces." MODULE -- this module MANDATORY-GROUPS { sonetMediumStuff, sonetSectionStuff } GROUP sonetLineStuff DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries." GROUP sonetFarEndLineStuff DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries, and that provide for a far end block error (FEBE) information at the SONET/SDH Line Layer." GROUP sonetPathStuff DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries." OBJECT sonetPathCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndPathStuff DESCRIPTION Expires 2/26/97 [Page 66] Internet Draft SONET/SDH Objects August 26, 1996 "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries, and that process Far End information." GROUP sonetVTStuff DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Virtual Tributaries." OBJECT sonetVTCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndVTStuff DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate the SONET/SDH floating Virtual Tributaries, and that process Far End information." ::= { sonetCompliances 1 } -- current compliance statements sonetCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SONET/SDH interfaces." MODULE -- this module MANDATORY-GROUPS { sonetMediumStuff2, sonetSectionStuff2 } OBJECT sonetMediumCircuitIdentifier MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sonetMediumLoopbackConfig MIN-ACCESS read-only DESCRIPTION Expires 2/26/97 [Page 67] Internet Draft SONET/SDH Objects August 26, 1996 "Write access is not required." OBJECT sonetSESthresholdSet MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the enumerated values need be supported." GROUP sonetLineStuff2 DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries." GROUP sonetFarEndLineStuff2 DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries, and that provide for a far end block error (FEBE) information at the SONET/SDH Line Layer." GROUP sonetPathStuff2 DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries." OBJECT sonetPathCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndPathStuff2 DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries, and that process Far End information." GROUP sonetVTStuff2 DESCRIPTION "Implementation of this group is mandatory for all Expires 2/26/97 [Page 68] Internet Draft SONET/SDH Objects August 26, 1996 SONET/SDH systems that terminate SONET/SDH Virtual Tributaries." OBJECT sonetVTCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndVTStuff2 DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate the SONET/SDH floating Virtual Tributaries, and that process Far End information." ::= { sonetCompliances 2 } -- units of conformance -- deprecated groups sonetMediumStuff OBJECT-GROUP OBJECTS { sonetMediumType, sonetMediumTimeElapsed, sonetMediumValidIntervals, sonetMediumLineCoding, sonetMediumLineType, sonetMediumCircuitIdentifier } STATUS deprecated DESCRIPTION "A collection of objects providing configuration information applicable to all SONET/SDH interfaces." ::= { sonetGroups 1 } sonetSectionStuff OBJECT-GROUP OBJECTS { sonetSectionCurrentStatus, sonetSectionCurrentESs, sonetSectionCurrentSESs, sonetSectionCurrentSEFSs, sonetSectionCurrentCVs, sonetSectionIntervalESs, sonetSectionIntervalSESs, sonetSectionIntervalSEFSs, sonetSectionIntervalCVs } Expires 2/26/97 [Page 69] Internet Draft SONET/SDH Objects August 26, 1996 STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Section interfaces." ::= { sonetGroups 2 } sonetLineStuff OBJECT-GROUP OBJECTS { sonetLineCurrentStatus, sonetLineCurrentESs, sonetLineCurrentSESs, sonetLineCurrentCVs, sonetLineCurrentUASs, sonetLineIntervalESs, sonetLineIntervalSESs, sonetLineIntervalCVs, sonetLineIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces." ::= { sonetGroups 3 } sonetFarEndLineStuff OBJECT-GROUP OBJECTS { sonetFarEndLineCurrentESs, sonetFarEndLineCurrentSESs, sonetFarEndLineCurrentCVs, sonetFarEndLineCurrentUASs, sonetFarEndLineIntervalESs, sonetFarEndLineIntervalSESs, sonetFarEndLineIntervalCVs, sonetFarEndLineIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces, and maintaining Line Far End information." ::= { sonetGroups 4 } sonetPathStuff OBJECT-GROUP OBJECTS { sonetPathCurrentWidth, sonetPathCurrentStatus, sonetPathCurrentESs, sonetPathCurrentSESs, sonetPathCurrentCVs, sonetPathCurrentUASs, Expires 2/26/97 [Page 70] Internet Draft SONET/SDH Objects August 26, 1996 sonetPathIntervalESs, sonetPathIntervalSESs, sonetPathIntervalCVs, sonetPathIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces." ::= { sonetGroups 5 } sonetFarEndPathStuff OBJECT-GROUP OBJECTS { sonetFarEndPathCurrentESs, sonetFarEndPathCurrentSESs, sonetFarEndPathCurrentCVs, sonetFarEndPathCurrentUASs, sonetFarEndPathIntervalESs, sonetFarEndPathIntervalSESs, sonetFarEndPathIntervalCVs, sonetFarEndPathIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces, and maintaining Path Far End information." ::= { sonetGroups 6 } sonetVTStuff OBJECT-GROUP OBJECTS { sonetVTCurrentWidth, sonetVTCurrentStatus, sonetVTCurrentESs, sonetVTCurrentSESs, sonetVTCurrentCVs, sonetVTCurrentUASs, sonetVTIntervalESs, sonetVTIntervalSESs, sonetVTIntervalCVs, sonetVTIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces." ::= { sonetGroups 7 } sonetFarEndVTStuff OBJECT-GROUP OBJECTS { sonetFarEndVTCurrentESs, Expires 2/26/97 [Page 71] Internet Draft SONET/SDH Objects August 26, 1996 sonetFarEndVTCurrentSESs, sonetFarEndVTCurrentCVs, sonetFarEndVTCurrentUASs, sonetFarEndVTIntervalESs, sonetFarEndVTIntervalSESs, sonetFarEndVTIntervalCVs, sonetFarEndVTIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces, and maintaining VT Far End information." ::= { sonetGroups 8 } -- current groups sonetMediumStuff2 OBJECT-GROUP OBJECTS { sonetMediumType, sonetMediumTimeElapsed, sonetMediumValidIntervals, sonetMediumLineCoding, sonetMediumLineType, sonetMediumCircuitIdentifier, sonetMediumInvalidIntervals, sonetMediumLoopbackConfig, sonetSESthresholdSet } STATUS current DESCRIPTION "A collection of objects providing configuration information applicable to all SONET/SDH interfaces." ::= { sonetGroups 9 } sonetSectionStuff2 OBJECT-GROUP OBJECTS { sonetSectionCurrentStatus, sonetSectionCurrentESs, sonetSectionCurrentSESs, sonetSectionCurrentSEFSs, sonetSectionCurrentCVs, sonetSectionIntervalESs, sonetSectionIntervalSESs, sonetSectionIntervalSEFSs, sonetSectionIntervalCVs, sonetSectionIntervalValidData } STATUS current Expires 2/26/97 [Page 72] Internet Draft SONET/SDH Objects August 26, 1996 DESCRIPTION "A collection of objects providing information specific to SONET/SDH Section interfaces." ::= { sonetGroups 10 } sonetLineStuff2 OBJECT-GROUP OBJECTS { sonetLineCurrentStatus, sonetLineCurrentESs, sonetLineCurrentSESs, sonetLineCurrentCVs, sonetLineCurrentUASs, sonetLineIntervalESs, sonetLineIntervalSESs, sonetLineIntervalCVs, sonetLineIntervalUASs, sonetLineIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces." ::= { sonetGroups 11 } sonetPathStuff2 OBJECT-GROUP OBJECTS { sonetPathCurrentWidth, sonetPathCurrentStatus, sonetPathCurrentESs, sonetPathCurrentSESs, sonetPathCurrentCVs, sonetPathCurrentUASs, sonetPathIntervalESs, sonetPathIntervalSESs, sonetPathIntervalCVs, sonetPathIntervalUASs, sonetPathIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces." ::= { sonetGroups 12 } sonetVTStuff2 OBJECT-GROUP OBJECTS { sonetVTCurrentWidth, sonetVTCurrentStatus, sonetVTCurrentESs, sonetVTCurrentSESs, Expires 2/26/97 [Page 73] Internet Draft SONET/SDH Objects August 26, 1996 sonetVTCurrentCVs, sonetVTCurrentUASs, sonetVTIntervalESs, sonetVTIntervalSESs, sonetVTIntervalCVs, sonetVTIntervalUASs, sonetVTIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces." ::= { sonetGroups 13 } sonetFarEndLineStuff2 OBJECT-GROUP OBJECTS { sonetFarEndLineCurrentESs, sonetFarEndLineCurrentSESs, sonetFarEndLineCurrentCVs, sonetFarEndLineCurrentUASs, sonetFarEndLineIntervalESs, sonetFarEndLineIntervalSESs, sonetFarEndLineIntervalCVs, sonetFarEndLineIntervalUASs, sonetFarEndLineIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces, and maintaining Line Far End information." ::= { sonetGroups 14 } sonetFarEndPathStuff2 OBJECT-GROUP OBJECTS { sonetFarEndPathCurrentESs, sonetFarEndPathCurrentSESs, sonetFarEndPathCurrentCVs, sonetFarEndPathCurrentUASs, sonetFarEndPathIntervalESs, sonetFarEndPathIntervalSESs, sonetFarEndPathIntervalCVs, sonetFarEndPathIntervalUASs, sonetFarEndPathIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces, and maintaining Path Far End information." Expires 2/26/97 [Page 74] Internet Draft SONET/SDH Objects August 26, 1996 ::= { sonetGroups 15 } sonetFarEndVTStuff2 OBJECT-GROUP OBJECTS { sonetFarEndVTCurrentESs, sonetFarEndVTCurrentSESs, sonetFarEndVTCurrentCVs, sonetFarEndVTCurrentUASs, sonetFarEndVTIntervalESs, sonetFarEndVTIntervalSESs, sonetFarEndVTIntervalCVs, sonetFarEndVTIntervalUASs, sonetFarEndVTIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces, and maintaining VT Far End information." ::= { sonetGroups 16 } END Expires 2/26/97 [Page 75] Internet Draft SONET/SDH Objects August 26, 1996 7. Acknowledgments This specification is a product of the AToM MIB Working Group. Expires 2/26/97 [Page 76] Internet Draft SONET/SDH Objects August 26, 1996 8. Security Considerations Security issues are not discussed in this memo. Expires 2/26/97 [Page 77] Internet Draft SONET/SDH Objects August 26, 1996 9. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB- II", RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). Expires 2/26/97 [Page 78] Internet Draft SONET/SDH Objects August 26, 1996 [9] American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Rates and Formats Specification, ANSI T1.105-1988. [9a] ANSI T1.105-1991. [10] American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Specification (Single-Mode), ANSI T1.106-1988. [11] American National Standard for Telecommunications -- Layer 1 In-Service Digital Transmission Performance Monitoring T1.231, September 1993. [12] K. McCloghrie and F. Kastenholz, Evolution of Interfaces Group of MIB-II, Internet Draft, November 29, 1993. [13] Fowler, D., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFCxxxx, Newbridge Networks, ???? 1996. [14] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFCxxxx, Newbridge Networks, ????? 1996. [15] CCITT Recommendation G.707, "Synchronous Digital Hierarchy Bit Rates", June 1992. [16] CCITT Recommendation G.708, "Network Node Interface for the Synchronous Digital Hierarchy", June 1992. [17] CCITT Recommendation G.709, "Synchronous Multiplexing Structure", June 1992. [18] CCITT Recommendation G.783, "Characteristics of Synchronous Digital Hierarchy (SDH) Multiplexing Equipment Functional Blocks", November 1992. [19] Brown, T., and K. Tesink, "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC1595, Bellcore, March 1994. [20] ANSI T1.231 1993 Expires 2/26/97 [Page 79] Internet Draft SONET/SDH Objects August 26, 1996 [21] Bellcore TR-NWT-000253, 1991 [22] ITU Recommendation G.826, "Error Performance Parameters and Objectives for International Constant Bit Rate Digital Paths at or above Primary Rate", September 1995 (COM 13-R57E). [23] Bellcore GR-253-CORE, Issue 2, Synchronous Optical Network (SONET) Transport SystemsL Common Generic Criteria", December 1995. Expires 2/26/97 [Page 80] Internet Draft SONET/SDH Objects August 26, 1996 10. Author's Address Kaj Tesink Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires 2/26/97 [Page 81] Internet Draft SONET/SDH Objects August 26, 1996 Appendix A: The delay-line approach to statistics collection. According to ANSI T1.231 unavailable time begins at the onset of 10 contiguous severely errored seconds -- that is, unavailable time starts with the first of the 10 contiguous SESs -- and while an interface is deemed unavailable all counters for that interface are frozen except for the UAS count. Since changes in the signal state lag the data to which they apply by 10 seconds, an implementation which wishes to avoid making retroactive adjustments to the counts must pass the the one-second statistics through a 10-second delay line prior to updating any counters. That can be done by performing the following steps at the end of each one second interval. i) Read near/far end line and path CV counts and alarm status flags from the hardware. ii) Accumulate the CV counts for the preceding second and compare them to the ES and SES threshold for the layer in question. Update the signal state and shift the one- second CV counts and ES/SES flags into the 10-element delay line. Note that far-end one-second statistics are to be flagged as "absent" during any second in which there is an incoming defect at the layer in question or at any lower layer. iii) Update the current interval statistics using the signal state from the previous update cycle and the one-second CV counts and ES/SES flags shifted out of the 10-element delay line. This procedure guarantees that the statistical counters will be correctly updated at all times, although they lag real time by 10 seconds. It is illustrated in the figure below. At the end of each 15 minutes interval the current interval counts are transferred to the most recent interval entry and each interval is shifted up by one position, with the oldest being discarded if necessary in order to make room. The current interval counts then start over from zero. Note, however, that the signal state calculation does not start anew at each interval boundary; rather, signal state information is retained across interval boundaries. Expires 2/26/97 [Page 82] Internet Draft SONET/SDH Objects August 26, 1996 +--------------------------------------------------------------+ | READ COUNTERS & STATUS INFO FROM HARDWARE | | | |LOS OOF/ SECT LINE LINE LINE LINE PATH PATH PATH PATH PATH | | LOF CV AIS CV RDI FEBE AIS LOP CV RDI CV | +--------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V V +--------------------------------------------------------------+ | ACCUM ONE-SEC STATS, CHK ERR THRESHOLDS, & UPDT SIGNAL STATE | | | | | | NEAR END/FAR END NEAR END/FAR END | |SECT SECT SECT LINE LINE LINE LINE PATH PATH PATH PATH | |CV ES SES CV ES SES AVA/UNA CV ES SES AVA/UNA | +--------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | V V V V V V | V V V | +-------------+ +-------------+ | +-------------+ | |ONE-SEC DELAY| |ONE-SEC DELAY| | |ONE-SEC DELAY| | | (1 OF 10) | | (1 OF 10) | | | (1 OF 10) | | |CV ES SES| |CV ES SES| | |CV ES SES| | +-------------+ +-------------+ | +-------------+ | | | | | | | | | | | | / / / / / / / / / / / / / / / / / / / / / / | | | | | | | | | | | V V V V V V | V V V | +-------------+ +-------------+ | +-------------+ | |ONE-SEC DELAY| |ONE-SEC DELAY| | |ONE-SEC DELAY| | | (10 OF 10) | | (10 OF 10) | | | (10 OF 10) | | |CV ES SES| |CV ES SES| | |CV ES SES| | +-------------+ +-------------+ | +-------------+ | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V +--------------------------------------------------------------+ | UPDATE STATISTICS COUNTERS | | | | NEAR END/FAR END NEAR END/FAR END | | SECTION LINE PATH | | CV ES EFS SES CV ES EFS SES AS UAS CV ES EFS SES AS UAS | +--------------------------------------------------------------+ Expires 2/26/97 [Page 83] Internet Draft SONET/SDH Objects August 26, 1996 Note that if such a procedure is adopted there is no current interval data for the first ten seconds after a system comes up. noSuchInstance must be returned if a management station attempts to access the current interval counters during this time. It is an implementation-specific matter whether an agent assumes that the initial state of the interface is available or unavailable. Expires 2/26/97 [Page 84] Internet Draft SONET/SDH Objects August 26, 1996 Appendix B - RFC1595 SES interpretation This appendix contains the values for x for the Section, Line, Path, and VT Layers as used in [11, 19, 21]. Value for x for SONET/SDH Section SES Definition Rate x Minimum Bit Error Rate ======================================================= OC-1 9 1.5 x 10^-7 OC-3 16 1 x 10^-7 OC-9 47 1 x 10^-7 OC-12 63 1 x 10^-7 OC-18 94 1 x 10^-7 OC-24 125 1 x 10^-7 OC-36 187 1 x 10^-7 OC-48 249 1 x 10^-7 Value for x for SONET/SDH Line SES Definition Rate x Minimum Bit Error Rate ======================================================= OC-1 12 2 x 10^-7 OC-3 32 2 x 10^-7 OC-9 47 2 x 10^-7 OC-12 124 2 x 10^-7 OC-18 186 2 x 10^-7 OC-24 248 2 x 10^-7 OC-36 370 2 x 10^-7 OC-48 494 2 x 10^-7 Value for x for SONET/SDH STS-Path SES Definition Rate x Minimum Bit Error Rate ======================================================= STS-1 9 1.5 x 10^-7 STS-3 16 1 x 10^-7 Expires 2/26/97 [Page 85] Internet Draft SONET/SDH Objects August 26, 1996 Value for x for SONET/SDH VT-Path SES Definition Rate x Minimum Bit Error Rate ======================================================= VT1.5 4 2 x 10^-6 VT2 6 2 x 10^-6 VT3 8 2 x 10^-6 VT6 14 2 x 10^-6 Expires 2/26/97 [Page 86] Internet Draft SONET/SDH Objects August 26, 1996 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 2 3 The SNMP Network Management Framework ................. 3 4 Objects ............................................... 4 4.1 Format of Definitions ............................... 4 5 Overview .............................................. 5 5.1 Use of the ifTable .................................. 5 5.2 Use of ifTable for SONET/SDH Medium/Section/Line Layer .............................................. 6 5.3 Use of ifTable for SONET/SDH Paths .................. 7 5.4 Use of ifTable for SONET/SDH VTs/VCs ................ 8 5.5 SONET/SDH Terminology ............................... 9 6 Object Definitions .................................... 19 6.1 The SONET/SDH Medium Group .......................... 21 6.2 The SONET/SDH Section Group ......................... 26 6.2.1 The SONET/SDH Section Current Group ............... 26 6.2.2 The SONET/SDH Section Interval Group .............. 29 6.3 The SONET/SDH Line Group ............................ 32 6.3.1 The SONET/SDH Line Current Group .................. 32 6.3.2 The SONET/SDH Line Interval Group ................. 35 6.4 The SONET/SDH Far End Line Group .................... 38 6.4.1 The SONET/SDH Far End Line Current Group .......... 38 6.4.2 The SONET/SDH Far End Line Interval Group ......... 41 6.5 The SONET/SDH Path Group ............................ 44 6.5.1 The SONET/SDH Path Current Group .................. 44 6.5.2 The SONET/SDH Path Interval Group ................. 47 6.6 The SONET/SDH Far End Path Group .................... 50 6.6.1 The SONET/SDH Far End Path Current Group .......... 50 6.6.2 The SONET/SDH Far End Path Interval Group ......... 52 6.7 The SONET/SDH Virtual Tributary Group ............... 55 6.7.1 The SONET/SDH VT Current Group .................... 55 6.7.2 The SONET/SDH VT Interval Group ................... 58 6.8 The SONET/SDH Far End VT Group ...................... 61 6.8.1 The SONET/SDH Far End VT Current Group ............ 61 6.8.2 The SONET/SDH Far End VT Interval Group ........... 63 6.9 Conformance Information ............................. 66 6.10 Compliance Statements .............................. 66 7 Acknowledgments ....................................... 76 8 Security Considerations ............................... 77 9 References ............................................ 78 10 Author's Address ..................................... 81 Expires 2/26/97 [Page 87] --=====================_846631197==_ Content-Type: text/plain; charset="us-ascii" _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_846631197==_--   Received: from ietf.org by ietf.org id aa04765; 30 Oct 96 10:28 EST Received: from localhost by ietf.org id aa01899; 30 Oct 96 9:50 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atm2TC-05.txt Date: Wed, 30 Oct 1996 09:50:32 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9610300950.aa01899@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management Author(s) : M. Noto, K. Tesink Filename : draft-ietf-atommib-atm2TC-05.txt Pages : 17 Date : 10/29/1996 This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-atm2TC-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2TC-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atm2TC-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961029150649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm2TC-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm2TC-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961029150649.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04764; 30 Oct 96 10:28 EST Received: from localhost by ietf.org id aa01931; 30 Oct 96 9:50 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atm1ng-02.txt Date: Wed, 30 Oct 1996 09:50:44 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9610300950.aa01931@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Managed Objects for ATM Management Author(s) : K. Tesink Filename : draft-ietf-atommib-atm1ng-02.txt Pages : 101 Date : 10/29/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-atm1ng-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm1ng-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atm1ng-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961029151517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm1ng-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm1ng-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961029151517.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa04760; 30 Oct 96 10:28 EST Received: from localhost by ietf.org id aa01915; 30 Oct 96 9:50 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-sonetng-02.txt Date: Wed, 30 Oct 1996 09:50:38 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9610300950.aa01915@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Managed Objects for the SONET/SDH Interface Type Author(s) : K. Tesink Filename : draft-ietf-atommib-sonetng-02.txt Pages : 87 Date : 10/29/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407 [13]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-sonetng-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-sonetng-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-sonetng-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961029151116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-sonetng-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-sonetng-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961029151116.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa06983; 30 Oct 96 11:04 EST Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa13280; 30 Oct 96 11:04 EST Received: from ietf.org (ietf.org [132.151.1.19]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id KAA07472 for ; Wed, 30 Oct 1996 10:42:24 -0500 (EST) Received: from localhost by ietf.org id aa01883; 30 Oct 96 9:50 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-perfhistTC-01.txt Date: Wed, 30 Oct 1996 09:50:26 -0500 Sender: cclark@ietf.org Message-ID: <9610300950.aa01883@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals Author(s) : K. Tesink Filename : draft-ietf-atommib-perfhistTC-01.txt Pages : 10 Date : 10/29/1996 When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. This is done through Textual Conventions as defined in RFC1903[1]. It is the purpose of this document to define the set of textual conventions to be used when performance history based on 15 minute intervals is kept. See for example the Trunk MIB modules [3][4][5]. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-perfhistTC-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-perfhistTC-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-perfhistTC-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961029145533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-perfhistTC-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-perfhistTC-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961029145533.I-D@ietf.org> --OtherAccess-- --NextPart--