draft-ietf-rsvp-mib-09.txt   rfc2206.txt 
Internet Draft RSVP MIB July 1997 Network Working Group F. Baker
Request for Comments: 2206 Cisco Systems
RSVP Management Information Base Category: Standards Track J. Krawczyk
draft-ietf-rsvp-mib-09.txt ArrowPoint Communications
A. Sastry
Thu Jul 10 14:54:59 PDT 1997 Cisco Systems
September 1997
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
fred@cisco.com
John Krawczyk
ArrowPoint Communications
235 Littleton Road
Westford, Massachusetts 01886
jjk@tiac.net
Arun Sastry
Cisco Systems
210 W. Tasman Drive
San Jose, California 95134
arun@cisco.com RSVP Management Information Base using SMIv2
1. Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are This document specifies an Internet standards track protocol for the
working documents of the Internet Engineering Task Force Internet community, and requests discussion and suggestions for
(IETF), its Areas, and its Working Groups. Note that other improvements. Please refer to the current edition of the "Internet
groups may also distribute working documents as Internet Official Protocol Standards" (STD 1) for the standardization state
Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of six Abstract
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 This memo defines a portion of the Management Information Base (MIB)
Internet Draft directory to learn the current status of this for use with network management protocols in TCP/IP-based internets.
or any other Internet Draft. In particular, it defines objects for managing the Resource
Reservation Protocol (RSVP) within the interface attributes defined
in the Integrated Services Model. Thus, the Integrated Services MIB
is directly relevant to and cross-referenced by this MIB. Comments
should be made to the RSVP Working Group, rsvp@isi.edu.
2. Abstract Table of Contents
This memo defines a portion of the Management Information Base 1 The SNMPv2 Network Management Framework ............... 2
(MIB) for use with network management protocols in TCP/IP- 1.1 Object Definitions .................................. 2
based internets. In particular, it defines objects for 2 Overview .............................................. 3
managing the Resource Reservation Protocol (RSVP) within the 2.1 Textual Conventions ................................. 3
interface attributes defined in the Integrated Services Model. 2.2 Structure of MIB .................................... 3
Thus, the Integrated Services MIB is directly relevant to and 2.3 Semantics of Writing the Path and Reservation
cross-referenced by this MIB. Comments should be made to the State Databases .................................... 3
RSVP Working Group, rsvp@isi.edu. 2.4 Intended use of Flow Notifications .................. 4
2.4.1 The lostFlow Notification ......................... 4
2.4.2 The newFlow Notification .......................... 4
3 Definitions ........................................... 4
3.1 RSVP Session Statistics Database .................... 6
3.2 RSVP Session Sender Database ........................ 9
3.3 RSVP Reservations Requested Database ................ 25
3.4 RSVP Reservation Requests Database .................. 35
3.5 RSVP Interface Attributes Database .................. 44
3.6 RSVP Neighbor Database .............................. 48
3.7 Notifications ....................................... 49
4 Security Considerations................................ 63
5 Authors' Addresses .................................... 63
6 Acknowledgements ...................................... 63
7 References ............................................ 64
This memo does not, in its draft form, specify a standard for 1. The SNMPv2 Network Management Framework
the Internet community.
3. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major
components. They are:
The SNMPv2 Network Management Framework consists of four major o RFC 1441 which defines the SMI, the mechanisms used for
components. They are: describing and naming objects for the purpose of
management.
o RFC 1441 which defines the SMI, the mechanisms used for o STD 17, RFC 1213 defines MIB-II, the core set of managed
describing and naming objects for the purpose of objects for the Internet suite of protocols.
management.
o RFC 1213 defines MIB-II, the core set of managed objects o RFC 1445 which defines the administrative and other
for the Internet suite of protocols. architectural aspects of the framework.
o RFC 1445 which defines the administrative and other o RFC 1448 which defines the protocol used for network
architectural aspects of the framework. access to managed objects.
o RFC 1448 which defines the protocol used for network The Framework permits new objects to be defined for the purpose of
access to managed objects. experimentation and evaluation.
The Framework permits new objects to be defined for the 1.1. Object Definitions
purpose of experimentation and evaluation.
3.1. Object Definitions 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)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. 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 descriptor, to refer to the
object type.
Managed objects are accessed via a virtual information store, 2. Overview
termed the Management Information Base or MIB. Objects in the
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) defined in the SMI. In particular, each object
type is named by an OBJECT IDENTIFIER, an administratively
assigned name. 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 descriptor, to refer to the object type.
4. Overview 2.1. Textual Conventions
4.1. Textual Conventions Several new data types are introduced as a textual convention in this
MIB document. These textual conventions enhance the readability of
the specification and can ease comparison with other specifications
if appropriate. It should be noted that the introduction of the
these textual conventions has no effect on either the syntax nor the
semantics of any managed objects. The use of these is merely an
artifact of the explanatory method used. Objects defined in terms of
one of these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or the SNMP
are necessary to accommodate these textual conventions which are
adopted merely for the convenience of readers and writers in pursuit
of the elusive goal of clear, concise, and unambiguous MIB documents.
Several new data types are introduced as a textual convention 2.2. Structure of MIB
in this MIB document. These textual conventions enhance the
readability of the specification and can ease comparison with
other specifications if appropriate. It should be noted that
the introduction of the these textual conventions has no
effect on either the syntax nor the semantics of any managed
objects. The use of these is merely an artifact of the
explanatory method used. Objects defined in terms of one of
these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or
the SNMP are necessary to accommodate these textual
conventions which are adopted merely for the convenience of
readers and writers in pursuit of the elusive goal of clear,
concise, and unambiguous MIB documents.
4.2. Structure of MIB The MIB is composed of the following sections:
The MIB is composed of the following sections: General Objects
General Objects Session Statistics Table
Session Statistics Table Session Sender Table
Session Sender Table Reservation Requests Received Table
Reservation Requests Received Table Reservation Requests Forwarded Table
Reservation Requests Forwarded Table RSVP Interface Attributes Table
RSVP Interface Attributes Table RSVP Neighbor Table
RSVP Neighbor Table
As a general rule, it is difficult in SNMP to describe As a general rule, it is difficult in SNMP to describe arbitrarily
arbitrarily long of complex messages; this MIB therefore seeks long of complex messages; this MIB therefore seeks to describe the
to describe the Path State Database and the Reservation State Path State Database and the Reservation State Database as though each
Database as though each flow and filter description received flow and filter description received in an aggregate message had been
in an aggregate message had been received in a separate received in a separate reservation message.
reservation message.
Thus, if a RESV message is received for session Thus, if a RESV message is received for session 224.1.2.3+UDP+4455
224.1.2.3+UDP+4455 with two filter/flow spec groups describing with two filter/flow spec groups describing a sender 1.2.3.4 and
a sender 1.2.3.4 and another sender 1.2.7.8, these two will another sender 1.2.7.8, these two will show in the MIB as two
show in the MIB as two separate rows: one for separate rows: one for 224.1.2.3+UDP+4455 from 1.2.3.4 and the other
224.1.2.3+UDP+4455 from 1.2.3.4 and the other for for 224.1.2.3+UDP+4455 from 1.2.7.8.
224.1.2.3+UDP+4455 from 1.2.7.8.
4.3. Semantics of Writing the Path and Reservation State 2.3. Semantics of Writing the Path and Reservation State Databases
Databases
The path and reservation state tables are writeable. Writing The path and reservation state tables are writeable. Writing into the
into the Path and Reservation State databases allows one to Path and Reservation State databases allows one to perform RSVP
perform RSVP reservations without authenticating through RSVP reservations without authenticating through RSVP mechanisms, but
mechanisms, but rather through SNMP mechanisms. State created rather through SNMP mechanisms. State created in this way by SNMP
in this way by SNMP does not time out and cannot be deleted by does not time out and cannot be deleted by receiving an RSVP teardown
receiving an RSVP teardown message; it can only be deleted by message; it can only be deleted by SNMP. Deletion is accomplished by
SNMP. Deletion is accomplished by writing 'destroy' to the writing 'destroy' to the associated Row Status object, and this will
associated Row Status object, and this will initiate a initiate a teardown message as if the state had timed out.
teardown message as if the state had timed out.
4.4. Intended use of Flow Notifications 2.4. Intended use of Flow Notifications
4.4.1. The lostFlow Notification 2.4.1. The lostFlow Notification
The Lost Flow notification is an asychronous event that The Lost Flow notification is an asychronous event that signifies
signifies that a flow is no longer being observed. that a flow is no longer being observed.
4.4.2. The newFlow Notification 2.4.2. The newFlow Notification
The newFlow Notification defined in this MIB can be used to The newFlow Notification defined in this MIB can be used to advise a
advise a network management system of the state of a flow. network management system of the state of a flow.
5. Definitions 3. Definitions
RSVP-MIB DEFINITIONS ::= BEGIN RSVP-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Gauge32, MODULE-IDENTITY, OBJECT-TYPE, Gauge32,
NOTIFICATION-TYPE, Integer32, experimental NOTIFICATION-TYPE, Integer32, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TruthValue, RowStatus, TEXTUAL-CONVENTION, TruthValue, RowStatus,
TimeStamp, TestAndIncr, TimeInterval TimeStamp, TestAndIncr, TimeInterval
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF NOTIFICATION-GROUP FROM SNMPv2-CONF
Port, SessionNumber, SessionType, Port, SessionNumber, SessionType,
Protocol, QosService, intSrvFlowStatus, Protocol, QosService, intSrvFlowStatus,
MessageSize, BitRate, BurstSize FROM INTEGRATED-SERVICES-MIB MessageSize, BitRate, BurstSize
FROM INTEGRATED-SERVICES-MIB
ifIndex, InterfaceIndex FROM IF-MIB; ifIndex, InterfaceIndex FROM IF-MIB;
rsvp MODULE-IDENTITY rsvp MODULE-IDENTITY
LAST-UPDATED "9511030500Z" -- Thu Jul 10 14:54:59 PDT 1997 LAST-UPDATED "9511030500Z" -- Thu Aug 28 09:03:53 PDT 1997
ORGANIZATION "IETF RSVP Working Group" ORGANIZATION "IETF RSVP Working Group"
CONTACT-INFO CONTACT-INFO
" Fred Baker " Fred Baker
Postal: Cisco Systems Postal: Cisco Systems
519 Lado Drive 519 Lado Drive
Santa Barbara, California 93111 Santa Barbara, California 93111
Tel: +1 805 681 0115 Tel: +1 805 681 0115
E-Mail: fred@cisco.com E-Mail: fred@cisco.com
John Krawczyk John Krawczyk
Postal: ArrowPoint Communications Postal: ArrowPoint Communications
235 Littleton Road 235 Littleton Road
Westford, Massachusetts 01886 Westford, Massachusetts 01886
Tel: +1 508 692 5875 Tel: +1 508 692 5875
E-Mail: jjk@tiac.net E-Mail: jjk@tiac.net
Arun Sastry Arun Sastry
Postal: Cisco Systems Postal: Cisco Systems
210 W. Tasman Drive 210 W. Tasman Drive
skipping to change at page 7, line 31 skipping to change at page 5, line 19
E-Mail: jjk@tiac.net E-Mail: jjk@tiac.net
Arun Sastry Arun Sastry
Postal: Cisco Systems Postal: Cisco Systems
210 W. Tasman Drive 210 W. Tasman Drive
San Jose, California 95134 San Jose, California 95134
Tel: +1 408 526 7685 Tel: +1 408 526 7685
E-Mail: arun@cisco.com" E-Mail: arun@cisco.com"
DESCRIPTION DESCRIPTION
"The MIB module to describe the RSVP Protocol" "The MIB module to describe the RSVP Protocol"
::= { experimental 71 } ::= { mib-2 51 }
rsvpObjects OBJECT IDENTIFIER ::= { rsvp 1 } -- tables rsvpObjects OBJECT IDENTIFIER
rsvpGenObjects OBJECT IDENTIFIER ::= { rsvp 2 } -- global objects ::= { rsvp 1 } -- tables
rsvpNotificationsPrefix OBJECT IDENTIFIER ::= { rsvp 3 } -- traps rsvpGenObjects OBJECT IDENTIFIER
rsvpConformance OBJECT IDENTIFIER ::= { rsvp 4 } -- conformance ::= { rsvp 2 } -- global objects
rsvpNotificationsPrefix OBJECT IDENTIFIER
::= { rsvp 3 } -- traps
rsvpConformance OBJECT IDENTIFIER
::= { rsvp 4 } -- conformance
RsvpEncapsulation ::= TEXTUAL-CONVENTION RsvpEncapsulation ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This indicates the encapsulation that an RSVP "This indicates the encapsulation that an RSVP
Neighbor is perceived to be using." Neighbor is perceived to be using."
SYNTAX INTEGER { SYNTAX INTEGER {
ip (1), -- IP Protocol 46 ip (1), -- IP Protocol 46
udp (2), -- UDP Encapsulation udp (2), -- UDP Encapsulation
both (3) -- neighbor is using both encapsulations both (3) -- neighbor is using both encapsulations
skipping to change at page 65, line 9 skipping to change at page 49, line 44
be used to configure neighbors. In the pres- be used to configure neighbors. In the pres-
ence of configured neighbors, the implementa- ence of configured neighbors, the implementa-
tion may (but is not required to) limit the set tion may (but is not required to) limit the set
of valid neighbors to those configured." of valid neighbors to those configured."
::= { rsvpNbrEntry 3 } ::= { rsvpNbrEntry 3 }
-- --
-- Notifications used to signal events -- Notifications used to signal events
-- --
rsvpNotifications OBJECT IDENTIFIER ::= { rsvpNotificationsPrefix 0 } rsvpNotifications OBJECT IDENTIFIER
::= { rsvpNotificationsPrefix 0 }
newFlow NOTIFICATION-TYPE newFlow NOTIFICATION-TYPE
OBJECTS { OBJECTS {
intSrvFlowStatus, rsvpSessionDestAddr, intSrvFlowStatus, rsvpSessionDestAddr,
rsvpResvFwdStatus, rsvpResvStatus, rsvpSenderStatus rsvpResvFwdStatus, rsvpResvStatus, rsvpSenderStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The newFlow trap indicates that the originat- "The newFlow trap indicates that the originat-
ing system has installed a new flow in its ing system has installed a new flow in its
skipping to change at page 78, line 13 skipping to change at page 60, line 46
::= { rsvpGroups 1 } ::= { rsvpGroups 1 }
rsvpSenderGroup OBJECT-GROUP rsvpSenderGroup OBJECT-GROUP
OBJECTS { OBJECTS {
rsvpSenderType, rsvpSenderDestAddr, rsvpSenderAddr, rsvpSenderType, rsvpSenderDestAddr, rsvpSenderAddr,
rsvpSenderDestAddrLength, rsvpSenderAddrLength, rsvpSenderDestAddrLength, rsvpSenderAddrLength,
rsvpSenderProtocol, rsvpSenderDestPort, rsvpSenderPort, rsvpSenderProtocol, rsvpSenderDestPort, rsvpSenderPort,
rsvpSenderHopAddr, rsvpSenderHopLih, rsvpSenderInterface, rsvpSenderHopAddr, rsvpSenderHopLih, rsvpSenderInterface,
rsvpSenderTSpecRate, rsvpSenderTSpecPeakRate, rsvpSenderTSpecRate, rsvpSenderTSpecPeakRate,
rsvpSenderTSpecBurst, rsvpSenderTSpecMinTU, rsvpSenderTSpecBurst, rsvpSenderTSpecMinTU,
rsvpSenderTSpecMaxTU, rsvpSenderInterval, rsvpSenderLastChange, rsvpSenderTSpecMaxTU, rsvpSenderInterval,
rsvpSenderStatus, rsvpSenderRSVPHop, rsvpSenderPolicy, rsvpSenderLastChange, rsvpSenderStatus,
rsvpSenderRSVPHop, rsvpSenderPolicy,
rsvpSenderAdspecBreak, rsvpSenderAdspecHopCount, rsvpSenderAdspecBreak, rsvpSenderAdspecHopCount,
rsvpSenderAdspecPathBw, rsvpSenderAdspecMinLatency, rsvpSenderAdspecPathBw, rsvpSenderAdspecMinLatency,
rsvpSenderAdspecMtu, rsvpSenderAdspecGuaranteedSvc, rsvpSenderAdspecMtu, rsvpSenderAdspecGuaranteedSvc,
rsvpSenderAdspecGuaranteedBreak, rsvpSenderAdspecGuaranteedBreak,
rsvpSenderAdspecGuaranteedCtot, rsvpSenderAdspecGuaranteedDtot, rsvpSenderAdspecGuaranteedCtot,
rsvpSenderAdspecGuaranteedCsum, rsvpSenderAdspecGuaranteedDsum, rsvpSenderAdspecGuaranteedDtot,
rsvpSenderAdspecGuaranteedCsum,
rsvpSenderAdspecGuaranteedDsum,
rsvpSenderAdspecGuaranteedHopCount, rsvpSenderAdspecGuaranteedHopCount,
rsvpSenderAdspecGuaranteedPathBw, rsvpSenderAdspecGuaranteedPathBw,
rsvpSenderAdspecGuaranteedMinLatency, rsvpSenderAdspecGuaranteedMinLatency,
rsvpSenderAdspecGuaranteedMtu, rsvpSenderAdspecCtrlLoadSvc, rsvpSenderAdspecGuaranteedMtu, rsvpSenderAdspecCtrlLoadSvc,
rsvpSenderAdspecCtrlLoadBreak, rsvpSenderAdspecCtrlLoadBreak,
rsvpSenderAdspecCtrlLoadHopCount, rsvpSenderAdspecCtrlLoadHopCount,
rsvpSenderAdspecCtrlLoadPathBw, rsvpSenderAdspecCtrlLoadPathBw,
rsvpSenderAdspecCtrlLoadMinLatency, rsvpSenderAdspecCtrlLoadMinLatency,
rsvpSenderAdspecCtrlLoadMtu, rsvpSenderNewIndex rsvpSenderAdspecCtrlLoadMtu, rsvpSenderNewIndex
} }
skipping to change at page 79, line 12 skipping to change at page 61, line 32
"These objects are required for RSVP Systems." "These objects are required for RSVP Systems."
::= { rsvpGroups 2 } ::= { rsvpGroups 2 }
rsvpResvGroup OBJECT-GROUP rsvpResvGroup OBJECT-GROUP
OBJECTS { OBJECTS {
rsvpResvType, rsvpResvDestAddr, rsvpResvSenderAddr, rsvpResvType, rsvpResvDestAddr, rsvpResvSenderAddr,
rsvpResvDestAddrLength, rsvpResvSenderAddrLength, rsvpResvDestAddrLength, rsvpResvSenderAddrLength,
rsvpResvProtocol, rsvpResvDestPort, rsvpResvPort, rsvpResvProtocol, rsvpResvDestPort, rsvpResvPort,
rsvpResvHopAddr, rsvpResvHopLih, rsvpResvInterface, rsvpResvHopAddr, rsvpResvHopLih, rsvpResvInterface,
rsvpResvService, rsvpResvTSpecRate, rsvpResvTSpecBurst, rsvpResvService, rsvpResvTSpecRate, rsvpResvTSpecBurst,
rsvpResvTSpecPeakRate, rsvpResvTSpecMinTU, rsvpResvTSpecMaxTU, rsvpResvTSpecPeakRate, rsvpResvTSpecMinTU,
rsvpResvRSpecRate, rsvpResvRSpecSlack, rsvpResvInterval, rsvpResvTSpecMaxTU, rsvpResvRSpecRate,
rsvpResvRSpecSlack, rsvpResvInterval,
rsvpResvScope, rsvpResvShared, rsvpResvExplicit, rsvpResvScope, rsvpResvShared, rsvpResvExplicit,
rsvpResvRSVPHop, rsvpResvLastChange, rsvpResvPolicy, rsvpResvRSVPHop, rsvpResvLastChange, rsvpResvPolicy,
rsvpResvStatus, rsvpResvNewIndex rsvpResvStatus, rsvpResvNewIndex
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"These objects are required for RSVP Systems." "These objects are required for RSVP Systems."
::= { rsvpGroups 3 } ::= { rsvpGroups 3 }
rsvpResvFwdGroup OBJECT-GROUP rsvpResvFwdGroup OBJECT-GROUP
OBJECTS { OBJECTS {
rsvpResvFwdType, rsvpResvFwdDestAddr, rsvpResvFwdSenderAddr, rsvpResvFwdType, rsvpResvFwdDestAddr, rsvpResvFwdSenderAddr,
rsvpResvFwdDestAddrLength, rsvpResvFwdSenderAddrLength, rsvpResvFwdDestAddrLength, rsvpResvFwdSenderAddrLength,
rsvpResvFwdProtocol, rsvpResvFwdDestPort, rsvpResvFwdPort, rsvpResvFwdProtocol, rsvpResvFwdDestPort, rsvpResvFwdPort,
rsvpResvFwdHopAddr, rsvpResvFwdHopLih, rsvpResvFwdInterface, rsvpResvFwdHopAddr, rsvpResvFwdHopLih, rsvpResvFwdInterface,
rsvpResvFwdNewIndex, rsvpResvFwdService, rsvpResvFwdNewIndex, rsvpResvFwdService,
rsvpResvFwdTSpecPeakRate, rsvpResvFwdTSpecMinTU, rsvpResvFwdTSpecPeakRate, rsvpResvFwdTSpecMinTU,
rsvpResvFwdTSpecMaxTU, rsvpResvFwdTSpecRate, rsvpResvFwdTSpecMaxTU, rsvpResvFwdTSpecRate,
rsvpResvFwdTSpecBurst, rsvpResvFwdRSpecRate, rsvpResvFwdTSpecBurst, rsvpResvFwdRSpecRate,
rsvpResvFwdRSpecSlack, rsvpResvFwdInterval, rsvpResvFwdScope, rsvpResvFwdRSpecSlack, rsvpResvFwdInterval,
rsvpResvFwdShared, rsvpResvFwdExplicit, rsvpResvFwdRSVPHop, rsvpResvFwdScope, rsvpResvFwdShared, rsvpResvFwdExplicit,
rsvpResvFwdLastChange, rsvpResvFwdPolicy, rsvpResvFwdStatus rsvpResvFwdRSVPHop, rsvpResvFwdLastChange,
rsvpResvFwdPolicy, rsvpResvFwdStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"These objects are optional, used for some RSVP "These objects are optional, used for some RSVP
Systems." Systems."
::= { rsvpGroups 4 } ::= { rsvpGroups 4 }
rsvpIfGroup OBJECT-GROUP rsvpIfGroup OBJECT-GROUP
OBJECTS { OBJECTS {
rsvpIfUdpNbrs, rsvpIfIpNbrs, rsvpIfNbrs, rsvpIfEnabled, rsvpIfUdpNbrs, rsvpIfIpNbrs, rsvpIfNbrs, rsvpIfEnabled,
skipping to change at page 81, line 4 skipping to change at page 63, line 6
rsvpNotificationGroup NOTIFICATION-GROUP rsvpNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { newFlow, lostFlow } NOTIFICATIONS { newFlow, lostFlow }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This notification is required for Systems sup- "This notification is required for Systems sup-
porting the RSVP Policy Module using an SNMP porting the RSVP Policy Module using an SNMP
interface to the Policy Manager." interface to the Policy Manager."
::= { rsvpGroups 8 } ::= { rsvpGroups 8 }
END END
6. Security Issues
Security issues for this MIB are entirely covered by the SNMP 4. Security Considerations
Security Architecture, and have not been expanded within the
contents of this MIB. RSVP has its own set of security issues,
which are outside the scope of this MIB.
7. Authors' Addresses The use of an SNMP SET results in an RSVP or Integrated Services
reservation under rules that are different compared to if the
reservation was negotiated using RSVP. However, no other security
considerations exist other than those imposed by SNMP itself.
Fred Baker 5. Authors' Addresses
Postal: Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Tel: +1 805 681 0115
E-Mail: fred@cisco.com
John Krawczyk Fred Baker
Postal: ArrowPoint Communications Postal: Cisco Systems
235 Littleton Road 519 Lado Drive
Westford, Massachusetts 01886 Santa Barbara, California 93111
Tel: +1 508 692 5875
E-Mail: jjk@tiac.net"
Arun Sastry Phone: +1 805 681 0115
Postal: Cisco Systems EMail: fred@cisco.com
210 W. Tasman Drive
San Jose, California 95134
Tel: +1 408 526 7685
E-Mail: arun@cisco.com
8. Acknowledgements John Krawczyk
Postal: ArrowPoint Communications
235 Littleton Road
Westford, Massachusetts 01886
This document was produced by the RSVP Working Group. Phone: +1 508 692 5875
EMail: jjk@tiac.net
9. References Arun Sastry
Postal: Cisco Systems
210 W. Tasman Drive
San Jose, California 95134
[1] M.T. Rose (editor), Management Information Base for Phone: +1 408 526 7685
Network Management of TCP/IP-based internets, Internet EMail: arun@cisco.com
Working Group Request for Comments 1213. Network
Information Center, SRI International, Menlo Park,
California, (May, 1990).
[2] Information processing systems - Open Systems 6. Acknowledgements
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[3] Information processing systems - Open Systems This document was produced by the RSVP Working Group.
Interconnection - Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
Table of Contents 7. References
1 Status of this Memo ................................... 1 [1] Rose, M., Editor, "Management Information Base for
2 Abstract .............................................. 2 Network Management of TCP/IP-based internets", STD 17,
3 The SNMPv2 Network Management Framework ............... 3 RFC 1213, May 1990.
3.1 Object Definitions .................................. 3
4 Overview .............................................. 3 [2] Information processing systems - Open Systems
4.1 Textual Conventions ................................. 3 Interconnection - Specification of Abstract Syntax
4.2 Structure of MIB .................................... 4 Notation One (ASN.1), International Organization for
4.3 Semantics of Writing the Path and Reservation Standardization. International Standard 8824, (December,
State Databases .................................... 4 1987).
4.4 Intended use of Flow Notifications .................. 5
4.4.1 The lostFlow Notification ......................... 5 [3] Information processing systems - Open Systems
4.4.2 The newFlow Notification .......................... 5 Interconnection - Specification of Basic Encoding Rules
5 Definitions ........................................... 6 for Abstract Notation One (ASN.1), International
5.1 RSVP Session Statistics Database .................... 8 Organization for Standardization. International Standard
5.1 RSVP Session Sender Database ........................ 12 8825, (December, 1987).
5.2 RSVP Reservations Requested Database ................ 32
5.3 RSVP Reservation Requests Database .................. 44
5.4 RSVP Interface Attributes Database .................. 57
5.5 RSVP Neighbor Database .............................. 62
5.4 Notifications ....................................... 64
6 Security Issues ....................................... 81
7 Authors' Addresses .................................... 81
8 Acknowledgements ...................................... 81
9 References ............................................ 82
 End of changes. 58 change blocks. 
196 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/