SEC. 7.2
`
`DNS-Domain Name System
`
`625
`
`about multiple domains. This field is thus the primary search key used to satisfy
`queries. The order of the records in the database is not significant. When a query
`is made about a domain, all the matching records of the class requested are
`returned.
`The Time_to_live field gives an indication of how stable the record is. Infor(cid:173)
`mation that is highly stable is assigned a large value, such as 86400 (the number
`of seconds in 1 day). Information that is highly volatile is assigned a small value,
`such as 60 (1 minute). We will come back to this point later when we have dis(cid:173)
`cussed caching.
`The Type field tells what kind of record this is. The most important types are
`listed in Fig. 7-26.
`
`Type
`
`Meaning
`
`Value
`
`SOA
`
`Start of Authority
`
`Parameters for this zone
`
`A
`
`MX
`
`NS
`
`IP address of a host
`
`32-Bit integer
`
`Mail exchange
`
`Priority, domain willing to accept email
`
`Name Server
`
`Name of a server for this domain
`
`CNAME Canonical name
`
`Domain name
`
`PTR
`
`Pointer
`
`Alias for an IP address
`
`HINFO
`
`Host description
`
`CPU and OS in ASCII
`
`TXT
`
`Text
`
`Uninterpreted ASCII text
`
`Fig. 7-26. The principal DNS resource record types.
`
`An SOA record provides the name of the primary source of information about
`the name server's zone (described below), the email address of its administrator, a
`unique serial number, and various flags and timeouts.
`The most important record type is the A (Address) record. It holds a 32-bit IP
`address for some host. Every Internet host must have at least one IP address, so
`other machines can communicate with it. Some hosts have two or more network
`connections, in which case they will have one type A resource record per network
`connection (and thus per IP address).
`The next most important record type is the MX record. It specifies the name
`of the domain prepared to accept email for the specified domain. A common use
`of this record is to allow a machine that is not on the Internet to receive email
`from Internet sites. Delivery is accomplished by having the non-Internet site
`make an arrangement with some Internet site to accept email for it and forward it
`using whatever protocol the two of them agree on.
`For example, suppose that Cathy is a computer science graduate student at
`UCLA. After she gets her degree in AI, she sets up a company, Electrobrain
`
`Ex.1006.643
`
`DELL
`
`

`

`626
`
`THE APPLICATION LAYER
`
`CHAP. 7
`
`Corporation, to commercialize her ideas. She cannot afford an Internet connec(cid:173)
`tion yet, so she makes an arrangement with UCLA to allow her to have her email
`sent there. A few times a day she will call up and collect it.
`Next, she registers her company with the com domain and is assigned the
`domain electrobrain.com. She might then ask the administrator of the com
`domain to add an MX record to the com database as follows:
`
`electrobrain.com 86400
`
`IN MX
`
`mailserver.cs.ucla.edu
`
`In this way, mail will be forwarded to UCLA where she can pick it up by logging
`in. Alternatively, UCLA could call her and transfer the email by any protocol
`they mutually agree on.
`The NS records specify name servers. For example, every DNS database nor(cid:173)
`mally has an NS record for each of the top-level domains, so email can be sent to
`distant parts of the naming tree. We will come back to this point later.
`CNAME records allow aliases to be created. For example, a person familiar
`with Internet naming in general wanting to send a message to someone whose
`login name is paul in the computer science department at M.I.T. might guess that
`paul@cs.mit.edu will work. Actually this address will not work, because the
`domain for M.I.T.'s computer science department is lcs.mit.edu. However, as a
`service to people who do not know this, M.I.T. could create a CNAME entry to
`point people and programs in the right direction. An entry like this one might do
`the job:
`
`cs.mit.edu 86400
`
`IN CNAME
`
`lcs.mit.edu
`
`Like CNAME, PTR points to another name. However, unlike CNAME, which
`is really just a macro definition, PTR is a regular DNS datatype whose interpreta(cid:173)
`tion depends on the context in which it is found. In practice, it is nearly always
`used to associate a name with an IP address to allow lookups of the IP address and
`return the name of the corresponding machine.
`HINFO records allow people to find out what kind of machine and operating
`system a domain corresponds to. Finally, TXT records allow domains to identify
`themselves in arbitrary ways. Both of these record types are for user convenience.
`Neither is required, so programs cannot count on getting them (and probably can(cid:173)
`not deal with them if they do get them).
`Getting back to the general structure of resource records, the fourth field of
`every resource record is the Class. For Internet information, it is always IN. For
`non-Internet information, other codes can be used.
`Finally, we come to the Value field. This field can be a number, a domain
`name, or an ASCII string. The semantics depend on the record type. A short
`description of the Value fields for each of the principal records types is given in
`Fig. 7-26.
`As an example of the kind of information one might find in the DNS database
`of a domain, see Fig. 7-27. This figure depicts part of a (semihypothetical)
`
`Ex.1006.644
`
`DELL
`
`

`

