As per Relevance of the word february, we have this rfc below:











Network Working Group T.
Request For Comments: 1304 K.

Bell Communications
February 1992


Definitions of Managed
for the SIP Interface

Status of this

This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited



This memo defines a 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 SIP (SMDS
Protocol) objects

Table of

1. The Network Management Framework ............................ 2
2. Objects ..................................................... 2
2.1 Format of Definitions ...................................... 3
3. Overview .................................................... 3
4. Object Definitions .......................................... 4
4.1 The SIP Level 3 group ...................................... 4
4.2 The SIP Level 2 group ...................................... 8
4.3 The SIP PLCP group ......................................... 11
4.3.1 The SIP DS1 PLCP group ................................... 12
4.3.2 The SIP DS3 PLCP group ................................... 14
4.4 The SMDS Applications group ................................ 16
4.5 The SMDS Carrier Selection group ........................... 18
4.6 The SIP Error Log group .................................... 18
5. Acknowledgments ............................................. 23
6. References .................................................. 23
7. Security Considerations...................................... 25
8. Authors' Addresses........................................... 25







SNMP Working Group [Page 1]

RFC 1304 SIP Objects February 1992


1. The Network Management

The Internet-standard Network Management Framework consists of
components. They are

RFC 1155 [3] which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management.
1212 [9] defines a more concise description mechanism, which
wholly consistent with the SMI

RFC 1156 [4] which defines MIB-I, the core set of managed
for the Internet suite of protocols. RFC 1213 [6], defines MIB
II, an evolution of MIB-I based on implementation experience
new operational requirements

RFC 1157 [5] which defines the SNMP, the protocol used for
access to managed objects

The Framework permits new objects to be defined for the purpose
experimentation and evaluation

2.

Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1)
International Standard 8824 [7] defined in the SMI. In particular
each object has a name, a syntax, and an encoding. The name is
object identifier, an administratively assigned name, which
an object type. The object type together with an object
serves to uniquely identify a specific instantiation of the object
For human convenience, we often use a textual string, termed
OBJECT DESCRIPTOR, to also refer to the object type

The syntax of an object type defines the abstract data
corresponding to that object type. The ASN.1 language is used
this purpose. However, the SMI RFC 1155 [3] purposely restricts
ASN.1 constructs which may be used. These restrictions
explicitly made for simplicity

The encoding of an object type is simply how that object type
represented using the object type's syntax. Implicitly tied to
notion of an object type's syntax and encoding is how the object
is represented when being transmitted on the network. The
specifies the use of the basic encoding rules of ASN.1
Standard 8825 [8], subject to the additional requirements imposed
the SNMP




SNMP Working Group [Page 2]

RFC 1304 SIP Objects February 1992


2.1. Format of

Section 4 contains contains the specification of all object
contained in this MIB module. The object types are defined using
conventions defined in the SMI, as amended by the
specified in RFC 1212 [9].

3.

These objects are used when the particular media being used
realize an interface is a SIP interface. At present, this applies
these values of the ifType variable in the Internet-standard MIB

sip (31)

For these interfaces, the value of the ifSpecific variable in
MIB-II [6] has the OBJECT IDENTIFIER value

sip OBJECT IDENTIFIER ::= { transmission 31 }

The definitions contained herein are based on the SIP
in Bellcore TR-TSV-000772 and TR-TSV-000773 [11,12].

The SIP (SMDS Interface Protocol) protocol stack is defined
follows in TR-TSV-000772 [11]:

___________________
| |
| SIP Level 3 [11] |
|___________________|
| |
| SIP Level 2 [11] |
|___________________|
| |
| PLCP [12] |
|___________________|
| |
| DS1 or DS3 [12] |
|___________________|

The PLCP (Physical Layer Convergence Procedure) adapts
capabilities of the transmission system (DS1 or DS3 formats) to
service expected by SIP Level 2. Managed objects for DS1 and DS
Interface Types are defined in RFC 1232 [13] and RFC 1233 [14]
respectively (and amended in RFC 1239 [17]), and can be utilized
management of SIP interfaces. This document defines managed
for the remaining protocol levels of the SIP Interface Type.
document does not specify objects for the management of



SNMP Working Group [Page 3]

RFC 1304 SIP Objects February 1992


