1 / 30

ASN.1, BER, and MIBs

ASN.1, BER, and MIBs. Dr. Niki Pissinou Network Management and Control Standards (TCN 6430). ASN.1 and Encoding Rules. ASN.1 (Abstract Syntax Notation One) defines the syntax of messages to be exchanged between peer applications independently of local representation.

sherry
Download Presentation

ASN.1, BER, and MIBs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ASN.1, BER, and MIBs Dr. Niki Pissinou Network Management and Control Standards (TCN 6430)

  2. ASN.1 and Encoding Rules • ASN.1 (Abstract Syntax Notation One) defines the syntax of messages to be exchanged between peer applications independently of local representation. • Encoding Rules define how application messages should be encoded while in transit between peers.

  3. ASN.1 History • Based on success of IPv4 • Original idea: use of OPTION field in IPv4 • Now XER oriented

  4. ASN.1 Example • Find out the advantages from this example: Priority ::= INTEGER (0..7) User ::= SEQUENCE { name IA5String (SIZE(1..128)), prio Priority, addr IA5String OPTIONAL, ... }

  5. Advantages of ASN.1 • Power to express both simple and complex types. • Types may be constrained in size and/or value. • More powerful constraints are available. • Fields may be marked as OPTIONAL. • Type extensibility allows for smooth enhancements.

  6. ASN.1 Benefits • Application protocol designers can focus on the information that needs to be exchanged • Provides implementers with a more precise description of the messages to be exchanged • Application programmers can focus on the substance of their application • Allows you to choose the most suitable programming language • Development time significantly reduced with use of quality ASN.1 tools • Proven technology • Widely adopted International Standard

  7. ASN.1 Types • BOOLEAN INTEGER • BIT STRING OCTET STRING • NULL REAL • ENUMERATED SEQUENCE • SEQUENCE OF GeneralizedTime • IA5String BMPString • UTF8String

  8. BER • BER specifies how data should be encoded for transmission, independently of machine type, programming language, or representation within an application program. • BER is highly structured, prefixing all values with a tag and a length. Priority ::= INTEGER (0..7) queue Priority ::= 6

  9. Application 1 02 01 06 Application 2 } Value Length Tag Total of 24 bits How BER travels • Network processing • hton() and ntoh() functions

  10. PER: Efficiency • Like BER, PER specifies how data should be encoded for transmission, independently of machine type, programming language, or representation within an application program. • Unlike BER, tags are never transmitted, while lengths and values are not transmitted if known by both peers. • PER’s reason for existence is to conserve bandwidth. It is valuable in audio and video over the Internet, air-ground communication, radio-paging, or wherever bandwidth is at a premium.

  11. Open standard: XER • Just like BER and PER, XER also specifies how data should be encoded for transmission, independently of machine type, programming language, or representation within an application program. • Unlike the more compact encoding rules, XER is immediately legible. • XER’s reason for existence is ease of legibility (no tools are needed), but, • XER uses significantly more bandwidth.

  12. MIBs • MIB - Management Information Base • Database of info conforming to SMI. • SMI - Structure of Management Information • Standard that defines how to create a MIB.

  13. MIB elements • OBJECT-TYPE • String that describes the MIB object. • Object IDentifier (OID). • SYNTAX • Defines what kind of info is stored in the MIB object. • ACCESS • READ-ONLY, READ-WRITE. • STATUS • State of object in regards the SNMP community. • DESCRIPTION • Reason why the MIB object exists.

  14. Example MIB Instance • sysUpTime • sysUpTime OBJECT-TYPE • SYNTAX Time-Ticks • ACCESS read-only • STATUS mandatory • DESCRIPTION • “Time since the network management portion of the system was last re-initialised.” • ::= {system 3}

  15. iso(1) 1 org(3) 3 dod(6) 6 internet(1) 1 private(4) directory(1) 4 1 mgmt(2) experimental(3) 2 3 mib-2(1) 1 tcp(6) system(1) 6 1 interfaces(2) ip(4) 4 2 OID of sysUpTime • 1.3.6.1.2.1.1 • system(1) group • sysDescr (1) • sysObjectID (2) • sysUpTime(3) • sysContact(4)

  16. Tree view vs. Syntax view SV TV • sysUpTime OBJECT-TYPE • SYNTAX INTEGER • ACCESS read-only • STATUS mandatory • DESCRIPTION • “The time (in hundredths of a second) since the • network management portion of the system was last re-initialized.” • ::= {system 3} mib-2(1) 1 system(1) 1 sysContact(3) 4 sysUpTime(3) sysDesc(1) 3 1 sysObjectID(2) 2

  17. MIB Instances • SNMP Instances • Each MIB object can have an instance. • Example: A MIB for a router’s (entity) interface information iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) interfaces(2) ifTable(2) ifEntry(1) ifType(3) • Require one ifType value per interface (e.g. 3) • One MIB object definition can represent multiple instances through Tables, Entries, and Indexes.

  18. ENTRY + INDEX = INSTANCE ifType(3) ifMtu(4) Etc… Index #1 ifType.1[6] ifMtu.1 Index #2 ifType.2:[9] ifMtu.2 Index #3 ifType.3:[15] ifMtu.3 Tables, Entries, Indices • Tables, Entries, and Indexes (an eg.) • Three interface types require 3 rows (index numbers) • Each column represents a MIB object, as defined by the entry node.

  19. MIB Query • Example MIB Query • If we queried the MIB on ifType we could get: ifType.1 : 6 ifType.2 : 9 ifType.3 : 15 • Which corresponds to: ifType.1 : ethernet ifType.2 : tokenRing ifType.3 : fddi • ifType OBJECT-TYPE • SYNTAX INTEGER { • other(1), • ethernet(6), • tokenRing(9) • fddi(15), • …} • etc…

  20. SNMP MIB Browser • java -Xmx384m -jar “path\lib\browser.jar” Breakdown… - LHS is the SNMP MIB structure. - Lower LHS has details of MIB structure. - RHS will present MIB values.

  21. SNMP Walk

  22. SNMP graphs • sysUpTime

  23. SNMP Counters • Why counters matter… • Subsystem performance monitoring • errors • utilization/measure of activity • Most debugging activities require counters • fault isolation • Resource usage evaluation/planning • trending & thresholds • Basis for most billing applications

  24. Using SNMP Counters • Allow you to compare apples to apples • Counters have standard definitions • as defined by IETF, IEEE, some vendors… • regardless of network element type or vendor • and globally unique, hard to pronounce names • 1.3.6.1.2.1.17.2.4 dot1dStpTopChanges • Have a well specified size • 32 or 64 bits wide • 64 bit data-type available in SNMP v2c or v3 • Hacks for SNMPv1 include split counters

  25. Finer details • Counters do not necessarily start at zero • Vendor implementation friendly • Are not for direct human consumption • require a DELTA function to compute rate • Can tell if the counter value polled is valid • Each counter has a well defined indicator that represents the validity of the sample taken known as a “discontinuity”

  26. Counter Semantics ifHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 6 }

  27. Practical examples • Good counters are generally derived from underlying protocol specification dot1dTpPortInFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frames that have been received by this port from its segment. Note that a frame received on the interface corresponding to this port is only counted by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames." REFERENCE "IEEE 802.1D-1990: Section 6.6.1.1.3"

  28. SNMP Counter Types • Structure of Management Information • Version 1 RFC 1155 • Version 2 RFC 2578-2580 • Counter32 / Counter64 • ZeroBasedCounter32 • Integer32, Gauge32, are not counters • but can be the basis for new counter Textual-Conventions

  29. Counter32 • RFC 2578 Section 7.1.6. Counter32 • The Counter32 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. • Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content.

  30. Identifying Counters • Need a scheme that allows two vendors or products within a vendor to compare like items. • Object Identifiers (OID) were chosen as the identification scheme. • An OID is an ordered sequence of non-negative integers written left to right, containing at least two elements (0.0) • Bound to simple names in MIB Modules: • “ifInOctets” is 1.3.6.1.2.1.2.2.1.10

More Related