`SEC. 7.2
`
`DNS--Domain Name System
`
`627
`
`database for the cs.vu.nl domain shown in Fig. 7-25. The database contains seven
`types of resource records.
`
`; Authoritative data for cs.vu.nl
`IN SOA
`cs.vu.nl.
`86400
`cs.vu.nl.
`86400
`IN TXT
`cs.vu.nl.
`86400
`IN TXT
`cs.vu.nl.
`86400
`IN MX
`cs.vu.nl.
`86400
`IN MX
`
`star boss (952771,7200,7200,2419200,86400)
`"Faculteit Wiskunde en Informatica."
`"Vrije Universiteit Amsterdam."
`1 zephyr.cs.vu.nl.
`2 top.cs.vu.nl.
`
`flits.cs.vu.nl.
`flits.cs.vu.nl.
`flits.cs.vu.nl.
`flits.cs.vu.nl.
`flits.cs.vu.nl.
`flits.cs.vu.nl.
`www.cs.vu.nl.
`ftp.cs.vu.nl.
`
`rowboat
`
`little-sister
`
`laserjet
`
`86400
`86400
`86400
`86400
`86400
`86400
`86400
`86400
`
`IN HINFO
`IN A
`IN A
`IN MX
`IN MX
`IN MX
`IN CNAME
`IN CNAME
`
`Sun Unix
`130.37.16.112
`192.31.231.165
`1 flits.cs.vu.nl.
`2 zephyr.cs.vu.nl.
`3 top.cs.vu.nl.
`star.cs.vu.nl
`zephyr.cs.vu.nl
`
`IN A
`IN MX
`IN MX
`IN HINFO
`
`130.37.56.201
`1 rowboat
`2 zephyr
`Sun Unix
`
`IN A
`IN HINFO
`
`130.37.62.23
`Mac MacOS
`
`IN A
`IN HINFO
`
`192.31.231.216
`"HP Laserjet lllSi" Proprietary
`
`Fig. 7-27. A portion of a possible DNS database for cs. vu.nl
`The first noncomment line of Fig. 7-27 gives some basic information about
`the domain, which will not concern us further. The next two lines give textual
`information about where the domain is located. Then come two entries giving the
`first and second places to try to deliver email sent to person@cs.vu.nl. The
`zephyr (a specific machine) should be tried first. If that fails, the top should be
`tried next.
`After the blank line, added for readability, come lines telling that the flits is a
`Sun workstation running UNIX and giving both of its IP addresses. Then three
`choices are given for handling email sent to flits.cs. vu.nl. First choice is naturally
`the flits itself, but if it is down, the zephyr and top are the second and third
`choices. Next comes an alias, www.cs.vu.nl, so that this address can be used
`without designating a specific machine. Creating this alias allows cs. vu.nl to
`change its World Wide Web server without invalidating the address people use to
`get to it. A similar argument holds for ftp.cs. vu.nl.
`
`Ex.1006.645
`
`DELL
`
`

`