or configuration of Subscriber-Network Interfaces (SNIs).
objects are defined in Definitions of Managed Objects for
Subscription [18]. Bellcore requirements on these objects
specified in TA-TSV-001062 [16].

4. Object

RFC1304-MIB DEFINITIONS ::=


Counter, TimeTicks,
FROM RFC1155-

FROM RFC1213-
OBJECT-
FROM RFC-1212;

-- This MIB module uses the extended OBJECT-TYPE
-- as defined in RFC-1212.

-- This is the MIB module for the SIP objects


sip OBJECT IDENTIFIER ::= { transmission 31 }

-- All representations of SMDS addresses in this
-- module use, as a textual convention (i.e.,
-- convention does not affect their encoding),
-- data type

SMDSAddress ::= OCTET STRING (SIZE (8))
-- the 60-bit SMDS address, preceded by 4 bits with
-- following values
-- "1100" when representing an individual
-- "1110" when representing a group


-- The SIP Level 3
-- Implementation of the SIP Level 3 group is
-- for all systems implementing SIP Level 3.

sipL3Table OBJECT-
SYNTAX SEQUENCE OF SipL3
ACCESS not-
STATUS

"This table contains SIP L3 parameters
state variables, one entry per SIP port."



SNMP Working Group [Page 4]

RFC 1304 SIP Objects February 1992


::= { sip 1 }

sipL3Entry OBJECT-
SYNTAX SipL3
ACCESS not-
STATUS

"This list contains SIP L3 parameters
state variables."
INDEX { sipL3Index }
::= { sipL3Table 1 }

SipL3Entry ::= SEQUENCE {
sipL3
INTEGER
sipL3
Counter
sipL3
Counter
sipL3
Counter
sipL3
Counter
sipL3
Counter
sipL3
Counter
sipL3
Counter
sipL3
Counter
sipL3

}

sipL3Index OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"The value of this object identifies the
port interface for which this entry
management information. The value of
object for a particular interface has the
value as the ifIndex object, defined in
1156 and RFC 1213, for the same interface."
::= { sipL3Entry 1 }




SNMP Working Group [Page 5]

RFC 1304 SIP Objects February 1992


sipL3ReceivedIndividualDAs OBJECT-
SYNTAX
ACCESS read-
STATUS

"The total number of individually addressed
Level 3 PDUs received from the remote
across the SNI. The total includes
unerrored L3PDUs."
::= { sipL3Entry 2 }

sipL3ReceivedGAs OBJECT-
SYNTAX
ACCESS read-
STATUS

"The total number of group addressed SIP Level 3
PDUs received from the remote system across
SNI. The total includes only unerrored L3PDUs."
::= { sipL3Entry 3 }

sipL3UnrecognizedIndividualDAs OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of SIP Level 3 PDUs received from
remote system with invalid or unknown
destination addresses (Destination
Screening violations are not included). See
Subscription MIB module."
::= { sipL3Entry 4 }

sipL3UnrecognizedGAs OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of SIP Level 3 PDUs received from
remote system with invalid or unknown
addresses. (Destination Address
violations are not included). See
Subscription MIB module."
::= { sipL3Entry 5 }

sipL3SentIndividualDAs OBJECT-
SYNTAX
ACCESS read-



SNMP Working Group [Page 6]

RFC 1304 SIP Objects February 1992


STATUS

"The number of individually addressed SIP Level 3
PDUs that have been sent by this system across
SNI."
::= { sipL3Entry 6 }

sipL3SentGAs OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of group addressed SIP L3PDUs
have been sent by this system across the SNI."
::= { sipL3Entry 7 }

-- The total number of SIP L3PDU errors can be calculated
-- (Syntactic errors + Semantic Service errors )
-- Syntactic errors include
-- sipL3
-- Latest occurrences of syntactic error types are logged
-- sipL3PDUErrorTable
-- Semantic Service errors include
-- sipL3
-- sipL3
-- sipL3
-- Note that public networks supporting SMDS may
-- SIP L3PDUs due to subscription violations.
-- managed objects are defined in Definitions of
-- Objects for SMDS Subscription


