blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
2.1. Changes from RFC 1253 Connected: An Internet Encyclopedia
2.1. Changes from RFC 1253

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1850
Up: 2. Overview
Prev: 2. Overview
Next: 2.2. Textual Conventions

2.1. Changes from RFC 1253

2.1. Changes from RFC 1253

The changes from RFC 1253 are the following:

  1. The textual convention PositiveInteger was changed from 1..'FFFFFFFF'h to 1..'7FFFFFFF'h at the request of Marshall Rose.

  2. The textual convention TOSType was changed to reflect the TOS values defined in the Router Requirements Draft, and in accordance with the IP Forwarding Table MIB's values.

  3. The names of some objects were changed, conforming to the convention that an acronym (for example, LSA) is a single word ("Lsa") in most SNMP names.

  4. textual changes were made to make the MIB readable by Dave Perkins' SMIC MIB Compiler in addition to Mosy. This involved changing the case of some characters in certain names and removing the DEFVAL clauses for Counters.

  5. The variables ospfAreaStatus and ospfIfStatus were added, having been overlooked in the original MIB.

  6. The range of the variable ospfLsdbType was extended to include multicastLink (Group-membership LSA) and nssaExternalLink (NSSA LSA).

  7. The variable ospfIfMetricMetric was renamed ospfIfMetricValue, and the following text was removed from its description:

    "The value FFFF is distinguished to mean 'no route via this TOS'."

  8. The variable ospfNbmaNbrPermanence was added, with the values 'dynamic' and 'permanent'; by this means, dynamically learned and configured neighbors can be distinguished.

  9. The DESCRIPTION of the variable ospfNbrIpAddr was changed from

    "The IP address of this neighbor."

    to

    "The IP address this neighbor is using in its IP Source Address. Note that, on addressless links, this will not be 0.0.0.0, but the address of another of the neighbor's interfaces."

    This is by way of clarification and does not change the specification.

  10. The OSPF External Link State Database was added. The OSPF Link State Database used to display all LSAs stored; in this MIB, it displays all but the AS External LSAs. This is because there are usually a large number of External LSAs, and they are relicated in all non-Stub Areas.

  11. The variable ospfAreaSummary was added to control the import of summary LSAs into stub areas. If it is noAreaSummary (default) the router will neither originate nor propagate summary LSAs into the stub area. It will rely entirely on its default route. If it is sendAreaSummary, the router will both summarize and propagate summary LSAs.

  12. The general variables ospfExtLsdbLimit and ExitOverflowInterval were introduced to help handle LSDB overflow.

  13. The use of the IP Forwarding Table is defined.

  14. The ospfAreaRangeTable was obsoleted and replaced with the ospfAreaAggregateTable to accommodate two additional indexes. The ospfAreaAggregateEntry keys now include a LsdbType (which can be used to differentiate between the traditional type-3 Aggregates and NSSA Aggregates) and an ospfAreaAggregateMask (which will more clearly express the range).

  15. The variable ospfAreaAggregateEffect was added. This permits the network manager to hide a subnet within an area.

  16. Normally, the border router of a stub area advertises a default route as an OSPF network summary. An NSSA border router will generate a type-7 LSA indicating a default route, and import it into the NSSA. ospfStubMetricType (ospf internal, type 1 external, or type 2 external) indicates the type of the default metric advertised.

  17. ospfMulticastExtensions is added to the OSPF General Group. This indicates the router's ability to forward IP multicast (Class D) datagrams.

  18. ospfIfMulticastForwarding is added to the Interface Group. It indicates whether, and if so, how, multicasts should be forwarded on the interface.

  19. The MIB is converted to SNMP Version 2. Beyond simple text changes and the addition of the MODULE-IDENTITY and MODULE-COMPLIANCE macros, this involved trading the TruthValue Textual Convention for SNMP Version 2's, which has the same values, and trading the Validation Textual Convention for SNMP Version 2's RowStatus.

  20. ospfAuthType (area authentication type) was changed to an interface authentication type to match the key. It also has an additional value, to indicate the use of MD5 for authentication.

  21. ospfIfIntfType has a new value, pointToMultipoint.

  22. ospfIfDemand (read/write) is added, to permit control of Demand OSPF features.

  23. ospfNbrHelloSuppressed and ospfVirtNbrHelloSuppressed were added, (read only). They indicate whether Hellos are being suppressed to the neighbor.

  24. ospfDemandExtensions was added to indicate whether the Demand OSPF extensions have been implemented, and to disable them if appropriate.


Next: 2.2. Textual Conventions

Connected: An Internet Encyclopedia
2.1. Changes from RFC 1253

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609