`628
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`The next four lines contain a typical entry for a workstation, in this case,
`rowboat.cs. vu.nl. The information provided contains the IP address, the primary
`and secondary mail drops, and information about the machine. Then comes an
`entry for a non-UNIX system that is not capable of receiving mail itself, followed
`by an entry for a laser printer.
`What is not shown (and is not in this file), are the IP addresses to use to look
`up the top level domains. These are needed to look up distant hosts, but since
`they are not part of the cs. vu.nl domain, they are not in this file. They are sup(cid:173)
`plied by the root servers, whose IP addresses are present in a system configuration
`file and loaded into the DNS cache when the DNS server is booted. They have
`very long timeouts, so once loaded, they are never purged from the cache.
`
`7.2.3. Name Servers
`
`In theory at least, a single name server could contain the entire DNS database
`and respond to all queries about it. In practice, this server would be so overloaded
`as to be useless. Furthermore, if it ever went down, the entire Internet would be
`crippled.
`To avoid the problems associated with having only a single source of informa-·
`tion, the DNS name space is divided up into nonoverlapping zones. One possible
`way to divide up the name space of Fig. 7-25 is shown in Fig. 7-28. Each zone
`contains some part of the tree and also contains name servers holding the authori(cid:173)
`tative information about that zone. Normally, a zone will have one primary name
`server, which gets its information from a file on its disk, and one or more secon(cid:173)
`dary name servers, which get their information from the primary name server. To
`improve reliability, some servers for a zone can be located outside the zone.
`
`I-·--- Generic ----~--1 1--· Countries -
`
`pc24
`
`Fig. 7-28. Part of the DNS name space showing the division into zones.
`Where the zone boundaries are placed within a zone is up to that zone's
`administrator. This decision is made in large part based on how many name
`
`Ex.1006.646
`
`DELL
`
`

`

`SEC. 7.2
`
`DNS-Domain Name System
`
`629
`
`servers are desired, and where. For example, in Fig. 7-28, Yale has a server for
`yale.edu that handles eng.yale.edu but not cs.yale.edu, which is a separate zone
`with its own name servers. Such a decision might be made when a department
`such as English does not wish to run its own name server, but a department such
`as computer science does. Consequently, cs.yale.edu is a separate zone but
`eng. yale. edu is not.
`When a resolver has a query about a domain name, it passes the query to one
`of the local name servers. If the domain being sought falls under the jurisdiction
`of the name server, such as ai.cs.yale.edu falling under cs.yale.edu, it returns the
`authoritative resource records. An authoritative record is one that comes from
`the authority that manages the record, and is thus always correct. Authoritative
`records are in contrast to cached records, which may be out of date.
`If, however, the domain is remote and no informatibn about the requested
`domain is available locally, the name server sends a query message to the top(cid:173)
`level name server for the domain requested. To make this process clearer, con(cid:173)
`sider the example of Fig. 7-29. Here, a resolver on flits.cs. vu.nl wants to know the
`IP address of the host linda.cs.yale.edu. In step 1, it sends a query to the local
`name server, cs.vu.nl. This que:ry contains the domain name sought, the type (A)
`and the class (JN).
`
`Originator
`
`1
`
`vu cs
`name server
`
`Edu
`name server
`
`2
`
`3
`
`flits.cs.vu.nl ~;jedu-server.netl, 'I
`
`Yale
`name server
`
`yale.edu
`
`Yale CS
`name server
`
`'I cs.yale.edu I
`
`1.
`
`4
`
`5
`
`8
`
`7
`
`6
`
`Fig. 7-29. How a resolver looks up a remote name in eight steps.
`Let us suppose the local name server has never had a query for this domain
`before and knows nothing about it. It may ask a few other nearby name servers,
`but if none of them know, it sends a UDP packet to the server for edu given in its
`database (see Fig. 7-29), edu-server.net. It is unlikely that this server knows the
`address of linda.cs.yale.edu, and probably does not know cs.yale.edu either, but it
`must know all of its own children, so it forwards the request to the name server
`for yale.edu (step 3). In turn, this one forwards the request to cs.yale.edu (step 4),
`which must have the authoritative resource records. Since each request is from a
`client to a server, the resource record requested works its way back in steps 5
`through 8.
`Once these records get back to the cs. vu.nl name server, they will be entered
`into a cache there, in case they are needed later. However, this information is not
`authoritative, since changes made at cs.yale.edu will not be propagated to all the
`caches in the world that may know about it. For this reason, cache entries should
`not live too long. This is the reason that the Time_to_live field is included in each
`resource record. It tells remote name servers how long to cache records. If a
`
`Ex.1006.647
`
`DELL
`
`

`

`630
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`certain machine has had the same IP address for years, it may be safe to cache that
`information for 1 day. For more volatile information, it might be safer to purge
`the records after a few seconds or a minute.
`It is worth mentioning that the query method described here is known as a
`recursive query, since each server that does not have the requested information
`goes and finds it somewhere, then reports back. An alternative form is also possi(cid:173)
`ble. In this form, when a query cannot be satisfied locally, the query fails, but the
`name of the next server along the line to try is returned. This procedure gives the
`client more control over the search process. Some servers do not implement
`recursive queries and always return the name of the next server to try.
`It is also worth pointing out that when a DNS client fails to get a response
`before its timer goes off, it normally will try another server next time. The
`assumption here is that the server is probably down, rather than the request or
`reply got lost.
`
`7.3. SNMP-SIMPLE NETWORK MANAGEMENT PROTOCOL
`
`In the early days of the ARPANET, if the delay to some host became unex(cid:173)
`pectedly large, the person detecting the problem would just run the Ping program
`to bounce a packet off the destination. By looking at the timestamps in the header
`of the packet returned, the location of the problem could usually be pinpointed
`and some appropriate action taken. In addition, the number of routers was so
`small, that it was feasible to ping each one to see if it was sick.
`When the ARPANET turned into the worldwide Internet, with multiple back(cid:173)
`bones and multiple operators, this solution ceased to be adequate, so better tools
`for network management were needed. Two early attempts were defined in RFC
`1028 and RFC 1067, but these were short lived. In May 1990, RFC 1157 was
`published, defining version 1 of SNMP (Simple Network Management Proto(cid:173)
`col). Along with a companion document (RFC 1155) on management informa(cid:173)
`tion, SNMP provided a systematic way of monitoring and managing a computer
`network. This framework and protocol were widely implemented in commercial
`products and became the de facto standards for network management.
`As experience was gained, shortcomings in SNMP came to light, so an
`enhanced version of SNMP (SNMPv2) was defined (in RFCs 1441 to 1452) and
`started along the road to become an Internet standard. In the sections to follow,
`we will give a brief discussion of the SNMP (meaning SNMPv2) model and pro(cid:173)
`tocol.
`Although SNMP was designed with the idea of its being simple, at least one
`author has managed to produce a 600-page book on it (Stallings, 1993a). For
`more compact descriptions (450-550 pages), see the books by Rose (1994) and
`Rose and McCloghrie (1995), both of whom were among the designers of SNMP.
`Other references are (Feit, 1995; and Hein and Griffiths, 1995).
`
`Ex.1006.648
`
`DELL
`
`

`

`

`

`632
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`In order to allow a management station (potentially from yet another supplier) to
`talk to all these diverse components, the nature of the information maintained by
`all the devices must be rigidly specified. Having the management station ask a
`router what its packet loss rate is of no use if the router does not keep track of its
`loss rate. Therefore, SNMP describes (in excruciating detail) the exact informa(cid:173)
`tion each kind of agent has to maintain and the format it has to supply it in. The
`largest portion of the SNMP model is the definition of who has to keep track of
`what and how this information is communicated.
`Very briefly, each device maintains one or more variables that describe its
`state. In the SNMP literature, these variables are called objects, but the term is
`misleading because they are not objects in the sense of an object-oriented system
`because they just have state and no methods (other than reading and writing their
`values). Nevertheless, the term is so ingrained (e.g., used in various reserved
`words in the specification language used) that we will use it here. The collection
`of all possible objects in a network is given in a data structure called the MIB
`(Management InformatioJ;J. Base).
`The management station interacts with the agents using the SNMP protocol.
`This protocol allows the management station to query the state of an agent's local
`objects, and change them if necessary. Most of SNMP consists of this query(cid:173)
`response type communication.
`However, sometimes events happen that are not planned. Managed nodes can
`crash and reboot, lines can go down and come back up, congestion can occur, and
`so on. Each significant event is defined in a MIB module. When an agent notices
`that a significant event has occurred, it immediately reports the event to all
`management stations in its configuration list. This report is called an SNMP trap
`(for historical reasons). The report usually just states that some event has
`occurred. It is up to the management station to then issue queries to find out all
`the gory details. Because communication from managed nodes to the manage(cid:173)
`ment station is not reliable (i.e., is not acknowledged), it is wise for the manage(cid:173)
`ment station to poll each managed node occasionally anyway, checking for
`unusual events, just in case. The model of polling at long intervals with accelera(cid:173)
`tion on receipt of a trap is called trap directed polling.
`This model assumes that each managed node is capable of running an SNMP
`agent internally. Older devices or devices not originally intended for use on a net(cid:173)
`work may not have this capability. To handle them, SNMP defines what is called
`a proxy agent, namely an agent that watches over one or more nonSNMP devices
`and communicates with the management station on their behalf, possibly com(cid:173)
`municating with the devices themselves using some nonstandard protocol.
`Finally, security and authentication play a major role in SNMP. A manage(cid:173)
`ment station has the capability of learning a great deal about every node under its
`control and also has the capability of shutting them all down. Hence it is of great
`importance that agents be convinced that queries allegedly coming from the
`management station, in fact, come from the management station. In SNMPvl, the
`
`Ex.1006.650
`
`DELL
`
`

`

`SEC. 7.3
`
`SNMP-SIMPLE NETWORK MANAGEMENT PROTOCOL
`
`633
`
`management station proved who it was by putting a (plaintext) password in each
`message. In SNMPv2, security was improved considerably using modern crypto(cid:173)
`graphic techniques of the type we have already studied. However, this addition
`made an already bulky protocol every bulkier, and it was later thrown out.
`
`7.3.2. ASN.1-Abstract Syntax Notation 1
`
`The heart of the SNMP model is the set of objects managed by the agents and
`read and written by the management station. To make multivendor communica(cid:173)
`tion possible, it is essential that these objects be defined in a standard and
`vendor-neutral way. Furthermore, a standard way is needed to encode them for
`transfer over a network. While definitions in C would satisfy the first require(cid:173)
`ment, such definitions do not define a bit encoding on the wire in such a way that
`a 32-bit two's complement little endian management station can exchange infor(cid:173)
`mation unambiguously with am agent on a 16-bit one's complement big endian
`CPU.
`For this reason, a standard object definition language, along with encoding
`rules, is needed. The one used by SNMP is taken from OSI and called ASN.1
`(Abstract Syntax Notation One). Like much of OSI, it is large, complex, and
`not especially efficient. (The author is tempted to say that by calling it ASN .1
`instead of just ASN, the designers implicitly admitted that it would soon be
`replaced by ASN.2, but he will politely refrain from saying this.) The one alleged
`strength of ASN.1 (the existence of unambiguous bit encoding rules) is now really
`a weakness, because the encoding rules are optimized to minimize the number of
`bits on the wire, at the cost of wasting CPU time at both ends encoding and
`decoding them. A simpler scheme, using 32-bit integers aligned on 4-byte boun(cid:173)
`daries would probably have been better. Nevertheless, for better or worse, SNMP
`is drenched in ASN. l, (albeit a simplified subset of it), so anyone wishing to truly
`understand SNMP must become fluent in ASN. l. Hence the following explana(cid:173)
`tion.
`Let us start with the data description language, described in International
`Standard 8824. After that we will discuss the encoding rules, described in Inter(cid:173)
`national Standard 8825. The ASN .1 abstract syntax is essentially a primitive data
`declaration language. It allows the user to define primitive objects and then com(cid:173)
`bine them into more complex ones. A series of declarations in ASN.1 is function(cid:173)
`ally similar to the declarations found in the header files associated with many C
`programs.
`SNMP has some lexical conventions that we will follow. These are not
`entirely the same as pure ASN.l uses, however. Built-in data types are written in
`uppercase (e.g., INTEGER). User-defined types begin with an uppercase letter
`but must contain at least one character other than an uppercase letter. Identifiers
`may contain upper and lowercase letters, digits, and hyphens, but must begin with
`a lowercase letter (e.g., counter). White space (tabs, carriage returns, etc.) is not
`
`Ex.1006.651
`
`DELL
`
`

`

`634
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`significant. Finally, comments start with -- and continue until the end of the line
`or the next occurrence of --.
`The ASN.l basic data types allowed in SNMP are shown in Fig. 7-31. (We
`will generally ignore features of ASN. l, such as BOOLEAN and REAL types, not
`permitted in SNMP.) The use of the codes will be described later.
`
`Primitive type
`
`Meaning
`
`Code
`
`INTEGER
`
`BIT STRING
`
`Arbitrary length integer
`
`A string of O or more bits
`
`OCTET STRING
`
`A string of O of more unsigned bytes
`
`NULL
`
`A place holder
`
`OBJECT IDENTIFIER
`
`An officially defined data type
`
`2
`
`3
`
`4
`
`5
`
`6
`
`Fig. 7-31. The ASN. l primitive data types permitted in SNMP.
`A variable of type INTEGER may, in theory, take on any integral value, but
`other SNMP rules limit the range. As an example of how types are used, consider
`how a variable, count, of type INTEGER would be declared and (optionally) ini(cid:173)
`tialized to 100 in ASN.1:
`
`count INTEGER::= 100
`
`Often a subtype whose variables are restricted to specific values or to a specific
`range is required. These can be declared as follows:
`
`Status::= INTEGER { up(1), down(2), unknown(3)}
`
`PacketSize ::=INTEGER (0 .. 1023)
`
`Variables of type BIT STRING and OCTET STRING contain zero or more bits
`and bytes, respectively. A bit is either 0 or 1. A byte falls in the range 0 to 255,
`inclusive. For both types, a string length and an initial value may be given.
`OBJECT IDENTIFIERs provide a way of identifying objects. In principle,
`every object defined in every official standard can be uniquely identified. The
`mechanism that is used is to define a standards tree, and place every object in
`every standard at a unique location in the tree. The portion of the tree that
`includes the SNMP MIB is shown in Fig. 7-32.
`The top level of the tree lists all the important standards organizations in the
`world (in ISO's view), namely ISO and CCITT (now ITU), plus the combination
`of the two. From the iso node, four arcs are defined, one of which is for
`identified-organization, which is ISO's concession that maybe some other folks
`are vaguely involved with standards, too. The U.S. Dept. of Defense has been
`assigned a place in this subtree, and DoD has assigned the Internet number 1 in its
`hierarchy. Under the Internet hierarchy, the SNMP MIB has code 1.
`
`Ex.1006.652
`
`DELL
`
`

`

`SEC. 7.3
`
`SNMP-SIMPLE NETWORK MANAGEMENT PROTOCOL
`
`635
`
`-----~
`
`iso (1)
`
`joint-iso-ccitt (2)
`
`ccitt (0)
`
`standard (0)
`
`registration(cid:173)
`authority (1)
`
`member(cid:173)
`body (2)
`
`identified(cid:173)
`organization (3)
`
`I
`
`dod (6)
`
`internet (1)
`
`directory (1) mgmt (2) experimental (3) private (4) security (5)
`
`snmpv2 (6)
`
`mib-2 (1)
`
`I
`~~:::::::::::::::::::::---
`
`system (1)
`
`interface (2)
`
`ip (4)
`
`icmp (5)
`
`tcp (6) udp (7) egp (8)
`
`transmission (10) sample (11)
`
`Fig. 7-32. Part of the ASN.1 object naming tree.
`
`Every arc in Fig. 7-32 has both a label and a number, so nodes can be identi(cid:173)
`fied by a list of arcs, using label(number) or numbers. Thus all SNMP MIB
`objects are identified by a label of the form
`
`{iso identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1) ... }
`
`or alternatively { 1 3 6 1 2 1 ... } . Mixed forms are also permitted. For example,
`the above identification can also be written as
`
`{internet( 1) 2 1 ... }
`
`In this way, every object in every standard can be represented as an OBJECT
`IDENTIFIER.
`ASN .1 defines five ways to construct new types from the basic ones.
`SEQUENCE is an ordered list of types, similar to a structure in C and a record in
`Pascal. SEQUENCE OF is a one-dimensional array of a single type. SET and
`SET OF are analogous, but unordered. CHOICE creates a union from a given list
`of types. The two set constructors are not used in any of the SNMP documents.
`Another way to create new types is to tag old ones. Tagging a type is some(cid:173)
`what similar to the practice in C of defining new types, say time_t and size_t, both
`of which are longs, but which are used in different contexts. Tags come in four
`
`Ex.1006.653
`
`DELL
`
`

`

`636
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`categories: universal, application-wide, context-specific and private. Each tag
`consists of a label and an integer identifying the tag. For example,
`
`Counter32 ::=[APPLICATION 1] INTEGER (0 . .4294967295)
`
`Gauge32
`
`::=[APPLICATION 2] INTEGER (0 . .4294967295)
`
`define two different application-wide types, both of which are implemented by
`32-bit unsigned integers, but which are conceptually different. The former might,
`for example, wrap around when it gets to the maximum value, whereas the latter
`might just continue to return the maximum value until its is decreased or reset.
`A tagged type can have the keyword IMPLICIT after the closing square
`bracket when the type of what follows is obvious from the context (not true in a
`CHOICE, for example). Doing so allows a more efficient bit encoding since the
`tag does not have to be transmitted. In a type involving a CHOICE between two
`different types, a tag must be transmitted to tell the receiver which type is present.
`ASN.1 defines a complex macro mechanism, which is heavily used in SNMP.
`A macro can be used as a kind of prototype to generate a set of new types and
`values, each with its own syntax. Each macro defines some (possibly optional)
`keywords, that are used in the call to identify which parameter is which (i.e., the
`macro parameters are identified by keyword, not by position). The details of how
`ASN. l macros work is beyond the scope of this book. Suffice it to say that a
`macro is invoked by giving its name and then listing (some of) its keywords and
`their values for this invocation. Macros are expanded at compile time, not at run
`time. Some examples of macros will be cited below.
`
`ASN.1 Transfer Syntax
`
`An ASN.l transfer syntax defines how values of ASN.l types are unambigu(cid:173)
`ously converted to a sequence of bytes for transmission (and unambiguously
`decoded at the other end). The transfer syntax used by ASN. l is called BER
`(Basic Encoding Rules). ASN.l has other transfer syntaxes that SNMP does not
`use. The rules are recursive, so the encoding of a structured object is just the con(cid:173)
`catenation of the encodings of the component objects. In this way, all object
`encodings can be reduced to a well-defined sequence of encoded primitive
`objects. The encoding of these objects, in turn, is defined by the BER.
`The guiding principle behind the basic encoding rules is that every value
`transmitted, both primitive and constructed ones, consists of up to four fields:
`
`1. The identifier (type or tag).
`
`2. The length of the data field, in bytes.
`
`3. The data field.
`
`4. The end-of-contents flag, if the data length is unknown.
`
`Ex.1006.654
`
`DELL
`
`

`

`

`

`638
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`bits. The solution chosen is to transmit I byte before the actual bit string telling
`how many bits (0 through 7) of the final byte are unused. Thus the encoding of
`the 9-bit string '010011111' would be 07, 4F, 80 (hexadecimal).
`Octet strings are easy. The bytes of the string are just transmitted in standard
`big endian style, left to right.
`The null value is indicated by setting the length field to 0. No numerical
`value is actually transmitted.
`An OBJECT IDENTIFIER
`the sequence of integers it
`is encoded as
`represents. For example; the Internet is {I, 3, 6, 1}. However, since the first
`number is always 0, 1, or 2, and the second is less than 40 (by definition-ISO
`simply will not recognize the 41 st category to show up on its doorstep), the first
`two numbers, a and b, are encoded as I byte having the value 40a + b. For the
`Internet, this number is 43. As usual, numbers exceeding 127 are encoded in mul(cid:173)
`tiple bytes, the first of which contains the high-order bit set to I and a byte count
`in the other 7 bits.
`Both sequence types are transmitted by first sending the type or tag, then the
`total length of the encoding for all the fields, followed by the fields themselves.
`The fields are sent in order.
`The encoding of a CHOICE value is the same as the encoding of the actual
`data structure being transferred.
`An example showing encoding of some values is given in Fig. 7-34. The
`values encoded are the INTEGER 49, the OCTET STRING '110', "xy", the only
`possible value for NULL, the OBJECT IDENTIFIER for the Internet { 1, 3, 6, 1},
`and a Gauge32 value of 14.
`
`Tag
`type
`
`Tag
`Number
`
`\
`l
`Value
`Length
`I o oioio o o 1 oi I o o o o o o o 1] Io o 1 1 o o o 1 i
`
`Integer 49
`
`Bit String ·11 O' I o oioio o o 1 111 o o o o o o 1 o] Io o o o o 1 o 1 i i 1 1 o o o o o ~
`
`Octet String
`
`I o oiolo o 1 o oi Io o o o o o 1 o] Io 1 1 1 1 o o o 11 o 1 1 1 1 o o 1 I
`
`NULL
`
`Io oioio o 1 o 1 i i o o o o o o o oi
`
`Internet object
`
`I o oioio o 1 1 oi i o o o o o o 1 1] i o o 1 o 1 o 1 111 o o o o o 1 1 o 11 o o o o o o o 1 i
`
`Gauge 32 14
`
`Io 1 ioio o o 1 ol Io o o o o o o 1 J Io o o o 1 1 1 o I
`
`Fig. 7-34. ASN. l encoding of some example values.
`
`Ex.1006.656
`
`DELL
`
`

`

`SEC. 7.3
`
`SNMP-SIMPLE NETWORK MANAGEMENT PROTOCOL
`
`639
`
`7.3.3. SMI-Structure of Management Information
`
`In the preceding section, we have discussed only those parts of ASN.l that are
`used in SNMP. In reality, the SNMP documents are organized differently. RFC
`1442 first says that ASN.1 will be used to describe SNMP data structures, then it
`goes on for 57 pages scratching out parts of the ASN.1 standard that it does not
`want and adding new definitions (in ASN.1) that are needed. In particular, RFC
`1442 defines four key macros and eight new data types that are heavily used
`throughout SNMP. It is this sub-super-set of ASN.1, which goes by the ungainly
`name of SMI (Structure of Management Information), that is really used to
`define the SNMP data structures.
`Although this approach is somewhat bureaucratic, some rules and regulations
`are necessary if products from hundreds of vendors are expected to talk to one
`another and actually understand what the others are saying. A few words about
`SMI are therefore now in order.
`At the lowest level, SNMP variabks are defined as individual objects.
`Related objects are collected together into groups, and groups are assembled into
`modules. For example, groups exist for IP objects and TCP objects. A router
`might support the IP group, si