sipL3Errors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The total number of SIP Level 3 PDUs
from the remote system that were discovered
have errors (including protocol processing and
errors but excluding addressing-related errors
and were discarded. Includes both group
L3PDUs and L3PDUs containing an
destination address."
::= { sipL3Entry 8 }






SNMP Working Group [Page 7]

RFC 1304 SIP Objects February 1992


sipL3InvalidSMDSAddressTypes OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of SIP Level 3 PDUs received from
remote system that had the Source or
Address_Type subfields, (the four most
bits of the 64 bit address field), not equal
the value 1100 or 1110. Also, an error
considered to have occurred if the Address_
field for a Source Address, the four
significant bits of the 64 bits, is equal to 1110
(a group address)."
::= { sipL3Entry 9 }

sipL3VersionSupport OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"A value which indicates the version(s) of
that this interface supports. The value is a sum
This sum initially takes the value zero. For
version, V, that this interface supports, 2
to (V - 1) is added to the sum. For example,
port supporting versions 1 and 2 would have
value of (2^(1-1)+2^(2-1))=3.
sipL3VersionSupport is effectively a bit mask
Version 1 equal to the least significant
(LSB)."
::= { sipL3Entry 10 }


-- The SIP Level 2
-- Implementation of the SIP Level 2 group is
-- for all systems implementing SIP Level 2.


sipL2Table OBJECT-
SYNTAX SEQUENCE OF SipL2
ACCESS not-
STATUS

"This table contains SIP L2PDU parameters
state variables, one entry per SIP port."
::= { sip 2 }




SNMP Working Group [Page 8]

RFC 1304 SIP Objects February 1992


sipL2Entry OBJECT-
SYNTAX SipL2
ACCESS not-
STATUS

"This list contains SIP L2 parameters and
variables."
INDEX { sipL2Index }
::= { sipL2Table 1 }

SipL2Entry ::= SEQUENCE {
sipL2
INTEGER
sipL2
Counter
sipL2
Counter
sipL2
Counter
sipL2
Counter
sipL2
Counter
sipL2
Counter
sipL2
Counter
sipL2

}

sipL2Index OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"The value of this object identifies the SIP
interface for which this entry contains
information. The value of this object for
particular interface has the same value as
ifIndex object, defined in RFC 1156 and RFC 1213,
for the same interface."
::= { sipL2Entry 1 }

sipL2ReceivedCounts OBJECT-
SYNTAX
ACCESS read-
STATUS



SNMP Working Group [Page 9]

RFC 1304 SIP Objects February 1992



"The number of SIP Level 2 PDUs received from
remote system across the SNI. The total
only unerrored L2PDUs."
::= { sipL2Entry 2 }

sipL2SentCounts OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of SIP Level 2 PDUs that have
sent by this system across the SNI."
::= { sipL2Entry 3 }

-- The total number of SIP L2PDU errors can be calculated
-- the sum of
-- sipL2
-- sipL2
-- sipL2
-- sipL2
-- sipL2
-- sipL2

sipL2HcsOrCRCErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of received SIP Level 2 PDUs that
discovered to have either a Header Check
error or a Payload CRC violation."
::= { sipL2Entry 4 }

sipL2PayloadLengthErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of received SIP Level 2 PDUs that
Payload Length errors that fall in the
specifications
- SSM L2_PDU payload length field value
- than 28 octets or greater than 44 octets

- BOM or COM L2_PDU payload length field
- equal to 44 octets




SNMP Working Group [Page 10]

RFC 1304 SIP Objects February 1992


- EOM L2_PDU payload length field value
- than 4 octets or greater than 44 octets."
::= { sipL2Entry 5 }

sipL2SequenceNumberErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of received SIP Level 2 PDUs that
a sequence number within the L2PDU not equal
the expected sequence number of the SMDS
receive process."
::= { sipL2Entry 6 }

sipL2MidCurrentlyActiveErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of received SIP Level 2 PDUs that
BOMs for which an active receive process
already started."
::= { sipL2Entry 7 }

sipL2BomOrSSMsMIDErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of received SIP Level 2 PDUs that
SSMs with a MID not equal to zero or are BOMs
MIDs equal to zero."
::= { sipL2Entry 8 }

sipL2EomsMIDErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of received SIP Level 2 PDUs that
EOMs for which there is no active receive
for the MID (i.e., the receipt of an EOM
does not correspond to a BOM) OR the EOM has a
equal to zero."
::= { sipL2Entry 9 }





SNMP Working Group [Page 11]

RFC 1304 SIP Objects February 1992


-- The SIP PLCP
-- Implementation of one of these groups is
-- if the PLCP is implemented

sipPLCP OBJECT IDENTIFIER ::= { sip 3 }


-- The SIP DS1 PLCP
-- Implementation of this group is
-- if the DS1 PLCP is implemented

sipDS1PLCPTable OBJECT-
SYNTAX SEQUENCE OF SipDS1
ACCESS not-
STATUS

"This table contains SIP DS1 PLCP parameters
state variables, one entry per SIP port."
::= { sipPLCP 1 }

sipDS1PLCPEntry OBJECT-
SYNTAX SipDS1
ACCESS not-
STATUS

"This list contains SIP DS1 PLCP parameters
state variables."
INDEX { sipDS1PLCPIndex }
::= { sipDS1PLCPTable 1 }

SipDS1PLCPEntry ::= SEQUENCE {
sipDS1
INTEGER
sipDS1
Counter
sipDS1
INTEGER
sipDS1

}


sipDS1PLCPIndex OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"The value of this object identifies the SIP



SNMP Working Group [Page 12]

RFC 1304 SIP Objects February 1992


interface for which this entry contains
information. The value of this object for
particular interface has the same value as
ifIndex object, defined in RFC 1156 and RFC 1213,
for the same interface."
::= { sipDS1PLCPEntry 1 }


sipDS1PLCPSEFSs OBJECT-
SYNTAX
ACCESS read-
STATUS

"A DS1 Severely Errored Framing Second (SEFS) is
count of one-second intervals containing one
more SEF events. A Severely Errored Framing (SEF
event is declared when an error in the A1
and an error in the A2 octet of a framing
pair (i.e., errors in both framing octets), or
consecutive invalid and/or nonsequential
Overhead Identifier octets are detected."
::= { sipDS1PLCPEntry 2 }

sipDS1PLCPAlarmState OBJECT-
SYNTAX INTEGER {
noAlarm (1),
receivedFarEndAlarm (2),
incomingLOF (3)
}
ACCESS read-
STATUS

"This variable indicates if there is an
present for the DS1 PLCP. The
receivedFarEndAlarm means that the DS1 PLCP
received an incoming Yellow Signal, the
incomingLOF means that the DS1 PLCP has declared
loss of frame (LOF) failure condition, and
value noAlarm means that there are no
present. See TR-TSV-000773 for a description
alarm states."
::= { sipDS1PLCPEntry 3 }


sipDS1PLCPUASs OBJECT-
SYNTAX
ACCESS read-
STATUS



SNMP Working Group [Page 13]

RFC 1304 SIP Objects February 1992



"The counter associated with the number
Unavailable Seconds, as defined by TR-TSV-000773,
encountered by the PLCP."
::= { sipDS1PLCPEntry 4 }


-- The SIP DS3 PLCP
-- Implementation of this group is
-- if the DS3 PLCP is implemented

sipDS3PLCPTable OBJECT-
SYNTAX SEQUENCE OF SipDS3
ACCESS not-
STATUS

"This table contains SIP DS3 PLCP parameters
state variables, one entry per SIP port."
::= { sipPLCP 2 }

sipDS3PLCPEntry OBJECT-
SYNTAX SipDS3
ACCESS not-
STATUS

"This list contains SIP DS3 PLCP parameters
state variables."
INDEX { sipDS3PLCPIndex }
::= { sipDS3PLCPTable 1 }

SipDS3PLCPEntry ::= SEQUENCE {
sipDS3
INTEGER
sipDS3
Counter
sipDS3
INTEGER
sipDS3

}


sipDS3PLCPIndex OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"The value of this object identifies the SIP



SNMP Working Group [Page 14]

RFC 1304 SIP Objects February 1992


interface for which this entry contains
information. The value of this object for
particular interface has the same value as
ifIndex object, defined in RFC 1156 and RFC 1213,
for the same interface."
::= { sipDS3PLCPEntry 1 }

sipDS3PLCPSEFSs OBJECT-
SYNTAX
ACCESS read-
STATUS

"A DS3 Severely Errored Framing Second (SEFS) is
count of one-second intervals containing one
more SEF events. A Severely Errored Framing (SEF
event is declared when an error in the A1
and an error in the A2 octet of a framing
pair (i.e., errors in both framing octets), or
consecutive invalid and/or nonsequential
Overhead Identifier octets are detected."
::= { sipDS3PLCPEntry 2 }

sipDS3PLCPAlarmState OBJECT-
SYNTAX INTEGER {
noAlarm (1),
receivedFarEndAlarm (2),
incomingLOF (3)
}
ACCESS read-
STATUS

"This variable indicates if there is an
present for the DS3 PLCP. The
receivedFarEndAlarm means that the DS3 PLCP
received an incoming Yellow Signal, the
incomingLOF means that the DS3 PLCP has declared
loss of frame (LOF) failure condition, and
value noAlarm means that there are no
present. See TR-TSV-000773 for a description
alarm states."
::= { sipDS3PLCPEntry 3 }


sipDS3PLCPUASs OBJECT-
SYNTAX
ACCESS read-
STATUS




SNMP Working Group [Page 15]

RFC 1304 SIP Objects February 1992


"The counter associated with the number
Unavailable Seconds, as defined by TR-TSV-000773,
encountered by the PLCP."
::= { sipDS3PLCPEntry 4 }


-- The SMDS Applications
-- Applications that have been identified for this group are
-- * IP-over-SMDS (details are specified in RFC 1209)
-- Implementation of this group is mandatory for
-- that implement IP-over-SMDS Interface Protocol

smdsApplications OBJECT IDENTIFIER ::= { sip 4 }

ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }

-- Although the objects in this group are read-only, at
-- agent's discretion they may be made read-write so that
-- management station, when appropriately authorized,
-- change the addressing information related to
-- configuration of a logical IP subnetwork implemented
-- top of SMDS

-- This table is necessary to support RFC1209 (IP-over-SMDS
-- and gives information on the Group Addresses and
-- Addresses used in the Logical IP subnetwork
-- One SMDS address may be associated with multiple
-- addresses. One SNI may be associated with multiple LISs

ipOverSMDSTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS

"The table of addressing information relevant
this entity's IP addresses."
::= { ipOverSMDS 1 }

ipOverSMDSEntry OBJECT-
SYNTAX
ACCESS not-
STATUS

"The addressing information for one of
entity's IP addresses."
INDEX { ipOverSMDSIndex, ipOverSMDSAddress }
::= { ipOverSMDSTable 1 }




SNMP Working Group [Page 16]

RFC 1304 SIP Objects February 1992


IpOverSMDSEntry ::=
SEQUENCE {

INTEGER

IpAddress

SMDSAddress

SMDSAddress


}

ipOverSMDSIndex OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"The value of this object identifies the SIP
interface for which this entry contains
information. The value of this object for
particular interface has the same value as
ifIndex object, defined in RFC 1156 and RFC 1213,
for the same interface."
::= { ipOverSMDSEntry 1 }

ipOverSMDSAddress OBJECT-
SYNTAX
ACCESS read-
STATUS

"The IP address to which this entry's
information pertains."
::= { ipOverSMDSEntry 2 }

ipOverSMDSHA OBJECT-
SYNTAX
ACCESS read-
STATUS

"The SMDS Individual address of the IP station."
::= { ipOverSMDSEntry 3 }

ipOverSMDSLISGA OBJECT-
SYNTAX
ACCESS read-
STATUS



SNMP Working Group [Page 17]

RFC 1304 SIP Objects February 1992



"The SMDS Group Address that has been
to identify the SMDS Subscriber-Network
(SNIs) of all members of the Logical IP
(LIS) connected to the network supporting SMDS."
::= { ipOverSMDSEntry 4 }

ipOverSMDSARPReq OBJECT-
SYNTAX
ACCESS read-
STATUS

"The SMDS address (individual or group) to
ARP Requests are to be sent."
::= { ipOverSMDSEntry 5 }


-- The SMDS Carrier Selection
-- This group is used as a place
-- for carrier selection objects

smdsCarrierSelection OBJECT IDENTIFIER ::= { sip 5}


-- The SIP Error
-- Implementation of this group is
-- for all systems that implement SIP Level 3.

sipErrorLog OBJECT IDENTIFIER ::= { sip 6 }

sipL3PDUErrorTable OBJECT-
SYNTAX SEQUENCE OF SipL3
ACCESS not-
STATUS

"A table that contains the latest occurrence
the following syntactical SIP L3PDU errors

- Destination Address Field Format Error

The following pertains to the 60 least
bits of the 64 bit address field. The 60
contained in the address subfield can be used
represent addresses up to 15 decimal digits.
decimal digit shall be encoded into four
using Binary Coded Decimal (BCD), with the
significant digit occurring left-most. If not
15 digits are required, then the remainder of



SNMP Working Group [Page 18]

RFC 1304 SIP Objects February 1992


field shall be padded on the right with bits
to one. An error is considered to have occurred
a). if the first four bits of the
subfield are not BCD, OR b). if the first
bits of the address subfield are populated
the country code value 0001, AND the 40 bits
follow are not Binary Coded Decimal (BCD)
values of the 10 digit addresses, OR the
16 least significant bits are not populated
1's, OR c). if the address subfield is
correct according to another numbering plan
is dependent upon the carrier assigning
numbers and offering SMDS

- Source Address Field Format Error

The description of this parameter is the same
the description of the Destination Address
Format Error

- Invalid BAsize Field Value

An error is considered to have occurred when
BAsize field of an SIP L3PDU contains a value
that 32, greater than 9220 octets without
CRC32 field present, greater than 9224 octets
the CRC32 field present, or not equal to
multiple of 4 octets

- Invalid Header Extension Length Field Value

An error is considered to have occurred when
Header Extension Length field value is not
3.

- Invalid Header Extension - Element Length

An error is considered to have occurred when
Header Extension - Element Length is greater
12.

- Invalid Header Extension - Version
Position, Length, or Value

An error is considered to have occurred when
Version element with Length=3, Type=0, and Value=1
does not appear first within the Header Extension
or an element Type=0 appears somewhere other



SNMP Working Group [Page 19]

RFC 1304 SIP Objects February 1992


within the first three octets in the
Extension

- Invalid Header Extension - Carrier
Element Position, Length, Value or Format

An error is considered to have occurred when
Carrier Selection element does not appear
within the Header Extension, if the Element
does not equal 1, the Element Length does
equal 4, 6, or 8, the Element Value field is
four BCD encoded decimal digits used in
the Carrier Identification Code (CIC), or
identified CIC code is invalid

- Header Extension PAD

An error is considered to have occurred when
Header Extension PAD is 9 octets in length, or
the Header Extension PAD is greater than
octets in length and the Header Extension PAD
not follow all Header Extension elements or
not begin with at least one octet of all zeros

- BEtag Mismatch Error

An error is considered to have occurred when
Beginning-End Tags in the SIP L3PDU header
trailer are not equal

- BAsize Field not equal to Length Field Error

An error is considered to have occurred when
value of the BAsize Field does not equal the
of the Length Field

- Incorrect Length Error,

An error is considered to have occurred when
the Length field value is not equal to the
of the SIP L3PDU which extends from
Destination Address field up to and including
CRC32 field (if present) or up to and
the PAD field (if the CRC32 field is not present).
As an optional check, an error is considered
have occurred when the length of a
received SIP L3PDU exceeds the BAsize value




SNMP Working Group [Page 20]

RFC 1304 SIP Objects February 1992


- MRI Timeout Error

An error is considered to have occurred when
elapsed time between receipt of BOM
corresponding EOM exceeds the value of the
(Message Receive Interval) for a
transport signal format

An entry is indexed by interface number and
type, and contains Source Address,
Address and a timestamp. All these errors
counted in the sipL3Errors counter.
sipL3PDUErrorTimeStamp is equal to zero,
SipL3PDUErrorEntry does not contain any
information."
::= { sipErrorLog 1 }

sipL3PDUErrorEntry OBJECT-
SYNTAX SipL3
ACCESS not-
STATUS

"An entry in the service disagreement table."
INDEX { sipL3PDUErrorIndex, sipL3PDUErrorType }
::= { sipL3PDUErrorTable 1 }

SipL3PDUErrorEntry ::= SEQUENCE {
sipL3
INTEGER
sipL3
INTEGER
sipL3
SMDSAddress
sipL3
SMDSAddress
sipL3

}

sipL3PDUErrorIndex OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS

"The value of this object identifies the SIP
interface for which this entry contains
information. The value of this object for
particular interface has the same value as



SNMP Working Group [Page 21]

RFC 1304 SIP Objects February 1992


ifIndex object, defined in RFC 1156 and RFC 1213,
for the same interface."
::= { sipL3PDUErrorEntry 1 }

sipL3PDUErrorType OBJECT-
SYNTAX INTEGER {
erroredDAFieldFormat (1),
erroredSAFieldFormat (2),
invalidBAsizeFieldValue (3),
invalidHdrExtLength (4),
invalidHdrExtElementLength (5),
invalidHdrExtVersionElementPositionLenthOrValue (6),
invalidHdrExtCarSelectElementPositionLenghtValueOrFormat (7),
hePADError (8),
beTagMismatch (9),
baSizeFieldNotEqualToLengthField (10),
incorrectLength (11),
mriTimeout (12)
}
ACCESS read-
STATUS

"The type of error."
::= { sipL3PDUErrorEntry 2 }

sipL3PDUErrorSA OBJECT-
SYNTAX
ACCESS read-
STATUS

"A rejected SMDS source address."
::= { sipL3PDUErrorEntry 3 }

sipL3PDUErrorDA OBJECT-
SYNTAX
ACCESS read-
STATUS

"A rejected SMDS destination address."
::= { sipL3PDUErrorEntry 4 }

sipL3PDUErrorTimeStamp OBJECT-
SYNTAX
ACCESS read-
STATUS

"The timestamp for the service disagreement.
timestamp contains the value of sysUpTime at



SNMP Working Group [Page 22]

RFC 1304 SIP Objects February 1992


latest occurrence of this type of
disagreement. See textual description
sipL3PDUErrorTable for boundary conditions."
::= { sipL3PDUErrorEntry 5 }



5.

This document was produced by the SNMP Working Group. In addition
the comments of the following individuals are also acknowledged:
Brunner, Jeff Case, Tracy Cox, Sherri Hiller, Steve Jaffe,
Kostick, Dave Piscitello, and Ron Reuss

6.

[1] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, NRI, April 1988.

[2] Cerf, V., "Report of the Second Ad Hoc Network Management
Group", RFC 1109, NRI, August 1989.

[3] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.

[4] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.

[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.

[6] McCloghrie K., and M. Rose, Editors, "Management
Base for Network Management of TCP/IP-based internets",
1213, Performance Systems International, March 1991.

[7] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization,
Standard 8824, December 1987.

[8] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation
(ASN.1), International Organization for Standardization
International Standard 8825, December 1987.



SNMP Working Group [Page 23]

RFC 1304 SIP Objects February 1992


[9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems
March 1991.

[10] Rose, M., Editor, "A Convention for Defining Traps for use
the SNMP", RFC 1215, Performance Systems International,
1991.

[11] "Generic System Requirements in Support of Switched Multi
megabit Data Service", Bellcore Technical Reference, TR-TSV
000772, Issue 1, May 1991.

[12] "Local Access System Generic Requirements, Objectives,
Interfaces in Support of Switched Multi-megabit Data Service",
Bellcore Technical Reference, TR-TSV-000773, Issue 1, June 1990.

[13] Baker F., and C. Kolb, Editors, "Definitions of Managed
for the DS1 Interface Type", RFC 1232, ACC, Performance
International, Inc., May 1991.

[14] Cox, T., and K. Tesink, Editors, "Definitions of Managed
for the DS3 Interface Type", RFC 1233, Bell
Research, May 1991.

[15] Piscitello, D., and J. Lawrence, Editors, The Transmission of
Datagrams over the SMDS Service", RFC 1209, Bell
Research, March 1991.

[16] "Generic Requirements For SMDS Customer Network
Service", TA-TSV-001062, Issue 1, February 1991, and
1, April 1991.

[17] Reynolds, J., "Reassignment of Experimental MIBs to
MIBs", RFC 1239, USC/Information Sciences Institute, June 1991.

[18] Tesink, K., "Definitions of Managed Objects for
Subscription", Version 1.0, Bellcore, March 1991.














SNMP Working Group [Page 24]

RFC 1304 SIP Objects February 1992


7. Security

Security issues are not discussed in this memo

8. Authors'

Tracy A.
Bell Communications
331 Newman Springs
Red Bank, NJ 07701

Phone: (908) 758-2107
EMail: tacox@sabre.bellcore.


Kaj
Bell Communications
331 Newman Springs
Red Bank, NJ 07701

Phone: (908) 758-5254
EMail: kaj@nvuxr.cc.bellcore.





























SNMP Working Group [Page 25]







if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum