Internet Engineering Task Force                Walter Weiss
    RAP Working Group                              Ellacoya Networks
    Expiration: October 2002 May 2003                           John Vollbrecht
    draft-ietf-rap-access-bind-01.txt
    draft-ietf-rap-access-bind-02.txt              David Spence
                                                   David Rago
                                                   InterLink Networks
                                                   Cees de Laat
                                                   Leon Gommans
                                                   Univ. of Amsterdam
                                                   Freek Dijkstra
                                                   Univ. of Utrecht
                                                   Leon Gommans
                                                   Enterasys
                                                   Amol Kulkarni
                                                   Ravi Sahita
                                                   Intel
                                                   Kwok Ho Chan
                                                   Nortel Networks

         Framework for Binding Access Control to COPS Provisioning

                           Last Updated: 3/1/02 11/4/02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119].

   Status of this Memo................................................1
   Conventions used in this document..................................1
   Abstract...........................................................4
   1. Introduction....................................................4
   2. Paradigm for the Access Bind PIB.......................................6
   2.1 PIB................................6
   2.1. Event Handler Concepts.........................................6
   2.1.1 Concepts........................................6
   2.1.1. Example - Ethernet IP Address Authorization..................9
   2.2. Authorization.................9
   2.1.2. Context Data.................................................10
   2.3. Data...............................................10
   2.1.3. Policy Distribution and Management...........................11
   2.4. Management.........................11
   2.2. Event Handlers and Application-Specific PIBs.................12
   2.3. Passive Monitoring vs. Programmatic API......................12
   2.3.1. Interactions with DiffServ model.............................11
   2.5. Interactions with RSVP model.................................12 data path model.................13
   2.3.2. The Programmatic API to the Access Bind PIB................14
   3. Supporting various client Authentication Protocols.............14 Access Bind PIB................................................16
   3.1. Provisioning.................................................14
   3.2. EAP Authentication...........................................15
   3.2.1. EAP Message sequence.......................................15
   3.2.2. AuthEapReqExt and AuthEapRespExt data structures...........17
   3.3. PAP Authentication...........................................17
   3.3.1. PAP Connection sequence....................................18
   3.3.2. AuthPapExtEntry datastructure..............................19
   3.4. CHAP Authentication..........................................20
   3.4.1. CHAP Connection sequence...................................20
   3.4.2. AuthChapExtEntry datastructure.............................22
   3.5. HTTP Authentication..........................................23
   4. Data Structures................................................24
   4.1. The Event class..................................................24
   4.2. Handler............................................16
   3.1.1. Functional Description.....................................17
   3.1.2. Event Criteria behavior....................................18
   3.1.3. Context Data usage.........................................19
   3.1.4. Data Description...........................................19
   3.1.4.1. EventHandler class...........................................24
   4.3. class.......................................19
   3.1.4.2. EventHdlrElement class.......................................25
   4.4. class...................................20
   3.1.4.3. EventHdlrEventScope class....................................26
   4.5. class................................22
   3.1.4.4. EventHdlrHandleScope class...................................28
   4.6. class...............................23
   3.1.4.5. ContextData class........................................24
   3.2. Event Handling...............................................25
   3.2.1. Functional Description.....................................25
   3.2.2. COPS Client Handle.........................................26
   3.2.3. DiffServ element...........................................26
   3.2.4. Behavior of the Event and Handle Scope classes...............29
   4.7. EventHdlrAuthProtocol class..................................30
   4.8. DatapathEventHdlr Class......................................31
   4.9. ContextData class............................................31
   4.10. classes.............27
   3.2.5. Context Data Entries.......................................28
   3.2.6. Data Description...........................................28
   3.2.6.1. Event class..............................................29
   3.2.6.2. ContextData classes.........................................32
   4.10.1. classes......................................29
   3.2.6.2.1. CtxtL3Hdr class...........................................32
   4.10.2. class........................................29
   3.2.6.2.2. Ctxt802Hdr class..........................................33
   4.10.3. CtxtDialupInterface class.................................34
   4.10.4 CtxtDialupIfFramedProtocol class...........................35
   4.10.5 CtxtDialupIfLoginService class.............................36
   4.10.6 CtxtDialupIfLoginLat class.................................36
   4.11. class.......................................30
   4. Identity Extensions PIB module.................................32
   4.1. Functional Description.......................................32
   4.1.1. Provisioning...............................................32
   4.1.2. EAP Authentication.........................................33
   4.1.2.1. EAP Message sequence.....................................33
   4.1.3. PAP Authentication.........................................35
   4.1.3.1. PAP Connection sequence..................................35
   4.1.4. CHAP Authentication........................................36
   4.1.4.1. CHAP Connection sequence.................................37
   4.2. Data Description.............................................38
   4.2.1. IdentityEventHdlr Class....................................38
   4.2.2. EventHdlrAuthProtocol class................................39
   4.2.3. AuthExt class...............................................37
   4.11.1. class..............................................39
   4.2.4. UserAuthExt class.........................................37
   4.11.2. AuthChapExt class.........................................37
   4.11.3. AuthPapExt class..........................................38
   4.11.4. class..........................................40
   4.2.5. AuthExtResult class.......................................38
   4.11.5. class........................................40
   4.2.6. AuthEapReqExt class.......................................38
   4.11.6. and AuthEapRespExt class......................................39 classes...................40
   4.2.7. AuthPapExtEntry class......................................41
   4.2.8. AuthChapExtEntry class.....................................42
   5. Signal Handling................................................43
   5.1 Functional Description........................................43
   5.2 Data Description..............................................43
   6. Programmatic Interface Between Signal and Event Handling.......44
   6.1. Functional Description.......................................44
   6.2. Method Description...........................................45
   6.3. Access Bind API Example......................................46
   7. Message Types..................................................40
   5.1. Types..................................................49
   7.1. Event Handler Provisioning Decisions.........................40
   5.2. Decisions.........................49
   7.2. Provisioning Decision........................................41
   5.3. PEP Event Message............................................41
   5.4. Report..........................................50
   7.3. PDP Provisioning Decision....................................42
   5.5. Decision....................................51
   7.4. PDP fetching Event-specific ContextData......................42
   5.6. ContextData......................51
   7.5. Event-specific ContextData Response..........................43
   5.7. Response..........................52
   7.6. Opaque Decision..............................................43
   5.8. Decision..............................................52
   7.7. Opaque Report................................................43
   6. Report................................................52
   7.8. Combining Data Structures in Messages..........................45
   6.1. Combining Context Data in Event Messages.....................45
   7. Messages........................53
   8. Access Bind Usage Examples.....................................46
   7.1 Examples.....................................54
   8.1 Wireless LAN (802.11 Access Point) Usage Example..............46
   7.1.1 Example..............54
   8.1.1 Wireless LAN Access Event Handler Provisioning..............47
   7.1.2 Provisioning..............54
   8.1.2 Wireless LAN Access Event Handling..........................48
   7.1.3 Handling..........................54
   8.1.3 Wireless LAN Access Event Decision..........................48
   7.2 Decision..........................55
   8.2 RSVP Usage Example............................................49
   8. Example............................................55
   9. The AccessBind PIB Module......................................56
   9. Security Considerations.......................................104 Module......................................63
   10. References...................................................105 Identity Extensions PIB.......................................79
   11. Application Specific RSVP Handling PIB Module.................90
   12. Application Specific Dialup Handling PIB Module..............104
   13. Security Considerations......................................115
   14. References...................................................116
   15. Author Information and Acknowledgments.......................106 Acknowledgments.......................117

Abstract

   There is an ever-growing distinction between edge and core
   functionality. While the core continues to focus on stability and
   pure forwarding functionality, the edges increasingly need to deal
   with dynamic capabilities like QoS management, VPN encapsulations,
   encryption, dynamic steering and service monitoring. The dynamic
   deployment of these functions is dependent on specific contextual
   knowledge such as the physical location of the data stream and the
   identity of the client or system generating the data.

   In many environments, there is a requirement to both bind resource
   consumption to an identity or account, and also to quickly and
   efficiently provision the appropriate set of policies for that
   client or account. It is possible to provide this capability with a
   collection of currently available protocols. However, the
   synchronization of account and provisioning information between
   these protocols makes this approach extremely unwieldy.

   This memo offers a solution in the form of a single COPS PIB capable
   not only of supporting all the above requirements but also offering
   a scalable means for extending the provisioning capabilities as new
   technologies are standardized. Specifically, we offer a mechanism
   for provisioning the criteria for initiating dynamic event
   notifications from the PEP as well as a means for propagating
   identity credentials received by the PEP to allow the PDP to
   validate a client identity or an account as part of the event
   notification process.

1. Introduction

   There are two sides to access control. The one side is the
   negotiation between the client and the edge device (also known as
   the policy enforcement point), for example between a workstation and
   an Ethernet switch supporting authentication protocols like 802.1x
   and PPPoE. The other side of a typical access control model is an
   interaction between the edge device (PEP) and a PDP, such that the
   PDP performs the client/account validation process and notifies the
   PEP of the result. This separation of access control into two parts
   is necessary because invariably the PEP does not have the capacity
   to store all possible identities and credentials. This information
   is typically stored in a server (PDP).

   In reality access control can include authentication as one piece of
   a larger authorization process. As such, authorization has much in
   common with RSVP. RSVP [RSVP]. When an RSVP service request is made, the
   PDP evaluates a set of criteria including what is being requested,
   what the availability of specific resources are, the identity of the
   requestor, and even the location of the requestor. All these
   criteria are taken into consideration before determining whether the
   RSVP request should be honored. In addition, if the request is
   honored, specific provisioning actions may be taken to bound bind or
   manage the request. Similarly, the ability for a PDP to respond to a
   non-RSVP service request potentially requires all the same
   information of a traditional RSVP request in order to determine
   whether the request should be accepted or rejected.

   It is also important to note that a service request should not just
   be restricted to network access. In practice, there are many
   instances where a determination of access privileges requires an
   explicit decision. For instance, there are scenarios where limited
   network access is granted based on the specific criteria, but
   subsequent authorization is required to access a premium resource
   that requires incremental authentication (via HTTP for example).
   Another possible scenario occurs when initial access is authorized
   based on one set of credentials, but usage of a specific resource
   requires an examination of an account balance. These authorizations
   will be referred to as "PEP Events" _PEP Events_ to denote the fact that PEP is
   generating an event indicating a request for some type of service.

   In order to support the broad variety of potential PEP Events, there
   must be a way of provisioning the criteria for generating the PEP
   Event. In the most common case the PEP Event is generated as a the
   result of some type of packet oriented event such as activity on a
   link, traffic of a particular type or traffic from a new, unknown IP
   address.

   This leads to a useful observation: In many cases, PEP Events need
   to be defined within the context of a network data path. In other
   words, the data path mechanisms defined in the DiffServ informal
   model [MODEL] and the DiffServ PIB [DSPIB] provide a means for
   specifying the circumstances for generating a PEP Event by reusing
   elements from the model like the qosDatapathTable table and the
   qosClfrTable table in the DiffServ PIB.

   The second circumstance for generating an event from the PEP is
   through a programmatic interface in between the PEP and an external
   service such as the policy control interface in an RSVP service. In
   these instances, this PIB is used to configure the PEP to accept
   specific events through the API. Using COPS provisioning, a PEP can
   be configured to generate events for one or more types of RSVP
   events such as a new PATH request or a new RESV request.

   Another consideration is the variety of information that can
   potentially be included in a PEP Event. For instance, a PEP Event
   could pass information about the client (domain), the physical port
   (dial up interface), L2 headers, L3 headers, encapsulation headers
   (tunnels), cookies, and additional information already negotiated
   prior to generating the PEP Event. Given the amount of information
   that could be sent with the PEP Event, it is reasonable to allow the
   PDP to configure the PEP with the set of information the PDP would
   like to have included with a specific type of PEP Event.

   PEP Events provide a convenient means for the PEP to signal an event
   that requires specific actions. A PDP authorization for access to
   specific resources (and the potential verification of identity) is
   one example of an event that not only requires a response but also
   some potential provisioning work. It is interesting to note how
   neatly RSVP decision support fits into this model. In the original
   COPS design [COPS], the RESV request was sent in a COPS request and
   a COPS response message determined whether the reservation should be
   accepted or not. The enhancements provided by this PIB not only
   allow RSVP messages to generate PEP events (also called access requests,
   requests), but also explicitly provision QoS resources, using COPS-PR COPS-
   PR [COPSPR], to support the reservation. This generalizes COPS for
   RSVP and allows it to evolve to the COPS-PR model.

   There are a number of situations where Events and associated
   provisioning need to be negotiated quickly. Mobile-IP applications
   in particular require speedy resolution of PEP Events. This implies
   that the combination of PEP Events and provisioning needs to be
   completed with the minimum number of communication legs (round
   trips).

2. Paradigm for the Access Bind PIB

   There are several key aspects to this PIB. First there is the
   ability to provisioning for future authorization events, known as
   PEP Events. Second, there is a set of tables that are used to notify
   the PDP of an attempt to access managed resources. These tables can
   also include credentials necessary to verify client identity.
   Finally, there are tables that determine how dialogs (COPS Request
   Handles) between the PEP and PDP should be grouped. In order to
   provide concurrency between competing events and provisioning
   requests, there must be a means for determining which PEP Events
   require a new COPS Request Handle and which should use existing
   handles.

2.1

2.1. Event Handler Concepts

   This section introduces the concept of an Event Handler. Much of
   what is described in this paper is based on the Event Handler.

   Event Handlers are implemented in PEPs and configured by PDPs. Event
   Handlers are provisioned by standard COPS-PR protocol sequences. A
   PEP will announce what Event Handlers are available in the
   capabilities table of the COPS-PR Request message. The PDP will
   provision the Event Handlers with Decision messages.

   Once an Event Handler is provisioned it is responsible for
   identifying packets or API requests that require the PDP to be
   notified with an Event Message.

   The general model for Event Messages Message requests includes a client, a
   Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). In
   this model, the PEP is the interface to the client, and the Event
   Handler is the part of the PEP that is responsible for recognizing
   the conditions for client authorization, generating the Event
   Message to the PDP, and communicating with the Client, if necessary,
   to get identity or other information.

   The Event Handler takes a signal or message from the client and
   translates it into an Event Message to send to the PDP. It takes the
   provisioning Decision from the PDP and, in cases where the client is
   aware of the authorization process, does what is needed to
   communicate the Decision to the client.

   The Event Message is sent from the PEP to the PDP. The PDP uses the
   Event Message to determine the appropriate provisioning steps. In
   some cases identity verification may require sending some
   intermediate messages to authenticate the client prior to
   provisioning the PEP with the policies appropriate to the client.
   The PEP then returns a Report to the PDP confirming what was
   provisioned by the Decision.

      |  C |->Access Request->|    |                         |    |
      |  L |                  |    |-Event Message---------->|    |
      |  I | <-(optional)->   |PEP | <-(optional)->          |PDP |
      |  E |                  |    |<-Provisioning Decision -|    |
      |  N |<-Access Decision-|    |                         |    |
   |  T |                  |    |
      |__T_|                  |____| --> Access Report ----->|    |

                Fig. 2.1 ----->|____|

      Figure 2.1: Access Control Protocol Sequence

   This paper is primarily concerned with the function of the Event
   Handler and the communication between the PEP and PDP. Communication
   between the Client and PEP is assumed to be something like PPP or
   802.1, and the capabilities described here should work with any
   Client/PEP communication method.

   The PEP Event Message and PDP Provisioning Decision sequence is
   similar to the "classical" _classical_ COPS RSVP model. The Report confirming
   that the Decision was installed correctly on the PEP is an extra
   message beyond what is included in the RSVP sequence. We believe
   this is a good approach, but expect further discussion (It is
   interesting to note that RADIUS does not send an acknowledgements acknowledgement of
   Access Accepts/Rejects, and the DIAMETER drafts specify no
   acknowledgement, but do expect a negative message if the Reply
   cannot be processed correctly).

   An Event Handler is a data path element in the PEP. Each Event
   Handler has a "selector" _selector_ that identifies packets that should cause
   Event Messages (See section 4.3 - Filter Entries). 3.1.2). The selector essentially divides
   all packets into two sets, one set categories, in the first, the Event Handler is
   responsible for generating Event Messages; in the other set other, it just
   passes the packets to the next data path element. For example, if an
   Event HandlerÆs Handler's selector is "All _All new source IP addresses", addresses_, an
   incoming packetÆs packet's Source IP address is examined and if it is old,
   the packet is passed on to the next data path element without
   further processing. If the source IP address is new or unknown, an
   Event Message is generated. generated and this packet may follow a different
   sequence of data path elements.

   Event Messages are grouped by COPS Request Handles. Each Event
   Message may cause a new COPS Request Handle to be generated or a set
   of Event Messages may all share the same COPS Request Handle (note:
   see section 4.3-4.6). Handle. The
   distinction between selector and Event Request Handle is spelled out in 4.3-4.6, and will be worked on in the next
   revision of this draft).
   section 3.1.4.4). Attributes in the Access Bind PIB are provided to
   identify what how Event Messages are bound to which COPS Request Handles. Handle a given Event Message should use.

   Event Handlers are designed to detect conditions in the PEP that
   result in the sending of Event Messages to the PDP. The Access Bind
   PIB defines a class to specify the criteria for generating an event.
   In some cases an event is appropriate every time the criteria is
   met. In other instances an event is appropriate only on the first
   occurrence. The provisioning of the event criteria using traditional
   classifiers can be difficult since it is often the case that the PDP canÆt
   can't anticipate what the PEP will see. For instance, when it is
   desirable to generate events every time a new user or device is
   recognized, the PDP canÆt can't anticipate which devices will be
   recognized or the order in which they will occur. Filter expressions
   can be constructed that enable the description of a set of packet
   fields that must match and a set of packet fields that collectively
   represent a new, unique combination.
   This The expressive capability of
   the Access Bind PIB allows the PDP to indicate to the PEP that one
   event should be generated the first time a Src IP address has been
   seen by the PEP, but not generate events for subsequent packets with
   the same Src IP address.

   One interesting problem associated with event driven provisioning is
   avoiding blocking of one event due to provisioning activity for a
   different event. On the other hand, there are situations where
   serialization or ordering of events is important. We use COPS
   Request Handles to address both these needs. However, this requires
   explicit provisioning to indicate when new handles should be
   provisioned and which events should be processed through which
   handles. The approach taken in this paper is that the scope of the
   COPS Request Handle is defined by one or more Filter entries entries. Some
   of the filters are defined in the COPS Framework PIB [FWPIB], this [FWPIB] as well
   as PIB and other PIBs. modules defined in this document. For example, if a FilterEntry Filter
   object specifies SRC IP address (10.20.0.0) and SRC IP Mask
   (FF.FF.0.0) each new IP address within the range 10.20.0.0 and
   10.20.255.255 will trigger the creation of a new Handle. The for For this
   example, any packet with a SRC IP address that generates a new Event
   Message will use the existing handle if that handle was already
   defined for that specific SRC IP address.

   When a packet arrives at the Event Handler, it first checks if it
   meets the criteria for generating an Event (event criteria will be
   discussed later). In the example above, a packet with a SRC IP
   address of 10.25.12.100 would not match the range criteria and would
   be passed to the next data path element. If it is selected, then a
   check is made to see if it matches the criteria for an existing COPS
   Request Handle.

   If it does not match the criteria for an existing COPS Request
   Handle, then the PEP instantiates a new Request Handle and sends an
   Event Message to the PDP using the new Handle. In either case the
   PDP analyzes the Event Message, possibly sending additional messages
   back to the PEP to support authentication and provisioning for the
   new address. If authentication was performed, a final Authentication
   Result object is sent to the PEP to indicate the authentication was
   successful or not. This is needed to allow the PAP, CHAP and EAP
   authentication processes to report success back to the
   authenticating user.

2.1.1

2.1.1. Example - Ethernet IP Address Authorization

   This (relatively simple) example assumes an edge device has an
   Ethernet interface and wants to require each new Source IP address
   arriving at one Ethernet port to be authorized before getting general
   access to the network. Assume also that some clients are to get
   preferred access (via DiffServ Marking).

   In the example, the PEP is configured with a classifier that has
   explicit entries for each source address that has already be been
   authenticated and a default classifier element matching all addresses
   to points to
   that has an Event Handler. Handler as the next element. Since the default
   classifier element is only used if none of the other classifier
   elements match, the Event Handler is only invoked for new Src IP
   addresses that have not yet been explicitly provisioned into the
   classifier. Each non-default classifier element points to another
   classifier that lists the policies uniquely for that Src IP address.
   The addresses of "premium" _premium_ users are assigned a high QoS while the
   addresses of "normal" _normal_ users are assigned best effort QoS. Since the
   Event Handler is not terminating any packets, the Event Handler
   passes all packets through to the Best Effort Queue.

   When the PEP comes up it sends information about its Event Handlers
   to the PDP in a capabilities table. After capability negotiation is
   complete, the PDP provisions a set of policies that configure the
   Event Handlers behind the Ethernet interfaceÆs datapath. interface's data path. Each Event
   Handler Table will have a pointer to a (tagged) set of
   EventHandlerElement Tables that provide Filter matching and COPS
   Request Handle matching rules. In this case, the EventHandlerElement
   table will be provisioned to generate unique Request Handles and
   Events the first time it matches a new "SourceIPAddresses." _SourceIPAddress._

   Once the Event Handler is setup, it is able to process packets
   arriving at the Ethernet Interface. The Event Handler looks at all
   packets with Src IP addresses that have not been explicitly been
   defined in the upstream Classifier and uses the event matching rules
   to check if the packet contains an unknown Src IP address within the
   configured range. If the packet matches an event matching rule, the
   Event Handler checks what information the PDP requires from the
   Client (e.g. username and credential), and collects this
   information. The PEP then checks to see if it should use an existing
   Request Handle or create a new one. In this example, each new
   address gets a unique COPS Request Handle so that all the address-
   specific (user specific) policies (and feedback information) are
   managed through a single COPS dialog. A unique handle also has the
   benefit of automatically removing all objects provisioned through
   the Handle when the Handle is deleted (the user ends their session).
   After the Request Handle is set up, an Event Message is sent to the
   PDP containing the user information including address, port, and
   credential information.

   The PDP checks the information passed in the Event Message,
   authenticates the client (if required), and decides which policy
   should apply to that IP address. It sends a Provisioning Decision,
   containing the appropriate policy (assign (add classifier element for the
   new address and set the next element of the classifier element to "premium"
   the _premium_ queue) to the PEP using the newly created Request
   Handle.

   Additional examples using the Access Bind PIB to support RSVP,
   802.11, and other protocols are described in section 7.

2.2. 8.

2.1.2. Context Data

   As mentioned previously, Event Messages frequently require
   information beyond just the identity of the client. Information
   about the physical interface, the protocols being used, and the
   protocol bindings (VLANs, IP addresses, etc.) may also be required
   to provide enough information to the PDP to provide proper
   provisioning guidance. Therefore a mechanism is required that allows
   the PDP to specify what information is needed.

   With the advent of Tunnels, the same headers can be repeated
   (nested) within a single client message. This makes identification
   of specific attributes such as IP Addresses difficult because it is
   unclear whether the PDP needs the IP Address in the innermost or
   outermost header. This gets even more complicated when more than two
   layers are involved (i.e. VLAN and MPLS label stacking). The
   ContextData class, described in more detail below, allows the PDP to
   explicitly specify the set of nested headers that it needs more
   details on. This can either be specified in from the outermost
   header or the innermost header, as well as all headers of a
   particular type.

   Since the volume of information can be quite large and is very PEP
   device and interface specific, it is appropriate to organize the
   information into manageable chunks. This approach was a compromise
   between two extremes. One extreme is one large data structure with
   all possible information. The other extreme is specifying each
   attribute explicitly. The first extreme is not viable because it is
   difficult to adapt to new types of information. The second
   alternative is very configuration intensive, particularly for header
   data that must distinguish inner and outer headers. The choice to
   group context data into classes and request the data at the class
   level is not without problems. If the PDP is only interested in a
   single attribute within a given class, there is no way to specify
   this. Hence the PEP has to fill in the entire class and the PDP has
   to parse the entire class to find the appropriate attribute.

   In order for the PDP to specify which chunks of context data it
   needs, this PIB defines a table called the ContextData class that
   allows the PDP to specify the tables it needs. This table is
   discussed in more detail in section 4.9. sections 3.1.3 and 3.1.4.5. The messages
   used to send ContextData are discussed in sections 5.1, 5.2, 5.3, and 6.1.

2.3. section 7

2.1.3. Policy Distribution and Management

   One of the purposes of this paper is to demonstrate how
   authorization and authentication can be bound to traditional COPS
   provisioning. Stated somewhat differently, this paper provides the
   means for seamlessly integrating outsourcing with provisioning using
   only PIBs. Authorization, Authentication, and COPS/RSVP are all
   forms of outsourcing because they are all triggered by events in the
   PEP and depend on decision support from the PDP. Earlier sections
   have gone into fair detail in describing how the PEP can generate
   Event Messages. However, we have not yet discussed how these
   semantics integrate with traditional COPS PR COPS-PR provisioning semantics.

   There are two aspects to provisioning that need to be considered.
   First is the provisioning of the Event Handlers themselves. Section
   2.1 went into some detail describing how Event Handlers are
   provisioned using policy decisions. More details on the Event
   Handler tables can be found in sections 4.1, 4.2, 3.1.1 and 4.3. 3.1.4. In addition
   the provisioning messages used to configure Event Handlers are also
   described in section 5.1. 7.1.

   The second aspect of provisioning is the use of standard
   provisioning decisions to bind policies to authorized clients. The
   goal in binding events to policies was to minimize reconfiguration.
   Therefore, this PIB has been designed to provision Event Handlers as
   well as Policies once and bind them together dynamically.

   The process for this binding is as follows. An Event Handler can be
   configured to generate COPS Request Handles and trigger an Event
   Message based on specific criteria. These criteria explicitly scope
   the Request Handle. For example, if the criteria were one per unique
   source IP address, then there would be one Request Handle for each
   unique source IP address and all policies bound to through that Request
   Handle would typically operate on all traffic with that source IP
   address. Note that the criteria that scope a Request Handle could
   also be a unique protocol, unique VLAN, or each unique RSVP RESV
   message. It is also worth noting that the Request Handle bounding
   criteria could also be a unique combination of field values such as
   a VLAN and TCP Port Number.

   With the scope of a Handle specified, the Event Handler can
   instantiate new Handles in conjunction with the Event Message.

2.4. Interactions with DiffServ model

   The DiffServ model [MODEL] and

   This PIB [DSPIB] allow for flexible
   addition of new Data Path Functional Elements. The has been designed to provision Event Handler is
   one such new Data Path Functional Element.  Previous sections have
   already described how this PIB extends the existing DiffServ
   Informal Model and the DiffServ PIB. However, it is worth describing
   how this PIB enhances the basic DiffServ model. First Handlers as well as
   Policies once and foremost,
   this new PIB provides bind them together dynamically. As described
   above, each Request Handle can manage a means for scaling the basic DiffServ model
   to the edges of the network that can have many interfaces and many
   specialized services. Previous PIBs only supported the static
   configuration of data paths. This meant that dynamic events such as
   binding set of new clients to existing or new services were difficult to
   support because there was no way to anticipate new clients and
   because policies. However, in
   most provisioning was managing classifiers on a per client
   per service basis did not scale well.

   This PIB addresses this problem by preserving the basic cases, these policies reference data path
   semantics but separating the creation of dynamic (event driven)
   policies into elements that are
   shared by multiple Handles. For example, a new data path component. This provides IP address may
   generate a stable data
   path for unique Request Handle that in turn provisions one or more
   elements in the generation of authorizations while also supporting a
   stable Classifier table. However, these elements may in
   turn point to other data path for the services elements, such as queues or meters
   that various clients may make use
   of. are shared across multiple independent IP address classifier
   elements.

2.2. Event Handlers and Application-Specific PIBs
   The linchpin of this Access Bind PIB is actually a modular set of PIBs. The Common
   PIB contains the Event Handler that provides and it's associated structures. An
   extension PIB is also provided to support user authentication. This
   PIB is provided because only a
   new type of demultiplexor that separates streams subset of traffic into
   individually grouped triggers that Events require identity
   management. Other PIBS are included in turn this document to support dynamic
   authorization. The policy provisioning that results from a
   variety of applications. In the future, these
   events can PIBS may be bound back to pre-defined policies to specified
   in independent documents. The Application-Specific PIBs minimize the
   changes required
   number of COPS-PR classes that must be implemented in order to
   support new clients. As a result, with this PIB,
   modifications to service policies can be added or removed at the
   session level rather than the raw data path level.

   So far we have only discussed the value of authorizing a client when Event Handler functionality for the link notices new IP address. However, it is worth noting many applications that
   because the
   require policy outsourcing.

2.3. Passive Monitoring vs. Programmatic API
   The Event Handler is part of the data path definition, it designed to operate in two specific scenarios.
   The first is
   far more flexible. For instance, a passive monitoring environment. In this mode, the
   Event Handler can be placed
   behind a Classifier to explicitly authorize access provisioned to a detect specific
   part types of traffic
   and generate events to the network or specific services. PDP based on the traffic. The Event
   Handler can also
   be does not alter the FailNext element behind a meter resulting packets in an authorization
   for any way. However, packets may
   be sent to different packet processing engines depending on the use of out-of-profile traffic. Bandwidth Brokers can use
   this approach or an Event Handler trapping RSVP RESV messages
   decisions the PDP installs after responding to
   support dynamic bandwidth allocation decisions. the event. The integration of Event Handler as a Data Path Functional Element
   allows seamless integration with DiffServ provisioning.
   DiffServ network device mechanism policy control continues
   Passive Monitoring mode was designed to be
   supported with the use of DiffServ PIB [DSPIB] with added
   functionality at the edge of operate within the network with usage context
   of the Event
   Handler. DiffServ data path model. This can now be totally controlled via the use of COPS-PR.

   The Policy Server level interaction with DiffServ comes naturally
   with the integration of Event Handler as a Data Path Functional
   Element when the network data model is common and scoped
   appropriately discussed in more
   detail in Section 2.3.1.

   In the schema level, second scenario, no packets are analyzed because some
   intermediate system is processing the packets and generating events.
   In this mode, the system needs the help of the PDP to continue
   processing. Therefore, the system uses a signaling API to interact
   with the Event Handler becoming
   stimuli Handler, which in turn generates the events and
   receives the decisions. This mode is particularly useful for DiffServ provisioning.

2.5. Interactions with RSVP.
   Since the RSVP model

   The engine is processing the actual PATH and RESV
   messages, there are no packets for the Event Handler to process or
   analyze. In fact, the traditional COPS model provides defines a means for detecting mapping of
   the RSVP RESV policy engine to COPS messages. This means that The Access Bind PIB is
   constructed to support a programmatic interface to the traditional COPS outsourcing model
   could eventually be phased out Event
   Handler. Further, the Programmatic API uses the same mechanisms as
   the passive monitoring mode to configure new policies in favor of
   intermediate systems. For instance, a RESV event received by the provisioning model
   Event Handler through the programmatic interface and propagated to
   the use of PDP allows the PDP to generate data path decisions that can be
   installed in the intermediate system through the programmatic API.
   The concepts behind this PIB. This is model are discussed in more detail greater depth in section
   7.2.

3. Supporting various client Authentication Protocols

   In
   Section 2.3.2.

   It is worth noting that both these modes are abstractions that may
   be equally applicable. It is possible to represent a service using
   the operational data path model for this PIB, the Authentication Server and it is possible to represent a specific function of packet
   processing engine as a service with a programmatic interface to the PDP.
   PEP. It is a design decision that dictates the preferred approach
   for processing PEP events. The main purpose advantage of the
   authentication portions of this PIB passive monitoring
   approach is to verify that it can more accurately represent the validity behavior of
   client credentials by an Authentication Server. The verification
   process itself may do this whilst ensuring some level
   the system. However the API is more tolerant in the areas of
   authenticity, confidentiality and integrity. Messages exchanged
   between a Client filter
   definition and Authentication Server (PDP) may remain
   confidential to PEP's COPS request handle management.

2.3.1. Interactions with DiffServ data path model

   The DiffServ model [MODEL] and Proxy Servers. PIB [DSPIB] allow for flexible
   addition of new Data Path Functional Elements. The message integrity may
   be ensured by some hashing algorithm so PEP's Event Handler is
   one such new Data Path Functional Element.  Previous sections have
   already described how this PIB extends the existing DiffServ
   Informal Model and Proxy's may
   inspect but not modify the content of authentication messages.
   Clients, PEP's, Proxy's DiffServ PIB. However, it is worth describing
   how this PIB enhances the basic DiffServ model. First and PDP's will always need some security
   method to ensure message authenticity.

   Some authentication protocols explicitly consider proxies by
   allowing foremost,
   this new PIB provides a means for scaling the payload basic DiffServ model
   to be carried over a variety of transports.
   Others depend on the termination point edges of the connection to
   explicitly proxy the authentication, when network that is necessary. In
   order to demonstrate can have many interfaces and many
   specialized services. Previous PIBs only supported the general utility static
   configuration of this model, a variety data paths. This meant that dynamic events such as
   binding of
   client authentication protocols will be considered in this document.
   For each protocol, the negotiation mechanism will be described and
   the mapping new clients to this framework will be detailed.

3.1. Provisioning

   The PEP will not start an authentication sequence with the client if
   it hasnÆt been told existing or new services were difficult to do that. It will only do so when a specific
   event occurs. The PDP tells the PEP exactly when this event should
   be triggered. This process is called provisioning.

   The
   support because there was no way to anticipate new clients. In
   addition most provisioning starts with the initial Provisioning Request, was managing Classifiers on a per client
   per service basis, which
   is typically sent at boot time. The PEP sends up capability PRCÆs
   indicating scales geometrically as the types number of authentication it can handle. The PDP will
   reply by setting the following Access Bind PRCÆs:
     a. dpeventHandler (datapathEventHandler)
     b. dpEventhdlrAuthProtocol
     c. eventHdlrElement
     d. eventHdlrEventScope
     e. eventHdlrHandleScope
     f. contextData
   clients and an additional PRC instance referred to services increases.

   This PIB addresses this problem by preserving the
   eventhdlrEventScopeFilter in the eventhdlrEventScope table,
   indicating how the signaling trigger is recognized.

   In case the PDP wants the PEP to perform an authentication when an
   event is triggered, it should set dpeventhdlrRequestAuth in basic data path
   semantics but separating the
   dpEventHdlr to true and optionally let creation of dynamic (event driven)
   policies into a new data path component. This provides a stable data
   path for the dpEventHdlrAuthProtocol
   field point to generation of authorizations while also supporting a dpEventHdlrAuthProtocol to indicate which
   authentication protocol should be used
   stable data path for the authentication.

   As soon as the PDP has provisioned the PEP to watch for certain
   traffic services that triggers an event, the PEP is ready to start an
   authentication.

3.2. EAP Authentication various clients may make use
   of. The most significant aspect distinguishing EAP [EAP] from other
   authentication protocols is that EAP assumes the negotiation linchpin of this PIB is
   between the client and the authentication server. In anticipation Event Handler, a new type of
   the fact
   demultiplexor, that the terminating point separates streams of a connection such as PPP or
   L2TP is not necessarily the same as the agent managing client
   authentication, EAP encapsulates itÆs negotiation process traffic into individually
   grouped triggers that in a
   separate header turn support dynamic authorization. The
   policy provisioning that results from these events can be forwarded in entirety bound back
   to pre-defined policies to minimize the server.
   This mechanism provides extra security by preventing intermediate
   proxies from monitoring or managing authentication credentials.

   EAP supports changes required to support
   new clients. As a number of different authentication mechanisms
   including MD5, TLS, and One-Time-Password authentication.

   The terminology used in [EAP] differs from result, with these PIB modules, service policies
   can be added or removed at the terminology used in
   this document. In particular, session level rather than the peer, as defined in section 1.2 raw
   data path level.

   So far we have only discussed the value of
   [EAP], is referred to as "Client" in this document. Similarly, authorizing a client when
   the
   "authenticator" is called link notices a PEP in this document and "back-end
   server" new IP address. However, it is called worth noting that
   because the Authentication Server function Event Handler is part of the PDP (or
   just PDP) in this document.

3.2.1. EAP Message sequence

   The generic sequence data path definition, it is
   far more flexible. For instance, the Event Handler can be placed
   behind a Classifier to explicitly authorize access to a specific
   part of transmissions between the PEP and PDP has
   already been described network or specific services. The Event Handler can also
   be the FailNext element behind a meter resulting in section 2. In particular, figure 2.1 gives an overview of authorization
   for the use of out-of-profile traffic. Bandwidth Brokers can use
   this approach or an Event Handler trapping RSVP RESV messages involved between the Client workstation,
   PEP to
   support dynamic bandwidth allocation decisions. MPLS LSRs and PDP. EAP messages are embedded in PPP packets in LERs
   can use this to detect label path addition or modification events.

   The integration of Event Handler as a Data Path Functional Element
   allows seamless integration with DiffServ provisioning.
   DiffServ network device mechanism policy control continues to be
   supported with the
   communication between use of DiffServ PIB [DSPIB] with added
   functionality at the Client and edge of the PEP. In network with usage of the communication
   between Event
   Handler.

   The Policy Server level interaction with DiffServ comes naturally
   with the PEP and PDP, integration of Event Handler as a Data Path Functional
   Element when the EAP messages are embedded in COPS
   Request, COPS Decision network data model is common and COPS Report messages. Figure 3.1 shows
   how EAP may be used scoped
   appropriately in the schema level, with the Event Handler becoming
   stimuli for DiffServ provisioning.

2.3.2. The Programmatic API to retrieve credentials from the client
   workstation by Access Bind PIB

   The programmatic API to the PDP.

   time
    |   +---+                     +---+                          +---+
    |   |   |                     |   |-- COPS-PRC exchange ---->|   |
    |   |   |                     |   |<- COPS-Dec eventHandler -|   |
    |   |   |-- PPP traffic ----->|   |                          |   |
    |   |   |<- PPP LCP Req-EAP --|   |                          |   |
    |   | U |-- PPP LCP ACK-EAP ->| P |                          | P |
    |   | s |<- PPP EAP Req Id ---| E |                          | D |
    |   | e |-- PPP EAP Res Id -->| P |                          | P |
    |   | r |                     |   |-- COPS-Req Ses-EAP  ---->|   |
    |   |   |                     |   |<- COPS-Dec EAP Req Chal -|   |
    |   |   |<- PPP EAP Req Chal -|   |                          |   |
    |   |   |- PPP EAP Res Chal ->|   |                          |   |
    |   |   |                     |   |- COPS-Rep EAP Res Chal ->|   |
    |   |   |                     |   |                          |   |
    |   |   |                     |   |<- COPS-Dec EAP Success --|   |
    |   |   |<- PPP EAP success --|   |                          |   |
    V   +---+                     +---+                          +---+

   Fig 3.1: Embedding of EAP messages between the Client workstation
   and Access Bind PIB is actually an
   implementation specific abstraction that allows intermediate systems
   to interact with the PEP, and between Event Handler. This PIB only defines the PEP and PDP. The EAP
   messages may be
   opaque that enable the Event Handler to generate events on behalf
   of intermediate systems. Since implementations of intermediate
   systems such as RSVP vary greatly both in features and usage, the PEP.

   Typically, when
   actual API that maps the PEP boots up, it sends itÆs capabilities RSVP policy engine to the
   PDP in a COPS message and Event Handler is than configured by
   dependent on the PDP with one or
   more datapathEventHandlers specifying the criteria for generating
   PEP Event Messages. The first message after this provisioning
   process from actual outsourcing requirements of the PEP to intermediate
   engine. However, the PDP Access Bind PIB is extremely flexible and can
   accommodate a new Event Message. broad range of events and policy decisions.

   The PEP
   sends a COPS request to typical programmatic API will have interfaces (methods) that
   parallel the PDP containing a new instance sequence of messages seen in the
   Event table. data path mode of
   operation. The eventEventHdlr attribute in intermediate system will first invoke the Event table entry
   is a ReferenceId that points API to
   register itself with the PDP. The COPS-PR side of the API would
   generate a dpeventHandler entry Capabilities message indicating
   (by means that the device supports
   the protocol or service represented by the intermediate system. The
   functionality of the dpEventHdlrAuthProtocol) API will be described by using RSVP as an
   example. It should be noted that EAP is a valid
   protocol any other service (such as SIP,
   H.323, or 3GPP-go) that needs to use for this Event. Also, outsource policy requests would
   work the eventCause attribute same way. In the case of RSVP, the API might be a function
   like EventHdlrRegister(RSVP-type). The API would in turn generate a
   COPS-PR capabilities message indicating that RSVP can be provisioned
   and monitored through the Event table entry event handler.

   The next step is a ReferenceId response from the PDP that points to an
   eventhdlrElement indication of which Filter (by means provisions a set of
   controls. The first is the
   eventhdlrEventScope) triggered the event.

   All EAP messages necessary to complete provisioning of the authentication process Event Handler that
   will be forwarded to interact with RSVP via the PDP. All of API. When the negotiation occurs between Event Handler is
   provisioned, the Client and RSVP service is notified that it may now outsource
   RSVP reservation requests to the PDP and should, except for through the EAP message code
   field, not API. Second, there
   may be examined by several provisioning tasks that are configured in the PEP. RSVP
   service through the API. In order many implementations of RSVP there may
   be many reservations requiring varying levels of QoS but only a few
   Queues to support multiple EAP
   protocols, this PIB supports a generic EAP request class and EAP
   response class. Each class has a single string attribute
   (authEapReqExtSpecific and authEapRespExtSpecific, respectively)
   within which the entire EAP message is passed.

   Although figure 3.1 shows two EAP messages going from scheduling of various RSVP flows. In these
   situations the PDP to may provision some or all of these queues using
   the
   Client Framework [FWPIB] and two EAP messages being returned from the client to the
   PDP, the actual number of messages exchanged DiffServ PIB [DSPIB]. The API can then be any amount. The
   PDP may continue
   used to map these provisioning requests to retrieve additional credentials from the client
   for as long as it wishes. As soon as actual RSVP
   implementation within the PDP has all RSVP service. This allows the necessary
   credentials from pre-
   configuration of queues, schedulers.

   When a reservation is processed by the client, RSVP service, the PDP may continue API is used
   to provision notify the
   PEP with policies. This is action event handler of a new RSVP event. When the event
   handler is not shown in figure 3.1.

   The PDP should end provisioned some of the EAP negotiation with an EAP Success or an EAP
   Failure message. If provisioned structures specify
   what events (RESV, PATH, etc.) the PDP sends will respond to and what
   information must be included in an event message. The API may be
   invoked with a EAP Success, method like EventGenReq() with parameters that
   describe the PEP must from
   then on use the matchNext Prid to determine type of message and the next processing
   filter for context data defined by the values described using that the
   eventhdlrEventScope.

3.2.2. AuthEapReqExt PDP
   requires and AuthEapRespExt data structures

   The EAP messages are embedded in the COPS by sending an instance request handle to use for this reservation.

   When the PDP completes the processing of the
   authEapReqExt or authEapRespExt table, which each have an attribute
   (Specific) event, a set of
   decisions are sent back to encapsulate the appropriate EAP messages necessary for PEP. These decisions are handed to
   the authentication mechanism. RSVP service via the API. The authEapReqExt table decisions will determine how the
   reservation is owned and
   managed by to be processed. If several queues were pre-
   provisioned, the PEP, while decisions may provision a classifier matching the authEapReqExt table is owned
   reservation's flow (4-tuple) and
   managed by a meter that rate limits the PDP. Put another way,
   traffic to the PDP generates authEapReqExt
   instances R-SPEC [RSVP]. The decisions would also indicate that it sends in Decision messages and
   the PEP generates
   authEapRespExt instances classifier should have the meter as the next element and that it sends in Report messages. Since
   neither
   the PEP nor meter would have the PDP needs appropriate (pre-provisioned) queue as its
   next element. The API may be implemented as a synchronous or
   asynchronous interface. If the interface is synchronous, the API
   will return an indication back to maintain the messages
   permanently, event handler as to whether
   the same instance of each class is used when more than
   one exchange decisions were successfully installed or not. If the interface
   is required in each direction.

   Since both AuthEapReqExt and AuthEapRespExt are extensions of asynchronous, the
   AuthExt class, they both inherit API will call the attributes of AuthExt.

       AuthEapReXXExt table attributes     Attribute type
       -------------------------------     --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authEapReXXExtSpecific              OCTET STRING

   Fig 3.2: Data elements in AuthEapReqExt event handler explicitly to
   indicate success or failure. In either case, an explicit decision
   result message must be sent back to the PDP so that both the PEP and AuthEapRespExt tables

   The AuthEapReXXExt class contains three attributes. The instanceId
   PDP are kept in sync on which policies have been installed in the
   PEP.

   When the RSVP service determines that the reservation should be torn
   down, the API is used to uniquely define close/terminate the instance in COPS Request Handle.
   This action will cause both the table. However, since
   EAP messages are meant PEP and the PDP to be opaque, they should not be referenced.
   Because remove the purpose
   decisions associated with this reservation (the classifier and
   meter).

3. Access Bind PIB

   Figure 3.1 shows the basic operation of the classes Access Bind PIB. In the
   first phase, the Event Handler is provisioned in the PEP. This
   process enables the PEP to carry EAP messages and each
   message is transient instances of these tables are temporary trap the configured events and
   should not be referred to. The Event attribute points pass them
   to the Event
   table entry for which EAP is being negotiated. PDP. The format process of EAP
   packages being passed by trapping events may involve an
   intermediate step of authenticating the AuthEapReXXExt classes user or device. This step is described
   represented in
   [EAP].

3.3. PAP Authentication

   PAP (Password Authentication Protocol), Figure 3.1 as described in section 2 of
   [AUTH] is a very simple an event message with possible
   authentication mechanism used over PPP. It
   is not considered to be a secure mechanism, since it sends passwords
   over message exchanges between the wire in clear text format. However, where one-time
   passwords are used, this security concern is mitigated. It is
   described here nonetheless for illustration purposes PDP and because it
   may still be used among ISPs, or in situations where another layer
   already performs encryption for security.

   The terminology used in [AUTH] differs from the terminology used in
   this document. In particular,
   user/device. After the peer as defined in section 1.2 event (and optional authentication has been
   processed by the PDP, the PDP can provision the PEP with a set of
   [AUTH] is referred
   policies specific to as "Client" in this document. Similar, that user, device, or event. When the decision
   policies are installed, the
   "authenticator" is called PEP in this document.

3.3.1. PAP Connection sequence

   Figure 3.3 shows how PAP notifies the PDP that the install
   has succeeded or failed. In addition, if authentication was
   involved, the user or device may be used to retrieve credentials from
   the client workstation by notified that the PDP. authentication
   process has completed.

   time
    |   +---+                       +---+                       +---+
    |   |   |                       |   |-- COPS-PRC exchange ---->| provisioning req. ->|   |
    |   |   |                       |   |<- COPS-Dec eventHandler -|   |<-- provisioning ------|   |
    |   | U |-- PPP traffic ----->|   |                          |   |
    |   |   |<- PPP LCP Req-PAP --| ----------->|   |                       |   |
    |   | U |-- PPP LCP ACK-PAP s |<-- (authentication) ->| P |                       | P |
    |   | s |-- PPP PAP Id, Pwd ->| E |                          | D |
    |   | e |                       | P E |-- COPS-Req event,     -->| P event (w/ authen) ->| D |
    |   | r |                     |   |--          userPapExt |<-- (authentication) --+ P +-- (authentication) -->| P |
    |   |   |                       |   |<-- decision ----------|   |
    |   |
    |   |   |                     |   |<- COPS-Dec eventElement -|   |
    |   |   |                     |   |<- COPS-Dec authResult ---|   |
    |   |   |<- PPP PAP ack ------|   |                          |   |<-- decision ----------|   |-- decision success -->|   |
    V   +---+                       +---+                       +---+

   Fig 3.3: Embedding of PAP messages between the Client workstation
   and the PEP, and between the PEP and PDP.

   When the dpEventHandler has been configured to require
   authentication, a PEP Event

      Figure 3.1: Typical message sequence when a trigger occurs.

   In many scenarios, no identity management will not be generated until
   after a minimal set of credentials have been negotiated with required and the
   client. For PAP, this means that a PEP Event Message
   authentication steps will not be
   generated until after the authRealm and authUsername occur. This is why identity management
   classes have been
   determined. This means that that the PEP must receive place in a PAP Identity
   message before it can send the PEP Event Message.

   The Client separate PIB, which is discussed in
   more detail in Section 4.

   Section 3.1 will send describe how the Identity PDP installs an event handler into
   a PEP, and Password to when the PEP. The PEP should trigger an event. Section 3.2, about
   the event handling, will embed describe the password into actions that the userPapExt datastructure and send
   this PEP needs to
   perform when an action is triggered. This chapter will focus on
   generic event handlers; Section 5 will describe additional classes
   required to support event handlers within the PDP. Since this datastructure inherits the fields context of specific
   signaling applications. Chapter 7 will describe the
   userAuthExt data structure and message sequence
   that follows the extAuth data structure, it will
   also contain event request, as well as the PAP message sequence
   associated with identity attribute inserted into authentication.

3.1. The Event Handler

   This Section will describe the
   authUsername attribute concept of Events, Event Handlers,
   Event Handler Element, Event Handler Event Scopes, and Event Handler
   Handle Scopes.

   In the framework described in this Instance.

   The first connection document, only events that match
   a predefined set of criteria can be sent from the PEP to the PDP is an alert that an
   event was triggered. PDP.
   The PEP sends an Event Message over COPS to the
   PDP containing a new instance main purpose of the Event table. The eventEventHdlr
   attribute in the Event table entry is a ReferenceId that points to a
   dpeventHandler entry indicating (by means of the
   dpEventHdlrAuthProtocol) that PAP Handler is a valid protocol to use for
   this Event. Also, the eventCause attribute in provision the Event table entry
   is a ReferenceId PEP with
   that points to an eventhdlrElement indication which
   Filter (by means set of criteria. If the eventhdlrEventScope) did trigger the event.
   Along with this new instance of criteria provisioned by the Event table, PEP are
   met, the PEP must also send an instance of Event message to the AuthPapExt table.

   Besides these required instances, PDP.

3.1.1. Functional Description

   The PDP provisions the PEP might have been configured
   by event handler onto the PDP to sent additional information about PEP. However, the client to PEP
   is the
   PDP. For example in first machine to contact the case PDP, typically at boot time of a dialup connection between
   the
   Client PEP. The PEP and the PEP, the PDP might specify communicate with each other using a contextData
   instance that
   common COPS-PR messages. After the PEP should also sent an instance of send a
   ctxtDialupInterface.

   The PDP performs capability message
   indicating that it supports event handlers, the PAP authentication. When PDP will respond by
   provisioning the authentication is
   complete and PEP with a set of configuration elements. These
   elements may include one or more instances (PRIs) of the PDP is ready to authorize Event
   Handler class, the event, EventHdlrElement class, the PDP EventHdlrScope class
   and optionally provisions the ContextDataPointer class. The PEP with policies. This sequence of
   messages should terminate will respond to
   this configuration request with a PDP Provisioning Decision (a COPS-
   PR Decision message). The PDP Provisioning Decision contains an
   instance of the AuthExtResult table with the authExtAuthSuccess set
   to either TRUE or FALSE. common COPS-PR report message
   indicating that these elements have been successfully provisioned.

      |  P  |---- COPS-PR Capability message -->|  P  |
      |  E  |<---     -                  COPS PR Decision -------------|  D  |
      |  P  |---- COPS-PR Report State -------->|  P  |

      Figure 3.2: The PEP must upon receipt of this initialization sequence

   The COPS Decision message, send PAP ACK or NACK message to the client. Also,
   if that the authExtAuthSuccess attribute was true, then PDP sends to the PEP should
   keep track of this particular data, defined by the unique values of
   the fields specified using the eventhdlrEventScope.

3.3.2. AuthPapExtEntry datastructure
   contain at least one EventHandler Instance. The PAP information EventHandler Entry
   is embedded in the PEP Event Message by sending
   an instance of the authPapExt table. Since base object which defines the authPapExt table is
   an extension behavior of the userAuthExt table, which PEP when no
   event criteria are met. Each EventHandler is an extension of the
   authExt table, accompanied with one or
   more EventHandlerElements. Each EventHandlerElement describes the authPapExt inherits
   action which the attributes of these
   tables.

   AuthPapExt table attributes         Attribute type
       ---------------------------         --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authRealm                           OCTET STRING
       authUsername                        OCTET STRING
       authPapExtPwd                       OCTET STRING

   Fig 3.4: Attributes PEP should take in case one of the AuthPapExt table.

   The AuthPapExt contains five attributes. The instanceId event criteria
   is used to
   uniquely define met.

   The EventHandler and the instance set of EventHandlerElements are grouped
   together because each EventHandlerElement in the table. However, since same group has the PAP
   password is sent to
   same TagId in the PDP once and eventHdlrElementGrpId attribute. The EventHandler
   is needed by neither the PDP
   nor associated with this group because it has the PEP after same value in the client is authenticated, the instance
   eventHdlrElementGrpId attribute.

   The EventHandlerElement objects specify what actions should
   not be referenced after it taken
   if an event is used triggered. To specify when an event must be
   triggered, the first time. EventHandlerElement uses zero or more
   EventHdlrEventScopes. The Event
   attribute points to Scopes are also grouped using a TagId, and
   have a precedence field. Each scope defines a simple condition, and
   all scopes from one group together form a complex boolean expression
   based on the Event table entry eventHdlrEventScopePrecedence fields. If two scopes in
   the same group have a different precedence number, then the event
   criteria for which PAP the EventHandlerElement is being
   negotiated.

   The result met if one of the authentication for PAP scopes
   condition is sent met. If two scopes in the
   AuthExtResult table. Since the authExtResult table is an extension
   of same group have the AuthExt table, it inherits same
   eventHdlrEventScopePrecedece fields, the attributes of AuthExt.

       AuthExtResult table attributes      Attribute type
       ------------------------------      --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authExtAuthSuccess                  Truth Value

   Fig 3.5: Attributes event criteria are only met
   if BOTH conditions of the AuthExtResult table.

   The AuthExtResult is sent by EventHdlrElements are met.

   Take for example, an EventHandlerElement with an
   eventHdlrElementEventScope TagId (and thus the PDP
   eventHdlrEventScopeGroup TagReferenceId of a certain
   group) set to the PEP. If the
   authentication was successful 5, and there are 3 scopes in the PEP should from now on use group 5, with the
   matchNext Prid
   eventHdlrEventScopePrecedence set to determine the next processing filter 2, 3, and 3 respectively for
   scope A, B and C. Then, only an event is triggered if (the next
   component down criteria
   of scope A OR (the criteria of scope B or the internal datapath criteria of scope C))
   are met. The exact rules are explained in the PEP) for all traffic
   defined by the values section 3.2.4.

3.1.2. Event Criteria behavior

   One key aspect of the parameters as set in the
   eventhdlrHandlerScope.

3.4. CHAP Authentication

   CHAP (Challenge Authentication Protocol) [CHAP] EventHdlrElement is a strong
   authentication mechanism, which eliminates the Event Criteria
   attribute. This attribute is used to describe whether unique events
   are one time events or repeatable events. For instance, every RSVP
   message may need to send
   passwords result in an Event Message. However, an Event
   Message may only be appropriate the clear, like PAP does. With CHAP, the Authenticator
   generates a challenge key, sends it to the Peer (Client) and the
   client responds with first time a cryptographically hashed response new Src IP address
   is seen. After that
   depends upon the Challenge and a secret key. no events should be generated for that address.
   However other new addresses should still generate Event Messages.
   The PDP checks the
   secret key by performing Event Criteria attribute defines the same encryption and comparing frequency with which events
   should be generated. If the
   results.

   The terminology used in [CHAP] differs from Event Criteria is set to 'One_Time',
   only one event will ever be generated for that EventHdlrElement when
   the terminology used in
   this document. In particular, first match occurs, irrespective of the peer as defined in section 1.2 number of
   [CHAP] subsequent
   matches. If the Event Criteria is referred set to as "Client" 'Every_Time', each match
   will result in this document. Similar, the
   "authenticator" an Event Message. A hybrid case is defined called PEP in this document.

3.4.1. CHAP Connection sequence

   Figure 3.6 shows how CHAP may be used
   'On_Change'. This option allows a subset of the filter attributes to retrieve credentials
   be required for matching and a different set of attributes that must
   from
   the client workstation by the PDP.

   time
    |   +---+                     +---+                          +---+
    |   |   |                     |   |-- COPS-PRC exchange ---->|   |
    |   |   |                     |   |<- COPS-Dec eventHandler -|   |
    |   |   |-- PPP traffic ----->|   |                          |   |
    |   |   |<- PPP LCP Req-CHAP -|   |                          |   |
    |   | U |- PPP LCP ACK-CHAP ->| P |                          | P |
    |   | s |<- PPP CHAP Chal ----| E |                          | D |
    |   | e |-- PPP CHAP Ident, ->| P |                          | P |
    |   | r |--        Id, Resp ->|   |                          |   |
    |   |   |                     |   |-- COPS-Req event-CHAP -->|   |
    |   |   |                     |   |-- COPS-Rep CHAP Resp, -->|   |
    |   |   |                     |   |--                Chal -->|   |
    |   |   |                     |   |                          |   |
    |   |   |                     |   |<- COPS-Dec eventElement -|   |
    |   |   |                     |   |<- COPS-Dec authResult ---|   |
    |   |   |<- PPP CHAP ack -----|   |                          |   |
    V   +---+                     +---+                          +---+

   Fig 3.6: Embedding a unique n-tuple in order to generate an Event Message. See
   Section 3.2.2 for more details of CHAP messages between the Client workstation
   and behavior of the PEP, and between 'On_Change'
   attribute.

   Whenever traffic arrives at the PEP and PDP.

   As soon as EventHandler for which an Event
   Message has not already been generated, it is compared against the PEP finished negotiating CHAP as
   FilterEntry objects of the Authentication
   protocol, EventHdlrEventScope objects referenced by
   the EventHdlrElement. If it generates matches the criteria specified in all of
   the FilterEntry objects, a challenge itself, new Event Message is generated and sends this sent
   to the
   Client. PDP. The client will respond to this authentication request by
   sending his or her identity, an identifier and value of EventHdlrElement's EventCriteria attribute
   in conjunction with the response. The
   response is a cryptographically encrypted hash based on value of the
   challenge Event Scope class's ChangeFlag
   attribute determine whether an Event Message will be generated.

   For example, if a FilterEntry object specifies SRC IP address
   (10.20.0.0) and secret key (password).

   The identifier is only used to keep track of CHAP messages, SRC IP Mask (FF.FF.0.0) and
   needs to be used by the PEP EventCriteria is set
   to recover 'One_Time', the associated challenge.

   The first connection from address in the PEP to range of 10.20.0.0 and
   10.20.255.255 will generate an event and no events will follow. If
   the PDP EventCriteria is set to 'Every_Time' for the same attribute
   settings, each time a notice of a new
   Event. The PEP sends packet contains an IP address within the range
   an Event Message will be generated. If the EventCriteria is set to
   'On_Change' and the PDP containing a eventHdlrEventScopeChangeFlag is set to True,
   each new
   instance of the Event Table. The eventEventHdlr attribute in IP address within the range 10.20.0.0 and 10.20.255.255
   will trigger a new Event table entry is Message. However, as soon as a ReferenceId specific Src
   IP address like 10.20.15.109 has generated an Event Message, that points
   specific address will no longer generate an event. If the
   EventCriteria is set to a dpeventHandler
   entry indicating (by means of 'On_Change' and the dpEventHdlrAuthProtocol) that CHAP
   eventHdlrEventScopeChangeFlag is a valid protocol set to use False for this Event. Also, the eventCause
   attribute in example
   address range, than the Event table entry eventHdlrEventScope instance with the
   ChangeFlag set to 'True' will determine uniqueness. In this
   scenario, the address range is acting as a ReferenceId strict filter that points to
   an eventhdlrElement indication of which Filter (by means of the
   eventhdlrEventScope) did trigger the event. Along with this new
   instance of the Event table, the PEP must also send an instance of
   the AuthChapExt table.

   Note that having the PEP issue the challenge allows the PEP
   be met without regard to
   perpetrate fraud by issuing a replayed request (assuming that the
   PEP and PDP are which address in different domains). The only guard against this
   is for the PDP to check range is responsible
   or whether that address has been seen previously.

   When multiple authentication requests fields are specified for the same client have unique challenges. This may be slow. PDP filter and
   Authentication server developers who feel this the ChangeFlag
   is set to 'True', each unique combination of field values generates
   an event. For example, if the SRC IP is assigned a security issue
   may want range of
   10.10.10.224 to use EAP-MD5 authentication rather 10.10.10.255 and DST Ports 80 to 90 then CHAP
   authentication, since EAP-MD5 addresses this problem by letting the
   PDP
   10.10.10.240+80, 10.10.10.240+81, and 10.10.10.250+80 would all
   generate the challenge.

   Besides these required instances, the PEP might have been configured
   by the PDP to send additional information about the client separate events. The combination of supporting multiple
   filters and being able to control precedence allows for the
   PDP. For example in the case
   construction of a dialup connection between the
   Client both lists (10.10.x.x and the PEP, the PDP might specify using 10.15.x.x) and
   combinations of disjoint headers in a contextData
   instance that the PEP should also sent an instance single match criteria (any
   combination of 10.10.x.x and VLANs 100 to 120). See Section 3.2.4
   for a
   ctxtDialupInterface.

   The PDP performs the CHAP authentication. When the authentication is
   complete and detailed example of filter construction.

3.1.3. Context Data usage

   For each application signaling protocol there are different pieces
   of information that the PDP is ready needs in order to authorize the client, make a provisioning
   decision. In some cases the PDP may
   choose need IP header information. In
   other cases, it may need some state information internal to provision the PEP with policies
   such as the activity timer for this client, which was
   probably a connection or the intention number of starting this authentication process in bytes
   originating from a particular IP address. Since there are a huge
   number of potentially interesting pieces of information that the first place. This sequence PDP
   may need, sending all the information can be expensive both in
   processor and bandwidth overhead. To address this issue, each
   EventHandlerElement instance can be independently provisioned with a
   list of messages classes that the PEP should terminate send as part of an Event
   message. This list is constructed with a
   PDP Provisioning Decision (a COPS-PR Decision message). The PDP
   Provisioning Decision contains an tag reference to a class
   called ContextData. Each instance of a ContextData class contains a
   class identifier (PRC). The class identifier specifies the AuthExtResult
   table type of
   ContextData class that should be passed with the authExtAuthSuccess set to either TRUE Event message.

   Typically a class will represent an autonomous structure such as an
   IP header or FALSE. The
   PEP must upon receipt the fields of this COPS Decision message, send PAP ACK or
   NACK message a RSVP reservation table entry. In some
   instances such as tunneling, there may be a list of entries that are
   applicable to the client. Also, if event. For this reason, the authExtAuthSuccess
   attribute was true, then the PEP should keep track of this
   particular data, defined by the unique values of the fields
   specified using ContextData class has
   attributes that allow the eventhdlrEventScope.

3.4.2. AuthChapExtEntry datastructure

   The CHAP information is embedded PDP to indicate whether a specific entry
   in the Event Message by sending an
   instance of the authChapExt table. Since the authChapExt table is an
   extension of list (relative to the userAuthExt table, which is an extension beginning or end of the
   authExt table, list) or all
   the authChapExt table inherits entries in the attributes list should be sent with an Event message. See
   Section 3.1.4.5 for details on organization of
   these tables.

       AuthChapExt table attributes        Attribute type
       ----------------------------        --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authRealm                           OCTET STRING
       authUsername                        OCTET STRING
       authChapExtId                       Unsigned32
       authChapExtChal                     OCTET STRING
       authChapExtResp                     OCTET STRING

   Fig 3.7: this class. Also see
   Sections 3.2.5 and 3.2.6.2.

3.1.4. Data elements of the AuthChapExtEntry datastructure.

   The AuthChapExtEntry contains seven attributes. Description

   The instanceId is
   used to uniquely define following sections the instance classes defined in the table. However, since
   the CHAP information is sent to Access Bind PIB.

3.1.4.1. EventHandler class
   Instances of the PDP once and is needed Event Handler PRC are provisioned by
   neither the PDP nor on the
   PEP after to catch specific events. The Event Handlers reference a group
   of eventHdlrElement PRIs that contain the client is authenticated, scope of the
   instance should not be referenced after it is used event and
   specify the first time.
   The Event attribute points context data to send to the Event table entry for which PAP is
   being negotiated.

   The authChapExtChal attribute PDP when an event is the challenge generated by the PEP. caught.

   The PDP may check attributes of the challenge to see if it is different from
   challenges used earlier. This provides EventHandler Class are as follows:

        eventHandlerId (InstanceId)
           Identifies an increased level instance of
   security. The Response and the Id is taken from the CHAP message
   sent by this class.

        eventHandlerElements (TagReferenceId)
           A reference to a group of eventHdlrElement instances, each
           of which determines the client scope (criteria for generating a new
           request) and put into the AuthChapExtEntry by the PEP.

3.5. HTTP Authentication

   This section will be added what context information to send in a subsequent version of this draft.

4. Data Structures request.

        eventHandlerNonMatchNext (Prid)
           The data classes defined formally in the Authentication PIB module
   (section 7) are introduced and discussed here.

4.1. Event class

   Instances path for 'out of this table represent events scope' traffic_ that occurred at is not
           matched by one of the PEP. eventHdlrElement's filter clauses.

3.1.4.2. EventHdlrElement class

   The events reference PDP installs EventHandlerElements as part of constructing the
   event handler instance handler. EventHandlerElements describe when events will be
   generated and which COPS request handles will be used to send the specific
   event handler element that
   requests.

   The purpose of the event was caught by. EventHdlrElement is to specify the
   characteristics of the EventHandler. The attributes in the
   EventHdlrElement provide maximal reuse by allowing multiple
   instances of this class are:

        eventId (InstanceId)
           Identifies this object

        eventEventHdlr (ReferenceId)
           This attribute allows a PEP to indicate an EventHandler to reuse the PDP that same EventHdlrElement
   instance. Each Instance of this
           event was generated due PRC belongs to a group of
   eventHdlrElement PRIs. The group is identified by the referenced Event Handler.
           This attribute references an event handler via
   eventHdlrElementGrpId attribute. These are provisioned by the
           indirection PDP on
   the PEP to catch specific events. This PRC frwkReference, since the event handler and
           event could potentially belong to a different PIB contexts.

        eventCause (ReferenceId)
           This attribute references the specific instance in a group
           of event Handler elements belonging to an event Handler that
           resulted in this event. This attribute references a specific
           event handler element via the indirection PRC frwkReference,
           since the event handler element and event could potentially
           belong to a different PIB contexts.

4.2. EventHandler class

   Instances of this PRC are provisioned by the PDP on the PEP to catch
   specific events. The Event Handlers reference a group of
   eventHdlrElement PRIs that contain the scope of the event and
   specify the context data to send to the PDP when an event is caught.

   The attributes of the EventHandler Class are as follows:

        eventHandlerId (InstanceId)
           identifies an instance of this class

        eventHandlerElements (TagReferenceId)
           A reference to a group of eventHdlrElement instances, each
           of which determines the scope (criteria for generating a new
           request) and what context information to send in a request.

        eventHandlerNonMatchNext (Prid)
           The data path for "out of scope" traffic that is not matched
           by one of the eventHdlrElementÆs filter clauses.

4.3. EventHdlrElement class

   The purpose of the EventHdlrElement is to specify the
   characteristics of the EventHandler. The attributes in the
   EventHdlrElement provide maximal reuse by allowing multiple
   instances of an EventHandler to reuse the same EventHdlrElement
   instance. Each Instance of this PRC belongs to a group of
   eventHdlrElement PRIs. The group is identified by the
   eventHdlrElementGrpId attribute. These are provisioned by the PDP on
   the PEP to catch specific events. This PRC contains the scope of contains the scope of the
   event and specifies the context data type to send to the PDP when an
   event is caught.

   Each EventHdlrElement constitutes a unique event semantic. Since the
   Event Scope, Handle Scope and Context Data are all bound to the
   EventHdlrElement, different EventHdlrElements can have different
   Event Scope (matching rules), Handle Scope (Handle generation
   rules), and Context Data (event specific data passed with the Event
   Message). This is why Event objects generated by the PEP reference
   both the Event Handler and the Event Handler Element that generated
   the event.

   One key aspect of the EventHdlrElement is the Event Criteria
   attribute. This attribute is used to describe whether unique events
   are one time events or repeatable events. For instance, every RSVP
   message may need to result in a Event Message. However, an Event
   Message may only be appropriate the first time a new Src IP address
   is seen. After that no events should be generated for that address.
   However other new addresses should still generate Event Messages.

   The Event Criteria attribute defines the frequency with which events
   should be generated. If the Event Criteria is set to One_Time, 'One_Time',
   only one event will ever be generated for that EventHdlrElement when
   the first match occurs, irrespective of the number of subsequent
   matches. If the Event Criteria is set to Every_Time, 'Every_Time', each match
   will result in an Event Message. A hybrid case is defined called
   On_Change.
   'On_Change'. This option allows a subset of the filter attributes to
   be required for matching and a different set of attributes that must
   from a unique n-tuple in order to generate an Event Message. See
   Section 4.6 3.2.4 for more details of the behavior of the On_Change 'On_Change'
   attribute.

   The EventHdlrHandleScope is optional. If it is not specified, itÆs it's
   behavioral rules are taken from the EventHdlrEventScope objects
   associated with the relevant EventHdlrElement. In other words, the
   criteria for generating Request Handles will be identical to the
   criteria for generating Event Messages when the EventHdlrHandleScope
   is not explicitly specified.

   The attributes of the EventHdlrElement class are:

        eventHdlrElementId (InstanceId)
           identifies the object

        eventHdlrElementEventCriteria (Unsigned32)
           Indicates when an event is generated. Valid options are
           one_time, every_time
           'one_time', 'every_time' and on_change. 'on_change'. This attribute
           allows event Handlers to distinguish one time events (ignore
           after the first match) from recurring events (generate an
           event every time a match occurs).  An enum type is also
           define to specify that a new event should be generated when
           a specific set of fields change. This is important for
           protocols like RSVP because messages are sent both to
           demonstrate that the reservation is active and to notify
           hops of changes to reservations. Since only changes need to
           propagate to the PDP, the on_change 'on_change' option indicates that that
           those events should be generated selectively.

        eventHdlrElementGrpId (TagId)
           Group identifier. All instances with the same group
           identifier belong to one group and can be referenced
           collectively from an eventHandler instance.

        eventHdlrElementEventScope (TagReferenceId)
           Identifies a group of eventHdlrEventScope entries associated
           with this eventHdlrElement instance.

        eventHdlrElementHandleScope TagReferenceId)
           Identifies a group of eventHdlrHandleScope entries
           associated with this eventHdlrElement instance. This is an
           optional attribute.

        eventHdlrElementContext (TagReferenceId)
           Identifies a list of ContextDataTable entries associated
           with this eventHdlrElement instance.

        eventHdlrElementMatchNext (Prid)
           The data path for traffic in scope.

4.4.

3.1.4.3. EventHdlrEventScope class

   This PRC defines the scope of an event handler element using
   references to filters defined in the Framework PIB or in some other
   PIBs. These filters may describe specific protocol properties for
   which events need to be generated. These filter references are
   grouped using a TagId, and this group is then referenced from the
   eventHdlrElement PRC.

   Whenever traffic arrives at the EventHandler for which an Event
   Message has not already been generated, it is compared against the
   FilterEntry objects of the EventHdlrEventScope objects referenced by
   the EventHdlrElement. If it matches the criteria specified in all of
   the FilterEntry objects, a new Event Message is generated and sent
   to the PDP. The value of EventHdlrElementÆs EventHdlrElement's EventCriteria attribute
   in conjunction with the value of the Event Scope classÆs class's ChangeFlag
   attribute determine whether an Event Message will be generated.

   For example, if a FilterEntry object specifies SRC IP address
   (10.20.0.0) and SRC IP Mask (FF.FF.0.0) and the EventCriteria is set
   to One_Time, the first address in the range of 10.20.0.0 and
   10.20.255.255 will generate an event and no events will follow. If
   the EventCriteria is set to Every_Time for the same attribute
   settings, each time a packet contains an IP address within the range
   an Event Message will be generated. If the EventCriteria is set to
   On_Change and the eventHdlrEventScopeChangeFlag is set to True, each
   new IP address within the range 10.20.0.0 and 10.20.255.255 will
   trigger a new Event Message. However, as soon as a specific Src IP
   address like 10.20.15.109 has generated an Event Message, that
   specific address will no longer generate an event. If the
   EventCriteria is set to On_Change and the
   eventHdlrEventScopeChangeFlag is set to False for the example
   address range, than the eventHdlrEventScope instance with the
   ChangeFlag set to True will determine uniqueness. In this scenario,
   the address range is acting as a strict filter that must be met
   without regard to which address in the range is responsible or
   whether that address has been seen previously.

   When multiple fields are specified for the filter and the ChangeFlag
   is set to true, each unique combination of field values generates an
   event. For example, if the SRC IP is assigned a range of
   10.10.10.224 to 10.10.10.255 and DST Ports 80 to 90 then
   10.10.10.240+80, 10.10.10.240+81, and 10.10.10.250+80 would all
   generate separate events. The combination of supporting multiple
   filters and being able to control precedence allows for the
   construction of both lists (10.10.x.x and 10.15.x.x) and
   combinations of disjoint headers in a single match criteria (any
   combination of 10.10.x.x and VLANs 100 to 120). See Section 4.6 for
   a detailed example of filter construction.

   The attributes of this class are:

        eventHdlrEventScopeId (InstanceId)
           Identifies this object

        eventHdlrEventScopeGroup (TagId)
           Contains the tag by which the EventHdlrElement references
           this object. This is the means by which a list of filters
           can be associated with an EventHandler.

        eventHdlrEventScopeFilter (PRID)
           Points to a FilterEntry object (as defined in the Framework
           PIB) that specifies the filter for this EventHdlrEventScope
           object

        eventHdlrEventScopePrecedence (Integer)
           Represents the precedence of this criterion with respect to
           other criteria within the same group. When the precedence is
           unique, the instance represents an alternative criterion (an
           OR function). When the precedence for two or more instances
           of the eventHdlrEventScope class is the same, the attributes
           within all the instances are treated collectively as a
           single filter criteria.

        eventHdlrEventScopeChangeFlag (TruthValue)
           Boolean value, if set to "True" 'true' indicates that a new event
           should be generated if any of the assigned fields in the
           associated filter change.

4.5.

3.1.4.4. EventHdlrHandleScope class

   This PRC defines the scope of Request Handles generated by the PEP
   due to events caught by the Event Handler Element. Each instance of
   this PRC references filters defined in the Framework PIB or some
   other signaling-protocol specific filter PRCs. These filters may
   describe specific protocol properties to which this Event Handler is
   sensitive. Essentially this table defines when a new COPS Request
   Handles must be created by the PEP based on protocol properties. The
   Event Handler may be set up to be sensitive to specific field values
   and/or the uniqueness of a set of values considered together. This
   accommodates various behaviors of signaling protocols. These filter
   references are grouped using a TagId, and this group is then
   referenced from the eventHdlrElement PRC via the
   eventHdlrElementHandleScope TagReference.

   The behavior of the EventHdlrHandleScope class is identical to the
   behavior of the EventHdlrEventScope. The only difference is the
   EventHdlrEventScope determines when new Events are created and the
   EventHdlrHandleScope determines when new COPS Request Handles are
   created. It is important to note that the attributes determining
   when a new Handle is created MUST be a subset of the filter
   attributes and filter values specified for the EventHdlrEventScope.
   The reason for this is that an Event Message MUST use one of the
   available Request Handles to notify the PDP of an Event. If the
   attributes and values used in the EventHdlrEventScope are not a
   superset of the attributes and values EventHdlrHandleScope, then
   there may be no valid Handle over which the Event Message can be
   sent to the PDP.

   The EventHdlrHandleScope is optional. If it is not specified, itÆs it's
   behavioral rules are taken from the EventHdlrEventScope objects
   associated with the relevant EventHdlrElement. In other words, the
   criteria for generating Request Handles will be identical to the
   criteria for generating Event Messages when the EventHdlrHandleScope
   is not explicitly specified.

   See Sections 4.3 3.1.2 and 4.6 3.2.4 for more details on the operational
   behavior of this class.

        eventHdlrHandleScopeId (InstanceId)
           An arbitrary integer index that uniquely identifies an
           instance of the eventHdlrHandleScopeTable class.

        eventHdlrHandleScopeGroup (TagId)
           Represents the binding between the eventHdlrElementEntry and
           the eventHdlrHandleScope entries. A group of
           eventHdlrHandleScope entries constitutes the criteria for
           defining the scope of the Handles generated.

        eventHdlrHandleScopeFilter (Prid)
           Pointer to a filter to be used as the criteria.

        eventHdlrHandleScopePrecedence (INTEGER)
           Represents the precedence of this criterion with respect to
           other criteria within the same group. When the precedence is
           unique, the instance represents an alternative criteria (an
           ORing function). When the precedence for two or more
           instances of the eventHdlrHandleScope class is the same, the
           attributes within all the instances are treated collectively
           as a single filter criteria.

        eventHdlrHandleScopeChangeFlag (TruthValue)
           Boolean value, if set to "True" 'true' indicates that a new Handle
           should be generated if any of the assigned fields in the
           associated filter change.

   The PDP installs EventHandlerElements as part of constructing

3.1.4.5. ContextData class

   This PRC specifies the
   event handler. EventHandlerElements describe when events will be
   generated and which COPS request handles will be used context information to send to the
   requests.

4.6. Behavior of the Event and Handle Scope classes PDP when
   an event is caught. The rules for interpreting Handle Scope and Event Scope are the
   same. One context information to send is applied described in
   terms of the PRC data types to Handles include in the request, the level of
   encapsulated data and the other is applied interface information for that request.

   The attributes of this class are:

        ContextDataId (InstanceId)
           Identifies this object

        ContextDataGroup (TagId)
           Defines the grouping of contextData instances that are
           applicable to Events.

   Each scope a given eventHdlrElement.

        ContextDataIfElement (PrcIdentifier)
           The OID of a class (Event Scope or Handle Scope) whose instance has a
   precedence value associated is to be included with it. When two
           the PEP request or more scope class
   instances event-specific ContextData Response.

        ContextDataEncapsulation (Integer)
           This attribute allows one to distinguish between inner and
           outer headers when there are multiple encapsulated headers
           of the same type (event vs handle) have in a packet.

               A value of:
               0 means all headers,
               positive number 'n' means the same
   precedence number, they are considered part of 'n'th header starting
               from the same rule. For
   example, outermost,
               negative number 'n' means the table below lists a set of Event Scope class instances,
   their precedence values and 'n'th header starting from
               the filter field names and values
   associated with each instance: (FName is innermost.

3.2. Event Handling

   As soon as the field name)

   Instance   Precedence   FName/Val   FName/Val   FName/Val
   --------   ----------   ---------   ---------   ---------
       1*         2        W/20        X/2-4
       2*         1        A/5-6       B/15        C/10-11
       3          2        W/14                    Y/500-550
       4          2        Q/4-9       R/92
   This example would result in events being generated when one of the
   two expressions below are matched:
   1. (A=5 or A=6) and (B=15) and (C=10 or C=11 or C=12)
   2. (W=20 or W=14) and (X=2-4) and (Y=500-550) and (Q=4-9) and (R=92)

   If the EventCriteria was set to "OneTime", then if either 1 or 2 is
   matched, one PEP detects a situation described by an event will be generated and this particular Event
   Handler Element will generate no further events. Note that if
   matches occur but the "OneTime"
   handler, it must trigger an event. If an event has already been generated, is triggered, the Event Hander Element's MatchNext attribute may still determine
   what PEP
   must send a message to the next forwarding action is for PDP that installs the packet event thought no handler. This
   section describes how this message looks like.

3.2.1. Functional Description

   The event is generated.

   If message that the EventCriteria was set PEP needs to "EveryTime", then every matching
   packet will cause an event. If the EventCriteria was set send to
   "OnChange", then events will be generated the first time a unique
   combination of attributes PDP is seen. Setting the ChangeFlag in the
   EventScope class (denoted by a common
   COPS-PR request message, containing exactly one event data
   structure, and optionally zero or more context data classes,
   depending on which eventHandlerElement triggered the asterisks event. Context
   Data classes are described in the previous example),
   identifies the set chapter 4.

   An event message typically represents an access request of attributes a client,
   the decision for which unique combinations of
   values generated new events.

   Continuing the example above PEP outsources to the following table shows a stream of
   packets and whether an PDP. See Figure
   3.3.

      time
       |   +---+                       +---+
       |   |   |-- provisioning req. ->|   |
       |   |   |<-- provisioning ------|   |
       |   | P |                       | P |
       |   | E |--- event will be generated.

   1. A=5, B=19, C=10                   No Event (B did not match)
   2. A=5, B=15, C=10                   Event (Unique pairing of A & C)
   3. A=6, B=15, C=11                   Event (Unique pairing of A & C)
   4. W=20, X=2, Y=500, Q=4, R=92       Event (Unique pairing of W & X)
   5. W=20, X=2, Y=505, Q=9, R=92       No Event (Already have a
                                                   matched for W & X)
   6. A=5, B=15, C=11                   Event (Unique pairing of A & C)
   7. A=5, B=15, C=10                   No Event (Already have a
                                        matched ------------>| D |
       |   | P |                       | P |
       |   |   |<-- decision ----------|   |
       V   +---+                       +---+
      Figure 3.3: Simple message sequence for A & C)

4.7. EventHdlrAuthProtocol class

   This
   class allows a PDP to configure provisioning and events.

3.2.2. COPS Client Handle

   The event and the set of authentication mechanisms
   that decision are allowed for users or devices that must authenticate associated with each other using the
   COPS Client Handle, which is described in
   order to have access policies assigned to them.

   The attributes section 2.2.1 of RFC 2748.
   Each COPS message contains this class are:

        EventHdlrAuthProtocolId (InstanceId)
           Identifies this object

        EventHdlrAuthProtocolGroup (TagId)
           Represents a binding between an datapathEventHdlrTable
           instance and a list of eventHdlrAuthProtocolTable instances.

        EventHdlrAuthProtocolAuthMechanism (Enum)
           Specifies Client Handle, which serves as an authentication mechanism
   identifier to match request and response, and can later be used in Event
           Messages triggered by the EventHandler referencing this
           EventHdlrAuthProtocol object. The value is from an
           enumerated list initially consisting of (PAP, CHAP, EAP-MD5,
           and EAP-TLS)

4.8. DatapathEventHdlr Class
   This PRC is to
   remove an extension of earlier install decision.

   Because the EventHandler PRC. This extension
   illustrates COPS Client Handle serves as a connection between the use of
   request and the EventHandler PRC concept for
   authentication usage. Instances of this PRC are provisioned by decision, there must not be more then one
   outstanding COPS request with the
   PDP on same Client Handle. It is possible
   to have multiple outstanding COPS requests, as long as their Client
   Handle is different.

   For most applications, the PEP to catch specific events that require authentication
   processing. This PRC references a group of eventHdlrAuthProtocol
   instances that define will generate a set of Authentication mechanisms to use new unique COPS
   Client Handle for each event. However, in some situation it can be
   useful if
   an access event the same client handle is caught by this event Handler. From its base class
   (Event Handler) this PRC also references a group of eventHdlrElement
   PRIs used for multiple events. This
   implies that contain the scope of second even can only be sent after the access event and PDP sent a
   response for the first event. The PDP can explicitly specify when
   the
   context data PEP must use a new COPS Client Handle, by using the
   eventHdlrElementHandleScope. This should point to send a scope, similar
   to the PDP eventHdlrElementEventScope. Only when an access event is caught.

   The attributes of this class are:
        datapathEventHdlrRequestAuth (TruthValue)
           Boolean flag, if set to "True" requires authentication data
           to be sent the criteria in the Event Message sent to
   eventHdlrElementHandleScope matches, the PDP.

        datapathEventHdlrAuthProtocol (TagReferenceId)
           References PEP must create a group of eventHdlrAuthProtocol instances, each new COPS
   Client Handle.

3.2.3. DiffServ element

   In case the Event Handler is part of which specifies an authentication mechanism.

4.9. ContextData class

   This PRC specifies a DiffServ model, the context information to send
   EventHandler acts as a Classifying DiffServ element. If no criteria
   are met, the ingress traffic for this element is forwarded to the PDP when
   an event
   DiffServ element specified by the eventHandlerNonMatchNext attribute
   in the EventHandler instance. If a criteria is caught. The context information met, traffic
   belonging to send this ingress dataflow is described dropped (or forwarded to the
   PDP, as is shown in
   terms of chapter 7), until the PRC data types PDP responds to include in the request,
   outstanding request. If the level of
   encapsulated data and response is affirmative, the interface information for that request.

   The attributes properties
   of this class are:

        ContextDataId (InstanceId)
           Identifies this object

        ContextDataGroup (TagId)
           Defines the grouping of contextData instances that are
           applicable to a given eventHdlrElement.

        ContextDataIfElement (PrcIdentifier)
           The OID of a class whose instance is to be included with ingress dataflow, as specified by the PEP request or event-specific ContextData Response.

        ContextDataEncapsulation (Integer)
           This attribute allows one to distinguish between inner
   eventHdlrElementEventCriteria and
           outer headers when there eventHdlrEventScopeChangeFlags are multiple encapsulated headers
           of the same type
   stored, typically in a packet.

               A value of:
               0 means lookup-table, and all headers,
               positive number 'n' means the 'n'th header starting traffic coming from
   this ingress dataflow is forwarded to the outermost,
               negative number 'n' means DiffServ element specified
   by the 'n'th header starting eventHdlrElementMatchNext attribute. If the response from the innermost.

4.10. ContextData classes

   This section contains examples of classes that might be referenced
   by
   PDP is negative, the ContextData class as classes that must be included in authorization failed, and the
   Event Message for various types of eventHdlrElements.

   There are two kinds of ContextData classes depending on PEP can just
   forward the type of
   PEP. Some PEPs receive traffic to the eventHandlerNonMatchNext until an event
   is triggered.

   An affirmative reply from many users over a shared port
   such the PDP is defined as an Ethernet port.  They recognize new users based on
   information a COPS-PR Decision
   message with the command in the headers Decision flag object set to Install
   (section 2.2.6 of incoming packets.  For them, the
   ContextData will come from packet headers.  The L3HeaderData class
   is an RFC 2748). An example of this kind of ContextData class.  Other PEPs receive
   traffic from one user per interface.  For them, the context data
   will be information about how the interface.  The
   CtxtDialupInterfaceFramedProtocol class is an example of this kind
   of ContextData class.

4.10.1. CtxtL3Hdr class

   This class specifies level three header data. This class EventCriteria and
   ChangeFlags specify a filter is used to
   inform the PDP of given in 3.1.2, while section 3.2.4
   further clarifies the details scopes.

3.2.4. Behavior of the IP header that caused the PEP Event Message to be generated. and Handle Scope classes

   The attributes of this class are:

        CtxtL3HdrId (InstanceId)
           identifies this object

        CtxtL3HdrSrcAddrType (Enum)
           specifies the type of the packetÆs layer 3 source address

        CtxtL3HdrSrcAddr rules for interpreting Handle Scope and Event Scope are the packetÆs layer 3 source address

        CtxtL3HdrDstAddrType (Enum)
           specifies
   same. One is applied to Handles and the type other is applied to Events.

   Some of the packetÆs layer 3 destination
           address

        CtxtL3HdrDstAddr
           the packetÆs layer 3 destination address

        CtxtL3HdrProtocol
           the packetÆs protocol field

        CtxtL3HdrSrcPort classes used by the packetÆs source port field
        CtxtL3HdrDstPort Access Bind PIB are the packetÆs destination port field

        CtxtL3HdrDscp Filter
   classes described in the packetÆs Type COPS-PR Framework PIB [FWPIB]. These
   classes allow a PDP to specify a set of Service (Diffserv Code Point)field

        CtxtL3HdrEcn (boolean)
           Indicates whether this packet is ECN capable (True) or not
           (False)

        CtxtL3HdrIpOpt 802.1 and IP Options

        CtxtL3HdrEncap
           The Encap allows the PEP to indicate where this header is in
           relation to other IP headers found in the packet (with
           tunnels). This value field
   values that can be either positive or negative
           depending on how the EventHandler (or the Session-specific
           Context Data request) was specified using negative or
           positive numbers.

           A negative n means return the nth layer from the innermost
           header. A positive n means return the nth layer from matched against packets. The Event Scope and
   Handle Scope classes can use these filter classes as well as other
   filter classes to define the
           outermost header.

4.10.2. Ctxt802Hdr class

   This criteria for generating an event.

   Each scope class specifies IEEE 802.1 header data. This (Event Scope or Handle Scope) instance has a
   precedence value associated with it. When two or more scope class is used to
   inform the PDP
   instances of the details of same type (event vs. handle) have the 802 header that caused same
   precedence number, they are considered part of the PEP
   Event Message to be generated.

   The attributes same rule. For
   example, table 3.1 lists a set of this Event Scope class are:

        Ctxt802HdrId (InstanceId)
           identifies this object

        Ctxt802HdrSrcAddr
           the frameÆs source MAC address

        Ctxt802HdrDstAddr
           the frameÆs destination MAC address

        Ctxt802HdrProtocol
           the layer 2 frameÆs protocol field

        Ctxt802HdrPriority instances, their
   precedence values and the layer 2 frameÆs priority filter field (only used if the frame names and values associated
   with each instance (FName is using the 802.q header extension)

        Ctxt802HdrVlan the layer 2 frameÆs VLAN field  (only used if the frame is
           using name):

      Instance   Precedence   FName/Val   FName/Val   FName/Val
      --------   ----------   ---------   ---------   ---------
          1*         2        W/20        X/2-4
          2*         1        A/5-6       B/15        C/10-11
          3          2        W/14                    Y/500-550
          4          2        Q/4-9       R/92

      Table 3.1: List of Filter rules

   This example would result in the 802.q header extension)
        Ctxt802HdrEncap
           The Encap allows following two filter expressions:
   1. (A=5 or A=6) and (B=15) and (C=10 or C=11 or C=12)
   2. (W=20 or W=14) and (X=2-4) and (Y=500-550) and (Q=4-9) and (R=92)

   If the PEP to indicate where this header is in
           relation EventCriteria was set to other IP headers found in the packet (with
           tunnels). This value can be 'One Time', then if either positive 1 or negative
           depending on how the 2 is
   matched, one event will be generated and this particular Event
   Handler (or Element will generate no further events. Note that if
   matches occur but the explicitly
           requested PDP Context Data request) was specified using
           negative or positive numbers.

           A negative n means return 'One Time' event has already been generated,
   the nth layer from Event Hander Element's MatchNext attribute may still determine
   what the innermost
           header. A positive n means return next forwarding action is for the nth layer from packet event even though
   no event is generated.

   If the
           outermost header.

4.10.3. CtxtDialupInterface class

   The CtxtDialupInterface class specifies data EventCriteria was set to 'Every Time', then every matching
   packet will cause an event. If the EventCriteria was set to 'On
   Change', then events will be included in Event
   Messages sent by Event Handlers providing dialin services.

   The attributes of this class are:

        CtxtDialupInterfaceId
           identifies this object

        CtxtDialupInterfaceNASPort
           This attribute indicates generated the physical port number first time a unique
   combination of
           the NAS which attributes is authenticating the user. Note that this is
           using 'port' in its sense of a physical connection on seen. Setting the
           NAS, not ChangeFlag to 'True'
   in the sense of a TCP or UDP port number.  Either
           CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType
           or both SHOULD be specified in a CtxtDialupInterface object,
           if EventScope class (denoted by the NAS differentiates among its ports.

        CtxtDialupInterfaceNASPortId
           This attribute contains a text string which asterisks next to the
   Instance number in Table 3.1), identifies the
           port set of the NAS attributes for
   which unique combinations of values generated new events. The
   ChangeFlag is authenticating applied to the user.  Note that
           this is using 'port' in its sense attribute, not the specific instance of a physical connection
           on
   the NAS, filter. Therefore, even though instance 3 does not in have the sense of a TCP or UDP port number.
           Either CtxtDialupInterfaceNasPort or
           CtxtDialupInterfaceNasPortId SHOULD be
   ChangeFlag set, the values for attribute W specified in a
           CtxtDialupInterface object, instance 3
   will be treated as if the NAS differentiates among
           its ports.  CtxtDialupInterfaceNasPortId is intended ChangeFlag was set for use
           by NASes which cannot conveniently number their ports.

        CtxtDialupInterfaceNASPortType (Enum)
           This attribute indicates that attribute, as
   per example 8 below.

   Continuing the type of example above the physical port following table shows a stream of the NAS which is authenticating the user.  It can
   packets and whether an event will be
           used instead generated.

   1. A=5, B=19, C=10                   No Event (B did not match)
   2. A=5, B=15, C=10                   Event (Unique pairing of or in addition to the
           CtxtDialupInterfaceNasPort attribute.

        CtxtDialupInterfaceCalledStationId
           This attribute allows the NAS to send the phone number that
           the user called, using Dialed Number Identification (DNIS)
           or similar technology.  Note that this may be different from
           the phone number the call comes in on.

        CtxtDialupInterfaceCallingStationId
           This attribute allows the NAS to send the phone number that A & C)
   3. A=6, B=15, C=11                   Event (Unique pairing of A & C)
   4. W=20, X=2, Y=500, Q=4, R=92       Event (Unique pairing of W & X)
   5. W=20, X=2, Y=505, Q=9, R=92       No Event (Already have a
                                                   matched for W & X)
   6. A=5, B=15, C=11                   Event (Unique pairing of A & C)
   7. A=5, B=15, C=10                   No Event (Already have a
                                        matched for A & C)
   8. W=20, X=3, Y=502, Q=7, R=95       No Event (no match on R)
   9. W=14, X=2, Y=500, Q=4, R=92       Event (Unique pairing of W & X)

3.2.5. Context Data Entries

   Section 3.1.3 described the call came from, using Automatic Number Identification
           (ANI) or similar technology.

        CtxtDialupInterfaceConnectInfo
           This attribute ContextData class and how it is sent from the NAS used to indicate
   provision the
           nature set of the user's connection.

   This is a notify-only class.  These attributes are not write-able by
   the PDP.

   Three additional notify/install classes can be defined.  These
   classes can event-specific information elements that must
   be included in an with each Event Message as information to Message. This section provides an
   overview of the
   PDP.  The PDP may change format of the values actual information elements.

   Each Context Data Entry is organized to logically describe a layer
   or grouping of these attributes, however, in
   subsequent provisioning messages.

4.10.4 CtxtDialupIfFramedProtocol class attributes. The CtxtDialupIfFramedProtocol class downside of this strategy is an optional class that may
   be sent if
   when a framed protocol specific entry is being used. This class MAY be
   specified in the ContextData PRC by requested, all the PDP fields in a decision message if the PDP needs this context information (if it was not already setup
   to entry must
   be sent in filled before the eventHandler). It MUST entry can be sent up to the PDP in a
   request message if it is specified via the ContextData PRC in an
   eventHandler.
   The attributes of this class are:

        CtxtDialupIfFramedProtocolId
           identifies this object

        CtxtDialupIfFramedProtocolProt PDP. This attribute indicates is a
   compromise between forcing the framing PDP to be used for
           framed access.

        CtxtDialupIfFramedProtocolMTU
           This attribute indicates describe all the Maximum Transmission Unit to be
           configured for fields
   explicitly and making the user, when PEP send all attributes of possible
   interest. Since a given PDP knows better what it needs to generate a
   decision than a PEP, the second alternative is not negotiated by some extremely unwieldy.
   On the other means (such as PPP).

        CtxtDialupIfFramedProtocolCompression (Enum)
           This attribute indicates a compression protocol to be used
           for hand, forcing the link.

        CtxtDialupIfFramedProtocolPortLimit
           This attribute sets PDP to describe all the maximum number fields
   necessary for a given event, would create an explosion of object
   definitions.

   In sections 3.2.6.2, there are two classes that are defined as part
   of ports to be
           provided to the user by Access Bind PIB. These objects define the NAS. relevant fields of
   a Ethernet header and a IP header. It is intended for use was determined that these
   headers existed in
           conjunction with Multilink PPP or similar uses.

        CtxtDialupIfFramedProtocolIpAddress a large enough cross-section of application-
   specific signaling PIBs, that they belonged in the Access Bind PIB.
   This attribute indicates does not impact those application-specific signaling PIBs that
   don't use one or both headers. Since the address PDP request only those
   headers relevant to each application specific event, these classes
   do not need to be configured for
           the user.  It MAY be used implemented in constructing policies for order to meet the
           user.

        CtxtDialupIfFramedProtocolIpNetmask compliance
   requirements for this PIB.

3.2.6. Data Description

   This attribute indicates section describes the IP netmask behavior of all classes associated with
   the generation of event messages to be
           configured for the user when the user is a router to a
           network.

4.10.5 CtxtDialupIfLoginService class

   The CtxtDialupIfLoginService class is an optional PDP.

3.2.6.1. Event class

   Instances of this table represent events that may be
   sent if a Login service is being provided. This class MAY be
   specified in occurred at the ContextData PRC by PEP.
   The events reference the PDP in event handler instance and the specific
   event handler element that the event was caught by.

   The attributes of this class are:

        eventId (InstanceId)
           Identifies this object

        eventEventHdlr (ReferenceId)
           This attribute allows a decision message if PEP to indicate to the PDP needs that this context information (if it
           event was not already setup
   to be sent in the eventHandler). It MUST be sent up generated due to the PDP in a
   request message if it is specified referenced Event Handler.
           This attribute references an event handler via the ContextData
           indirection PRC in an
   eventHandler.

   This class contains frwkReference, since the event handler and
           event could potentially belong to a single attribute:

        CtxtDialupIfLoginIpHost different PIB contexts.

        eventCause (ReferenceId)
           This attribute indicates references the system with which specific instance in a group
           of event Handler elements belonging to connect he
           user.

4.10.6 CtxtDialupIfLoginLat class
   This class MAY be specified an event Handler that
           resulted in this event. This attribute references a specific
           event handler element via the ContextData indirection PRC by the PDP in a
   decision message if frwkReference,
           since the PDP needs this context information (if it
   was not already setup event handler element and event could potentially
           belong to a different PIB contexts.

3.2.6.2. ContextData classes

   This section contains examples of classes that might be sent in referenced
   by the eventHandler). It MUST ContextData class as classes that must be
   sent up to the PDP included in a request message if it is specified via the
   Event Message for various types of eventHdlrElements.

   There are two kinds of ContextData PRC in classes depending on the type of
   PEP. Some PEPs receive traffic from many users over a shared port
   such as an eventHandler. Ethernet port.  They recognize new users based on
   information in the headers of incoming packets.  For them, the
   ContextData will come from packet headers.  The CtxtDialupIfLoginLat L3HeaderData class extends the
   CtxtDialupInterfaceLoginService
   is an example of this kind of ContextData class.  Its attributes are:

        CtxtDialupIfLoginLatService
           This attribute indicates the system with which the  Other PEPs receive
   traffic from one user
           is to be connected by LAT.

        CtxtDialupIfLoginLatNode
           This attribute indicates the Node with which per interface.  For them, the user is to context data
   will be automatically connected by LAT.

        CtxtDialupIfLoginLatGroup
           This attribute contains a string identifying information about the LAT group
           codes which interface.  The
   CtxtDialupInterfaceFramedProtocol class is an example of this user kind
   of ContextData class.

3.2.6.2.1. CtxtL3Hdr class

   This class specifies level three header data. This class is authorized used to use.

           LAT supports 256 different group codes, which LAT uses as a
           form of access rights.  LAT encodes
   inform the group codes as a 256
           bit bitmap.

           Administrators can assign one or more PDP of the group code bits
           at details of the LAT service provider; it will only accept LAT
           connections IP header that have these group codes set in caused the bit map. PEP
   Event Message to be generated.

   The administrators assign a bitmap attributes of authorized group codes
           to each user; LAT gets these from this class are:

        CtxtL3HdrId (InstanceId)
           identifies this object

        CtxtL3HdrSrcAddrType (Enum)
           specifies the operating system, and
           uses these in its requests to type of the service providers.

        CtxtDialupIfLoginLatPort
           This attribute indicates packet's layer 3 source address

        CtxtL3HdrSrcAddr
           the Port with which packet's layer 3 source address

        CtxtL3HdrDstAddrType (Enum)
           specifies the user is to
           be connected by LAT.

4.11. AuthExt class

   This is an abstract PRC. This PRC can be extended by authentication
   PRCs that contain attributes specific to that authentication
   protocol. An instance type of the extended class packet's layer 3 destination
           address

        CtxtL3HdrDstAddr
           the packet's layer 3 destination address

        CtxtL3HdrProtocol
           the packet's protocol field

        CtxtL3HdrSrcPort
           the packet's source port field

        CtxtL3HdrDstPort
           the packet's destination port field

        CtxtL3HdrDscp
           the packet's Type of Service (Diffserv Code Point)field

        CtxtL3HdrEcn (boolean)
           Indicates whether this packet is created by ECN capable (True) or not
           (False)

        CtxtL3HdrIpOpt
           IP Options

        CtxtL3HdrEncap
           The Encap allows the PEP
   and sent to the PDP. The PDP may send information back indicate where this header is in
           relation to other IP headers found in the PEP packet (with
           tunnels). This value can be either positive or
   may use negative
           depending on how the information to authenticate EventHandler (or the PEP's Event Message. Session-specific
           Context Data request) was specified using negative or
           positive numbers.

           A negative n means return the nth layer from the innermost
           header. A positive n means return the nth layer from the
           outermost header.

3.2.6.2.2. Ctxt802Hdr class

   This class specifies IEEE 802.1 header data. This PRC itself should not be instantiated.

   The data in this class is passed between used to
   inform the PDP and of the client with
   little or no involvement details of the PEP except to forward it in 802 header that caused the
   appropriate AuthExt class instance. The PEP is not meant to store
   AuthExt objects. As such, this class, along with all its extending
   classes, is meant
   Event Message to be 'transient'. Its instances are temporary and
   are deleted by the PEP after a certain time or event. The PDP, in
   its decisions, must not refer to instances of this class that are
   sent by the PEP in its requests. Likewise, the PEP must not refer to
   instances sent by the PDP. Also, since instances are deleted, it is
   possible for InstanceIds to be reused.

   The AuthExt class is extended for each authentication mechanism
   supported. As a base class, it is never instantiated. generated.

   The attributes of this class are:

        AuthExtId

        Ctxt802HdrId (InstanceId)
           identifies this object

4.11.1. UserAuthExt class
   This is a concrete PRC used to contain user authentication fields.
   This PRC extends the base PRC authExtEntry.

   The attributes of this class are:
        userAuthExtRealm (OCTET STRING)
           The user realm octet string.

        userAuthExtUsername (OCTET STRING)
           The Username octet string.

4.11.2. AuthChapExt class
   The AuthChapExt class extends

        Ctxt802HdrSrcAddr
           the UserAuthExt class. It contains frame's source MAC address

        Ctxt802HdrDstAddr
           the
   attributes of frame's destination MAC address

        Ctxt802HdrProtocol
           the CHAP layer 2 frame's protocol [CHAP]. (See section 3.3.)

   The attributes that this class adds to field

        Ctxt802HdrPriority
           the base class are:

        AuthChapExtId (Unsigned32)
           The AuthChapExtId is generated by layer 2 frame's priority field (only used if the PEP. The ID value frame
           is
           sent to the client. When using the client endpoint (Peer)
           generates a CHAP response it includes 802.q header extension)

        Ctxt802HdrVlan
           the same ID, and layer 2 frame's VLAN field  (only used if the
           ID is then included in this attribute when it frame is sent to
           using the
           PDP.

        AuthChapExtChal (Octet String) 802.q header extension)

        Ctxt802HdrEncap
           The AuthChapExtChal is generated by Encap allows the PEP. The Challenge
           value PEP to indicate where this header is sent in
           relation to other IP headers found in the client, along with packet (with
           tunnels). This value can be either positive or negative
           depending on how the ID. When Event Handler (or the
           client generates a CHAP response containing explicitly
           requested PDP Context Data request) was specified using
           negative or positive numbers.

           A negative n means return the ID and
           Response (key), nth layer from the Challenge associated with innermost
           header. A positive n means return the ID is
           included in this attribute when it is sent to nth layer from the PDP.

        AuthChapExtResp (Octet String)
           outermost header.

4. Identity Extensions PIB module

   The Response is calculated by the client and forwarded by
           the Access Bind PIB provides a basic framework for processing PEP to
   events. A subset of events require identity management of some type.
   In some cases this means that the PDP.

4.11.3. AuthPapExt class

   The AuthPapExt class PDP, PEP and end system are
   involved in some type of authentication process. An Identity
   Extensions PIB is provided that extends the UserAuthExt class. It contains the
   PAP Password. (See sec. 3.2.)

   The attributes that this EventHandler class and
   adds to the base class are:

        AuthPapExtPwd (Octet String)
           A one-time password used to authenticate the client

4.11.4. AuthExtResult class

   The AuthExtResult class extends the AuthExt class. It contains the some Authentication result Boolean flag.

   The attributes that Protocol specific classes. This PIB is
   described in detail below.

4.1. Functional Description

   In the operational model for this class adds to PIB, the base class are:

        AuthExtSuccessful (TruthValue)
           A Boolean flag set to true if Authentication Server is
   a specific function of the authentication (via CHAP
           or PAP) was successful.

4.11.5. AuthEapReqExt class PDP. The AuthEapReqExt class extends main purpose of the AuthExt class. It contains an
   EAP message. (See sec. 3.1.) Instances
   authentication portions of this class are sent by the
   PDP PIB is to verify the PEP. validity of
   client credentials by an Authentication Server. The attributes that verification
   process itself may do this class adds whilst ensuring some level of
   authenticity, confidentiality and integrity. Messages exchanged
   between a Client and Authentication Server (PDP) may remain
   confidential to the base class are:

        AuthEapReqExtSpecific (Octet String)
           An EAP PEP's and Proxy Servers. The message [EAP] passed from integrity may
   be ensured by some hashing algorithm so PEP's and Proxy's may
   inspect but not modify the PDP content of authentication messages.
   Clients, PEP's, Proxy's and PDP's will always need some security
   method to ensure message authenticity.

   Some authentication protocols explicitly consider proxies by
   allowing the client via
           the PEP in payload to be carried over a COPS-PR Decision message.

4.11.6. AuthEapRespExt class

   The AuthEapRespExt class extends variety of transports.
   Others depend on the AuthExt class. It contains an
   EAP message. (See sec. 3.1.) Instances termination point of this class are sent by the
   PEP connection to
   explicitly proxy the PDP.

   The attributes authentication, when that this class adds to the base class are:

        AuthEapRespExtSpecific (Octet String)
           An EAP message [EAP] passed from the client is necessary. In
   order to demonstrate the PDP via
           the PEP in a COPS-PR Report message.

5. Message Types

   All PIB messages have some form of transactional semantics. Most all
   transactions consist general utility of requests and responses. Typical provisioning
   PIBs have the PDP sending this model, a provisioning decision to variety of
   client authentication protocols will be considered in this document.
   For each protocol, the PEP negotiation mechanism will be described and
   the
   PEP responding with a success or fail. This PIB uses mapping to this paradigm
   in some cases, but it also uses a paradigm where the framework will be detailed.

4.1.1. Provisioning

   The PEP initiates will not start an event and the PDP responds authentication sequence with a success or fail. The the client if
   it hasn't been told to do that. It will only do so when a specific
   use of
   event occurs. The PDP tells the PEP exactly when this paradigm event should
   be triggered. This process is called provisioning.

   The provisioning starts with the PEP Access Event Message, initial Provisioning Request, which
   is
   triggered by a typically sent at boot time. The PEP event and requires authentication success or
   failure semantics as part sends up capability PRC's
   indicating the types of authentication it can handle. The PDP will
   reply by setting the Provisioning Decision. This section
   discusses both paradigms following Access Bind PRC's:
     a. identEventHandler (IdentityEventHandler)
     b. identEventhdlrAuthProtocol
     c. eventHdlrElement
     d. eventHdlrEventScope
     e. eventHdlrHandleScope
     f. contextData
   and how the various classes defined in
   Section 4 are combined an additional PRC instance referred to form by the various message interactions
   described in sections 2 and 3.

   Each message description
   eventhdlrEventScopeFilter in this section will include the purpose of eventhdlrEventScope table,
   indicating how the message, signaling trigger is recognized.

   In case the COPS-PR message type, PDP wants the direction PEP to perform an authentication when an
   event is triggered, provisions an Identity Event Handler
   (identEventHandler) instead of the message,
   and the class instances typically found in the message.

5.1. standard Event Handler Provisioning Decisions Handler. The
   Identity Event Handler Provisioning Decision message is has a COPS-PR
   Decision message used by few extra attributes in the PDP class to provision each Event Handler in
   allow the PEP. It is likely PDP to be a piece of a larger Decision message
   that provisions other data path components that occur either before
   or after indicate what authentication protocols to use and
   whether authentication is mandatory. This is done by setting the Event Handler
   identEventhdlrRequestAuth in the data path. However, it could also
   be sent as a part of unrelated data path or other provisioning
   components. Event Handler provisioning typically includes the
   EventHandler class, the EventHdlrElement class, the
   EventHdlrEventScope class, often the EventHdlrHandleScope class identEventHdlr to true and
   optionally letting the ContextData class. An optional set of EventHdlrAuthProtocol
   class instances may be sent if identEventHdlrAuthProtocol field reference a DataPathEventHandler is set up
   eventHdlrAuthProtocol tagid to indicate which authentication
   protocols should be used for
   Access Event Messages.

   Because the EventHdlrElement, ContextData, EventHdlrEventScope, and authentication.

   As soon as the EventHdlrHandleScope classes all describe configuration details
   of PDP has provisioned the EventHandler, any of these class instances may be shared by
   multiple EventHandler instances. Therefore, in many cases, an
   EventHandler Provisioning Decision will contain only an EventHandler PEP to watch for certain
   traffic that references instances of triggers an event, the other classes defined in previous
   Provisioning Decisions. In addition, these classes can also be
   provisioned individually in anticipation of being applied PEP is ready to start an
   EventHandler. However, because there
   authentication.

4.1.2. EAP Authentication

   The most significant aspect distinguishing EAP [EAP] from other
   authentication protocols is a relationship between that EAP assumes the
   EventHandler and EventHdlrElement classes, there negotiation is an order
   dependency
   between the classes. For instance, an EventHdlrEventScope
   must be provisioned at client and the same time or before an EventHdlrElement
   making use authentication server. In anticipation of
   the EventHdlrEventScope. EventHdlrElement,ContextData
   and data path class instances referenced by an EventHandler must be
   provisioned at fact that the same time terminating point of a connection such as PPP or before the EventHandler
   L2TP is
   provisioned.

   When not necessarily the PEP receives an EventHandler Provisioning Decision, it must
   always respond with a Provisioning Report indicating success or
   failure.

   Note same as the agent managing client
   authentication, EAP encapsulates it's negotiation process in a
   separate header that additional EventHdlrElements can simply be added forwarded in entirety to an
   existing EventHandler the server.
   This mechanism provides extra security by using preventing intermediate
   proxies from monitoring or managing authentication credentials.

   EAP supports a number of different authentication mechanisms
   including MD5, TLS, and One-Time-Password authentication.

   The terminology used in [EAP] differs from the TagId (group identifier) for terminology used in
   this document. In particular, the
   EventHandler peer, as defined in section 1.2 of
   [EAP], is referred to which as 'Client' in this document. Similarly, the element
   'authenticator' is to be added. Additional
   EventHdlrEventScope or EventHdlrHandleScope instances can be added
   similarly by adding PRIs with called a PEP in this document and 'back-end
   server' is called the TagId value Authentication Server function of the group these
   instances are to be added to. This allows incremental updates to be
   made to PDP (or
   just PDP) in this document.

4.1.2.1. EAP Message sequence

   The generic sequence of transmissions between the Event Handlers.

5.2. Provisioning Decision

   A report must follow all provisioning decisions PEP and PDP has
   already been described in section
   5.1. This report may not have any class instances in it. However, it
   explicitly notifies 2. In particular, figure 2.1 gives
   an overview of the PDP that messages involved between the provisioning was successful or
   whether it failed. If many structures were simultaneously
   provisioned Client workstation,
   PEP and PDP. EAP messages are embedded in PPP packets in the Provisioning Decision and a failure occurred,
   none of
   communication between the class instances will be accepted by Client and the PEP. Hence it is
   possible that subsequent Provisioning Decisions occur with a smaller
   subset of the class instances or an alternative set of class
   instances that can satisfy the service policies defined in In the PDP.

5.3. PEP Event Message

   A PEP Event Message is generated by communication
   between the PEP to indicate that a new
   class of traffic has been identified by the Event Handler. This
   Event Message possibly uses a new COPS Request Handle. The decision
   to use a new COPS Request Handle or reuse an existing Handle is
   based on the EventHdlrHandleScope information configured in the
   Event Handler. The Handle Scope information is a set of criteria
   that is protocol specific, and specifies PDP, the set of fields EAP messages are embedded in the
   protocol that the Event Handler is sensitive towards. The PEP Event
   Message is essentially a COPS-PR Request message. The PEP Event
   Message will always include an instance of the Event class. This
   Event instance references which EventHandlerElement instance COPS
   Request, COPS Decision and
   EventHandler instance caught the event. This tells the PDP what
   events belong to which Event Handler. Other Classes that COPS Report messages. Figure 4.1 shows
   how EAP may be a
   part of a PEP Event Message include one or more instances of
   protocol specific Header Context Data and Interface data classes and
   optionally an instance of one of the Authentication Extension
   classes (for example, if the Event is an access event).

   When authentication protocols such as PAP or CHAP are in use, the
   PIB assumes that used to retrieve credentials from the UserId, Challenge, and Password will all be
   determined client
   workstation by the PEP prior to generating the PEP Access Event
   Message. PDP.

   time
    |   +---+                     +---+                          +---+
    |   |   |                     |   |-- COPS-PRC exchange ---->|   |
    |   |   |                     |   |<- COPS-Dec eventHandler -|   |
    |   |   |-- PPP traffic ----->|   |                          |   |
    |   |   |<- PPP LCP Req-EAP --|   |                          |   |
    |   | U |-- PPP LCP ACK-EAP ->| P |                          | P |
    |   | s |<- PPP EAP is an exception to this rule because Req Id ---| E |                          | D |
    |   | e |-- PPP EAP assumes a
   direct negotiation Res Id -->| P |                          | P |
    |   | r |                     |   |-- COPS-Req Ses-EAP  ---->|   |
    |   |   |                     |   |<- COPS-Dec EAP Req Chal -|   |
    |   |   |<- PPP EAP Req Chal -|   |                          |   |
    |   |   |- PPP EAP Res Chal ->|   |                          |   |
    |   |   |                     |   |- COPS-Rep EAP Res Chal ->|   |
    |   |   |                     |   |                          |   |
    |   |   |                     |   |<- COPS-Dec EAP Success --|   |
    |   |   |<- PPP EAP success --|   |                          |   |
    V   +---+                     +---+                          +---+

   Figure 4.1: Embedding of EAP messages between the Endpoint Client workstation
   and the Authentication
   server. For EAP, it is assumed that PEP, and between the Endpoint generates a
   response PEP and PDP. The EAP messages may be
   opaque to the EAP Identity Request message before PEP.

   Typically, when the PEP boots up, it sends
   the Access Event Message. This allows the PEP it's capabilities to fill in the
   Username and Realm
   PDP in the UserAuthExt table. However, for this
   scenario, it a COPS message and is also assumed that than configured by the PEP Access Event Message will
   include the EAP Identity Response in the authEapRespExtSpecific
   attribute of the AuthEapRespExtEntry class. Subsequent EAP
   negotiation will be performed PDP with one or
   more datapathEventHandlers specifying the Opaque Decision and Opaque
   Report criteria for generating
   PEP Event Messages. The first message types. When after this provisioning
   process from the negotiation PEP to the PDP is complete a new Event Message. The PEP
   sends a COPS request to the PDP send containing a Provisioning Decision message (that includes an new instance of the
   AuthExtResult class specifying success or failure). Note that all
   interactions resulting from a given
   Event Message (including
   authentication negotiation) is performed within table. The eventEventHdlr attribute in the context Event table entry
   is a ReferenceId that points to a dpeventHandler entry indicating
   (by means of the dpEventHdlrAuthProtocol) that EAP is a
   single COPS Request Handle. The COPS Request Handle provides an
   independent dialog between valid
   protocol to use for this Event. Also, the PDP and eventCause attribute in
   the PEP to fully process an
   Access Event Message in table entry is a synchronous way.

5.4. PDP Provisioning Decision

   When ReferenceId that points to an
   eventhdlrElement indication of which Filter (by means of the PDP has all
   eventhdlrEventScope) triggered the event.

   All EAP messages necessary information to determine what
   policies complete the authentication process
   will be forwarded to provision for the event that was generated by PDP. All of the PEP,
   and it has completed any intermediate data path provisioning that negotiation occurs between
   the event may be dependent on, Client and the PDP will generate a PDP
   Provisioning Decision message. The PDP Provisioning Decision and should, except for the EAP message
   only contains code
   field, not be examined by the instances of the classes the PDP wants to
   configure as a result of the event. PEP. In addition order to support multiple EAP
   protocols, this message the
   PDP may also send unsolicited Provisioning responses on other COPS
   handles to add policies that may be shared across events.

   The PEP is the only entity that knows when traffic is no longer
   flowing through a particular session (either because of a timer
   expiring or because of PIB supports a physical link termination). Therefore
   lifetime of generic EAP request class and EAP
   response class. Each class has a COPS Request handle is always controlled by the PEP.
   The PDP may advise the PEP that single string attribute
   (authEapReqExtSpecific and authEapRespExtSpecific, respectively)
   within which the Handle entire EAP message is no longer valid via a
   provisioning update. However, passed.

   Although figure 4.1 shows two EAP messages going from the ultimate dispensation of PDP to the
   Request Handle
   Client and two EAP messages being returned from the associated tables are always determined by client to the PEP.
   PDP, the actual number of messages exchanged can be any amount. The
   PDP can also indicate that a traffic flow may no longer
   have access continue to resources by changing retrieve additional credentials from the data path to drop packets
   arriving client
   for that traffic flow. Since as long as it wishes. As soon as the PDP can modify the data
   path such that has all packets for the flow will be dropped, both
   alternatives achieve the same semantics. The PEP can delete necessary
   credentials from the COPS
   Request Handle simply by notifying client, the PDP via a Delete Request
   Message that may continue to provision the provisioned policies for that Handle are no longer
   valid. Since a COPS-PR Provisioning Decision
   PEP with policies. This is used, action is not shown in figure 4.1.

   The PDP should end the EAP negotiation with an EAP Success or an EAP
   Failure message. If the PDP sends a EAP Success, the PEP must
   send a report back to from
   then on use the PDP matchNext Prid to confirm that there are no problems
   with determine the next processing
   filter for data path change requested defined by the PDP.

   When values described using the
   eventhdlrEventScope.

4.1.3. PAP Authentication

   PAP (Password Authentication Protocol), as described in section 2 of
   [AUTH] is a COPS Request Handle very simple authentication mechanism used over PPP. It
   is removed all contained class instances
   must not considered to be removed as well. Typically these will include header a secure mechanism, since it sends passwords
   over the wire in clear text format. However, where one-time
   passwords are used, this security concern is mitigated. It is
   described here nonetheless for illustration purposes and
   authentication table instances.

5.5. PDP fetching Event-specific ContextData

   The ContextData class can because it
   may still be specified either during used among ISPs, or in situations where another layer
   already performs encryption for security.

   The terminology used in [AUTH] differs from the
   configuration of terminology used in
   this document. In particular, the EventHandler peer as defined in section 1.2 of
   [AUTH] is referred to indicate what context data
   should be sent with each as 'Client' in this document. Similar, the
   'authenticator' is called PEP Event Message or it can in this document.

4.1.3.1. PAP Connection sequence

   Figure 4.2 shows how PAP may be used to retrieve credentials from
   the client workstation by the
   PDP to get additional context data for an event after it receives a
   Event Message. In the latter case, PDP.

   time
    |   +---+                     +---+                          +---+
    |   |   |                     |   |-- COPS-PRC exchange ---->|   |
    |   |   |                     |   |<- COPS-Dec eventHandler -|   |
    |   |   |-- PPP traffic ----->|   |                          |   |
    |   |   |<- PPP LCP Req-PAP --|   |                          |   |
    |   | U |-- PPP LCP ACK-PAP ->| P |                          | P |
    |   | s |-- PPP PAP Id, Pwd ->| E |                          | D |
    |   | e |                     | P |-- COPS-Req event,     -->| P |
    |   | r |                     |   |--          userPapExt -->|   |
    |   |   |                     |   |                          |   |
    |   |   |                     |   |<- COPS-Dec eventElement -|   |
    |   |   |                     |   |<- COPS-Dec authResult ---|   |
    |   |   |<- PPP PAP ack ------|   |                          |   |
    V   +---+                     +---+                          +---+

   Figure 4.2: Embedding of PAP messages between the PDP may send a solicited
   response that specifies ContextData for Client workstation
   and the last Event Message
   received on PEP, and between the same Request Handle. The ContextData message
   contains PRC names to retrieve PEP and PDP.

   When the specific information needed dpEventHandler has been configured to
   either authorize require
   authentication, a pending event, monitor PEP Event message will not be generated until
   after a minimal set of policies bound to
   the handle or get more context information regarding credentials have been negotiated with the event.
   Since each ContextData class only retrieves
   client. For PAP, this means that a specific subset of the
   information regarding PEP Event Message will not be
   generated until after the event within authRealm and authUsername have been
   determined. This means that that the context of a Request
   Handle, PEP must receive a single request PAP Identity
   message before it can contain multiple instances of
   the ContextData class, thereby supporting send the retrieval of as much
   event-specific information as needed in a single message. PEP Event Message.

   The COPS-PR message type used Client will send the Identity and Password to fetch Event-specific ContextData is
   a Provisioning Decision message. the PEP. The ContextData class instances are
   sent in an updated Event-specific ContextData Request on PEP
   will embed the same
   COPS Request Handle. password into the userPapExt datastructure and send
   this to the PDP. Since this datastructure inherits the TagId in fields of the ContextData class is
   only used when
   userAuthExt data structure and the ContextData class is configured with an
   EventHandler, extAuth data structure, it will
   also contain the TagId PAP identity attribute should not be set when inserted into the class
   is used in an Event-specific ContextData Fetch. When
   authUsername attribute of this Instance.

   The first connection from the PEP
   receives a message from to the PDP asking for Event-specific
   ContextData, it will send is an Event-specific ContextData message in a alert that an
   event was triggered. The PEP sends an Event Message over COPS Request message back to the PDP.

   The updated Event-specific ContextData Request from the PEP will
   contain
   PDP containing a set new instance of Header and Interface context data class instances.
   Since the updated request uses Event table. The eventEventHdlr
   attribute in the same Request Handle Event table entry is a ReferenceId that points to a
   dpeventHandler entry indicating (by means of the PDP knows
   which event
   dpEventHdlrAuthProtocol) that PAP is being updated by more context data. Using PDP Fetched
   ContextData messages precludes a valid protocol to use for
   this Event. Also, the PDP from provisioning eventCause attribute in the PEP Event table entry
   is a ReferenceId that points to
   allow multiple simultaneous an eventhdlrElement indication which
   Filter (by means of the eventhdlrEventScope) did trigger the event.
   Along with this new instance of the Event Messages outstanding on table, the same
   Handle.

5.6. Event-specific ContextData Response

   The Event-specific ContextData Response message is used PEP must also
   send an instance of the AuthPapExt table.

   Besides these required instances, the PEP might have been configured
   by the PDP to report
   specific interface and/or packet header sent additional information back to about the PDP.
   This message is implemented as a COPS-PR Report message. A Report
   message may include any number of Interface or Header table
   instances. However, because Reference Identifiers client to the Event table
   are not specified
   PDP. For example in the header or interface data tables, case of a Report
   message may contain header and interface data for one dialup connection between the
   Client and only one
   Event or the most recent Event Message received on that specific
   COPS Request Handle.

5.7. Opaque Decision

   An Opaque Decision message is used to send specialized
   authentication messages from PEP, the PDP to might specify using a contextData
   instance that the PEP. Specifically, this
   type PEP should also sent an instance of COPS-PR Decision message is used to pass EAP request
   messages. a
   ctxtDialupInterface.

   The class used in this message PDP performs the PAP authentication. When the authentication is used to send
   authEapReqExt table instances.

5.8. Opaque Report
   An Opaque Report message
   complete and the PDP is used ready to send specialized authentication
   messages from the PEP to the PDP. Specifically, this type of COPS-PR
   Report message is used to pass EAP response messages. The class used
   in this message is used to send authEapRespExt table instances.

6. Combining Data Structures in Messages

   In authorize the most degenerate case, event, the PDP
   optionally provisions the EventHandler to
   only send the Event object when an event occurs. The PDP then
   requests Event-specific Context Data that the PEP will respond to with Report Message. In addition, if EAP authentication is required,
   a policies. This sequence of Opaque Decisions and Opaque Reports are also required.
   Finally, if new data paths need to be provisioned (including
   specialized EventHandlers), normal
   messages should terminate with a PDP Provisioning Decision and Report
   messages (a COPS-
   PR Decision message). The PDP Provisioning Decision contains an
   instance of the AuthExtResult table with the authExtAuthSuccess set
   to either TRUE or FALSE. The PEP must also be exchanged. Note that these provisioning
   decisions may be on separate upon receipt of this COPS Request Handles.

   In some environments, for example authorization, it is essential
   Decision message, send PAP ACK or NACK message to
   complete the transaction as quickly as possible. The way to
   accelerate client. Also,
   if the authExtAuthSuccess attribute was true, then the PEP should
   keep track of this process particular data, defined by the unique values of
   the fields specified using the eventhdlrEventScope.

4.1.4. CHAP Authentication

   CHAP (Challenge Authentication Protocol) [CHAP] is to combine as many messages into a single
   message as possible. This section describes strong
   authentication mechanism, which messages can be
   collapsed, and what eliminates the rules are for collapsing need to send
   passwords in the messages.

6.1. Combining Context Data in Event Messages

   Previous sections have discussed at length how Event Handlers can be
   pre-provisioned to generate specific Event Messages with ContextData
   (Interface and Header data) in the PEP Event Message. When the
   choice of what context data is entirely dependent on information
   found in clear, like PAP does. With CHAP, the PEP when Authenticator
   generates a packet causing challenge key, sends it to the Event Message, pre-
   provisioned Event Handlers is Peer (Client) and the preferred approach.

7. Access Bind Usage Examples

   Following examples on how
   client responds with a cryptographically hashed response that
   depends upon the Access Bind PIB PRCs are used provide
   some additional clarifications on Challenge and a secret key. The PDP checks the PRC definitions.  But they
   secret key by
   no means indicate all performing the PRCs needed for same encryption and comparing the application given by
   results.

   The terminology used in [CHAP] differs from the example.  And providing these examples here does not indicate
   where terminology used in
   this document. In particular, the application specific PRCs should be defined.  These
   examples are provided only to assist better and easier understanding peer as defined in section 1.2 of
   [CHAP] is referred to as 'Client' in this document. Similar, the Access Bind PIB.

7.1 Wireless LAN (802.11 Access Point) Usage Example

   A wireless LAN Access Point (AP)
   'authenticator' is pictured called PEP in this document.

4.1.4.1. CHAP Connection sequence

   Figure 7.1 below.
   This is based roughly on 802.11/802.1x concepts.  The following is
   meant to give an indication of 4.3 shows how the Access Bind PIB could CHAP may be
   included in such an AP.  Note that this is an exercise used to see if retrieve credentials from
   the
   concepts fit together, not a proposal for exactly how they would
   fit.

   The AP shown below includes a æService ManagerÆ (SM), which
   interfaces with the wireless data interface.  For incoming wireless
   data it separates management frames and level 2 frames.  In the
   following we will deal particularly with Associate and ReAssociate
   Management Frames.

   The SM  (as interpreted here) takes Associate and Reassociate
   management frames and creates a temporary Port Access Entity PAE for
   the association.  The PAE must then be authenticated and provisioned
   by an external Authentication Server (AS).  Communication with the
   AS is assumed in this model to be mediated client workstation by a Policy Enforcement
   Point (PEP, which is part of the AP).  The AS acts as a Policy
   Decision Point (PDP).

   oooooooooo  Ethernet Port
            o
   +--------o-------------------------------------+
   |        o        Service Manager              |
   |        o                            +-----+  |    (1)     +------+
   | +------o------+                     | PEP |  |Capabilities|      |
   | |QoS policies |                     |     +--+----------->| Auth |
   | |     for     |                     |     |  |            |Server|
   | | previously  |                     |     |  |    (2)     |(PDP) |
   | |authenticated|                     |     |  |Service Mgr |      |
   | |    PAEs     |                     |     |  |Provisioning|      |
   | |      o      |<-+---------+--------+-----+--+------------+      |
   | +------o------+  |         |        |     |  |            |      | PDP.

   time
    |        o    ^   +---+                     +---+                          +---+
    |         V   |   |                     |   |-- COPS-PRC exchange ---->|   |
    |   |        o   |                     | +-------------+   |<- COPS-Dec eventHandler -|   |
    |   |    (3)   |-- PPP traffic ----->|   |                          |   |        o
    |   | |Authenticator|   |<- PPP LCP Req-CHAP -|   |                          |   | Event Msg
    |   | U |- PPP LCP ACK-CHAP ->| P |        o                          | P |
    |   (Event    +--+-----+--+----------->|   | s |<- PPP CHAP Chal ----| E |        o                          | D |
    |   Handler)   | e |-- PPP CHAP Ident, ->| P |                          | P |
    |   | r |--        Id, Resp ->|   |        o                          |   |
    |   |   |                     |   |-- COPS-Req event-CHAP -->|   |    (4)
    |   |   |        o                     |   |-- COPS-Rep CHAP Resp, -->|   |
    |   |   |                     |  |EAP exchange|   |--                Chal -->|   |
    |        o   |   |                     |             |<-+-----+--+------------+   |                          |        o   |
    |   |             |--+-----+--+----------->|   |                     |        o   |<- COPS-Dec eventElement -|   |
    | +-----o-------+   |   |                     |   |<- COPS-Dec authResult ---|   |
    |   |        o   |<- PPP CHAP ack -----|   |                          |       o   |     |  |    (5)     |      |
   |        o    |    |       o          |     |  | Decision   |      |
   |        o    +-----------------------+-----+--+------------+      |
   |        o    |    |       o          |     |  |            |      |
   |        o    V
    V       o          |     |  |    (6)     |      |
   |    +---o-----------------o---+      |     |  |Success Rpt |      |
   |    |   o   Classifier    o   |      |     +--+----------->|      |
   |    |   o                 o   |      +-----+  |            +------+
   |    |Controlled   Uncontrolled|               |
   |    |   Port           Port   |               |
   |    |   ooooo         ooooo   |               |
   |    |       ooooo ooooo       |               |
   |    +------------o------------+               |
   |                 o                            |
   +-----------------o----------------------------+
                     o
           ooooooooooooooooooooo
           o                   o
   +-------o--------+  +-------o--------+
   |Wireless Station|  |Wireless Station|
   +----------------+  +----------------+   +---+                     +---+                          +---+

   Figure 7.1: Wireless LAN AP Architecture

7.1.1 Wireless LAN Access Event Handler Provisioning

   In an Access Bind PIB implementation, figure 7.1 shows 4.3: Embedding of CHAP messages between the SM
   sending a REQ at boot time to tell Client
   workstation and the AS that it is up PEP, and what
   capabilities between the PEP and PDP.

   As soon as the PEP finished negotiating CHAP as the Authentication
   protocol, it has.  The PDP returns generates a configuration challenge itself, and sends this to support the
   SM.  In particular, this configuration includes provisioning
   information for how
   Client. The client will respond to instantiate this authentication request by
   sending his or her identity, an identifier and the response. The
   response is a PAE cryptographically encrypted hash based on the
   challenge and what trigger
   information should secret key (password).

   The identifier is only used to keep track of CHAP messages, and
   needs to be sent used by the instantiated PAE PEP to recover the PDP. associated challenge.

   The provisioning of first connection from the Event Handler is supported by PEP to the Access
   Bind PIB by using PDP is a notice of a new
   Event. The PEP sends an Event Message to the following PRCs in PDP containing a new
   instance of the decision (DEC) message:
   - eventHandler
   - eventhdlrElement
   - eventhdlrEventScope

   With eventhdlrEventScopeFilter indicating how Event Table. The eventEventHdlr attribute in the signaling protocol
   is recognized.

7.1.2 Wireless LAN Access
   Event Handling

   When an event (here a Associate or ReAssociate) table entry is detected the
   SM/event handler instantiates and initializes a PAE.  The initial
   PAE instance includes an access port which splits internally into a
   controlled and uncontrolled port.

   The controlled port is what is used ReferenceId that points to pass data from a dpeventHandler
   entry indicating (by means of the access
   port dpEventHdlrAuthProtocol) that CHAP
   is a valid protocol to use for this Event. Also, the external Ethernet.  It is controlled eventCause
   attribute in that there the Event table entry is a
   switch that must be turned on by the authenticator before data can
   flow.  It may also have QoS parameters ReferenceId that can be controlled by the
   AS.  In its initial state the controlled port drops all incoming
   frames.

   The uncontrolled port connects to an internal authenticator.  The
   authenticator creates the initial trigger.  In some cases it may
   need points to send
   an EAP frame back to the Station prior to sending eventhdlrElement indication of which Filter (by means of the
   initial trigger, and other times it may have enough information from
   eventhdlrEventScope) did trigger the initial Associate or ReAssociate to create event. Along with this new
   instance of the trigger
   immediately.

   The Event handling is supported by table, the Access Bind PIB.

   The PEP creates must also send an instance of event PRC, with eventEventhdlr
   referencing
   the eventHandler, and eventCause referencing
   eventhdlrElement provisioned in Access Event Handler Provisioning
   above.

   This event PRI will be sent by AuthChapExt table.

   Note that having the PEP to issue the PDP in a REQ using a
   new COPS Request Handle.  This REQ message may contain additional
   PRIs as dictated challenge allows the PEP to
   perpetrate fraud by how issuing a specific signaling protocol should be
   handled.

7.1.3 Wireless LAN Access Event Decision replayed request (assuming that the
   PEP and PDP are in different domains). The AS/PDP decides whether only guard against this
   is for the trigger contains enough information PDP to make an check that multiple authentication decision.  If not, it may initiate an EAP
   dialog through requests for
   the authenticator same client have unique challenges. This may be slow. PDP and
   Authentication server developers who feel this is a security issue
   may want to use EAP-MD5 authentication rather then CHAP
   authentication, since EAP-MD5 addresses this problem by letting the STATION.

   Once it has enough information
   PDP generate the challenge.

   Besides these required instances, the PEP might have been configured
   by the PDP makes a decision and sends a
   Provisioning message to send additional information about the AP that sets QoS parameters and æclosesÆ client to the switch on
   PDP. For example in the controlled port. Since case of a dialup connection between the controlled
   Client and
   uncontrolled port is easily modeled with a DiffServ Classifier, the
   closing of PEP, the switch is simply PDP might specify using a matter contextData
   instance that the PEP should also sent an instance of a installing a Decision
   in
   ctxtDialupInterface.

   The PDP performs the classifier indicating that subsequent traffic matching CHAP authentication. When the
   specific PAEÆs criteria should be bound authentication is
   complete and the PDP is ready to authorize the set of pre-existing
   policies that are appropriate for that authenticated PAE.

   The decision (DEC) message sent by client, the PDP may
   choose to provision the PEP will be using with policies for this client, which was
   probably the same COPS Request Handle created as a result intention of starting this authentication process in
   the first in
   Access Event. place. This sequence of messages should terminate with a
   PDP Provisioning Decision (a COPS-PR Decision message). The content (PRCs) carried by PDP
   Provisioning Decision contains an instance of the DEC message will
   depend on AuthExtResult
   table with the functionality need to be provided.  It may be command authExtAuthSuccess set to æcloseÆ the switch on the controlled port, it may contain QoS
   parameters.

7.2 RSVP Usage Example
   RSVP is a signaling protocol used for a variety of purposes
   including some call setup applications and MPLS label distribution
   for traffic engineering. RSVP uses a number either TRUE or FALSE. The
   PEP must upon receipt of this COPS Decision message, send PAP ACK or
   NACK message types to
   negotiate both the hop-by-hop path and client. Also, if the service requirements
   between a sender and one or more receivers.

   Some RSVP messages contain information that helps determine whether authExtAuthSuccess
   attribute was true, then the reservation PEP should be accepted or not. However, keep track of this
   particular data, defined by the router may
   not equipped with sufficient context to take advantage unique values of the
   information in determining whether to accept or reject an RSVP
   message. COPS was designed to pass specific RSVP messages to a PDP
   (Policy Server). The PDP could then analyze fields
   specified using the RSVP message and
   usually determine whether to accept or reject eventhdlrEventScope.

4.2. Data Description

   This section describes each of the reservation.

   With classes defined in the advent Identity
   Extension PIB module.

4.2.1. IdentityEventHdlr Class
   This PRC is an extension of COPS-PR, it became possible to construct more
   sophisticated policies beyond simple accept or reject messages.
   However, these more sophisticated policies were targeted for
   DiffServ rather than RSVP. With the definition of the AccessBind
   PIB, it becomes possible to provision a router not only to specify
   which RSVP messages should be sent to EventHandler PRC. This extension
   illustrates the PDP, but also to use
   existing PIBs to specify how the QoS requirements in a RSVP
   reservation should be supported in a specific router implementation.

   Two types RSVP specific structures are added to AccessBind to
   support RSVP. In order to provision of the EventHandler class to detect
   RSVP messages, a number PRC concept for
   authentication usage. Instances of filter classes must be defined. These
   filter classes this PRC are general purpose and could be used both by
   EventHandlers and provisioned by Classifiers although the semantics of
   PDP on the
   filter class are somewhat different for each. The other PEP to catch specific events that require authentication
   processing. This PRC references a group of
   classes eventHdlrAuthProtocol
   instances that define a set of Authentication mechanisms to use if
   an access event is the Context Data classes caught by this event Handler. From its base class
   (Event Handler) this PRC also references a group of eventHdlrElement
   PRIs that pass some or all parts contain the scope of the RSVP message access event and specify the
   context data to send to the PDP when the EventHandler generates an
   event.

   Because COPS assumes that all RSVP message objects are sent access event is caught.

   The attributes of this class are:
        identityEventHdlrRequestAuth (TruthValue)
           Boolean flag, if set to 'true' requires authentication data
           to be sent in the
   PDP, Event Message sent to the PDP.

        identityEventHdlrAuthProtocol (TagReferenceId)
           References a group of identityHdlrAuthProtocol instances,
           each well known RSVP object will be assigned of which specifies an authentication mechanism.

4.2.2. EventHdlrAuthProtocol class

   This class allows a unique Context
   Data PRC identifier and PDP to configure the rest set of the RSVP objectÆs authentication
   mechanisms that are allowed for users or devices that must
   authenticate in order to have access control policies assigned to
   them.

   The attributes
   will be part of the PIB this class in the same order are:

        eventHdlrAuthProtocolId (InstanceId)
           Identifies this object

        eventHdlrAuthProtocolGroup (TagId)
           Represents a binding between an datapathEventHdlrTable
           instance and format as a list of eventHdlrAuthProtocolTable instances.

        eventHdlrAuthProtocolAuthMechanism (Enum)
           Specifies an authentication mechanism to be used in Event
           Messages triggered by the
   original RSVP EventHandler referencing this
           EventHdlrAuthProtocol object. The actual PRC mappings for these objects can
   be found in the PIB definition. For details on the operation value is from an
           enumerated list initially consisting of
   these objects refer to [RSVP] (PAP, CHAP, EAP-MD5,
           and [INTSERV]. In addition, a PIB EAP-TLS)

4.2.3. AuthExt class

   This is also defined an abstract PRC. This PRC can be extended by authentication
   PRCs that contain attributes specific to support unrecognized RSVP objects.

   A Context Data PIB that authentication
   protocol. An instance of the extended class is also specified created by the PEP
   and sent to describe the relevant
   RSVP common header attributes. PDP. The attributes in PDP may send information back to the common header
   that will be specified are:
      1. The RSVP MsgType attribute, which distinguishes a PATH message
         from a RESV PEP or PATHerr message.
      2. The RSVP Flags attribute is used
   may use the information to indicate whether Refresh
         Reduction is possible or not.
      3. The Send TTL (Time To Live) attribute, provides a easy
         mechanism for determining whether non-RSVP hops have been
         traversed by comparing this field with the IP TTL field.
      4. The In Interface (if known)
      5. The Out Interface (if known)

   A special context data class, called AllRSVPMsgObjects, is defined
   to simplify the process of specifying authenticate the set of RSVP objects to be
   included with a COPS-PR PEP's Event message. Rather than explicitly
   specifying every context data class that Message.
   This PRC itself should not be instantiated.

   Typically this class and it's subclasses are included with as part of an
   event message containing the Event message, class (Section 3.2.6.1).

   The data in this class (when referenced by PRC through is passed between the
   ContextDataIfElement attribute PDP and the client with
   little or no involvement of the ContextData class) indicates
   that all RSVP objects, including PEP except to forward it in the common header
   appropriate AuthExt class described
   above, should instance. The PEP is not meant to store
   AuthExt objects. As such, this class, along with all its extending
   classes, is meant to be encapsulated 'transient'. Its instances are temporary and propagated to
   are deleted by the PDP. All Refresh
   Reduction related RSVP objects (MESSAGE_ID, MESSAGE_ID_ACK, and
   MESSAGE_ID_NACK) PEP after a certain time or event. The PDP, in
   its decisions, must not refer to instances of this class that are explicitly excluded from being
   sent to by the PDP
   when PEP in its requests. Likewise, the AllRSVPMessageObjects attribute is set PEP must not refer to True. These
   objects
   instances sent by the PDP. Also, since instances are specifically deleted, it is
   possible for purpose of synchronizing state between
   RSVP hops and bears no value in the policy decision process.
   However, a context data PIB object InstanceIds to be reused.

   The AuthExt class is defined extended for each of these
   classes in the event that authentication mechanism
   supported. As a PDP determines that base class, it needs these
   objects. is never instantiated.

   The EventScope classes have been specified attributes of this class are:

        AuthExtId (InstanceId)
           identifies this object

4.2.4. UserAuthExt class
   This is a concrete PRC used to roughly follow contain user authentication fields.
   This PRC extends the
   same mappings as base PRC authExtEntry.

   The attributes of this class are:
        userAuthExtRealm (OCTET STRING)
           The user realm octet string.

        userAuthExtUsername (OCTET STRING)
           The Username octet string.

4.2.5. AuthExtResult class

   All authentication message sequences conclude with an authentication
   result message sent from the Context Data PIB classes. However, since PDP to the
   typical criteria for outsourcing a RSVP PEP. This message are is usually rather
   simple, only a subset of
   accompanied by one or more provisioning decisions associated with
   the RSVP objects require mappings to COPS-
   PR filter classes. If some implementations require support for
   filtering additional objects, it is trivial to extend authenticated identity. The AuthExtResult class extends the filters.
   Note that
   AuthExt class. It contains the filters bound to EventHandlers determine whether a
   matching packet should generate an Event or not. Authentication result Boolean flag.

   The RSVP objects attributes that will be mapped to filters in this
   specification will include the RSVP common header, class adds to the RSVP Dclass
   object, base class are:

        AuthExtSuccessful (TruthValue)
           A Boolean flag set to true if the RSVP session object, authentication (via CHAP
           or PAP) was successful.

4.2.6. AuthEapReqExt and the RSVP style object. AuthEapRespExt classes

   The last
   three EAP messages are used to describe various characteristics embedded in COPS by sending an instance of the data
   traffic for
   authEapReqExt or authEapRespExt table, which each have an attribute
   (Specific) to encapsulate the reservation is being performed. Since appropriate EAP messages necessary for
   the
   filters can describe both AND authentication mechanism. The authEapReqExt table is owned and OR semantics,
   managed by the challenge PEP, while the authEapReqExt table is owned and
   managed by the PDP. Put another way, the PDP generates authEapReqExt
   instances that it sends in
   organizing Decision messages and the fields of PEP generates
   authEapRespExt instances that it sends in Report messages. Since
   neither the objects PEP nor the PDP needs to simplify filter expressions
   as much as possible. Since this maintain the messages
   permanently, the same instance of each class is used when more than
   one exchange is required in each direction.

   Since both AuthEapReqExt and AuthEapRespExt are extensions of the primary goal
   AuthExt class, they both inherit the appropriate attributes of each object have been combined into a single PIB
   class. AuthExt.

       AuthEapReXXExt table attributes     Attribute type
       -------------------------------     --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authEapReXXExtSpecific              OCTET STRING

   Figure 4.4: Data elements in AuthEapReqExt and AuthEapRespExt tables

   The RSVP filter PIB AuthEapReXXExt class contains the following three attributes. The fields marked with asterisks will instanceId
   is used to uniquely define the instance in the table. However, since
   EAP messages are meant to be represented as masked
   values (for IP addresses) opaque, they should not be referenced.
   Because the purpose of the classes is to carry EAP messages and ranges (for UDP/TCP ports) each
   message is transient instances of these tables are temporary and
   should not be referred to. The Event attribute points to add
   flexibility.

        RSVP MsgType
        RSVP Flags
        Send TTL
        DCLASS DSCP
        Session Dest IP*
        Session Protocol
        Session Dest Port*
        Filter Src IP*
        Filter Src Port*
        Style value

   This paper does not address reservation specification (TSPEC and
   FLOWSPEC) modifications that depend on the RSVP refresh model. RSVP
   refresh reduction [REFRESH] is assumed as a simplifying assumption Event
   table entry for this application which EAP is being negotiated. The format of EAP
   packages being passed by the Access Bind PIB. However, if support for
   traditional RSVP refresh AuthEapReXXExt classes is desirable, it can be supported described in this
   model
   [EAP].

4.2.7. AuthPapExtEntry class

   The PAP information is embedded in the PEP Event Message by adding explicit filters for sending
   an instance of the RSVP FlowSpec and RSVP
   Tspec objects as specified in [IntServ].

   In order to support RSVP outsourcing with authPapExt table. Since the AccessBind PIB authPapExt table is
   an extension of the
   Event Handler must be provisioned with userAuthExt table, which is an extansion of the appropriate settings to
   recognize specific RSVP messages, create new request handles, and
   generate events (outsourcing requests). After we have described how
   this
   authExt table, the authPapExt inherits the attributes of these
   tables.

   AuthPapExt table attributes         Attribute type
       ---------------------------         --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authRealm                           OCTET STRING
       authUsername                        OCTET STRING
       authPapExtPwd                       OCTET STRING

   Figure 4.5: Atributes of the AuthPapExt table.

   The AuthPapExt contains five attributes. The instanceId is accomplished, we will show used to
   uniquely define the actual message flows involved instance in the RSVP outsourcing process.

   The specific PIB classes that need table. However, since the PAP
   password is sent to be provisioned are the
   EventHandler, EventhdlrElemenet, ContextData, EventhdlrHandleScope, PDP once and EventhdlrEventScope. The EventHandler provides a termination
   point for processing RSVP messages. As RSVP messages arrive, they
   are directed to the EventHandler is needed by a classifier. In this scenario
   the EventHandler as behaving as a termination point for all RSVP
   messages. Hence, neither the EventHandler class is provisioned with no data
   path elements following PDP
   nor the EventHandler. Therefore, PEP after the attribute
   eventhdlrNonMatchNext client is left unassigned.

   Alternatively, authenticated, the EventHandler can also instance should
   not be provisioned such that
   RSVP and non-RSVP packets alike pass through the EventHandler, but
   only RSVP messages invoke events. In this case, referenced after it is used the first time. The Event
   attribute
   eventhdlrNonMatchNext would specify the next data path element that
   should process any packets not matching points to the EventHandlerÆs criteria
   (non RSVP packets). Event table entry for which PAP is being
   negotiated.

   The EventhdlrElement class identifies a specific category result of events.
   Suppose one wanted to generate different Events the authentication for PATH messages
   and RESV messages. This could be done by configuring one
   EventhdlrElement to only match PATH messages and another
   EventhdlrElement to only match RESV messages. Event messages contain
   a reference to PAP is sent in the EventhdlrElement that generated
   AuthExtResult table. Since the event.
   Therefore, it authExtResult table is possible to generate different events from an extension
   of the same
   EventHandler.

   The EventhdlrElement contains two main semantics. First, AuthExt table, it
   specifies inherits the criteria for creating new Request Handles. Each
   Request Handle constitutes a unique dialog between attributes of AuthExt.

       AuthExtResult table attributes      Attribute type
       ------------------------------      --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authExtAuthSuccess                  Truth Value

   Figure 4.6: Atributes of the PEP and PDP. AuthExtResult table.

   The second semantic AuthExtResult is sent by the criteria for generating events. In some
   situations, it is desirable to generate a one-time event and not
   generate events when similar messages are seen later. A good example
   of this is RSVP Refresh messages. When RSVP Refresh messages are
   used to indicate that the reservation is still active, generating
   events for each message is inappropriate. In contrast, when Refresh
   Reduction [Refresh] is active, only reservation changes are
   propagated as full RSVP messages. In this situation, every message
   may constitute an Event.

   With RSVP it is usually appropriate to assign a unique COPS-PR
   Request Handle for every new RSVP session. Since EventHandlers are
   typically bound PDP to an interface data path, the RSVP Path message and PEP. If the Resv message will be processed on different data paths.
   Therefore, unique events
   authentication was successful and unique COPS-PR Request Handles will
   typically be assigned for each message type. However, this is not
   significant since the provisioning objectives for Path messages are
   different PEP should from the provisioning objectives for Resv messages. For
   RSVP, the EventhdlrElement will now on use the Tag Reference
   EventhdlrElementHandleScope to describe the criteria for creating a
   unique handle. Each EventhdlrHandleScope object will contain
   pointers
   matchNext Prid to determine the RSVP next processing filter objects mentioned earlier to describe (the next
   component down the internal datapath in the PEP) for all traffic
   defined by the various fields whose combination of values constitute a unique
   handle.

   Typically, of the Filter parameters as set in the
   eventhdlrHandlerScope.

4.2.8. AuthChapExtEntry class used

   The CHAP information is embedded in the RSVP filter class. For this
   class, Event Message by sending an
   instance of the session attributes (SessionDestIP, SessionDestPort, and
   SessionProtocol) will be assigned wildcard values and all other
   attributes assigned to NULL to indicate that any combination of
   these attributes constitutes a unique handle. When various messages
   arrive that require authChapExt table. Since the generation of authChapExt table is an event and that have a newly
   unique combination
   extension of the filter attribute values, a new request
   handle will be assigned. When a message arrives for userAuthExt table, which a previous
   message has already generated a handle, that handle is used to pass an extansion of the appropriate event to
   authExt table, the PDP. authChapExt table inherits the attributes of
   these tables.

       AuthChapExt table attributes        Attribute type
       ----------------------------        --------------
       authExtId                           InstanceId
       authExtEvent                        ReferenceId
       authRealm                           OCTET STRING
       authUsername                        OCTET STRING
       authChapExtId                       Unsigned32
       authChapExtChal                     OCTET STRING
       authChapExtResp                     OCTET STRING

   Figure 4.7: Data elements of the AuthChapExtEntry datastructure.

   The other class pointed to AuthChapExtId is generated by the EventhdlrElement PEP. The ID value is the
   EventhdlrEventScope. This class describes the criteria for
   generating an event. Typically, the MsgType attribute in conjunction
   with the session attributes will be wildcarded and the other fields
   assigned to NULL to indicate that all RSVP messages should be sent to
   the PDP. This describes client. When the criteria for an event: Every time a
   unique combination of all these attributes occurs, generate client endpoint (Peer) generates a new
   event.

   In many cases CHAP
   response it may make sense to assign includes the filter attributes
   (SessionDestIP same ID, and SessionDestPort) to the EventhdlrEventScope
   and/or EventhdlrHandleScope class. This would be done ID is then included in
   this attribute when it is
   desirable sent to notify of the PDP of the need to allocate additional
   resources to a set of reserved flows going PDP.

   The AuthChapExtEntry contains seven attributes. The instanceId is
   used to uniquely define the same destination
   but originating from different sources.

   A new COPS-PR Request Handle MUST only be created when a valid event
   occurs. If a packet matches instance in the criteria described table. However, since
   the CHAP information is sent to the PDP once and is needed by
   EventhdlrHandleScope but does not match any EventhdlrEventScope
   criteria, a COPS-PR Request Handle must
   neither the PDP nor the PEP after the client is authenticated, the
   instance should not be generated.

   This version of referenced after it is used the paper only describes how RSVP can be supported
   when Refresh Reduction [REFRESH] first time.
   The Event attribute points to the Event table entry for which PAP is
   being used. negotiated.

   The complexity of
   addressing the distinction between RSVP refresh messages and
   reservation update messages authChapExtChal attribute is too great to be addressed in this
   version. Any RSVP message containing bundle messages (MsgType 12)
   MUST be decomposed and each message in the bundle must be
   iteratively processed through challenge generated by the EventHandler as PEP.
   The PDP may check the challenge to see if individual RSVP
   messages were generated it is different from the RSVP neighbor. Whether
   EventhdlrMatchNext applies
   challenges used earlier. This to provides an increased level of
   security. The Response and the individual sub-messages or Id is taken from the
   bundled CHAP message is beyond
   sent by the scope of this paper.

   Irrespective of whether Refresh Reduction is in use or not, client and put into the RSVP
   daemon AuthChapExtEntry by the PEP.

   The authChapExtResp is responsible for aging out reservations that are no longer
   valid. As with traditional COPS, when a reservation is aged out, calculated by the
   RSVP daemon or other entity responsible for aging out reservations
   MUST take responsibility for deleting COPS Request Handles. This
   allows client and forwarded by the PDP
   PEP to clean up state associated with the reservation PDP.

5. Signal Handling

5.1 Functional Description

5.2 Data Description

6. Programmatic Interface Between Signal and
   ensures Event Handling

   The programmatic interface between signal and event handling (Access
   Bind API) allows flexible implementation of signal handling
   mechanisms loosely coupled to the proper removal event handling capability provided
   by the Access Bind.  This flexibility allows multiple different
   types of any policies signaling technology be used and integrated using Access
   Bind.

6.1. Functional Description

   The Access Bind API consist of multiple phases of operation:
   The notification and specification of Event Handling needs by the
   signal handling mechanism.  We call this signal handling
   Registration with event handling.
   The result of the Registration indicated by event handling of Access
   Bind.
   The indication by signal handling for event generation.
   The indication of event result by event handling.
   Signal handling state information notification.
   Registration session termination.

   Each of the above phases uses PRCs defined in the PEP specifically
   assigned through Access Bind
   Framework PIB and COPS-PR functionality.

   When the COPS Request Handle.

   Figure 7.2 shows how signaling mechanism initializes or realize it requires
   event handling assistance, it shall register with event handling
   using the various EventHdlrReg() method.  This acts as an indication to
   event handling what services signal handling need and can also
   indicate the capability of signal handling if necessary.  These
   service requirement and capability are indicated using PRC
   definitions.  Event Handler objects would be
   provisioned in a router handling uses these requirement and signal
   handling capability, together with event handling capability to ensure
   generate the initial COPS REQ message that an event is generated for
   every RSVP message.

   +-------------------+
   |EventHandler       |
   | Id=EH1            |
   | NonMatchNext=<NUL>|
   | ElementRef=(Elem1)|
   +-------------+-----+
                 |
                 V
   +------------------+    +-----------------+
   |EH_Element        |    |ContextData      |
   | Id=Elem1         |    | Id=CD1          |
   | MatchNext=<NUL>  |    | DataGroup=RSVP  |
   | Criteria=AllMatch|    | IfElement=(PRC)-+--AllRSVPMsgObjects
   | Context=(RSVP)---+--->| DataEncap=0     |
   | EventScope=(MSG)-+--+ +-----------------+
   | HandleScope=(HD) |  |
   +-------------+----+  +-------------------+
                 |       |                   |
                 |       |  +-------------+  |   +-------------+
                 |       +->|EventScope   |  +-->|EventScope   |
                 |          | Id=Ev1      |      | Id=Ev2      |
                 |          | Group=MSG   |      | Group=MSG   |
                 |          | Filter=(F1)-+--+   | Filter=(R1)-+--+
                 |          | Precedence=1|  |   | Precedence=1|  |
                 |          | ChangeFlag=?|  |   | ChangeFlag=?|  |
                 |          +-------------+  |   +-------------+  |
                 |                           |                    |
                 |  +-------------+          V                    V
                 |  |HandleScope  |     +-------------+  +------------+
                 +->| Id=Hd1      |  +->|IpFilter     |  |RsvpFilter  |
                 |  | Group=HD    |  |  | Id=F1       |  | Id=R1      |
                 |  | Filter=(F1)-+--+  | Protocol=46 |  | DestIP=*   |
                 |  | Precedence=1|     +-------------+  | Protocol=* |
                 |  +-------------+                      | DestPort=* |
                 |                      +------------+   | SrcIP=*    |
                 |  +-------------+  +->|RsvpFilter  |   | SrcPort=*
                 |  |HandleScope  |  |  | Id=R2 carry instances of the
   capability and limitation PRC as they are defined in [FRWKPIB].

   The Registration result is generated based on the COPS DEC message
   received by event handling.  This sets up and creates corresponding
   entries in eventHandlerTable, eventHdlrElementTable,
   eventHdlrEventScopeTable, eventHdlrHandleScopeTable, and
   contextDataTable.  Some of the content of these entries may be from
   information provided by signal handling during registration.  Event
   handling shall use EventHdlrRegRsp() to provide the registration
   result to signal handling.  The amount of information included in
   with the registration result is based on the functionality of the
   signal handling mechanism and may include provisioning information
   for the signal handling mechanism.

   After the registration is completed, the event handling is ready for
   event requests from signal handling.  This is provided by the
   EventGenReq() method.  The signal handling mechanism must provide
   the corresponding information necessary for the event generation.
   This includes, in the form of PRIs, information necessary for event
   handling and PDP to determine the event result.  This may include
   information on what the event result signal handling is expecting
   for the specific event.  The EventGenReq() shall cause event
   handling to create an entry in eventTable and send a COPS REQ
   message.  Signal handling also have the responsibility for
   indicating how the COPS Request Handles are used and re-used for
   specific EventGenReq() invocation.

   Upon receive of COPS DEC message from PDP, event handling uses
   EventRslt() to communicate to signal handling the event result.  The
   result can be as simple as a yes/no response or as complex as
   indicating in detail everything signal handling need to do to
   process the event result.  The degree of complexity is determined by
   the signal handling mechanism.  Event handling and this API in
   Access Bind are flexible to handle this spectrum of complexity.  The
   event result can also affect event handling for integration of the
   dynamic nature of event and the possibly more static setup of data
   path usage.

   Signal handling is required to indicate to event handling its
   response for accepting/implementing the event result by using the
   EventStateUpd() method.  This information provided by signal
   handling is again dependent on the signal handling mechanism and can
   be simple or complex.  The EventStateUpd() method is also used by
   signal handling to indicate any asynchronous state changes or usage
   indications.

   When either signal handling or event handling wants to end the event
   handler session registration, the EventHdlrRegTerm() method is used.

6.2. Method Description

   EventHdlrReg(), called by signal handling
        Indicates to event handling the services needed by signal
        handling.

        Parameters may include:
             Signal Handling Type (COPS Client-Type).
             Signal Handling Capability/Limitation (as PIB PRCs).

   EventHdlrRegRsp(), called by event handling
        Indicates the success/failure of the registration.  For
        successful registration, may provision the signal handler for
        event generation and other signal handling tasks.

        Parameters may include:
             Registration Success/Failure
             Signal handler provisioning PRCs

   EventGenReq(), called by signal handling.

        Event generation request.  Used to request for service from
        event handling.  Triggers the sending of COPS REQ message to
        PDP.

        Parameters may include:
             EventState, indicate create new or reuse existing event
             state (COPS Handle).  When reuse, ID for existing event
             state.

             AssociationInfo, the association for this event state.
             This can be interface or service identification.

             SignalInfo, the signal handling specific information.  The
             signaling information needed for correct event handling.

   EventRslt(), called by event handling Event result.
        Containing the information in a COPS DEC message for handling
        the event.

        Parameters may include:
             EventState, indicate for which event state (COPS Handle)
             this result is for.
             ResultInfo, contains signal handling specific information.

   EventStateUpd(), called by signal handling
        For Event State update due to signal handling info changes,
        including to indicate the Event Result have been implemented.
        This may also be used for usage feedback purposes.  This
        triggers the generation of COPS Report message.

        Parameters may include:
             EventState, indicate for which event state (COPS Handle)
             this update is for.
             UpdateInfo, the state information being updated.

   EventStateTerm(), called by either signal or event handling
   Event state termination.
        Removes the event state.

        Parameters may include:
             EventState, indicate which event state to terminate.
             TermInfo, the termination information, e.g. reason code.

   EventHdlrRegTerm(), called by either signal or event handling
   Registration termination.
        Ends the current registration.

6.3. Access Bind API Example

   As an example, using RSVP as the signaling protocol for an unicast
   flow between sender S1 and receiver R1 through a RSVP and Policy
   aware router as in Figure 6.1.

                         +-----------------+
                         |   +------------+
                 +->| Id=Hd2                 |
                         |       PDP       | DestIP=*
                         |                 | Group=HD
                         +--------+--------+
                                  |
                                  |
                         +--------+--------+
                         | Protocol=*       PEP       |
                         +-----------------+
                         | Filter=(R2)-+--+                 | DestPort=*
          R1 ------------+if1    RSVP   if2+------------ S1
                         |                 | Precedence=1|     +------------+
                    +-------------+
   Fig 7.2: Representation
                         +-----------------+

   Figure 6.1: Signal/Event Handling API _ RSVP Example

   When the signaling protocol is RSVP, the API is used as follows:
   1. EventHdlrReg() called by Signal Handling
        RSVP Signal Handling indicates to the generic Event Handling
        its need to communicate to the PDP via COPS-PR.

        This will have Event Handling generate:
        COPS REQ msg containing PRCs:
           Framework PIB Capability/Limitation PRC for
           - Event Handler (eventHandler/HdlrElement/etc)
           - Signal Handler specific trigger filters
           - Signal Handler provisioning PRCs
           That indicate what signal handling needs from PDP

   2. EventHdlrRegRsp() called by Event Handling
        Indication of success/failure of Event Handler initialization.

        This is caused by the event handler receiving:
        A COPS DEC msg, and may include instances of PRCs that:
             - Provisions the Signal Handler for event generation.
               (i.e. eventHandler/HdlrElement/HdlrEventScope and RSVP
               Filter PRC instances)
             - Provisions the Signal Handler if supported.
               (i.e. enable RSVP multicast, refresh timers)

   3. EventGenReq() called by Signal Handling
        Event Generation Request.

        For RSVP, this is used as indication of PSB or RSB state
        changes, when receiving or about to send RSVP messages,
        requiring Policy Decisions.

        Parameters:

           EventState, indicate create new or reuse existing event
             state (COPS Handle).  When reuse, ID for existing event
             state.
           AssociationInfo, the association for this event state.  For
             RSVP this is the In/Out Interface identification.
           SignalInfo, the signal handling specific information.  For
             RSVP, this contains PRCs for In/Out/Allocate Context,
             Path/ResV/PathErr/ResVErr signal message type, and the
             RSVP objects themselves (as carried by the COPS-RSVP
             ClientSI).

        This causes the sending of a COPS REQ message.

   4. EventRslt() called by Event Handling
        Event Result.
        For RSVP, this is the decision from the PDP for a previously
        generated event.

        Parameters:
           EventState, indicate for which event state (COPS Handle)
             this result is for.
           ResultInfo, contains the signal handling specific
             information.  For RSVP, this contains PRCs for
             In/Out/Allocate Context, Path/ResV/PathErr/ResVErr signal
             message type, and the RSVP objects themselves (as carried
             by the COPS-RSVP ClientSI).

   5. EventStateUpd() called by Signal Handling
        For Event State update due to signal handling info changes.  To
        indicate the Event Result have been implemented.
        For RSVP, this is used for generating the COPS Report message.

        Parameters:
           EventState, indicate for which event state (COPS Handle)
             this update is for.
           UpdateInfo, the state information being updated.  For RSVP,
             used to indicate report type.

   6. EventTerm() called by either Signal or Event Handling
      Event Terminiation.
        Removes the Event State.

        Parameters:
           EventState, indicate which event state is to be terminated.
           TermInfo, termination information.  For RSVP, reason code.

7. Message Types

   All PIB messages have some form of transactional semantics. Most all
   transactions consist of requests and responses. Typical provisioning
   PIBs have the PDP sending a provisioning decision to the PEP and the
   PEP responding with a success or fail. This PIB uses this paradigm
   in some cases, but it also uses a paradigm where the PEP initiates
   an event and the PDP responds with a success or fail. The specific
   use of this paradigm is with the PEP Access Event Message, which is
   triggered by a PEP event and requires authentication success or
   failure semantics as part of the Provisioning Decision. This section
   discusses both paradigms and how the various classes defined in
   sections 3 and 4 are combined to form the various message
   interactions described in sections 2, 3 and 4.

   Each message description in this section will include the purpose of
   the message, the COPS-PR message type, the direction of the message,
   and the class instances typically found in the message.

7.1. Event Handler Provisioning Decisions

   The Event Handler Provisioning Decision message is a COPS-PR
   Decision message used by the PDP to provision each Event Handler in
   the PEP. It is likely to be a piece of a larger Decision message
   that provisions other data path components that occur either before
   or after the Event Handler in the data path. However, it could also
   be sent as a part of unrelated data path or other provisioning
   components. Event Handler provisioning typically includes the
   EventHandler class, the EventHdlrElement class, the
   EventHdlrEventScope class, often the EventHdlrHandleScope class and
   the ContextData class. An optional set of EventHdlrAuthProtocol
   class instances may be sent if an IdentityEventHdlr object is set up
   for Access Event Messages.

   Because the EventHdlrElement, ContextData, EventHdlrEventScope, and
   the EventHdlrHandleScope classes all describe configuration details
   of the EventHandler, any of these class instances may be shared by
   multiple EventHandler instances. Therefore, in many cases, an
   EventHandler Provisioning Decision will contain only an EventHandler
   that references instances of the other classes defined in previous
   Provisioning Decisions. In addition, these classes can also be
   provisioned individually in anticipation of being applied to an
   EventHandler. However, because there is a relationship between the
   EventHandler and EventHdlrElement classes, there is an order
   dependency between the classes. For instance, an EventHdlrEventScope
   must be provisioned at the same time or before an EventHdlrElement
   making use of the EventHdlrEventScope. EventHdlrElement, ContextData
   and data path class instances referenced by an EventHandler must be
   provisioned at the same time or before the EventHandler is
   provisioned.

   When the PEP receives an EventHandler Provisioning Decision, it MUST
   always respond with a Provisioning Report indicating success or
   failure.

   Note that additional EventHdlrElements can simply be added to an
   existing EventHandler by using the TagId (group identifier) for the
   EventHandler to which the element is to be added. Additional
   EventHdlrEventScope or EventHdlrHandleScope instances can be added
   similarly by adding PRIs with the TagId value of the group these
   instances are to be added to. This allows incremental updates to be
   made to the Event Handlers.

7.2. Provisioning Report

   A report MUST follow all provisioning decisions described in section
   7.1. This report may not have any class instances in it. However, it
   explicitly notifies the PDP that the provisioning was successful or
   whether it failed. If many structures were simultaneously
   provisioned in the Provisioning Decision and a failure occurred,
   none of the class instances will be accepted by the PEP. Hence it is
   possible that subsequent Provisioning Decisions occur with a smaller
   subset of the class instances or an alternative set of class
   instances that can satisfy the service policies defined in the PDP.

   7.3. PEP Event Message
   A PEP Event Message is generated by the PEP to indicate that a new
   class of traffic has been identified by the Event Handler. This
   Event Message possibly uses a new COPS Request Handle. The decision
   to use a new COPS Request Handle or reuse an existing Handle is
   based on the EventHdlrHandleScope information configured in the
   Event Handler. The Handle Scope information is a set of criteria
   that is protocol specific, and specifies the set of fields in the
   protocol that the Event Handler is sensitive towards. The PEP Event
   Message is essentially a COPS-PR Request message. The PEP Event
   Message MUST always include an instance of the Event class. This
   Event instance references the EventHandlerElement instance and
   EventHandler instance that caught the event. This allows the PDP to
   identify events belonging to each Event Handler. Other Classes that
   may be a part of a PEP Event Message include one or more instances
   of protocol specific Context Data and Interface data classes and
   optionally an instance of one of the Authentication Extension
   classes (for example, if the Event is an access event).

   When authentication protocols such as PAP or CHAP are in use, the
   PIB assumes that the UserId, Challenge, and Password will all be
   determined by the PEP prior to generating the PEP Access Event
   Message. EAP is an exception to this rule because EAP assumes a
   direct negotiation between the Endpoint and the Authentication
   server. For EAP, it is assumed that the Endpoint generates a
   response to the EAP Identity Request message before the PEP sends
   the Access Event Message. This allows the PEP to fill in the
   Username and Realm in the UserAuthExt table. However, for this
   scenario, it is also assumed that the PEP Access Event Message will
   include the EAP Identity Response in the authEapRespExtSpecific
   attribute of the AuthEapRespExtEntry class. Subsequent EAP
   negotiation will be performed with the Opaque Decision and Opaque
   Report message types. When the negotiation is complete the PDP sends
   a Provisioning Decision message (that includes an instance of the
   AuthExtResult class specifying success or failure). Note that all
   interactions resulting from a given Event Message (including
   authentication negotiation) are performed within the context of a
   single COPS Request Handle. The COPS Request Handle provides an
   independent dialog between the PDP and the PEP to fully process an
   Access Event Message in a synchronous way.

7.3. PDP Provisioning Decision

   When the PDP has all the necessary information to determine what
   policies to provision for the event that was generated by the PEP,
   and it has completed any intermediate data path provisioning that
   the event may be dependent on, the PDP SHOULD generate a PDP
   Provisioning Decision message. The PDP Provisioning Decision message
   only contains the instances of the classes the PDP wants to
   configure as a result of the event. In addition to this message the
   PDP MAY also send unsolicited Provisioning responses on other COPS
   handles to add policies that may be shared across events.

   The PEP is the only entity that knows when traffic is no longer
   flowing through a particular session (either because of a timer
   expiring or because of a physical link termination). Therefore the
   lifetime of a COPS Request handle is always controlled by the PEP.
   The PDP MAY advise the PEP that the Handle is no longer valid via a
   provisioning update. However, the ultimate dispensation of the
   Request Handle and the associated tables are always determined by
   the PEP. The PDP MAY also indicate that a traffic flow may no longer
   have access to resources by changing the data path to drop packets
   arriving for that traffic flow. Since the PDP can modify the data
   path such that all packets for the flow will be dropped, both
   alternatives achieve the same semantics. Since a COPS-PR
   Provisioning Decision is used, the PEP MUST send a report back to
   the PDP to confirm that there are no problems with the data path
   change requested by the PDP.

   The PEP MAY delete the COPS Request Handle simply by notifying the
   PDP via a Delete Request Message that the provisioned policies for
   that Handle are no longer valid.

   When a COPS Request Handle is removed, all contained class instances
   MUST be removed as well. Typically these will include header and
   authentication table instances.

7.4. PDP fetching Event-specific ContextData

   The ContextData class MAY be specified either during the
   configuration of the EventHandler to indicate what context data
   should be sent with each PEP Event Message or it MAY be used by the
   PDP to get additional context data for an event after it receives an
   Event Message. In the latter case, the PDP MAY send a solicited
   decision that specifies ContextData for the last Event Message
   received on the same Request Handle. The ContextData message
   contains PRC names to retrieve the specific information. This
   information may be needed to either authorize a pending event,
   monitor a set of policies bound to the handle or get more context
   information regarding the event. Since each ContextData class only
   retrieves a specific subset of the information regarding the event
   within the context of a Request Handle, a single request message MAY
   contain multiple instances of the ContextData class, thereby
   supporting the retrieval of as much event-specific information as
   needed in a single message.

   The COPS-PR message type used by the PDP to fetch Event-specific
   ContextData is a Provisioning Decision message. When the PEP
   receives a message from the PDP asking for Event-specific
   ContextData, it MUST send an Event-specific ContextData message in a
   COPS Request message back to the PDP. This request message MUST use
   the same COPS Request Handle. Since the TagId in the ContextData
   class is only used when the ContextData class is configured with an
   EventHandler, the TagId attribute should not be set when the class
   is used in an Event-specific ContextData Fetch.

   The updated Event-specific ContextData Request from the PEP SHOULD
   contain a set of Header and Interface context data class instances.
   Since the updated request uses the same Request Handle, the PDP
   knows which event is being updated by more context data. Using PDP
   Fetched ContextData messages precludes the PDP from provisioning the
   PEP to allow multiple simultaneous Event Messages outstanding on the
   same Handle.

7.5. Event-specific ContextData Response

   The Event-specific ContextData Response message is used to report
   specific interface and/or packet header information back to the PDP.
   This message is implemented as a COPS-PR Report message. A Report
   message MAY include any number of Interface or Header table
   instances. However, because Reference Identifiers to the Event table
   are not specified in the header or interface data tables, a Report
   message may contain header and interface data for one and only one
   Event or the most recent Event Message received on that specific
   COPS Request Handle.

7.6. Opaque Decision

   An Opaque Decision message is used to send specialized
   authentication messages from the PDP to the PEP. Specifically, this
   type of COPS-PR Decision message is used to pass EAP request
   messages via authEapReqExt table instances.

7.7. Opaque Report
   An Opaque Report message is used to send specialized authentication
   messages from the PEP to the PDP. Specifically, this type of COPS-PR
   Report message is used to pass EAP response messages via
   authEapRespExt table instances.

7.8. Combining Data Structures in Messages

   In the most degenerate case, the PDP provisions the EventHandler to
   only send the Event object when an event occurs. The PDP then
   requests Event-specific Context Data that the PEP will respond to
   with a Report Message. In addition, if EAP authentication is
   required, a sequence of Opaque Decisions and Opaque Reports are also
   required. Finally, if new data paths need to be provisioned
   (including specialized EventHandlers), normal Provisioning Decision
   and Report messages must also be exchanged. Note that these
   provisioning decisions may be on separate COPS Request Handles.

   In some environments, for example authorization, it is essential to
   complete the transaction as quickly as possible. The way to
   accelerate this process is to combine as many messages into a single
   message as possible.

8. Access Bind Usage Examples

   Following examples on how the Access Bind PIB PRCs are used provide
   some additional clarifications on the PRC definitions.  But they by
   no means indicate all the PRCs needed for the application given by
   the example.  And providing these examples here does not indicate
   where the application specific PRCs should be defined.  These
   examples are provided only to assist better and easier understanding
   of the Access Bind PIB.

8.1 Wireless LAN (802.11 Access Point) Usage Example

   A wireless LAN Access Point (AP) is pictured in Figure 7.1.1 below.
   This is based roughly on 802.11/802.1x concepts.  The following is
   meant to give an indication of how the Access Bind PIB could be
   included in such an AP.  Note that this is an exercise to see if the
   concepts fit together, not a proposal for exactly how they would
   fit.

   The AP shown below includes a _Service Manager_ (SM), which
   interfaces with the wireless data interface.  For incoming wireless
   data it separates management frames and level 2 frames.  In the
   following we will deal particularly with Associate and ReAssociate
   Management Frames.

   The SM  (as interpreted here) takes Associate and Reassociate
   management frames and creates a temporary Port Access Entity PAE for
   the association.  The PAE must then be authenticated and provisioned
   by an external Authentication Server (AS).  Communication with the
   AS is assumed in this model to be mediated by a Policy Enforcement
   Point (PEP, which is part of the AP.  The AS acts as a Policy
   Decision Point (PDP).

8.1.1 Wireless LAN Access Event Handler Provisioning

   In a Access PIB implementation the figure shows the SM sending a REQ
   at boot time to tell the AS that it is up and what capabilities it
   has.  The PDP returns a configuration to support the SM.  In
   particular, this configuration includes provisioning information for
   how to instantiate a PAE and what trigger information should be sent
   by the instantiated PAE to the PDP.
   The Event Handler Provisioning is supported by the Access Bind PIB
   by using the following PRCs in the decision (DEC) message:
   - eventHandler
   - eventhdlrElement
   - eventhdlrEventScope

   With eventhdlrEventScopeFilter indicating how the signaling protocol
   is recognized.

8.1.2 Wireless LAN Access Event Handling
   When an event (here a Associate or ReAssociate) is detected the
   SM/event handler instantiates and initializes a PAE.  The initial
   PAE instance includes an access port which splits internally into a
   controlled and uncontrolled port.

   The controlled port is what is used to pass data from the access
   port to the external Ethernet.  It is controlled in that there is a
   switch that must be turned on by the authenticator before data can
   flow.  It may also have QoS parameters that can be controlled by the
   AS.  In its initial state the controlled port drops all incoming
   frames.

   The uncontrolled port connects to an internal authenticator.  The
   authenticator creates the initial trigger.  In some cases it may
   need to send an EAP frame back to the Station prior to sending the
   initial trigger, and other times it may have enough information from
   the initial Associate or ReAssociate to create the trigger
   immediately.

   The Access Event Handling is supported by the Access Bind PIB.

   The PEP creates an instance of event PRC, with eventEventhdlr
   referencing the eventHandler, and eventCasue referencing
   eventhdlrElement provisioned in Access Event Handler Provisioning
   above.

   This event PRI will be sent by the PEP to the PDP in a REQ using a
   new COPS Request Handle.  This REQ message may contain additional
   PRIs as dictated by how a specific signaling protocol should be
   handled.

8.1.3 Wireless LAN Access Event Decision

   The AS/PDP decides whether the trigger contains enough information
   to make an authentication decision.  If not, it may initiate an EAP
   dialog through the authenticatior to the STATION.

   Once it has enough information the PDP makes a decision and sends a
   Provisioning message to the AP that sets QoS parameters and _closes_
   the switch on the controlled port.

   The decision (DEC) message sent by the PDP to the PEP will be using
   the same COPS Request Handle created in Access Event Handling above.
   The content (PRCs) carried by the DEC message will depend on the
   functionality need to be provided.  It may be command to _close_ the
   switch on the controlled port, it may contain QoS parameters.  This
   step is very similar to, if not the same as, provisioning using the
   DiffServ PIB.

8.2 RSVP Usage Example
   RSVP is a signaling protocol used for a variety of purposes
   including some call setup applications and MPLS label distribution
   for traffic engineering. RSVP uses a number of message types to
   negotiate both the hop-by-hop path and the service requirements
   between a sender and one or more receivers.

   Some RSVP messages contain information that helps determine whether
   the reservation should be accepted or not. However, the router may
   not equipped with sufficient context to take advantage of the
   information in determining whether to accept or reject an RSVP
   message. COPS was designed to pass specific RSVP messages to a PDP
   (Policy Server). The PDP could then analyze the RSVP message and
   usually determine whether to accept or reject the reservation.

   With the advent of COPS-PR, it became possible to construct more
   sophisticated policies beyond simple accept or reject messages.
   However, these more sophisticated policies were targeted for
   DiffServ rather than RSVP. With the definition of the AccessBind
   PIB, it becomes possible to provision a router not only to specify
   which RSVP messages should be sent to the PDP, but also to use
   existing PIBs to specify how the QoS requirements in a RSVP
   reservation should be supported in a specific router implementation.

   Two types RSVP specific structures are added to AccessBind to
   support RSVP. In order to provision the EventHandler class to detect
   RSVP messages, a number of filter classes must be defined. These
   filter classes are general purpose and could be used both by
   EventHandlers and by Classifiers although the semantics of the
   filter class are somewhat different for each. The other group of
   classes is the Context Data classes that pass some or all parts of
   the RSVP message to the PDP when the EventHandler generates an
   event.

   Because COPS assumes that all RSVP message objects are sent to the
   PDP, each well known RSVP object will be assigned a unique Context
   Data PRC identifier and the rest of the RSVP object's attributes
   will be part of the PIB class in the same order and format as in the
   original RSVP object. The actual PRC mappings for these objects can
   be found in the PIB definition. For details on the operation of an
   these objects refer to [RSVP] and [INTSERV]. In addition, a PIB
   class is also defined to support unrecognized RSVP objects.

   A Context Data PIB class is also specified to describe the relevant
   RSVP common header attributes. The attributes in the common header
   that will be specified are:
     1.         The RSVP MsgType attribute, which distinguishes a PATH message
        from a RESV or PATHerr message.
     2.         The RSVP Flags attribute is used to indicate whether Refresh
        Reduction is possible or not.
     3.         The Send TTL (Time To Live) attribute, provides a easy
        mechanism for determining whether non-RSVP hops have been
        traversed by comparing this field with the IP TTL field.
     4.         The In Interface (if known)
     5.         The Out Interface (if known)

   A special context data class, called AllRSVPMsgObjects, is defined
   to simplify the process of specifying the set of RSVP objects to be
   included with a COPS-PR Event Handler message. Rather than explicitly
   specifying every context data class that should be included with the
   Event message, this class (when referenced by PRC through the
   ContextDataIfElement attibute of the ContextData class) indicates
   that all RSVP objects, including the common header class described
   above, should be encapsulated and propagated to the PDP. All Refresh
   Reduction related RSVP objects (MESSAGE_ID, MESSAGE_ID_ACK, and
   MESSAGE_ID_NACK) are explicitly excluded from being sent to the PDP
   when the AllRSVPMessageObjects attribute is set to True. These
   objects are specifically for purpose of synchronizing state between
   RSVP

   Figure 7.2 represents hops and bears no value in the set of policy decision process.
   However, a context data PIB object is defined for each of these
   classes that would be
   provisioned in order the event that a PDP determines that it needs these
   objects.

   The EventScope classes have been specified to indicate roughly follow the
   same mappings as the Context Data PIB classes. However, since the
   typical criteria for outsourcing a RSVP message are usually rather
   simple, only a subset of the RSVP objects require mappings to COPS-
   PR filter classes. If some implementations require support for
   filtering additional objects, it is trivial to extend the PEP filters.
   Note that RSVP messages the filters bound to EventHandlers determine whether a
   matching packet should generate unique events for any combination of filters an Event or
   sessions. However, all messages using not.

   The RSVP objects that will be mapped to filters in this
   specification will include the same unique RSVP common header, the RSVP Dclass
   object, the RSVP session will
   share object, and the same COPS Request Handle.

   When an RSVP message arrives at style object. The last
   three are used to describe various characteristics of the PEP with an new combination data
   traffic for which the reservation is being performed. Since the
   filters can describe both AND and OR semantics, the challenge is in
   organizing the fields of
   session attribute values, the PEP will create objects to simplify filter expressions
   as much as possible. Since this is the primary goal the appropriate
   attributes of each object have been combined into a new COPS Request
   Handle. Following this, an Event message single PIB
   class. The RSVP filter PIB class contains the following attributes.
   The fields marked with asterisks will be generated
   containing an Event object with references to EventHandler EH1 represented as masked
   values (for IP addresses) and
   EventhdlrElement Elem1. These two pieces of information allow the
   PDP ranges (for UDP/TCP ports) to determine which provisioned EventHandler add
   flexibility.

        RSVP MsgType
        RSVP Flags
        Send TTL
        DCLASS DSCP
        Session Dest IP*
        Session Protocol
        Session Dest Port*
        Filter Src IP*
        Filter Src Port*
        Style value
   This paper does not address reservation specification (TSPEC and which specific
   event type generated the event. In addition
   FLOWSPEC) modifications that depend on the Event message also
   contains RSVP refresh model. RSVP
   refresh reduction [REFRESH] is assumed as a set simplifying assumption
   for this application of Context Data objects. Since the AllRSVPMsgObjects
   class was specified Access Bind PIB. However, if support for
   traditional RSVP refresh is desirable, it can be supported in this
   model by adding explicit filters for the ContextData class, all RSVP FlowSpec and RSVP
   Tspec objects are
   encapsulated as specified in COPS-PR PIB classes and sent [IntServ].

   In order to support RSVP outsourcing with the PDP in AccessBind PIB the
   Event
   message.

   When the PDP receives Handler must be provisioned with the Event message, it determines what policies appropriate settings to provision in the PEP. Suppose the
   recognize specific RSVP message was a reservation messages, create new request for a controlled load service with a bandwidth allocation of
   1 Mbps handles, and session object contained (SessionDestIP = 1.2.3.4,
   SessionProtocol=UDP, SessionDestPort=7788). If
   generate events (outsourcing requests). After we have described how
   this is accomplished, we will show the routerÆs
   implementation only supported 4 queues with respective bandwidth
   allocations of 20Mb, 40Mb, 30Mb, and 10Mb, actual message flows involved
   in the PDP may decide RSVP outsourcing process.

   The specific PIB classes that
   allocating the reservation need to queue 3 can satisfy be provisioned are the reservation
   request. Hence,
   EventHandler, EventhdlrElemenet, ContextData, EventhdlrHandleScope,
   and EventhdlrEventScope. The EventHandler provides a PDP might generate termination
   point for processing RSVP messages. As RSVP messages arrive, they
   are directed to the EventHandler by a provisioning policy classifier. In this scenario
   the EventHandler as behaving as a
   result of termination point for all RSVP
   messages. Hence, the PEPÆs Event message EventHandler class is provisioned with no data
   path elements following the EventHandler. Therefore, the attribute
   eventhdlrNonMatchNext is left unassigned.

   Alternatively, the EventHandler can also be provisioned such that creates a new Classifier
   Element
   RSVP and Filter non-RSVP packets alike pass through the EventHandler, but
   only RSVP messages invoke events. In this case, the attribute
   eventhdlrNonMatchNext would specify the next data path element that matches all 1.2.3.4:7788 traffic and directs
   it to queue 3.

8. The AccessBind PIB Module

         ACCESSBIND-PIB PIB-DEFINITIONS ::= BEGIN

         IMPORTS
             Unsigned32, Integer32, MODULE-IDENTITY,
             MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
                     FROM COPS-PR-SPPI
             InstanceId, Prid
                     FROM COPS-PR-SPPI-TC
             RoleCombination, PrcIdentifier
                     FROM FRAMEWORK-TC-PIB
             InetAddress, InetAddressType
                     FROM INET-ADDRESS-MIB
             TruthValue, PhysAddress
                     FROM SNMPv2-TC;

         accessBindPib  MODULE-IDENTITY
             SUBJECT-CATEGORIES { all }
             LAST-UPDATED "200202202002Z"
             ORGANIZATION "IETF RAP WG"
             CONTACT-INFO "
                           Walter Weiss
                           Ellacoya Networks
                           7 Henry Clay Drive
                           Merrimack, NH 03054
                           Phone: 603-879-7364
                           E-mail: wweiss@ellacoya.com
                         "
             DESCRIPTION
                   "A PIB module containing
   should process any packets not matching the set EventHandler's criteria
   (non RSVP packets).

   The EventhdlrElement class identifies a specific category of classes events.
   Suppose one wanted to generate different Events for PATH messages
   and RESV messages. This could be done by configuring one
   EventhdlrElement to
                   configure generic event handlers, only match PATH messages and outsource
                   events as they occur. One application of this PIB is another
   EventhdlrElement to bind authorization and authentication only match RESV messages. Event messages contain
   a reference to COPS
                   Provisioning."

             ::= { pib xxx }    -- xxx the EventhdlrElement that generated the event.
   Therefore, it is possible to be assigned by IANA

         --
         -- generate different events from the same
   EventHandler.

   The branch OIDs in EventhdlrElement contains two main semantics. First, it
   specifies the AccessBind PIB
         --

         capabilityClasses OBJECT IDENTIFIER ::= { accessBindPib 1 }
         eventClasses OBJECT IDENTIFIER ::= { accessBindPib 2 }
         eventHdlrClasses OBJECT IDENTIFIER ::= { accessBindPib 3 }
         contextClasses OBJECT IDENTIFIER ::= { accessBindPib 4 }
         authClasses OBJECT IDENTIFIER ::= { accessBindPib 5 }
         filterClasses OBJECT IDENTIFIER ::= { accessBindPib 6 }

         --
         -- Event Table
         --
         -- Instances criteria for creating new Request Handles. Each
   Request Handle constitutes a unique dialog between the PEP and PDP.
   The second semantic is the criteria for generating events. In some
   situations, it is desirable to generate a one-time event and not
   generate events when similar messages are seen later. A good example
   of this table represent events is RSVP Refresh messages. When RSVP Refresh messages are
   used to indicate that occurred at
         -- the PEP. The reservation is still active, generating
   events reference for each message is inappropriate. In contrast, when Refresh
   Reduction [Refresh] is active, only reservation changes are
   propagated as full RSVP messages. In this situation, every message
   may constitute an Event.

   With RSVP it is usually appropriate to assign a unique COPS-PR
   Request Handle for every new RSVP session. Since EventHandlers are
   typically bound to an interface data path, the event handler instance
         -- RSVP Path message and
   the specific event handler element that the event was
         -- caught by.

         eventTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF EventEntry
             PIB-ACCESS     notify
             STATUS         current
             DESCRIPTION
              "An instance of Resv message will be processed on different data paths.
   Therefore, unique events and unique COPS-PR Request Handles will
   typically be assigned for each message type. However, this class is created by not
   significant since the PEP and sent provisioning objectives for Path messages are
   different from the provisioning objectives for Resv messages. For
   RSVP, the EventhdlrElement will use the Tag Reference
   EventhdlrElementHandleScope to describe the PDP. As criteria for creating a result of this event, The PDP may send
              additional unsolicited decisions
   unique handle. Each EventhdlrHandleScope object will contain
   pointers to the PEP after
              sending the mandatory solicited decision for RSVP filter objects mentioned earlier to describe
   the event."

             ::= { eventClasses 1 }

         eventEntry OBJECT-TYPE
             SYNTAX         EventEntry
             STATUS         current
             DESCRIPTION
                 "An instance various fields whose combination of values constitute a unique
   handle.

   Typically, the eventTable PRC."

             PIB-INDEX { eventId }
             UNIQUENESS { }

             ::= { eventTable 1 }

         EventEntry ::= SEQUENCE {
                 eventId                  InstanceId,
                 eventEventHdlr           ReferenceId,
                 eventCause               ReferenceId
         }

         eventId  OBJECT-TYPE
             SYNTAX         InstanceId
             STATUS         current
             DESCRIPTION
                 "An index to uniquely identify Filter class used is the RSVP filter class. For this event."

             ::= { eventEntry 1 }

         eventEventHdlr  OBJECT-TYPE
             SYNTAX         ReferenceId
             PIB-REFERENCES {  frwkReferenceEntry }
             STATUS         current
             DESCRIPTION
              "This attribute allows a PEP
   class, the session attributes (SessionDestIP, SessionDestPort, and
   SessionProtocol) will be assigned wildcard values and all other
   attributes assigned to indicate NULL to the PDP indicate that
              this event was generated due to any combination of
   these attributes constitutes a unique handle. When various messages
   arrive that require the referenced Event
              Handler. This attribute references generation of an event handler via
              the indirection PRC frwkReference, since the event
              handler and event could potentially belong to that have a different
              PIB contexts."

             ::= { eventEntry 2 }

         eventCause OBJECT-TYPE
             SYNTAX         ReferenceId
             PIB-REFERENCES { frwkReferenceEntry }
             STATUS         current
             DESCRIPTION
              "This attribute references newly
   unique combination of the specific instance in filter attribute values, a
              group of new request
   handle will be assigned. When a message arrives for which a previous
   message has already generated a handle, that handle is used to pass
   the appropriate event Handler elements belonging to the PDP.

   The other class pointed to by the EventhdlrElement is the
   EventhdlrEventScope. This class describes the criteria for
   generating an event
              Handler that resulted in this event. This attribute
              references a specific event handler element via Typically, the
              indirection PRC frwkReference, since MsgType attribute in conjunction
   with the event handler
              element session attributes will be wildcarded and event could potentially belong to a different
              PIB contexts."

             ::= { eventEntry 3 }

         --
         -- EventHandler Table
         --
         -- Instances of this PRC are provisioned by the PDP on the PEP
         -- other fields
   assigned to catch specific events. The Event Handlers reference a
         -- group of eventHdlrElement PRIs NULL to indicate that contain all RSVP messages should be sent
   to the scope PDP. This describes the criteria for an event: Every time a
   unique combination of
         -- all these attributes occurs, generate a new
   event.

   In many cases it may make sense to assign the event filter attributes
   (SessionDestIP and specify the context data to send SessionDestPort) to the PDP
         -- EventhdlrEventScope
   and/or EventhdlrHandleScope class. This would be done when an event it is caught.

         eventHandlerTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHandlerEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
               "The eventHandlerTable specifies for what events the PEP
               should send a request
   desirable to notify of the PDP. As a  result PDP of this
               request, the PEP may send configuration changes need to the
               PEP. An instance allocate additional
   resources to a set of this class defines reserved flows going to the circumstances
               for generating same destination
   but originating from different sources.

   A new COPS-PR Request Handle MUST only be created when a request, and provides the means for
               specifying valid event
   occurs. If a packet matches the contents criteria described by
   EventhdlrHandleScope but does not match any EventhdlrEventScope
   criteria, a COPS-PR Request Handle must not be generated.

   This version of the PEP Request. Hence, the
               eventHandlerTable paper only describes how RSVP can be said to create eventTable
               entries. "

           ::= {  eventHdlrClasses 1 }

         eventHandlerEntry OBJECT-TYPE
           SYNTAX  EventHandlerEntry
           STATUS  current
           DESCRIPTION
                "eventTable entry."
           PIB-INDEX { eventHandlerId }
           UNIQUENESS {    eventHandlerElements,
                           eventHandlerNonMatchNext
                      }

           ::= { eventHandlerTable 1}

         EventHandlerEntry ::= SEQUENCE {
           eventHandlerId                   InstanceId,
           eventHandlerElements             TagReferenceId,
           eventHandlerNonMatchNext         Prid
         }

         eventHandlerId OBJECT-TYPE
           SYNTAX    InstanceId
           STATUS        current
           DESCRIPTION
                "An arbitrary integer index that uniquely identifies
                an instance supported
   when Refresh Reduction [REFRESH] is being used. The complexity of
   addressing the distinction between RSVP refresh messages and
   reservation update messages is too great to be addressed in this
   version. Any RSVP message containing bundle messages (MsgType 12)
   MUST be decomposed and each message in the eventHandlerTable class."

            ::= { eventHandlerEntry 1}

          eventHandlerElements OBJECT-TYPE
           SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrElementGrpId }
           STATUS        current
           DESCRIPTION
             "A reference bundle must be
   iteratively processed through the EventHandler as if individual RSVP
   messages were generated from the RSVP neighbor. Whether
   EventhdlrMatchNext applies to a group of eventHdlrElement instances,
             each of which  determines the individual sub-messages or the
   bundled message is beyond the scope (criteria for
             generating a new  request) and what context information to
             send in a request."

              ::= { eventHandlerEntry 2}

          eventHandlerNonMatchNext  OBJECT-TYPE
           SYNTAX       Prid
           STATUS       current
           DESCRIPTION
                "The data path for 'out of scope' traffic."

              ::= { eventHandlerEntry 3}

         --
         -- EventHdlrElement Table
         --
         -- Each Instance of this PRC belongs to a group paper.

   Irrespective of
         -- eventHdlrElement PRIs. The group whether Refresh Reduction is identified by in use or not, the
         -- eventHdlrElementGrpId attribute. These RSVP
   daemon is responsible for aging out reservations that are provisioned by
         -- no longer
   valid. As with traditional COPS, when a reservation is aged out, the PDP on
   RSVP daemon or other entity responsible for aging out reservations
   MUST take responsibility for deleting COPS Request Handles. This
   allows the PEP PDP to catch specific events. This PRC
         -- contain clean up state associated with the scope reservation and
   ensures the proper removal of any policies in the event and specify PEP specifically
   assigned through the context data
         -- type to send to COPS Request Handle.

   Figure 7.1 shows how the PDP when an event is caught.

         eventHdlrElementTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHdlrElementEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
              "The eventHdlrElementTable specifies a single eventHdlr
              element's scope via various Event Handler objects would be
   provisioned in a reference router to a group of filters and
              the context data type and encapsulation meta-information ensure that the PEP needs to send an event notification to the
              PDP."

           ::= { eventHdlrClasses 2 }

         eventHdlrElementEntry OBJECT-TYPE
           SYNTAX  EventHdlrElementEntry
           STATUS  current
           DESCRIPTION
                "eventTable entry."
           PIB-INDEX { eventHdlrElementId }
           UNIQUENESS {    eventHdlrElementEventCriteria,
                           eventHdlrElementGrpId,
                           eventHdlrElementEventScope,
                           eventHdlrElementHandleScope,
                           eventHdlrElementContext,
                           eventHdlrElementMatchNext
                      }

           ::= { eventHdlrElementTable 1}

         EventHdlrElementEntry ::= SEQUENCE {
           eventHdlrElementId                      InstanceId,
           eventHdlrElementEventCriteria           Unsigned32,
           eventHdlrElementGrpId                   TagId,
           eventHdlrElementEventScope              TagReferenceId,
           eventHdlrElementHandleScope             TagReferenceId,
           eventHdlrElementContext                 TagReferenceId,
           eventHdlrElementMatchNext               Prid
         }

         eventHdlrElementId OBJECT-TYPE
           SYNTAX    InstanceId
           STATUS        current
           DESCRIPTION
                "An arbitrary integer index that uniquely identifies
                an instance is generated for
   every RSVP message.

   +-------------------+
   |EventHandler       |
   | Id=EH1            |
   | NonMatchNext=<NUL>|
   | ElementRef=(Elem1)|
   +-------------+-----+
                 |
                 V
   +------------------+    +-----------------+
   |EH_Element        |    |ContextData      |
   | Id=Elem1         |    | Id=CD1          |
   | MatchNext=<NUL>  |    | DataGroup=RSVP  |
   | Criteria=AllMatch|    | IfElement=(PRC)-+--AllRSVPMsgObjects
   | Context=(RSVP)---+--->| DataEncap=0     |
   | EventScope=(MSG)-+--+ +-----------------+
   | HandleScope=(HD) |  |
   +-------------+----+  +-------------------+
                 |       |                   |
                 |       |  +-------------+  |   +-------------+
                 |       +->|EventScope   |  +-->|EventScope   |
                 |          | Id=Ev1      |      | Id=Ev2      |
                 |          | Group=MSG   |      | Group=MSG   |
                 |          | Filter=(F1)-+--+   | Filter=(R1)-+--+
                 |          | Precedence=1|  |   | Precedence=1|  |
                 |          | ChangeFlag=?|  |   | ChangeFlag=?|  |
                 |          +-------------+  |   +-------------+  |
                 |                           |                    |
                 |  +-------------+          V                    V
                 |  |HandleScope  |     +-------------+  +------------+
                 +->| Id=Hd1      |  +->|IpFilter     |  |RsvpFilter  |
                 |  | Group=HD    |  |  | Id=F1       |  | Id=R1      |
                 |  | Filter=(F1)-+--+  | Protocol=46 |  | DestIP=*   |
                 |  | Precedence=1|     +-------------+  | Protocol=* |
                 |  +-------------+                      | DestPort=* |
                 |                      +------------+   | SrcIP=*    |
                 |  +-------------+  +->|RsvpFilter  |   | SrcPort=*
                 |  |HandleScope  |  |  | Id=R2      |   +------------+
                 +->| Id=Hd2      |  |  | DestIP=*   |
                    | Group=HD    |  |  | Protocol=* |
                    | Filter=(R2)-+--+  | DestPort=* |
                    | Precedence=1|     +------------+
                    +-------------+
   Fig 8.1: Representation of the eventHdlrElementTable class."

            ::= { eventHdlrElementEntry 1}

         eventHdlrElementEventCriteria  OBJECT-TYPE
           SYNTAX        Unsigned32 {
                                       one_time(1),
                                       every_time(2),
                                       on_change(3)
                                    }
           STATUS        current
           DESCRIPTION
              "Indicates when an event is generated. Valid options are
              one_time, every_time and on_change. This attribute allows
              event Handlers to distinguish one time events (ignore
              after the first match) from recurring events (generate an
              event every time a match occurs).  A enum type was also
              define to specify that a new event should be generated
              when a specific set of fields change. This is important Event Handler for protocols like RSVP because messages are sent both to
              demonstrate that

   Figure 8.1 represents the reservation is active and to notify
              hops set of changes to reservations. Since only changes need PIB classes that would be
   provisioned in order to propagate indicate to the PDP, the on_change option indicates
              that PEP that events RSVP messages
   should be generated selectively.

              This criteria controls behavior generate unique events for any combination of both, filters or
   sessions. However, all messages using the EventScope
              and same unique session will
   share the HandleScope."

              ::= { eventHdlrElementEntry 2}

         eventHdlrElementGrpId OBJECT-TYPE
           SYNTAX        TagId        -- corresponding Tag Reference in
                                      -- eventHandlerEntry
           STATUS        current
           DESCRIPTION
                "Group identifier. All instances same COPS Request Handle.

   When an RSVP message arrives at the PEP with an new combination of
   session attribute values, the PEP will create a new COPS Request
   Handle. Following this, an Event message will be generated
   containing an Event object with the same group
                identifier belong references to one group EventHandler EH1 and can be referenced
                collectively from an eventHandler instance."

              ::= { eventHdlrElementEntry 3}

         eventHdlrElementEventScope OBJECT-TYPE
           SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrEventScopeGroup }
           STATUS        current
           DESCRIPTION
                "Identifies a group
   EventhdlrElement Elem1. These two pieces of eventHdlrEventScope entries
                associated with this eventHdlrElement instance."

              ::= { eventHdlrElementEntry 4}

         eventHdlrElementHandleScope OBJECT-TYPE
           SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrHandleScopeGroup }
           STATUS        current
           DESCRIPTION
                "Identifies information allow the
   PDP to determine which provisioned EventHandler and which specific
   event type generated the event. In addition the Event message also
   contains a group set of eventHdlrHandleScope entries
                associated with this eventHdlrElement instance. This is
                an optional attribute. If it is not present Context Data objects. Since the
                semantics of AllRSVPMsgObjects
   class was specified in the Handle processing is interpreted as
                identical ContextData class, all RSVP objects are
   encapsulated in COPS-PR PIB classes and sent to the PDP in the Event Scope handling specified
   message.

   When the PDP receives the Event message, it determines what policies
   to provision in the
                EventScope objects"

              ::= { eventHdlrElementEntry 5}

         eventHdlrElementContext OBJECT-TYPE
           SYNTAX       TagReferenceId
           PIB-TAG       { contextDataGroup }
           STATUS        current
           DESCRIPTION
                "Identifies PEP. Suppose the RSVP message was a list reservation
   request for a controlled load service with a bandwidth allocation of ContextDataTable entries
                associated
   1 Mbps and session object contained (SessionDestIP = 1.2.3.4,
   SessionProtocol=UDP, SessionDestPort=7788). If the router's
   implementation only supported 4 queues with this eventHdlrElement instance."

              ::= { eventHdlrElementEntry 6}

         eventHdlrElementMatchNext OBJECT-TYPE
           SYNTAX        Prid
           STATUS        current
           DESCRIPTION
                "The data path for traffic in scope."

             ::= { eventHdlrElementEntry 7}

      --
      -- EventHdlrEventScope Table
      --
      -- This PRC defines respective bandwidth
   allocations of 20Mb, 40Mb, 30Mb, and 10Mb, the scope of an event handler element using
      -- references PDP may decide that
   allocating the reservation to filters defined in queue 3 can satisfy the Framework reservation
   request. Hence, a PDP might generate a provisioning policy as a
   result of the PEP's Event message that creates a new Classifier
   Element and Filter that matches all 1.2.3.4:7788 traffic and directs
   it to queue 3.

9. The AccessBind PIB or in some
      -- other PIBs. These filters may describe specific protocol Module

   -- properties for which events need to be generated. These filter
   -- references are grouped using a TagId, and this group is then The AccessBind PIB Module
   -- referenced from the eventHdlrElement PRC.

         eventHdlrEventScopeTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHdlrEventScopeEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
                 "This class defines the criteria to be used for
                 partitioning various portions of traffic."

   ACCESSBIND-PIB PIB-DEFINITIONS ::= BEGIN

      IMPORTS
          Unsigned32, Integer32, MODULE-IDENTITY,
          MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
                  FROM COPS-PR-SPPI
          InstanceId, Prid
                  FROM COPS-PR-SPPI-TC
          RoleCombination, PrcIdentifierOid
                  FROM FRAMEWORK-TC-PIB
          InetAddress, InetAddressType
                  FROM INET-ADDRESS-MIB
          TruthValue, PhysAddress
                  FROM SNMPv2-TC;

      accessBindPib  MODULE-IDENTITY
          SUBJECT-CATEGORIES { eventHdlrClasses 3 all }

         eventHdlrEventScopeEntry OBJECT-TYPE
           SYNTAX  EventHdlrEventScopeEntry
           STATUS  current
          LAST-UPDATED "200202202002Z"
          ORGANIZATION "IETF RAP WG"
          CONTACT-INFO "
                        Walter Weiss
                        Ellacoya Networks
                        7 Henry Clay Drive
                        Merrimack, NH 03054
                        Phone: 603-879-7364
                        E-mail: wweiss@ellacoya.com
                        "
          DESCRIPTION
             "An instance
                "A PIB module containing the set of classes to
                configure generic event handlers, and outsource
                events as they occur. One application of this class defines an individual criterion PIB is
                to be used towards generating an event."
           PIB-INDEX bind authorization and authentication to COPS
                Provisioning."

          ::= { eventHdlrEventScopeId pib 4 }
           UNIQUENESS    -- xxx to be assigned by IANA

      --
      -- The branch OIDs in the AccessBind PIB
      --

      eventClasses OBJECT IDENTIFIER ::= { eventHdlrEventScopeGroup,
                        eventHdlrEventScopeFilter accessBindPib 1 }
      eventHdlrClasses OBJECT IDENTIFIER ::= { eventHdlrEventScopeTable 1}

         EventHdlrEventScopeEntry::= SEQUENCE {
           eventHdlrEventScopeId         InstanceId,
           eventHdlrEventScopeGroup      TagId,
           eventHdlrEventScopeFilter     Prid,
           eventHdlrEventScopePrecedence INTEGER,
           eventHdlrEventScopeChangeFlag TruthValue accessBindPib 2 }

         eventHdlrEventScopeId    OBJECT-TYPE
           SYNTAX        InstanceId
           STATUS        current
           DESCRIPTION
                "An arbitrary integer index that uniquely identifies an
                instance of the eventHdlrEventScopeTable class."
      contextClasses OBJECT IDENTIFIER ::= { eventHdlrEventScopeEntry 1}

         eventHdlrEventScopeGroup  OBJECT-TYPE
           SYNTAX        TagId accessBindPib 3 }
      -- corresponding TagReference
      -- defined in eventHdlrElementEntry
           STATUS        current
           DESCRIPTION
              "Represents Event Table
      --
      -- Instances of this table represent events that occurred at
      -- the binding between PEP. The events reference the eventHdlrElementEntry event handler instance
      -- and the eventHdlrEventScope entries. A group of
              eventHdlrEventScope entries constitutes the criteria for
              partitioning various portions of traffic."

              ::= { eventHdlrEventScopeEntry 2}

         eventHdlrEventScopeFilter   OBJECT-TYPE
           SYNTAX        Prid
           STATUS        current
           DESCRIPTION
                "Pointer to a filter to be used as specific event handler element that the criteria."
              ::= { eventHdlrEventScopeEntry 3}

         eventHdlrEventScopePrecedence event was
      -- caught by.
      eventTable OBJECT-TYPE
          SYNTAX        INTEGER         SEQUENCE OF EventEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "Represents the precedence of this criterion with respect
              to other criteria within the same group. When the
              precedence is unique, the
              "An instance represents an
              alternative criteria (an ORing function). When the
              precedence for two or more instances of the
              eventHdlrEventScope this class is created by the same, the attributes
              within all PEP and sent
              to the instances are treated collectively as PDP. As a
              single filter criteria with the following rules:
              1. If the filters are not result of this event, The PDP may send
              additional unsolicited decisions to the same type, the filters
                 are ANDÆed as a whole eg (RSVP and IP)
              2. If the filter types are the same, the attribute values
                 are ORÆed and PEP after
              sending the attributes themselves are ANDÆed, mandatory solicited decision for example, two IP filters with src protocol values
                 56 and 57 respectively and dst protocol values 20 and
                 25 , would be treated as the condition (src port (56
                 or 57) AND dst port (20 or 25)." event."

          ::= { eventHdlrEventScopeEntry 4}

         eventHdlrEventScopeChangeFlag eventClasses 1 }

      eventEntry OBJECT-TYPE
          SYNTAX        TruthValue         EventEntry
          STATUS         current
          DESCRIPTION
             "Boolean value, if set to 'true' indicates that a new
             event should be generated if any
              "An instance of the assigned fields in
             the associated filter change." eventTable PRC."

          PIB-INDEX { eventId }
          UNIQUENESS { }

          ::= { eventHdlrEventScopeEntry 5}

      --
      -- EventHdlrHandleScope Table
      --
      -- This PRC defines eventTable 1 }

      EventEntry ::= SEQUENCE {
          eventId                  InstanceId,
          eventEventHdlr           ReferenceId,
          eventCause               ReferenceId
      }

      eventId  OBJECT-TYPE
          SYNTAX         InstanceId
          STATUS         current
          DESCRIPTION
              "An index to uniquely identify this event."

          ::= { eventEntry 1 }

      eventEventHdlr  OBJECT-TYPE
          SYNTAX         ReferenceId
          PIB-REFERENCES {  frwkReferenceEntry }
          STATUS         current
          DESCRIPTION
              "This attribute allows a PEP to indicate to the scope of request handles PDP that
              this event was generated by the
      -- PEP due to events caught by the referenced Event
              Handler. This attribute references an event handler element. Each
      -- instance of this via
              the indirection PRC references filters defined in frwkReference, since the
      -- Framework event
              handler and event could potentially belong to a different
              PIB or some other signaling-protocol specific filter
      -- PRCs. These filters may describe contexts."

          ::= { eventEntry 2 }

      eventCause OBJECT-TYPE
          SYNTAX         ReferenceId
          PIB-REFERENCES { frwkReferenceEntry }
          STATUS         current
          DESCRIPTION
              "This attribute references the specific protocol properties
      -- instance in a
              group of event Handler elements belonging to which an event
              Handler that resulted in this event. This attribute
              references a specific event handler is sensitive. Essentially this
      -- table defines when element via the
              indirection PRC frwkReference, since the event handler
              element and event could potentially belong to a new COPS RequestHandle must be created by different
              PIB contexts."

          ::= { eventEntry 3 }

      --
      -- EventHandler Table
      --
      -- Instances of this PRC are provisioned by the PEP based PDP on protocol properties. The event handler may be the PEP
      -- set up to be sensitive to catch specific field values and/or the
      -- uniqueness of events. The Event Handlers reference a set of values considered together. This
      -- accommodates various behaviors group of eventHdlrElement PRIs that contain the scope of signaling protocols. These
      -- filters references are grouped using a TagId, the event and this group
      -- is then referenced from specify the eventHdlrElement PRC via context data to send to the PDP
      -- eventHdlrElementHandleScope TagReference.

         eventHdlrHandleScopeTable when an event is caught.

      eventHandlerTable OBJECT-TYPE
          SYNTAX          SEQUENCE OF EventHdlrHandleScopeEntry EventHandlerEntry
          PIB-ACCESS      install
          STATUS          current
          DESCRIPTION
               "This
              "The eventHandlerTable specifies for what events the PEP
              should send a request to the PDP. As a  result of this
              request, the PDP may send configuration changes to the
              PEP. An instance of this class defines the criteria to be used circumstances
              for
               deciding whether to create generating a new COPS RequestHandle request, and provides the means for
               an event or
              specifying the contents of the PEP Request. Hence, the
              eventHandlerTable can be said to use an existing Handle." create eventTable
              entries. "

          ::= {  eventHdlrClasses 4 1 }

         eventHdlrHandleScopeEntry

      eventHandlerEntry OBJECT-TYPE
          SYNTAX  EventHdlrHandleScopeEntry  EventHandlerEntry
          STATUS  current
          DESCRIPTION
             "An instance of this class defines an individual criterion
             to be used towards deciding when to create a new Handle."
              "eventTable entry."
          PIB-INDEX { eventHdlrHandleScopeId eventHandlerId }
          UNIQUENESS { eventHdlrHandleScopeGroup,
                        eventHdlrHandleScopeFilter    eventHandlerElements,
                          eventHandlerNonMatchNext
                     }

          ::= { eventHdlrHandleScopeTable eventHandlerTable 1}

         EventHdlrHandleScopeEntry::=

      EventHandlerEntry ::= SEQUENCE {
           eventHdlrHandleScopeId
          eventHandlerId                   InstanceId,
           eventHdlrHandleScopeGroup      TagId,
           eventHdlrHandleScopeFilter     Prid,
           eventHdlrHandleScopePrecedence INTEGER,
           eventHdlrHandleScopeChangeFlag TruthValue
          eventHandlerElements             TagReferenceId,
          eventHandlerNonMatchNext         Prid
      }

         eventHdlrHandleScopeId

      eventHandlerId OBJECT-TYPE
          SYNTAX    InstanceId
          STATUS        current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the eventHdlrHandleScopeTable eventHandlerTable class."

          ::= { eventHdlrHandleScopeEntry eventHandlerEntry 1}

         eventHdlrHandleScopeGroup

      eventHandlerElements OBJECT-TYPE
          SYNTAX        TagId   -- corresponding TagReference
                                 -- defined in eventHdlrElementEntry        TagReferenceId
          PIB-TAG       { eventHdlrElementGrpId }
          STATUS        current
          DESCRIPTION
              "Represents the binding between the eventHdlrElementEntry
              and the eventHdlrHandleScope entries. A
              "A reference to a group of
              eventHdlrHandleScope entries constitutes the criteria for
              defining the scope eventHdlrElement instances,
              each of which  determines the Handles generated." scope (criteria for
              generating a new  request) and what context information
              to send in a request."

          ::= { eventHdlrHandleScopeEntry eventHandlerEntry 2}

         eventHdlrHandleScopeFilter

      eventHandlerNonMatchNext  OBJECT-TYPE
          SYNTAX       Prid
          STATUS       current
          DESCRIPTION
                "Pointer to a filter to be used as the criteria."
              "The data path for 'out of scope' traffic."

          ::= { eventHdlrHandleScopeEntry eventHandlerEntry 3}

         eventHdlrHandleScopePrecedence OBJECT-TYPE
           SYNTAX        INTEGER
           STATUS        current
           DESCRIPTION
              "Represents the precedence

      --
      -- EventHdlrElement Table
      --
      -- Each Instance of this criterion with respect PRC belongs to other criteria within the same group. When the
              precedence is unique, the instance represents an
              alternative criteria (an ORing function). When the
              precedence for two or more instances a group of the
              eventHdlrHandleScope class
      -- eventHdlrElement PRIs. The group is identified by the same, the attributes
              within all the instances
      -- eventHdlrElementGrpId attribute. These are treated collectively as a
              single filter criteria."

              ::= { eventHdlrHandleScopeEntry 4}

         eventHdlrHandleScopeChangeFlag OBJECT-TYPE
           SYNTAX        TruthValue
           STATUS        current
           DESCRIPTION
             "Boolean value, if set to 'true' indicates that a new
             Handle should be generated to send the event request if
             any of provisioned by
      -- the assigned fields in PDP on the associated filter
             change."

              ::= { eventHdlrHandleScopeEntry 5}

         --
         -- EventHdlrAuthProtocol Table
         --
         -- PEP to catch specific events. This PRC specifies
      -- contain the Auth Mechanism to use in scope of the event and specify the Access context data
      -- request type to send to the PDP when a data path Event Handler an event is configured to
         -- catch access events.

         eventHdlrAuthProtocolTable caught.

      eventHdlrElementTable OBJECT-TYPE
          SYNTAX          SEQUENCE OF EventHdlrAuthProtocolEntry EventHdlrElementEntry
          PIB-ACCESS      install
          STATUS          current
          DESCRIPTION
               "This class lists
              "The eventHdlrElementTable specifies a single eventHdlr
              element's scope via a reference to a group of filters and
              the authentication protocols context data type and encapsulation meta-information
              that can
               be used for the PEP needs to send an access request." event notification to the
              PDP."

          ::= { eventHdlrClasses 5 2 }

         eventHdlrAuthProtocolEntry

      eventHdlrElementEntry OBJECT-TYPE
          SYNTAX  EventHdlrAuthProtocolEntry  EventHdlrElementEntry
          STATUS  current
          DESCRIPTION
             "An instance of this class describes an authentication
             protocol that may be used for an access request. Instances
             of this class that share the same TagId value collectively
             constitute a list of authentication protocols that may be
             used for a given access request"
              "eventTable entry."
          PIB-INDEX { eventHdlrAuthProtocolId eventHdlrElementId }
          UNIQUENESS { eventHdlrAuthProtocolGroup,
                        eventHdlrAuthProtocolAuthMechanism    eventHdlrElementEventCriteria,
                          eventHdlrElementGrpId,
                          eventHdlrElementEventScope,
                          eventHdlrElementHandleScope,
                          eventHdlrElementContext,
                          eventHdlrElementMatchNext
                     }

          ::= { eventHdlrAuthProtocolTable eventHdlrElementTable 1}

         EventHdlrAuthProtocolEntry::=

      EventHdlrElementEntry ::= SEQUENCE {
           eventHdlrAuthProtocolId
          eventHdlrElementId                      InstanceId,
           eventHdlrAuthProtocolGroup
          eventHdlrElementEventCriteria           Unsigned32,
          eventHdlrElementGrpId                   TagId,
           eventHdlrAuthProtocolAuthMechanism  INTEGER
          eventHdlrElementEventScope              TagReferenceId,
          eventHdlrElementHandleScope             TagReferenceId,
          eventHdlrElementContext                 TagReferenceId,
          eventHdlrElementMatchNext               Prid
      }

         eventHdlrAuthProtocolId

      eventHdlrElementId OBJECT-TYPE
          SYNTAX    InstanceId
          STATUS        current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies an
                instance uniquely identifies
              an instance of the eventHdlrElementTable class."

          ::= { eventHdlrElementEntry 1}

      eventHdlrElementEventCriteria  OBJECT-TYPE
          SYNTAX        Unsigned32 {
                                     one_time(1),
                                     every_time(2),
                                     on_change(3)
                                   }
          STATUS        current
          DESCRIPTION
              "Indicates when an event is generated. Valid options are
              one_time, every_time and on_change. This attribute allows
              event Handlers to distinguish one time events (ignore
              after the first match) from recurring events (generate an
              event every time a match occurs).  A enum type was also
              define to specify that a new event should be generated
              when a specific set of fields change. This is important
              for protocols like RSVP because messages are sent both to
              demonstrate that the reservation is active and to notify
              hops of changes to reservations. Since only changes need
              to propagate to the ContextDataTable class." PDP, the on_change option indicates
              that that events should be generated selectively.

              This criteria controls behavior of both, the EventScope
              and the HandleScope."

          ::= { eventHdlrAuthProtocolEntry 1}

         eventHdlrAuthProtocolGroup eventHdlrElementEntry 2}

      eventHdlrElementGrpId OBJECT-TYPE
          SYNTAX        TagId        -- corresponding TagReference
                                -- Tag Reference in datapathEventHdlrEntry
                                      -- eventHandlerEntry
          STATUS        current
          DESCRIPTION
                "Represents a binding between an datapathEventHdlrTable
                instance
              "Group identifier. All instances with the same group
              identifier belong to one group and a list of eventHdlrAuthProtocolTable
                instances." can be referenced
              collectively from an eventHandler instance."

          ::= { eventHdlrAuthProtocolEntry 2}

         eventHdlrAuthProtocolAuthMechanism eventHdlrElementEntry 3}

      eventHdlrElementEventScope OBJECT-TYPE
          SYNTAX        INTEGER        TagReferenceId
          PIB-TAG       {
                                     PAP (0),
                                     CHAP (1),
                                     EAP_MD5(2),
                                     EAP_TLS(3) eventHdlrEventScopeGroup }
          STATUS        current
          DESCRIPTION
                "The authentication protocol that may be used for an
                access request."
              "Identifies a group of eventHdlrEventScope entries
              associated with this eventHdlrElement instance."

          ::= { eventHdlrAuthProtocolEntry 3}

         --
         -- DataPath Event Handler Table
         --
         -- eventHdlrElementEntry 4}

      eventHdlrElementHandleScope OBJECT-TYPE
          SYNTAX        TagReferenceId
          PIB-TAG       { eventHdlrHandleScopeGroup }
          STATUS        current
          DESCRIPTION
              "Identifies a group of eventHdlrHandleScope entries
              associated with this eventHdlrElement instance. This PRC is
              an extension of the EventHandler PRC. This
         -- extension illustrates optional attribute. If it is not present the use
              semantics of the EventHandler PRC
         -- concept for authentication usage. Instances of this PRC are
         -- provisioned by Handle processing is interpreted as
              identical to the PDP on Event Scope handling specified in the PEP to catch specific access
         -- events. This PRC references
              EventScope objects"

          ::= { eventHdlrElementEntry 5}

      eventHdlrElementContext OBJECT-TYPE
          SYNTAX       TagReferenceId
          PIB-TAG       { contextDataGroup }
          STATUS        current
          DESCRIPTION
              "Identifies a group list of ContextDataTable entries
                associated with this eventHdlrElement instance."

          ::= { eventHdlrElementEntry 6}

      eventHdlrElementMatchNext OBJECT-TYPE
          SYNTAX        Prid
          STATUS        current
          DESCRIPTION
              "The data path for traffic in scope."

          ::= { eventHdlrElementEntry 7}

      -- eventHdlrAuthProtocol instances which define a set of
      -- Authentication mechanisms to use if an access event is EventHdlrEventScope Table
      -- caught by this event Handler. From its base class (Event
      -- Handler) this This PRC also references a group of
         -- eventHdlrElement PRIs that contain defines the scope of the
         -- access an event and specify the context data to send handler element using
      -- references to filters defined in the Framework PIB or in some
      -- PDP when an access event other PIBs. These filters may describe specific protocol
      -- properties for which events need to be generated. These filter
      -- references are grouped using a TagId, and this group is caught.

         datapathEventHdlrTable then
      -- referenced from the eventHdlrElement PRC.

      eventHdlrEventScopeTable OBJECT-TYPE
          SYNTAX          SEQUENCE OF DatapathEventHdlrEntry EventHdlrEventScopeEntry
          PIB-ACCESS      install
          STATUS          current
          DESCRIPTION
              "The datapathEventHdlrTable specifies for what access
              events the PEP should send an access request to the PDP.
              As a result of this access request,
              "This class defines the PEP may send
              configuration changes criteria to the PEP or specific policies be used for
              specific users. An
              partitioning various portions of traffic."

          ::= { eventHdlrClasses 3 }

      eventHdlrEventScopeEntry OBJECT-TYPE
          SYNTAX  EventHdlrEventScopeEntry
          STATUS  current
          DESCRIPTION
              "An instance of this class defines the
              circumstances for an individual
              criterion to be used towards generating an access request, and
              provides event."
          PIB-INDEX { eventHdlrEventScopeId }
          UNIQUENESS { eventHdlrEventScopeGroup,
                       eventHdlrEventScopeFilter
                     }
          ::= { eventHdlrEventScopeTable 1}

      EventHdlrEventScopeEntry::= SEQUENCE {
          eventHdlrEventScopeId         InstanceId,
          eventHdlrEventScopeGroup      TagId,
          eventHdlrEventScopeFilter     Prid,
          eventHdlrEventScopePrecedence INTEGER,
          eventHdlrEventScopeChangeFlag TruthValue
      }

      eventHdlrEventScopeId    OBJECT-TYPE
          SYNTAX        InstanceId
          STATUS        current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies an
              instance of the eventHdlrEventScopeTable class."

          ::= { eventHdlrEventScopeEntry 1}

      eventHdlrEventScopeGroup  OBJECT-TYPE
          SYNTAX        TagId   -- corresponding TagReference
                                -- defined in eventHdlrElementEntry
          STATUS        current
          DESCRIPTION
              "Represents the means for specifying binding between the authentication
              mechanisms eventHdlrElementEntry
              and contents of the PEP Request. Hence, the
              datapathEventHdlrTable can be said to create eventTable eventHdlrEventScope entries. A group of
              eventHdlrEventScope entries constitutes the criteria for user access. "
              partitioning various portions of traffic."

          ::= {  eventHdlrClasses 6 }

         datapathEventHdlrEntry eventHdlrEventScopeEntry 2}

      eventHdlrEventScopeFilter   OBJECT-TYPE
          SYNTAX  DatapathEventHdlrEntry        Prid
          STATUS        current
          DESCRIPTION
                "dataPathEventHdlrTable entry."
           EXTENDS { EventHandlerEntry }
           UNIQUENESS {    eventHandlerElements,
                           eventHandlerNonMatchNext,
                           datapathEventHdlrRequestAuth
                      }

           ::= { datapathEventHdlrTable 1}

         DatapathEventHdlrEntry
              "Pointer to a filter to be used as the criteria."
          ::= SEQUENCE {
           datapathEventHdlrRequestAuth    TruthValue,
           datapathEventHdlrAuthProtocol   TagReferenceId
         }

         datapathEventHdlrRequestAuth eventHdlrEventScopeEntry 3}

      eventHdlrEventScopePrecedence OBJECT-TYPE
          SYNTAX        TruthValue        INTEGER
          STATUS        current
          DESCRIPTION
                "Boolean flag, if set to 'true' requires authentication
                data to be sent in
              "Represents the request sent precedence of this criterion with respect
              to other criteria within the PDP same group. When the
              precedence is unique, the instance represents an
              alternative criteria (an ORing function). When the
              precedence for two or more instances of the
              eventHdlrEventScope class is the same, the attributes
              within all the instances are treated collectively as a
              single filter criteria with the
                access event." following rules:
              1. If the filters are not of the same type, the filters
                 are AND'ed as a whole eg (RSVP and IP)
              2. If the filter types are the same, the attribute values
                 are OR'ed and the attributes themselves are AND'ed,
                 for example, two IP filters with src protocol values
                 56 and 57 respectively and dst protocol values 20 and
                 25 , would be treated as the condition (src port (56
                 or 57) AND dst port (20 or 25)."

          ::= { datapathEventHdlrEntry 1}
         datapathEventHdlrAuthProtocol eventHdlrEventScopeEntry 4}

      eventHdlrEventScopeChangeFlag OBJECT-TYPE
          SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrAuthProtocolGroup }        TruthValue
          STATUS        current
          DESCRIPTION
                "References
              "Boolean value, if set to 'true' indicates that a group of eventHdlrAuthProtocol instances,
                 each new
              event should be generated if any of which specifies an authentication mechanism." the assigned fields
              in the associated filter change."

          ::= { datapathEventHdlrEntry 2} eventHdlrEventScopeEntry 5}

      --
      --
      -- ContextData Table
      --
      -- This PRC specifies the context information to send to the PDP
      -- when an event is caught. The context information to send is
      -- described in terms of the PRC data types to include in the
      -- request, the level of encapsulated data and the interface
      -- information for that request.

      contextDataTable OBJECT-TYPE
          SYNTAX          SEQUENCE OF ContextDataEntry
          PIB-ACCESS      install
          STATUS          current
          DESCRIPTION
              "This class points to the context information to be
              included with a request."

          ::= { contextClasses 1 }

      contextDataEntry OBJECT-TYPE
          SYNTAX  ContextDataEntry
          STATUS  current
          DESCRIPTION
              "An instance of this class contains the type description
              (the assigned OID) of the class which needs to be filled
              in by the PEP and included with a PEP request."
          PIB-INDEX { contextDataId }
          UNIQUENESS { }

          ::= { contextDataTable 1}
      ContextDataEntry::= SEQUENCE {
          contextDataId            InstanceId,
          contextDataGroup         TagId,
          contextDataIfElement     PrcIdentifier,     PrcIdentifierOid,
          contextDataEncapsulation INTEGER
      }

      contextDataId   OBJECT-TYPE
          SYNTAX        InstanceId
          STATUS        current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies an
              instance of the contextDataTable class."

          ::= { contextDataEntry 1}

      contextDataGroup  OBJECT-TYPE
          SYNTAX        TagId   --corresponding TagReference
                                --defined in eventHdlrElement
          STATUS        current
          DESCRIPTION
              "Defines the grouping of contextData instances
              that are applicable to a given eventHdlrElement. When
              instances of this PRC are sent to the PEP without the
              event Handler information, this attribute is unused."

          ::= { contextDataEntry 2}

      contextDataIfElement      OBJECT-TYPE
          SYNTAX        PrcIdentifier        PrcIdentifierOid
          STATUS        current
          DESCRIPTION
              "The OID of a class whose instance is to be included with
              the PEP request or event-specific ContextData Response."

          ::= { contextDataEntry 3}

      contextDataEncapsulation OBJECT-TYPE
          SYNTAX        INTEGER
          STATUS        current
          DESCRIPTION
              "This attribute allows one to distinguish between inner
              and outer headers when there are multiple encapsulated
              headers of the same type in a packet.

              A value of:
              0 means all headers,
              positive number 'n' means the 'n'th header starting
              from the outermost,
              negative number 'n' means the 'n'th header starting from
              the innermost."
          ::= { contextDataEntry 4}
      --
      -- Layer 3 Header Data PRC
      --

      ctxtL3HdrTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF ctxtL3HdrEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "An instance of this class is created by the PEP and
              sent to the PDP to provide the PDP with information it
              requested in the ContextData PRC. The PDP uses
              this PRC to make Authentication/Provisioning
              decisions."

          ::= { contextClasses 2 }

      ctxtL3HdrEntry OBJECT-TYPE
          SYNTAX         CtxtL3HdrEntry
          STATUS         current
          DESCRIPTION
              "An instance of the ctxtL3HdrTable PRC."

          PIB-INDEX { ctxtL3HdrId }
          UNIQUENESS { }

          ::= { ctxtL3HdrTable 1 }

      CtxtL3HdrEntry::= SEQUENCE {
          ctxtL3HdrId               InstanceId,
          ctxtL3HdrSrcAddrType        InetAddressType,
          ctxtL3HdrSrcAddr            InetAddress,
          ctxtL3HdrDstAddrType        InetAddressType,
          ctxtL3HdrDstAddr            InetAddress,
          ctxtL3HdrProtocol           Unsigned32,
          ctxtL3HdrSrcPort            Unsigned32,
          ctxtL3HdrDstPort            Unsigned32,
          ctxtL3HdrDscp               Unsigned32,
          ctxtL3HdrEcn                TruthValue,
          ctxtL3HdrIpOpt              OCTET STRING,
          ctxtL3HdrEncap              Integer32
      }

      ctxtL3HdrId  OBJECT-TYPE
          SYNTAX         InstanceId
          STATUS         current
          DESCRIPTION
              "An index to uniquely identify an instance of this
              provisioning class."

          ::= { ctxtL3HdrEntry 1 }
      ctxtL3HdrSrcAddrType OBJECT-TYPE
          SYNTAX         InetAddressType
          STATUS         current
          DESCRIPTION
              "The address type enumeration value [INETADDR] to specify
               the type of the packet's source L3 address)."

          ::= { ctxtL3HdrEntry 2 }

      ctxtL3HdrSrcAddr OBJECT-TYPE
          SYNTAX         InetAddress
          STATUS         current
          DESCRIPTION
              " The packet's source L3 address."

          ::= { ctxtL3HdrEntry 3 }

      ctxtL3HdrDstAddrType OBJECT-TYPE
          SYNTAX         InetAddressType
          STATUS         current
          DESCRIPTION
              "The address type enumeration value [INETADDR] to specify
               the type of the packet's destination L3 address."

          ::= { ctxtL3HdrEntry 4 }

      ctxtL3HdrDstAddr OBJECT-TYPE
          SYNTAX         InetAddress
          STATUS         current
          DESCRIPTION
              "The packet's destination L3 address."

          ::= { ctxtL3HdrEntry 5 }

      ctxtL3HdrProtocol OBJECT-TYPE
          SYNTAX         Unsigned32
          STATUS         current
          DESCRIPTION
              "The packet's protocol field."

          ::= { ctxtL3HdrEntry 6 }

      ctxtL3HdrSrcPort  OBJECT-TYPE
          SYNTAX         Unsigned32
          STATUS         current
          DESCRIPTION
              "This attribute binds an existing upstream session to
              this session instance."

          ::= { ctxtL3HdrEntry 7 }
      ctxtL3HdrDstPort  OBJECT-TYPE
          SYNTAX         Unsigned32
          STATUS         current
          DESCRIPTION
              "This attribute binds an existing upstream session to
              this session instance."

          ::= { ctxtL3HdrEntry 8 }

      ctxtL3HdrDscp  OBJECT-TYPE
          SYNTAX         Unsigned32
          STATUS         current
          DESCRIPTION
              "DiffServ CodePoint."

          ::= { ctxtL3HdrEntry 9 }

      ctxtL3HdrEcn  OBJECT-TYPE
          SYNTAX         TruthValue
          STATUS         current
          DESCRIPTION
              "PEP sets this attribute to true(1) if ECN capable."

          ::= { ctxtL3HdrEntry 10 }

      ctxtL3HdrIpOpt  OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
              "IP Options field in the packet."

          ::= { ctxtL3HdrEntry 11 }

      ctxtL3HdrEncap  OBJECT-TYPE
          SYNTAX         Integer32
          STATUS         current
          DESCRIPTION
              "This attribute specifies which encapsulated header is
              being described. The sign on this value will be the same
              as the value specified in the ContextData
              instance that requested this header. If the original
              ContextData instance specified a
              ContextDataEncapsulation value of zero (meaning
              return all headers), then all instances of this attribute
              MUST be expressed as positive numbers.

              A value of:

              positive number 'n' means the 'n'th header starting
              from the outermost,
              negative number 'n' means the 'n'th header starting from
              the innermost."
          ::= { ctxtL3HdrEntry 12 }

      --
      -- 802.1 Header Data PRC
      --

      ctxt802HdrTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF Ctxt802HdrEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "An instance of this class is created by the PEP and sent
              to the PDP to provide the PDP with information it
              requested in the ContextData PRC. The PDP uses this PRC
              to make Authorization/Provisioning decisions."

          ::= { contextClasses 3 }

      ctxt802HdrEntry OBJECT-TYPE
          SYNTAX         Ctxt802HdrEntry
          STATUS         current
          DESCRIPTION
              "An instance of the ctxt802HdrTable PRC."

          PIB-INDEX { ctxt802HdrId }
          UNIQUENESS { }

          ::= { ctxt802HdrTable 1 }

      Ctxt802HdrEntry::= SEQUENCE {
          ctxt802HdrId               InstanceId,
          ctxt802HdrSrcAddr          PhysAddress,
          ctxt802HdrDstAddr          PhysAddress,
          ctxt802HdrProtocol         Unsigned32,
          ctxt802HdrPriority         Unsigned32,
          ctxt802HdrVlan             Unsigned32,
          ctxt802HdrEncap            Integer32
      }

      ctxt802HdrId  OBJECT-TYPE
          SYNTAX         InstanceId
          STATUS         current
          DESCRIPTION
              "An index to uniquely identify an instance of this
              provisioning class."

          ::= { ctxt802HdrEntry 1 }

      ctxt802HdrSrcAddr OBJECT-TYPE
          SYNTAX         PhysAddress
          STATUS         current
          DESCRIPTION
              " The packet's source MAC address."

          ::= { ctxt802HdrEntry 2 }

      ctxt802HdrDstAddr OBJECT-TYPE
          SYNTAX         PhysAddress
          STATUS         current
          DESCRIPTION
              "The packet's destination MAC address."

          ::= { ctxt802HdrEntry 3 }

      ctxt802HdrProtocol OBJECT-TYPE
          SYNTAX         Unsigned32 (0..'ffff'h)
          STATUS         current
          DESCRIPTION
              "The L2 packet's protocol field."

          ::= { ctxt802HdrEntry 4 }

      ctxt802HdrPriority OBJECT-TYPE
          SYNTAX         Unsigned32 (0..7)
          STATUS         current
          DESCRIPTION
              "The L2 packet's priority field. This attribute is only
              valid for packets using the 802.1q header extension."

          ::= { ctxt802HdrEntry 5 }

      ctxt802HdrVlan OBJECT-TYPE
          SYNTAX         Unsigned32 (1..4094)
          STATUS         current
          DESCRIPTION
              "The L2 packet's VLAN field. This attribute is only valid
              for packets using the 802.1q header extension."

          ::= { ctxt802HdrEntry 6 }

      ctxt802HdrEncap OBJECT-TYPE
          SYNTAX         Integer32
          STATUS         current
          DESCRIPTION
              "This attribute specifies which encapsulated header is
              being described. The sign on this value will be the same
              as the value specified in the ContextData
              instance that requested this header. If the original
              ContextData instance specified an
              ContextDataEncapsulation value of zero (meaning
              return all headers), then all instances of this attribute
              MUST be expressed as positive numbers.

              A value of:
              positive number 'n' means the 'n'th header starting
              from the outermost,
              negative number 'n' means the 'n'th header starting from 'n'th header starting from
              the innermost."

             ::= { ctxt802HdrEntry 7 }

      --
      -- conformance section tbd
      --

      END

10. Identity Extensions PIB

   --
   -- The AccessBind Identity Extensions PIB Module
   --

   ACCESSBIND-IDENTEXT-PIB PIB-DEFINITIONS ::= BEGIN

      IMPORTS
          MODULE-IDENTITY, MODULE-COMPLIANCE,
          OBJECT-TYPE, OBJECT-GROUP, pib
                  FROM COPS-PR-SPPI
          InstanceId, Prid
                  FROM COPS-PR-SPPI-TC
          TruthValue
                  FROM SNMPv2-TC;

      accessBindIdentityExtPib  MODULE-IDENTITY
          SUBJECT-CATEGORIES { all }
          LAST-UPDATED "200211032002Z"
          ORGANIZATION "IETF RAP WG"
          CONTACT-INFO "
                        Walter Weiss
                        Ellacoya Networks
                        7 Henry Clay Drive
                        Merrimack, NH 03054
                        Phone: 603-879-7364
                        E-mail: wweiss@ellacoya.com
                       "
          DESCRIPTION
              "A PIB module containing the set of classes to
              associate authentication protocols with configured
              event handlers, and outsource authentication events
              as they occur."

          ::= { pib 7 }    -- xxx to be assigned by IANA

      --
      -- The branch OIDs in the AccessBind Signalling PIB
      --

      identEventHdlrClasses OBJECT IDENTIFIER ::= {
          accessBindIdentityExtPib  1 }
      identAuthClasses OBJECT IDENTIFIER ::= {
          accessBindIdentityExtPib  2 }

      --
      -- Identity Event Handler Table
      --
      -- This PRC is an extension of the EventHandler PRC. This
      -- extension illustrates the use of the EventHandler PRC
      -- concept for authentication usage. Instances of this PRC are
      -- provisioned by the PDP on the PEP to catch specific access
      -- events. This PRC references a group of
      -- eventHdlrAuthProtocol instances which define a set of
      -- Authentication mechanisms to use if an access event is
      -- caught by this event Handler. From its base class (Event
      -- Handler) this PRC also references a group of
      -- eventHdlrElement PRIs that contain the scope of the innermost."
             ::= { ctxt802HdrEntry 7 }
      -- access event and specify the context data to send to the
      -- CtxtDialupInterface Table
         --

         ctxtDialupInterfaceTable PDP when an access event is caught.

      identityEventHdlrTable OBJECT-TYPE
          SYNTAX          SEQUENCE OF CtxtDialupInterfaceEntry IdentityEventHdlrEntry
          PIB-ACCESS     notify      install
          STATUS          current
          DESCRIPTION
                 "Dialup Interface context data."
              "The identityEventHdlrTable specifies for what access
              events the PEP should send an access request to the PDP.
              As a result of this access request, the PEP may send
              configuration changes to the PEP or specific policies for
              specific users. An instance of this class defines the
              circumstances for generating an access request, and
              provides the means for specifying the authentication
              mechanisms and contents of the PEP Request. Hence, the
              identityEventHdlrTable can be said to create eventTable
              entries for user access. "

          ::= { contextClasses 4  identEventHdlrClasses 1 }

         ctxtDialupInterfaceEntry

      identityEventHdlrEntry OBJECT-TYPE
          SYNTAX         CtxtDialupInterfaceEntry  IdentityEventHdlrEntry
          STATUS  current
          DESCRIPTION
                 "Entry oid of the ctxtDialupInterfaceTable PRC."

             PIB-INDEX
              "identityEventHdlrTable entry."
          EXTENDS { ctxtDialupInterfaceId eventHandlerEntry }
          UNIQUENESS {    eventHandlerElements,
                          eventHandlerNonMatchNext,
                          identityEventHdlrRequestAuth
                     }

          ::= { ctxtDialupInterfaceTable 1 }

         CtxtDialupInterfaceEntry::= identityEventHdlrTable 1}

      IdentityEventHdlrEntry ::= SEQUENCE {
                 ctxtDialupInterfaceId                InstanceId,
                 ctxtDialupInterfaceNASPort           Integer32,
                 ctxtDialupInterfaceNASPortId         OCTET STRING,
                 ctxtDialupInterfaceNASPortType       INTEGER,
                 ctxtDialupInterfaceCalledStationId   OCTET STRING,
                 ctxtDialupInterfaceCallingStationId  OCTET STRING,
                 ctxtDialupInterfaceConnectInfo       OCTET STRING
          identityEventHdlrRequestAuth    TruthValue,
          identityEventHdlrAuthProtocol   TagReferenceId
      }

         ctxtDialupInterfaceId

      identityEventHdlrRequestAuth    OBJECT-TYPE
          SYNTAX         InstanceId        TruthValue
          STATUS        current
          DESCRIPTION
                 "An index
              "Boolean flag, if set to uniquely identify an instance of this
                 provisioning class."

             ::= { ctxtDialupInterfaceEntry 1 }

         ctxtDialupInterfaceNASPort  OBJECT-TYPE
             SYNTAX         Integer32
             STATUS         current
             DESCRIPTION
              "This Attribute indicates the physical port number of the
              NAS which is authenticating the user.  It is only used in
              Access-Request packets.  Note that this is using 'port' 'true' requires authentication
              data to be sent in its sense of a physical connection on the NAS, not in request sent to the sense of a TCP or UDP port number." PDP with the
              access event."
          ::= { ctxtDialupInterfaceEntry 2 }

         ctxtDialupInterfaceNASPortId identityEventHdlrEntry 1}

      identityEventHdlrAuthProtocol    OBJECT-TYPE
          SYNTAX         OCTET STRING        TagReferenceId
          PIB-TAG       { eventHdlrAuthProtocolGroup }
          STATUS        current
          DESCRIPTION
               "This Attribute contains
              "References a text string which identifies
               the port group of the NAS which is authenticating the user. It
               is only used in Access-Request and Accounting-Request
               packets.  Note that this is using 'port' in its sense eventHdlrAuthProtocol instances,
              each of
               a physical connection on which specifies an authentication mechanism."

          ::= { identityEventHdlrEntry 2}

      --
      -- EventHdlrAuthProtocol Table
      --
      -- This PRC specifies the NAS, not Auth Mechanism to use in the sense of Access
      -- request when a
               TCP or UDP port number. "

             ::= { ctxtDialupInterfaceEntry 3 }

         ctxtDialupInterfaceNASPortType identity Event Handler is configured to
      -- catch access events.
      --

      eventHdlrAuthProtocolTable OBJECT-TYPE
          SYNTAX  INTEGER {
                              radAsync(0),
                              radSync(1),
                              radIsdnSync(2),
                              radIsdnAsyncV120(3),
                              radIsdnAsyncV110(4),
                              radVirtual(5),
                              radPIAFS(6),
                              radHdlcClearChannel(7),
                              radX25(8),
                              radX75(9),
                              radG3Fax(10),
                              radSDSL(11),
                              radAdslCAP(12),
                              radAdslDMT(13),
                              radIdsl(14),
                              radEthernet(15),
                              radXdsl(16),
                              radCable(17),
                              radWirelessOther(18),
                              radWirelessIEEE80211(19)
                      }          SEQUENCE OF EventHdlrAuthProtocolEntry
          PIB-ACCESS      install
          STATUS          current
          DESCRIPTION
              "This Attribute indicates the type of the physical port
              of the NAS which is authenticating class lists the user.  It authentication protocols that can
              be used instead of or in addition to the radNasPort (5)
              attribute.  It is only used in Access-Request packets.
              Either radNasPort (5) or radNasPortType or both SHOULD be
              present in for an Access-Request packet, if the NAS
              differentiates among its ports.

                   A value of 'radAsync(0)' indicates Async.

                   A value of 'radSync(1)' indicates Sync.

                   A value of 'radIsdnSync(2)' indicates ISDN Sync.

                   A value of 'radIsdnAsyncV120(3)' indicates ISDN
                   Async V.120.

                   A value of 'radIsdnAsyncV110(4)' indicates ISDN
                   Async V.110.

                   A value of 'radVirtual(5)' indicates Virtual.
                   Virtual refers to a connection to the NAS via some
                   transport protocol, instead access request."

          ::= { identEventHdlrClasses 2 }

      eventHdlrAuthProtocolEntry OBJECT-TYPE
          SYNTAX  EventHdlrAuthProtocolEntry
          STATUS  current
          DESCRIPTION
              "An instance of through a physical
                   port. For example, if a user telnetted into a NAS to
                   authenticate himself as this class describes an Outbound-User, the
                   Access-Request might include radNasPortType =
                   Virtual as a hint to the RADIUS server authentication
              protocol that may be used for an access request.
              Instances of this class that share the user
                   was not on a physical port.

                   A same TagId value of 'radPIAFS(6)' indicates PIAFS. PIAFS is
              collectively constitute a
                   form list of wireless ISDN commonly authentication
              protocols that may be used in Japan, and
                   stands for PHS (Personal Handyphone System) Internet
                   Access Forum Standard (PIAFS).

                   A value of 'radHdlcClearChannel(7)' indicates HDLC
                   Clear Channel.

                   A value of 'radX25(8)' indicates X.25.

                   A value of 'radX75(9)' indicates X.75.

                   A value of 'radG3Fax(10)' indicates G.3 Fax.

                   A value of 'radSDSL(11)' indicates SDSL " Symmetric
                   DSL.

                   A value of 'radAdslCAP(12)' indicates ADSL-CAP -
                   Asymmetric DSL, Carrierless Amplitude Phase
                   Modulation.

                   A value of 'radAdslDMT(13)' indicates ADSL-DMT -
                   Asymmetric DSL, Discrete Multi-Tone.

                   A value of 'radIdsl(14)' indicates IDSL " ISDN
                   Digital Subscriber Line.

                   A value of 'radEthernet(15)' indicates Ethernet.

                   A value of 'radXdsl(16)' indicates xDSL - Digital
                   Subscriber Line of unknown type.

                   A value of 'radCable(17)' indicates Cable.

                   A value a given access request"
          PIB-INDEX { eventHdlrAuthProtocolId }
          UNIQUENESS { eventHdlrAuthProtocolGroup,
                       eventHdlrAuthProtocolAuthMechanism
                     }

          ::= { eventHdlrAuthProtocolTable 1}

      EventHdlrAuthProtocolEntry::= SEQUENCE {
          eventHdlrAuthProtocolId             InstanceId,
          eventHdlrAuthProtocolGroup          TagId,
          eventHdlrAuthProtocolAuthMechanism  INTEGER
      }

      eventHdlrAuthProtocolId    OBJECT-TYPE
          SYNTAX        InstanceId
          STATUS        current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies an
              instance of 'radWirelessOther(18)' indicates Wireless
                   - Other.

                   A value the ContextDataTable class."

          ::= { eventHdlrAuthProtocolEntry 1}

      eventHdlrAuthProtocolGroup OBJECT-TYPE
          SYNTAX        TagId  -- corresponding TagReference
                               -- in identityEventHdlrEntry
          STATUS        current
          DESCRIPTION
              "Represents a binding between an identityEventHdlrTable
              instance and a list of 'radWirelessIEEE80211(19)' indicates
                   Wireless - IEEE 802.11." eventHdlrAuthProtocolTable
              instances."

          ::= { ctxtDialupInterfaceEntry 4 }

         ctxtDialupInterfaceCalledStationId eventHdlrAuthProtocolEntry 2}

      eventHdlrAuthProtocolAuthMechanism OBJECT-TYPE
          SYNTAX         OCTET STRING        INTEGER {
                                    PAP (0),
                                    CHAP_MD5 (1),
                                    CHAP_MS (2),
                                    EAP_MD5(3),
                                    EAP_TLS(4)
                                }
          STATUS        current
          DESCRIPTION
                 "This Attribute allows the NAS to send in the Access-
                 Request packet the phone number that the user called,
                 using Dialed Number Identification (DNIS) or similar
                 technology.  Note
              "The authentication protocol that this may be different from the
                 phone number used for an
              access request. Based on this attribute the call comes in on.  It is only
              corresponding Auth Extensions PRC must be used in
                 Access-Request packets. " as
              defined under the identAuthClasses branch. For
              CHAP_MD5, and CHAP_MS, the same authChapExtTable must
              be used."
          ::= { ctxtDialupInterfaceEntry 5 }

         ctxtDialupInterfaceCallingStationId eventHdlrAuthProtocolEntry 3}

      --
      -- Authentication Extension Tables
      --

      --
      -- AuthExtensions Base Table
      --

      authExtTable OBJECT-TYPE
          SYNTAX         OCTET STRING         SEQUENCE OF AuthExtEntry
          PIB-ACCESS     install-notify
          STATUS         current
          DESCRIPTION
              "This Attribute allows the NAS is an abstract PRC. This PRC can be extended by
              authentication PRCs that contain attributes specific to send in the Access-
              Request packet the phone number
              that authentication protocol. An instance of the user extended
              class is calling
              from, using Dialed Number Identification (DNIS) created by the PEP and sent to the PDP. The PDP
              may send information back to the PEP or
              similar technology.  Note that this may be different from uses the phone number called.  It
              information to authenticate the PEP's access request.
              This  PRC itself should not be instantiated.

              This is only used in
              Access-Request packets. "
             ::= { ctxtDialupInterfaceEntry 6 }

         ctxtDialupInterfaceConnectInfo  OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
               "This Attribute allows a 'transient' class. Its instances are temporary
              and are deleted by the NAS PEP after a certain time/event.
              Thus it must not be referred to send in the Access-
               Request packet the phone number that by the call came from,
               using Automatic Number Identification (ANI) or similar
               technology.  It is only used in Access-Request packets."
             ::= { ctxtDialupInterfaceEntry 7 }

         ---
         --- CtxtDialupInterfaceFramedProtocol Table
         ---

         ctxtDialupIfFramedProtocolTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF CtxtDialupIfFramedProtocolEntry
             PIB-ACCESS     notify
             STATUS         current
             DESCRIPTION
                 "." server."

          ::= { contextClasses 5 identAuthClasses 1 }

         ctxtDialupIfFramedProtocolEntry

      authExtEntry OBJECT-TYPE
          SYNTAX         CtxtDialupIfFramedProtocolEntry         AuthExtEntry
          STATUS         current
          DESCRIPTION
              "Entry oid of for the ctxtDialupIfFramedProtocolTable AuthExtTable PRC."

          PIB-INDEX { ctxtDialupIfFramedProtocolId authExtId }
          UNIQUENESS { }

          ::= { ctxtDialupIfFramedProtocolTable authExtTable 1 }

         CtxtDialupIfFramedProtocolEntry

      AuthExtEntry ::= SEQUENCE {
                 ctxtDialupIfFramedProtocolId           InstanceId,
                 ctxtDialupIfFramedProtocolProt         INTEGER,
                 ctxtDialupIfFramedProtocolMTU          Integer32,
                 ctxtDialupIfFramedProtocolCompression  INTEGER,
                 ctxtDialupIfFramedProtocolPortLimit    Unsigned32,
                 ctxtDialupIfFramedProtocolIpAddress    InetAddress,
                 ctxtDialupIfFramedProtocolIpNetmask    InetAddress
          authExtId                InstanceId
      }

         ctxtDialupIfFramedProtocolId

      authExtId  OBJECT-TYPE
          SYNTAX         InstanceId
          STATUS         current
          DESCRIPTION
              "An index to uniquely identify an instance of this the
              entended provisioning class."

          ::= { ctxtDialupIfFramedProtocolEntry authExtEntry 1 }

         ctxtDialupIfFramedProtocolProt

      --
      -- UserAuthExt Table
      --

      userAuthExtTable OBJECT-TYPE
          SYNTAX  INTEGER         SEQUENCE OF UserAuthExtEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "This is a concrete PRC used to contain user
              authentication fields. This PRC extends the base PRC
              authExtEntry."
          ::= {
                              radPPP(1),
                              radSLIP(2),
                              radARAP(3),
                              radGandalf(4),
                              radXylogics(5),
                              radX75Synchronous(6) identAuthClasses 2 }

      userAuthExtEntry OBJECT-TYPE
          SYNTAX         UserAuthExtEntry
          STATUS         current
          DESCRIPTION
               "This Attribute indicates
              "Entry for the framing to be used UserAuthExtTable PRC. InstanceId's for
               framed access. It MAY be used in both Access-Request and
               Access-Accept packets.

                    A value of 'radPPP(1)' represents PPP.

                    A value of 'radSLIP(2)' represents SLIP.

                    A value of 'radARAP(3)' represents AppleTalk Remote
                    Access Protocol (ARAP).

                    A value of 'radGandalf(4)' represents Gandalf
                    proprietary SingleLink/MultiLink protocol.

                    A value of 'radXylogics(5)' represents Xylogics
                    proprietary IPX/SLIP.

                    A value of 'radX75Synchronous(6)' represents X.75
                    Synchronous."
              this extended PRC are assigned by the base PRC AuthExt
              [SPPI]."

          EXTENDS { authExtEntry }
          UNIQUENESS { }

          ::= { userAuthExtTable 1 }

      UserAuthExtEntry ::= SEQUENCE {
          userAuthExtRealm      OCTET STRING,
          userAuthExtUsername   OCTET STRING
      }

      userAuthExtRealm OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
              "user realm octet string."

          ::= { ctxtDialupIfFramedProtocolEntry userAuthExtEntry 1 }

      userAuthExtUsername OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
              "Username octet string."

          ::= { userAuthExtEntry 2 }

         ctxtDialupIfFramedProtocolMTU

      --
      -- AuthChapExt Table
      --

      authChapExtTable OBJECT-TYPE
          SYNTAX         Integer32         SEQUENCE OF AuthChapExtEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "This Attribute indicates the Maximum Transmission Unit
              to be configured for the user, when it is not negotiated
              by some other means (such as PPP).  It MAY be used in
              Access-Accept packets.  It MAY be used in an Access-
              Request packet as a hint by the NAS to the server that it
              would prefer that value, but the server is not required concrete PRC used to honor contain CHAP
              authentication fields. This PRC extends the hint." PRC
              userAuthExtEntry."

          ::= { ctxtDialupIfFramedProtocolEntry identAuthClasses 3 }

         ctxtDialupIfFramedProtocolCompression
      authChapExtEntry OBJECT-TYPE
          SYNTAX  INTEGER {
                              radNone(0),
                              radVJ(1),
                              radIPXheader(2),
                              radStacLZS(3)
                      }         AuthChapExtEntry
          STATUS         current
          DESCRIPTION
              "This Attribute indicates a compression protocol to be
              used
              "Entry oid for the link.  It MAY be used in Access-Accept
              packets.  It MAY be used in an Access-Request packet as a
              hint to the server that the NAS would prefer to use that
              compression, but the server is not required to honor the
              hint.

              More than one compression protocol Attribute MAY be sent.
              It is the responsibility of the NAS to apply AuthChapExtTable PRC. InstanceId's for
              this extended PRC are assigned by the proper
              compression protocol to appropriate link traffic.

                      A value of 'radNone(0)' indicates None.

                      A value of 'radVJ(1)' indicates VJ TCP/IP header
                      compression.

                      A value of 'radIPXheader(2)' indicates IPX header
                      compression.

                      A value of 'radStacLZS(3)' indicates Stac-LZS
                      compression." base PRC [SPPI]."

          EXTENDS { userAuthExtEntry }
          UNIQUENESS { }

          ::= { ctxtDialupIfFramedProtocolEntry 4 authChapExtTable 1 }

         ctxtDialupIfFramedProtocolPortLimit

      AuthChapExtEntry::= SEQUENCE {
          authChapExtId        Unsigned32,
          authChapExtChal      OCTET STRING,
          authChapExtResp      OCTET STRING
      }

      authChapExtId OBJECT-TYPE
          SYNTAX         Unsigned32
          STATUS         current
          DESCRIPTION
               "This Attribute sets the maximum number of ports to be
               provided to the user by the NAS.  This Attribute MAY be
               sent
              "CHAP Id field."

          ::= { authChapExtEntry 1 }

      authChapExtChal OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
              "CHAP Challenge octet string. The challenge is generated
              by the server to the client in an Access-Accept
               packet.  It PEP."

          ::= { authChapExtEntry 2 }

      authChapExtResp OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
              "CHAP Challenge Response octet string. The challenge
              response is intended for use in conjunction with
               Multilink PPP [10] or similar uses.  It MAY also be sent
               by the NAS to the server as a hint that that many ports
               are desired for use, but PDP along with the server challenge."

          ::= { authChapExtEntry 3 }

      --
      -- AuthPapExt Table
      --

      authPapExtTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthPapExtEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "This is not required a concrete PRC used to
               honor contain PAP
              authentication fields. This PRC extends the hint." PRC
              userAuthExtEntry."

          ::= { ctxtDialupIfFramedProtocolEntry 5 identAuthClasses 4 }

         ctxtDialupIfFramedProtocolIpAddress

      authPapExtEntry OBJECT-TYPE
          SYNTAX         InetAddress         AuthPapExtEntry
          STATUS         current
          DESCRIPTION
               "This Attribute indicates the address to be configured
              "Entry oid for the user.  It MAY be used in Access-Accept packets.
               It MAY be used in an Access-Request packet as a hint AuthPapExtTable PRC. InstanceId's for
              this extended PRC are assigned by the NAS to the server that it would prefer that address,
               but the server is not required to honor the hint." base PRC [SPPI]."

          EXTENDS { userAuthExtEntry }
          UNIQUENESS { }

          ::= { ctxtDialupIfFramedProtocolEntry 6 authPapExtTable 1 }

      AuthPapExtEntry::= SEQUENCE {
          authPapExtPwd      OCTET STRING
      }

         ctxtDialupIfFramedProtocolIpNetmask

      authPapExtPwd OBJECT-TYPE
          SYNTAX         InetAddress         OCTET STRING
          STATUS         current
          DESCRIPTION
              "This Attribute indicates the IP netmask to be configured
              for the user when the user is a router to a network.  It
              MAY be used in Access-Accept packets.  It MAY be used in
              an Access-Request packet as a hint by the NAS to the
              server that it would prefer that netmask, but the server
              is not required to honor the hint."
              "PAP password octet string."

          ::= { ctxtDialupIfFramedProtocolEntry 7 authPapExtEntry 1 }

         ---
         --- CtxtDialupIfLoginService

      --
      -- AuthExtResult Table
         ---

         ctxtDialupIfLoginServiceTable
      --

      authExtResultTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF CtxtDialupIfLoginServiceEntry AuthExtResultEntry
          PIB-ACCESS     notify     install
          STATUS         current
          DESCRIPTION
                 "Base class."
              "This is a concrete PRC used to contain authentication
              results. This PRC extends the base PRC authExtEntry."

          ::= { contextClasses 6 identAuthClasses 5 }

         ctxtDialupIfLoginServiceEntry

      authExtResultEntry OBJECT-TYPE
          SYNTAX         CtxtDialupIfLoginServiceEntry         AuthExtResultEntry
          STATUS         current
          DESCRIPTION
              "Entry oid of for the ctxtDialupIfLoginServiceTable PRC."

             PIB-INDEX authExtResultTable PRC. InstanceId's for
              this extended PRC are assigned by the base PRC AuthExt
              [SPPI]."

          EXTENDS { ctxtDialupIfLoginServiceId authExtEntry }
          UNIQUENESS { }

          ::= { ctxtDialupIfLoginServiceTable authExtResultTable 1 }

         CtxtDialupIfLoginServiceEntry::=

      AuthExtResultEntry ::= SEQUENCE {
                 ctxtDialupIfLoginServiceId       InstanceId,
                 ctxtDialupIfLoginServiceIpHost   InetAddress
          authExtResultSuccess          TruthValue
      }

         ctxtDialupIfLoginServiceId

      authExtResultSuccess OBJECT-TYPE
          SYNTAX         InstanceId         TruthValue
          STATUS         current
          DESCRIPTION
                 "An index
              "Set to uniquely identify an instance of 'true' if authentication was successful, else
              false."

          ::= { authExtResultEntry 1 }

      --
      -- AuthEapReqExt Table
      --

      authEapReqExtTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthEapReqExtEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "This is a concrete PRC used to contain EAP
              authentication fields. This PRC extends the base PRC
              authExtEntry. The PEP uses this
                 provisioning class." PRC to send EAP messages
              to the PDP."

          ::= { identAuthClasses 6 }

      authEapReqExtEntry OBJECT-TYPE
          SYNTAX         AuthEapReqExtEntry
          STATUS         current
          DESCRIPTION
              "Entry oid for the authEapReqExtTable PRC. InstanceId's
              for this extended PRC are assigned by the base PRC
              [SPPI]."

          EXTENDS { authExtEntry }
          UNIQUENESS { }

          ::= { ctxtDialupIfLoginServiceEntry authEapReqExtTable 1 }

         ctxtDialupIfLoginServiceIpHost
      AuthEapReqExtEntry::= SEQUENCE {
          authEapReqExtSpecific    OCTET STRING
      }

      authEapReqExtSpecific OBJECT-TYPE
          SYNTAX         InetAddress         OCTET STRING
          STATUS         current
          DESCRIPTION
                 "."
              "Opaque EAP Request octet string."

          ::= { ctxtDialupIfLoginServiceEntry 2 authEapReqExtEntry 1 }

         ---
         --- CtxtDialupIfLoginLat

      --
      -- AuthEapRespExt Table (Extends
         --- CtxtDialupIfLoginService)
         ---

         ctxtDialupIfLoginLatTable
      --

      authEapRespExtTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF CtxtDialupIfLoginLatEntry AuthEapRespExtEntry
          PIB-ACCESS     notify     install
          STATUS         current
          DESCRIPTION
                 "Extended class."
              "This is a concrete PRC used to contain EAP
              authentication fields. This PRC extends the base PRC
              authExtEntry. The PDP responds using this PRC for EAP
              exchanges."

          ::= { contextClasses identAuthClasses 7 }

         ctxtDialupIfLoginLatEntry

      authEapRespExtEntry OBJECT-TYPE
          SYNTAX         CtxtDialupIfLoginLatEntry         AuthEapRespExtEntry
          STATUS         current
          DESCRIPTION
              "Entry oid of for the ctxtDialupIfLoginLatTable PRC." authEapRespExtTable PRC. InstanceId's
              for this extended PRC are assigned by the base PRC
              [SPPI]."

          EXTENDS { ctxtDialupIfLoginServiceEntry authExtEntry }
          UNIQUENESS { }

          ::= { ctxtDialupIfLoginLatTable authEapRespExtTable 1 }

         CtxtDialupIfLoginLatEntry::=

      AuthEapRespExtEntry::= SEQUENCE {
                 ctxtDialupIfLoginLatService   OCTET STRING,
                 ctxtDialupIfLoginLatNode      OCTET STRING,
                 ctxtDialupIfLoginLatGroup     OCTET STRING,
                 ctxtDialupIfLoginLatPort
          authEapRespExtSpecific    OCTET STRING
      }

         ctxtDialupIfLoginLatService

      authEapRespExtSpecific OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
                 "."
              "Opaque EAP Response octet string."
          ::= { ctxtDialupIfLoginLatEntry authEapRespExtEntry 1 }

         ctxtDialupIfLoginLatNode  OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "."

      --
      -- conformance section tbd
      --

   END

11. Application Specific RSVP Handling PIB Module

   --
   -- The AccessBind RSVP Handling PIB Module
   --

   ACCESSBIND-APP-RSVP-PIB PIB-DEFINITIONS ::= BEGIN

      IMPORTS
          Unsigned32, Integer32, MODULE-IDENTITY,
          MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
                  FROM COPS-PR-SPPI
          InstanceId, Prid
                  FROM COPS-PR-SPPI-TC
          InetAddress, InetAddressType
                  FROM INET-ADDRESS-MIB;

      accessBindAppRsvpPib  MODULE-IDENTITY
          SUBJECT-CATEGORIES { ctxtDialupIfLoginLatEntry 2 all }
         ctxtDialupIfLoginLatGroup  OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
          LAST-UPDATED "200211032002Z"
          ORGANIZATION "IETF RAP WG"
          CONTACT-INFO "
                        Walter Weiss
                        Ellacoya Networks
                        7 Henry Clay Drive
                        Merrimack, NH 03054
                        Phone: 603-879-7364
                        E-mail: wweiss@ellacoya.com
                       "
          DESCRIPTION
                 "."
              "A PIB module containing the set of classes to
              be used with the access bind PIB framework classes
              to configure RSVP specific event handlers, and
              outsource RSVP events as they occur."

          ::= { pib 5 }    -- xxx to be assigned by IANA

      --
      -- The branch OIDs in the AccessBind PIB
      --

      contextClasses OBJECT IDENTIFIER ::= { ctxtDialupIfLoginLatEntry 3
          accessBindAppRsvpPib  1
      }

         ctxtDialupIfLoginLatPort  OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "."
      filterClasses OBJECT IDENTIFIER ::= { ctxtDialupIfLoginLatEntry 4
          accessBindAppRsvpPib  2
      }

      --
      -- The RSVP Filter table
      --
      rsvpFilterTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF RsvpFilterEntry
          PIB-ACCESS      install
          STATUS                current
          DESCRIPTION
              "RSVP specific filter table."

          ::= { filterClasses 1 }

      rsvpFilterEntry OBJECT-TYPE
          SYNTAX  RsvpFilterEntry
          STATUS  current
          DESCRIPTION
              " RSVP specific filter table entry."

          PIB-INDEX { rsvpFilterId }
          UNIQUENESS { }

          ::= { rsvpFilterTable 1 }

      RsvpFilterEntry ::= SEQUENCE {
          rsvpFilterId                          InstanceId,
          rsvpFilterFlags                       OCTET STRING,
          rsvpFilterSendTTL                     Unsigned32,
          rsvpFilterDClassDscp          Integer32,
          rsvpFilterSessionDestAddrType InetAddressType,
          rsvpFilterSessionDestAddr     InetAddress,
          rsvpFilterSessionDestAddrMask Unsigned32,
          rsvpFilterSessionProtocol     Integer32,
          rsvpFilterSessionDestPort     Unsigned32,
          rsvpFilterSessionSrcAddrType  InetAddressType,
          rsvpFilterSessionSrcAddr              InetAddress,
          rsvpFilterSessionSrcAddrMask  Unsigned32,
          rsvpFilterSessionSrcPort              Unsigned32,
          rsvpFilterStyleValue          OCTET STRING
      }

      rsvpFilterId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { rsvpFilterEntry 1 }

      rsvpFilterFlags OBJECT-TYPE
          SYNTAX       OCTET STRING
          STATUS       current
          DESCRIPTION
              "The Flags carried in the RSVP header. Currently all
              these flags should be set to zero."

          ::= { rsvpFilterEntry 2 }

      rsvpFilterSendTTL OBJECT-TYPE
          SYNTAX       Unsigned32 (0..255)
          STATUS       current
          DESCRIPTION
              "The IP TTL value with which the message was sent."

          ::= { rsvpFilterEntry 3 }

      rsvpFilterDClassDscp OBJECT-TYPE
          SYNTAX       Integer32 (-1| 0..63)
          STATUS       current
          DESCRIPTION
              "The DClass dscp value."

          ::= { rsvpFilterEntry 4 }

      rsvpFilterSessionDestAddrType OBJECT-TYPE
          SYNTAX       InetAddressType
          STATUS       current
          DESCRIPTION
              "The address type enumeration value [INETADDR] to
              specify the type of the destination IP address."

          ::= { rsvpFilterEntry 5 }

      rsvpFilterSessionDestAddr OBJECT-TYPE
          SYNTAX       InetAddress
          STATUS       current
          DESCRIPTION
              "The destination IP address."

          ::= { rsvpFilterEntry 6 }

      rsvpFilterSessionDestAddrMask OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The length of a mask for the matching of the
              destination IP address.."

          ::= { rsvpFilterEntry 7 }

      rsvpFilterSessionProtocol OBJECT-TYPE
          SYNTAX       Integer32 (-1 | 0..255)
          STATUS       current
          DESCRIPTION
              "The IP protocol to match against the packet's
              protocol. A value of -1 means match all."
          ::= { rsvpFilterEntry 8 }

      rsvpFilterSessionDestPort OBJECT-TYPE
          SYNTAX       Unsigned32 (0..65535)
          STATUS       current
          DESCRIPTION
              "The packet's Layer 4 destination port."

          ::= { rsvpFilterEntry 9 }

      rsvpFilterSessionSrcAddrType OBJECT-TYPE
          SYNTAX       InetAddressType
          STATUS       current
          DESCRIPTION
              "The address type enumeration value [INETADDR] to
              specify the type of the source IP address."

          ::= { rsvpFilterEntry 10 }

      rsvpFilterSessionSrcAddr OBJECT-TYPE
          SYNTAX       InetAddress
          STATUS       current
          DESCRIPTION
              "The source IP address."

          ::= { rsvpFilterEntry 11 }

      rsvpFilterSessionSrcAddrMask OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The length of a mask for the matching of the source
              IP address."

          ::= { rsvpFilterEntry 12 }

      rsvpFilterSessionSrcPort OBJECT-TYPE
          SYNTAX       Unsigned32 (0..65535)
          STATUS       current
          DESCRIPTION
              "The packet's Layer 4 source port."

          ::= { rsvpFilterEntry 13 }

      rsvpFilterStyleValue OBJECT-TYPE
          SYNTAX       OCTET STRING
          STATUS       current
          DESCRIPTION
              "The RSVP packet's Style value."

          ::= { rsvpFilterEntry 14 }
      --
      -- RSVP Common Context Data
      --

      ctxtRsvpTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpEntry
          PIB-ACCESS      notify
          STATUS                current
          DESCRIPTION
              ""

          ::= { contextClasses 8 1 }

      ctxtRsvpEntry OBJECT-TYPE
          SYNTAX  CtxtRsvpEntry
          STATUS  current
          DESCRIPTION
              ""

          PIB-INDEX { ctxtRsvpId }
          UNIQUENESS { }

          ::= { ctxtRsvpTable 1 }

      CtxtRsvpEntry ::= SEQUENCE {
          ctxtRsvpId                    InstanceId,
                ctxtRsvpMsgType         INTEGER,
          ctxtRsvpFlags                 OCTET STRING,
          ctxtRsvpSendTTL               Unsigned32,
          ctxtRsvpInIntfId              Unsigned32,
          ctxtRsvpInIntfAddrType        InetAddressType,
          ctxtRsvpInIntfAddr            InetAddress,
          ctxtRsvpOutIntfId             Unsigned32,
          ctxtRsvpOutIntfAddrType       InetAddressType,
          ctxtRsvpOutIntfAddr           InetAddress
      }

      ctxtRsvpId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { ctxtRsvpEntry 1 }

      ctxtRsvpMsgType OBJECT-TYPE
          SYNTAX       INTEGER {
                                 Path (1),
                                 PathErr (2),
                                 Resv (3),
                                 ResvErr (4)
          }
          STATUS       current
          DESCRIPTION
              "The RSVP message type."

          ::= { ctxtRsvpEntry 2 }

      ctxtRsvpFlags OBJECT-TYPE
          SYNTAX       OCTET STRING
          STATUS       current
          DESCRIPTION
              "The RSVP flags contained in the message header.
              They are currently undefined and should be set to
              zero."

          ::= { ctxtRsvpEntry 3 }

      ctxtRsvpSendTTL OBJECT-TYPE
          SYNTAX       Unsigned32 (0..255)
          STATUS       current
          DESCRIPTION
              "The IP TTL value."

          ::= { ctxtRsvpEntry 4 }

      ctxtRsvpInIntfId OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The Interface Id."

          ::= { ctxtRsvpEntry 5 }

      ctxtRsvpInIntfAddrType OBJECT-TYPE
          SYNTAX       InetAddressType
          STATUS       current
          DESCRIPTION
              "The address type enumeration value [INETADDR] to
              specify the type of the In Interface IP address."

          ::= { ctxtRsvpEntry 6 }

      ctxtRsvpInIntfAddr OBJECT-TYPE
          SYNTAX       InetAddress
          STATUS       current
          DESCRIPTION
              "The In Interface IP address."

          ::= { ctxtRsvpEntry 7 }

      ctxtRsvpOutIntfId OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The Out Interface Id."

          ::= { ctxtRsvpEntry 8 }

      ctxtRsvpOutIntfAddrType OBJECT-TYPE
          SYNTAX       InetAddressType
          STATUS       current
          DESCRIPTION
              "The address type enumeration value [INETADDR] to
              specify the type of the Out Interface IP address."

          ::= { ctxtRsvpEntry 9 }

      ctxtRsvpOutIntfAddr OBJECT-TYPE
          SYNTAX       InetAddress
          STATUS       current
          DESCRIPTION
              "The Out Interface IP address."

          ::= { ctxtRsvpEntry 10 }

      --
      -- RSVP Path Context Data
      --

      ctxtRsvpPathTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpPathEntry
          PIB-ACCESS      notify
          STATUS                current
          DESCRIPTION
              ""

          ::= { contextClasses 9 2 }

      ctxtRsvpPathEntry OBJECT-TYPE
          SYNTAX  CtxtRsvpPathEntry
          STATUS  current
          DESCRIPTION
              ""

          PIB-INDEX { ctxtRsvpPathId }
          UNIQUENESS { }

          ::= { ctxtRsvpPathTable 1 }

      CtxtRsvpPathEntry ::= SEQUENCE {
             ctxtRsvpPathId             InstanceId,
             ctxtRsvpPathTokenRate      Unsigned32
      }

      ctxtRsvpPathId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { ctxtRsvpPathEntry 1 }

      ctxtRsvpPathTokenRate OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The token bucket rate for the TSPEC."

          ::= { ctxtRsvpPathEntry 2 }

      --
      -- RSVP PathErr Context Data
      --

      ctxtRsvpPathErrTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpPathErrEntry
          PIB-ACCESS      notify
          STATUS                current
          DESCRIPTION
              ""

          ::= { contextClasses 10 3 }

      ctxtRsvpPathErrEntry OBJECT-TYPE
          SYNTAX  CtxtRsvpPathErrEntry
          STATUS  current
          DESCRIPTION
              ""

          PIB-INDEX { ctxtRsvpPathErrId }
          UNIQUENESS { }

          ::= { ctxtRsvpPathErrTable 1 }

      CtxtRsvpPathErrEntry ::= SEQUENCE {
             ctxtRsvpPathErrId          InstanceId,
          ctxtRsvpPathErrTokenRate      Unsigned32,
          ctxtRsvpPathErrErrorAddrType  InetAddressType,
          ctxtRsvpPathErrErrorAddr      InetAddress,
          ctxtRsvpPathErrErrorCode      Unsigned32,
          ctxtRsvpPathErrErrorValue     Unsigned32
      }

      ctxtRsvpPathErrId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { ctxtRsvpPathErrEntry 1 }

      ctxtRsvpPathErrTokenRate OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The token bucket rate for the TSPEC."

          ::= { ctxtRsvpPathErrEntry 2 }

      ctxtRsvpPathErrErrorAddrType OBJECT-TYPE
          SYNTAX       InetAddressType
          STATUS       current
          DESCRIPTION
              "The address type IP address in error."

          ::= { ctxtRsvpPathErrEntry 3 }

      ctxtRsvpPathErrErrorAddr OBJECT-TYPE
          SYNTAX       InetAddress
          STATUS       current
          DESCRIPTION
              "The Error IP address."

          ::= { ctxtRsvpPathErrEntry 4 }

      ctxtRsvpPathErrErrorCode OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The RSVP error code."

          ::= { ctxtRsvpPathErrEntry 5 }

      ctxtRsvpPathErrErrorValue OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The RSVP error value."

          ::= { ctxtRsvpPathErrEntry 6 }

      --
      -- RSVP Resv Context Data
      --

      ctxtRsvpResvTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpResvEntry
          PIB-ACCESS      notify
          STATUS                current
          DESCRIPTION
              ""

          ::= { contextClasses 11 4 }

      ctxtRsvpResvEntry OBJECT-TYPE
          SYNTAX  CtxtRsvpResvEntry
          STATUS  current
          DESCRIPTION
              ""

          PIB-INDEX { ctxtRsvpResvId }
          UNIQUENESS { }

          ::= { ctxtRsvpResvTable 1 }

      CtxtRsvpResvEntry ::= SEQUENCE {
             ctxtRsvpResvId     InstanceId,
             ctxtRsvpResvFSpecGrp       TagReferenceId,
             ctxtRsvpResvSvcType        INTEGER,
             ctxtRsvpResvTokenRate      Unsigned32
      }

      ctxtRsvpResvId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { ctxtRsvpResvEntry 1 }

      ctxtRsvpResvFSpecGrp OBJECT-TYPE
          SYNTAX       TagReferenceId
          PIB-TAG { ctxtRsvpFilterSpecTagId }
          STATUS       current
          DESCRIPTION
              "Identifies a group of Filter Spec entries."

          ::= { ctxtRsvpResvEntry 2 }

      ctxtRsvpResvSvcType OBJECT-TYPE
          SYNTAX       INTEGER {
                                 Controlled_Load(1),
                                 Guaranteed(2)
                             }
          STATUS       current
          DESCRIPTION
              "An enum describing the type of service."

          ::= { ctxtRsvpResvEntry 3 ctxtRsvpResvEntry 3 }

      ctxtRsvpResvTokenRate OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The token bucket rate for the TSPEC."

          ::= { ctxtRsvpResvEntry 4 }

      --
      -- RSVP ResvErr Context Data
      --

      ctxtRsvpResvErrTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpResvErrEntry
          PIB-ACCESS      notify
          STATUS                current
          DESCRIPTION
              ""

          ::= { contextClasses 5 }

      ctxtRsvpResvErrEntry OBJECT-TYPE
          SYNTAX  CtxtRsvpResvErrEntry
          STATUS  current
          DESCRIPTION
              ""

          PIB-INDEX { ctxtRsvpResvErrId }
          UNIQUENESS { }

          ::= { ctxtRsvpResvErrTable 1 }

      CtxtRsvpResvErrEntry ::= SEQUENCE {
          ctxtRsvpResvErrId                     InstanceId,
          ctxtRsvpResvErrFSpecGrp       TagReferenceId,
          ctxtRsvpResvErrSvcType                INTEGER,
          ctxtRsvpResvErrTokenRate              Unsigned32,
          ctxtRsvpResvErrErrorAddrType  InetAddressType,
          ctxtRsvpResvErrErrorAddr              InetAddress,
          ctxtRsvpResvErrErrorCode      Unsigned32,
          ctxtRsvpResvErrErrorValue     Unsigned32
      }

      ctxtRsvpResvErrId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { ctxtRsvpResvErrEntry 1 }

      ctxtRsvpResvErrFSpecGrp OBJECT-TYPE
          SYNTAX       TagReferenceId
          PIB-TAG { ctxtRsvpFilterSpecTagId }
          STATUS       current
          DESCRIPTION
              "Identifies a group of Filter Spec entries."

          ::= { ctxtRsvpResvErrEntry 2 }

      ctxtRsvpResvErrSvcType OBJECT-TYPE
          SYNTAX       INTEGER {
                                 Controlled_Load(1),
                                 Guaranteed(2)
                             }
          STATUS       current
          DESCRIPTION
              "An enum describing the type of service."

          ::= { ctxtRsvpResvErrEntry 3 }

      ctxtRsvpResvErrTokenRate OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The token bucket rate for the TSPEC."

          ::= { ctxtRsvpResvErrEntry 4 }

      ctxtRsvpResvErrErrorAddrType OBJECT-TYPE
          SYNTAX       InetAddressType
          STATUS       current
          DESCRIPTION
              "The address type IP address in error."

          ::= { ctxtRsvpResvErrEntry 5 }

      ctxtRsvpResvErrErrorAddr OBJECT-TYPE
          SYNTAX       InetAddress
          STATUS       current
          DESCRIPTION
              "The Error IP address."

          ::= { ctxtRsvpResvErrEntry 6 }

      ctxtRsvpResvErrErrorCode OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The RSVP error code."

          ::= { ctxtRsvpResvErrEntry 7 }

   ctxtRsvpResvTokenRate

      ctxtRsvpResvErrErrorValue OBJECT-TYPE
          SYNTAX       Unsigned32
          STATUS       current
          DESCRIPTION
              "The token bucket rate for the TSPEC." RSVP error value."

          ::= { ctxtRsvpResvEntry 4 ctxtRsvpResvErrEntry 8 }

      --
      -- RSVP ResvErr Filter Spec Context Data
      --
   ctxtRsvpResvErrTable

      ctxtRsvpFilterSpecTable OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpResvErrEntry CtxtRsvpFilterSpecEntry
          PIB-ACCESS      notify
          STATUS                current
          DESCRIPTION
              ""

          ::= { contextClasses 12 6 }
   ctxtRsvpResvErrEntry

      ctxtRsvpFilterSpecEntry OBJECT-TYPE
          SYNTAX  CtxtRsvpResvErrEntry  CtxtRsvpFilterSpecEntry
          STATUS  current
          DESCRIPTION
              ""

          PIB-INDEX { ctxtRsvpResvErrId ctxtRsvpFilterSpecId }
          UNIQUENESS { }

          ::= { ctxtRsvpResvErrTable ctxtRsvpFilterSpecTable 1 }

   CtxtRsvpResvErrEntry ::=

      CtxtRsvpFilterSpecEntry::= SEQUENCE {
                ctxtRsvpResvErrId
          ctxtRsvpFilterSpecId          InstanceId,
                ctxtRsvpResvErrFSpecGrp         TagReferenceId,
                ctxtRsvpResvErrSvcType          INTEGER,
                ctxtRsvpResvErrTokenRate        Unsigned32,
                ctxtRsvpResvErrErrorAddrType
          ctxtRsvpFilterSpecTagId       TagId,
          ctxtRsvpFilterSpecAddrType    InetAddressType,
                ctxtRsvpResvErrErrorAddr
          ctxtRsvpFilterSpecAddr                InetAddress,
                ctxtRsvpResvErrErrorCode        Unsigned32,
                ctxtRsvpResvErrErrorValue
          ctxtRsvpFilterSpecPort                Unsigned32
      }

   ctxtRsvpResvErrId

      ctxtRsvpFilterSpecId OBJECT-TYPE
          SYNTAX       InstanceId
          STATUS       current
          DESCRIPTION
              "An arbitrary integer index that uniquely identifies
              an instance of the class."

          ::= { ctxtRsvpResvErrEntry ctxtRsvpFilterSpecEntry 1 }

   ctxtRsvpResvErrFSpecGrp

      ctxtRsvpFilterSpecTagId OBJECT-TYPE
          SYNTAX       TagReferenceId
       PIB-TAG { ctxtRsvpFilterSpecTagId }       TagId
          STATUS       current
          DESCRIPTION
              "Identifies a the group of Filter Spec entries." PRIs that this
              PRI belongs to."

          ::= { ctxtRsvpResvErrEntry ctxtRsvpFilterSpecEntry 2 }

   ctxtRsvpResvErrSvcType
      ctxtRsvpFilterSpecAddrType OBJECT-TYPE
          SYNTAX       INTEGER {
                                        Controlled_Load(1),
                                        Guaranteed(2)
                                }       InetAddressType
          STATUS       current
          DESCRIPTION
          "An enum describing
              "The address type enumeration value [INETADDR] to
              specify the type of service." the IP address."

          ::= { ctxtRsvpResvErrEntry ctxtRsvpFilterSpecEntry 3 }

   ctxtRsvpResvErrTokenRate

      ctxtRsvpFilterSpecAddr OBJECT-TYPE
          SYNTAX       Unsigned32       InetAddress
          STATUS       current
          DESCRIPTION
              "The token bucket rate for the TSPEC." Filter Spec IP address."

          ::= { ctxtRsvpResvErrEntry ctxtRsvpFilterSpecEntry 4 }

   ctxtRsvpResvErrErrorAddrType

      ctxtRsvpFilterSpecPort OBJECT-TYPE
          SYNTAX       InetAddressType       Unsigned32 (0..65535)
          STATUS       current
          DESCRIPTION
              "The address type IP address packet's Layer 4 destination port."

          ::= { ctxtRsvpFilterSpecEntry 5 }

   END

12. Application Specific Dialup Handling PIB Module

   --
   -- The AccessBind Dialup Application PIB Module
   --

   ACCESSBIND-APP-DIALUP-PIB PIB-DEFINITIONS ::= BEGIN

      IMPORTS
          Unsigned32, Integer32, MODULE-IDENTITY,
          MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
                  FROM COPS-PR-SPPI
          InstanceId
                  FROM COPS-PR-SPPI-TC
          InetAddress, InetAddressType
                  FROM INET-ADDRESS-MIB;

      accessBindAppDialupPib  MODULE-IDENTITY
          SUBJECT-CATEGORIES { all }
          LAST-UPDATED "200211032002Z"
          ORGANIZATION "IETF RAP WG"
          CONTACT-INFO "
                        Walter Weiss
                        Ellacoya Networks
                        7 Henry Clay Drive
                        Merrimack, NH 03054
                        Phone: 603-879-7364
                        E-mail: wweiss@ellacoya.com
                       "
          DESCRIPTION
              "A PIB module containing the set of classes to
              be used with the access bind PIB framework classes
              to configure dialup event handlers, and outsource
              dialup events as they occur."

          ::= { pib 5 }    -- xxx to be assigned by IANA

      --
      -- The branch OIDs in error." the AccessBind PIB
      --

      contextClasses OBJECT IDENTIFIER ::= { ctxtRsvpResvErrEntry 5
          accessBindAppDialupPib  1
      }

   ctxtRsvpResvErrErrorAddr

      --
      -- CtxtDialupInterface Table
      --

      ctxtDialupInterfaceTable OBJECT-TYPE
          SYNTAX       InetAddress         SEQUENCE OF CtxtDialupInterfaceEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
          "The Error IP address."
              "Dialup Interface context data."

          ::= { ctxtRsvpResvErrEntry 6 contextClasses 1 }

   ctxtRsvpResvErrErrorCode

      ctxtDialupInterfaceEntry OBJECT-TYPE
          SYNTAX       Unsigned32         CtxtDialupInterfaceEntry
          STATUS         current
          DESCRIPTION
          "The RSVP error code."
              "Entry oid of the ctxtDialupInterfaceTable PRC."

          PIB-INDEX { ctxtDialupInterfaceId }
          UNIQUENESS { }

          ::= { ctxtRsvpResvErrEntry 7 ctxtDialupInterfaceTable 1 }

   ctxtRsvpResvErrErrorValue

      CtxtDialupInterfaceEntry::= SEQUENCE {
          ctxtDialupInterfaceId                InstanceId,
          ctxtDialupInterfaceNASPort           Integer32,
          ctxtDialupInterfaceNASPortId         OCTET STRING,
          ctxtDialupInterfaceNASPortType       INTEGER,
          ctxtDialupInterfaceCalledStationId   OCTET STRING,
          ctxtDialupInterfaceCallingStationId  OCTET STRING,
          ctxtDialupInterfaceConnectInfo       OCTET STRING
      }

      ctxtDialupInterfaceId  OBJECT-TYPE
          SYNTAX       Unsigned32         InstanceId
          STATUS         current
          DESCRIPTION
          "The RSVP error value."
              "An index to uniquely identify an instance of this
              provisioning class."

          ::= { ctxtRsvpResvErrEntry 8 ctxtDialupInterfaceEntry 1 }

   --
   -- RSVP Filter Spec Context Data
   --

   ctxtRsvpFilterSpecTable

      ctxtDialupInterfaceNASPort  OBJECT-TYPE
          SYNTAX  SEQUENCE OF CtxtRsvpFilterSpecEntry
           PIB-ACCESS      notify         Integer32
          STATUS         current
          DESCRIPTION
                   ""
              "This Attribute indicates the physical port number
              of the NAS which is authenticating the user.  It is
              only used in Access-Request packets.  Note that this
              is using 'port' in its sense of a physical
              connection on the NAS, not in the sense of a TCP or
              UDP port number."

          ::= { contextClasses 13 ctxtDialupInterfaceEntry 2 }

   ctxtRsvpFilterSpecEntry

      ctxtDialupInterfaceNASPortId  OBJECT-TYPE
          SYNTAX  CtxtRsvpFilterSpecEntry         OCTET STRING
          STATUS         current
          DESCRIPTION
                   ""

           PIB-INDEX { ctxtRsvpFilterSpecId }
           UNIQUENESS { }
              "This Attribute contains a text string which
              identifies the port of the NAS which is
              authenticating the user. It is only used in
              Access-Request and Accounting-Request packets.  Note
              that this is using 'port' in its sense of a physical
              connection on the NAS, not in the sense of a TCP or
              UDP port number. "

          ::= { ctxtRsvpFilterSpecTable 1 }

   CtxtRsvpFilterSpecEntry::= SEQUENCE {
                ctxtRsvpFilterSpecId            InstanceId,
                ctxtRsvpFilterSpecTagId         TagId,
                ctxtRsvpFilterSpecAddrType      InetAddressType,
                ctxtRsvpFilterSpecAddr          InetAddress,
                ctxtRsvpFilterSpecPort          Unsigned32 { ctxtDialupInterfaceEntry 3 }

   ctxtRsvpFilterSpecId

      ctxtDialupInterfaceNASPortType  OBJECT-TYPE
          SYNTAX       InstanceId  INTEGER {
                      radAsync(0),
                      radSync(1),
                      radIsdnSync(2),
                      radIsdnAsyncV120(3),
                      radIsdnAsyncV110(4),
                      radVirtual(5),
                      radPIAFS(6),
                      radHdlcClearChannel(7),
                      radX25(8),
                      radX75(9),
                      radG3Fax(10),
                      radSDSL(11),
                      radAdslCAP(12),
                      radAdslDMT(13),
                      radIdsl(14),
                      radEthernet(15),
                      radXdsl(16),
                      radCable(17),
                      radWirelessOther(18),
                      radWirelessIEEE80211(19)
          }
          STATUS         current
          DESCRIPTION
          "An arbitrary integer index that uniquely identifies
              "This Attribute indicates the type of the physical
              port of the NAS which is authenticating the user.
              It can be used instead of or in addition to the
              radNasPort (5) attribute.  It is only used in
              Access-Request packets. Either radNasPort (5) or
              radNasPortType or both SHOULD be present in an
          instance
              Access-Request packet, if the NAS differentiates
              among its ports.

              A value of 'radAsync(0)' indicates Async.

              A value of 'radSync(1)' indicates Sync.

              A value of 'radIsdnSync(2)' indicates ISDN Sync.

              A value of 'radIsdnAsyncV120(3)' indicates ISDN
              Async V.120.

              A value of 'radIsdnAsyncV110(4)' indicates ISDN
              Async V.110.

              A value of 'radVirtual(5)' indicates Virtual.
              Virtual refers to a connection to the NAS via some
              transport protocol, instead of through a physical
              port. For example, if a user telnetted into a NAS to
              authenticate himself as an Outbound-User, the
              Access-Request might include radNasPortType =
              Virtual as a hint to the RADIUS server that the user
              was not on a physical port.

              A value of 'radPIAFS(6)' indicates PIAFS. PIAFS is a
              form of wireless ISDN commonly used in Japan, and
              stands for PHS (Personal Handyphone System) Internet
              Access Forum Standard (PIAFS).

              A value of 'radHdlcClearChannel(7)' indicates HDLC
              Clear Channel.

              A value of 'radX25(8)' indicates X.25.

              A value of 'radX75(9)' indicates X.75.

              A value of 'radG3Fax(10)' indicates G.3 Fax.

              A value of 'radSDSL(11)' indicates SDSL _ Symmetric
              DSL.

              A value of the class." 'radAdslCAP(12)' indicates ADSL-CAP -
              Asymmetric DSL, Carrierless Amplitude Phase
              Modulation.

              A value of 'radAdslDMT(13)' indicates ADSL-DMT -
              Asymmetric DSL, Discrete Multi-Tone.

              A value of 'radIdsl(14)' indicates IDSL _ ISDN
              Digital Subscriber Line.

              A value of 'radEthernet(15)' indicates Ethernet.

              A value of 'radXdsl(16)' indicates xDSL - Digital
              Subscriber Line of unknown type.

              A value of 'radCable(17)' indicates Cable.

              A value of 'radWirelessOther(18)' indicates
              Wireless - Other.

              A value of 'radWirelessIEEE80211(19)' indicates
              Wireless - IEEE 802.11."
          ::= { ctxtRsvpFilterSpecEntry 1 ctxtDialupInterfaceEntry 4 }

   ctxtRsvpFilterSpecTagId

      ctxtDialupInterfaceCalledStationId  OBJECT-TYPE
          SYNTAX       TagId         OCTET STRING
          STATUS         current
          DESCRIPTION
          "Identifies
              "This Attribute allows the group of Filter Spec PRIs NAS to send in the
              Access-Request packet the phone number that the user
              called, using Dialed Number Identification (DNIS) or
              similar technology.  Note that this PRI
          belongs to." may be different
              from the phone number the call comes in on.  It is
              only used in Access-Request packets."

          ::= { ctxtRsvpFilterSpecEntry 2 ctxtDialupInterfaceEntry 5 }

   ctxtRsvpFilterSpecAddrType

      ctxtDialupInterfaceCallingStationId  OBJECT-TYPE
          SYNTAX       InetAddressType         OCTET STRING
          STATUS         current
          DESCRIPTION
          "The address type enumeration value [INETADDR]
              "This Attribute allows the NAS to specify send in the
          type of
              Access-Request packet the IP address."
       ::= { ctxtRsvpFilterSpecEntry 3 }

   ctxtRsvpFilterSpecAddr OBJECT-TYPE
       SYNTAX       InetAddress
       STATUS       current
       DESCRIPTION
          "The Filter Spec IP address."
       ::= { ctxtRsvpFilterSpecEntry 4 }

   ctxtRsvpFilterSpecPort OBJECT-TYPE
       SYNTAX       Unsigned32 (0..65535)
       STATUS       current
       DESCRIPTION
          "The packet's Layer 4 destination port." phone number that the user
              is calling from, using Dialed Number Identification
              (DNIS) or similar technology.  Note that this may be
              different from the phone number called.  It is only
              used in Access-Request packets."

          ::= { ctxtRsvpFilterSpecEntry 5 }

         --
         -- Authentication Extension Tables
         --
         --
         -- AuthExtensions Base Table
         --

         authExtTable ctxtDialupInterfaceEntry 6 }

      ctxtDialupInterfaceConnectInfo  OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthExtEntry
             PIB-ACCESS     install-notify         OCTET STRING
          STATUS         current
          DESCRIPTION
              "This is an abstract PRC. This PRC can be extended by
              authentication PRCs that contain attributes specific to
              that authentication protocol. An instance of the extended
              class is created by Attribute allows the PEP and sent NAS to the PDP. The PDP
              may send information back to in the PEP or may uses
              Access-Request packet the
              information to authenticate phone number that the PEP's access request.
              This  PRC itself should not be instantiated.

              This call
              came from, using Automatic Number Identification
              (ANI) or similar technology.  It is a 'transient' class. Its instances are temporary
              and are deleted by the PEP after a certain time/event.
              Thus it must not be referred to by the server." only used in
              Access-Request packets."

          ::= { authClasses 1 ctxtDialupInterfaceEntry 7 }

         authExtEntry

      ---
      --- CtxtDialupInterfaceFramedProtocol Table
      ---

      ctxtDialupIfFramedProtocolTable OBJECT-TYPE
          SYNTAX         AuthExtEntry         SEQUENCE OF
                             CtxtDialupIfFramedProtocolEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
              "."

          ::= { contextClasses 2 }

      ctxtDialupIfFramedProtocolEntry OBJECT-TYPE
          SYNTAX         CtxtDialupIfFramedProtocolEntry
          STATUS         current
          DESCRIPTION
              "Entry oid for of the AuthExtTable ctxtDialupIfFramedProtocolTable
              PRC."

          PIB-INDEX { authExtId ctxtDialupIfFramedProtocolId }
          UNIQUENESS { }

          ::= { authExtTable ctxtDialupIfFramedProtocolTable 1 }

         AuthExtEntry

      CtxtDialupIfFramedProtocolEntry ::= SEQUENCE {
                 authExtId                InstanceId
          ctxtDialupIfFramedProtocolId           InstanceId,
          ctxtDialupIfFramedProtocolProt         INTEGER,
          ctxtDialupIfFramedProtocolMTU          Integer32,
          ctxtDialupIfFramedProtocolCompression  INTEGER,
          ctxtDialupIfFramedProtocolPortLimit    Unsigned32,
          ctxtDialupIfFramedProtocolIpAddress    InetAddress,
          ctxtDialupIfFramedProtocolIpNetmask    InetAddress
      }

         authExtId

      ctxtDialupIfFramedProtocolId OBJECT-TYPE
          SYNTAX         InstanceId
          STATUS         current
          DESCRIPTION
              "An index to uniquely identify an instance of the
                  entended this
              provisioning class."

          ::= { authExtEntry ctxtDialupIfFramedProtocolEntry 1 }

         --
         -- UserAuthExt Table
         --
         userAuthExtTable

      ctxtDialupIfFramedProtocolProt  OBJECT-TYPE
          SYNTAX         SEQUENCE OF UserAuthExtEntry
             PIB-ACCESS     notify  INTEGER {
                      radPPP(1),
                      radSLIP(2),
                      radARAP(3),
                      radGandalf(4),
                      radXylogics(5),
                      radX75Synchronous(6)
          }
          STATUS         current
          DESCRIPTION
              "This is a concrete PRC used to contain user
                 authentication fields. This PRC extends Attribute indicates the base PRC
                 authExtEntry." framing to be used for
               framed access. It MAY be used in both Access-
               Request and Access-Accept packets.

               A value of 'radPPP(1)' represents PPP.

               A value of 'radSLIP(2)' represents SLIP.

               A value of 'radARAP(3)' represents AppleTalk Remote
               Access Protocol (ARAP).

               A value of 'radGandalf(4)' represents Gandalf
               proprietary SingleLink/MultiLink protocol.

               A value of 'radXylogics(5)' represents Xylogics
               proprietary IPX/SLIP.

               A value of 'radX75Synchronous(6)' represents X.75
               Synchronous."

          ::= { authClasses ctxtDialupIfFramedProtocolEntry 2 }

         userAuthExtEntry

      ctxtDialupIfFramedProtocolMTU  OBJECT-TYPE
          SYNTAX         UserAuthExtEntry         Integer32
          STATUS         current
          DESCRIPTION
               "Entry for
              "This Attribute indicates the UserAuthExtTable PRC. InstanceId's Maximum Transmission
              Unit to be configured for
                this extended PRC are assigned the user, when it is not
              negotiated by some other means (such as PPP).  It
              MAY be used in Access-Accept packets.  It MAY be
              used in an Access-Request packet as a hint by the base PRC AuthExt
                [SPPI]."

             EXTENDS { authExtEntry }
             UNIQUENESS { }

             ::= { userAuthExtTable 1 }

         UserAuthExtEntry
              NAS to the server that it would prefer that value,
              but the server is not required to honor the hint."

          ::= SEQUENCE {
                 userAuthExtRealm      OCTET STRING,
                 userAuthExtUsername   OCTET STRING ctxtDialupIfFramedProtocolEntry 3 }

         userAuthExtRealm

      ctxtDialupIfFramedProtocolCompression  OBJECT-TYPE
          SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "user realm octet string."

             ::=         INTEGER { userAuthExtEntry 1
                             radNone(0),
                             radVJ(1),
                             radIPXheader(2),
                             radStacLZS(3)
          }

         userAuthExtUsername OBJECT-TYPE
             SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
                 "Username octet string."
              "This Attribute indicates a compression protocol to
              be used for the link.  It MAY be used in Access-
              Accept packets.  It MAY be used in an Access-Request
              packet as a hint to the server that the NAS would
              prefer to use that compression, but the server is
              not required to honor the hint.

              More than one compression protocol Attribute MAY be
              sent. It is the responsibility of the NAS to apply
              the proper compression protocol to appropriate link
              traffic.

              A value of 'radNone(0)' indicates None.

              A value of 'radVJ(1)' indicates VJ TCP/IP header
              compression.

              A value of 'radIPXheader(2)' indicates IPX header
              compression.

              A value of 'radStacLZS(3)' indicates Stac-LZS
              compression."

          ::= { userAuthExtEntry 2 ctxtDialupIfFramedProtocolEntry 4 }

         --
         -- AuthChapExt Table
         --
         authChapExtTable

      ctxtDialupIfFramedProtocolPortLimit  OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthChapExtEntry
             PIB-ACCESS     notify         Unsigned32
          STATUS         current
          DESCRIPTION
              "This Attribute sets the maximum number of ports to
              be provided to the user by the NAS.  This Attribute
              MAY be sent by the server to the client in an
              Access-Accept packet.  It is intended for use in
              conjunction with Multilink PPP [10] or similar uses.
              It MAY also be sent by the NAS to the server as a concrete PRC used
              hint that that many ports are desired for use, but
              the server is not required to contain CHAP
               authentication fields. This PRC extends honor the PRC
               userAuthExtEntry." hint."

          ::= { authClasses 3 ctxtDialupIfFramedProtocolEntry 5 }

         authChapExtEntry

      ctxtDialupIfFramedProtocolIpAddress  OBJECT-TYPE
          SYNTAX         AuthChapExtEntry         InetAddress
          STATUS         current
          DESCRIPTION
              "Entry oid for
              "This Attribute indicates the AuthChapExtTable PRC. InstanceId's address to be
              configured for
               this extended PRC are assigned the user.  It MAY be used in Access-
              Accept packets. It MAY be used in an Access-Request
              packet as a hint by the base PRC [SPPI]."

             EXTENDS { userAuthExtEntry }
             UNIQUENESS { }

             ::= { authChapExtTable 1 }

         AuthChapExtEntry::= SEQUENCE {
                 authChapExtId        Unsigned32,
                 authChapExtChal      OCTET STRING,
                 authChapExtResp      OCTET STRING
         }

         authChapExtId OBJECT-TYPE
             SYNTAX         Unsigned32
             STATUS         current
             DESCRIPTION
                 "CHAP Id field." NAS to the server that it
              would prefer that address, but the server is not
              required to honor the hint."

          ::= { authChapExtEntry 1 ctxtDialupIfFramedProtocolEntry 6 }

         authChapExtChal

      ctxtDialupIfFramedProtocolIpNetmask  OBJECT-TYPE
          SYNTAX         OCTET STRING         InetAddress
          STATUS         current
          DESCRIPTION
               "CHAP Challenge octet string. The challenge
              "This Attribute indicates the IP netmask to be
              configured for the user when the user is generated a router to
              a network.  It MAY be used in Access-Accept packets.

              It MAY be used in an Access-Request packet as a hint
              by the PEP."

             ::= { authChapExtEntry 2 }

         authChapExtResp OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "CHAP Challenge Response octet string. The challenge
                 response is sent NAS to the PDP along with server that it would prefer that
              netmask, but the challenge." server is not required to honor the
              hint."

          ::= { authChapExtEntry 3 ctxtDialupIfFramedProtocolEntry 7 }

         --
         -- AuthPapExt

      ---
      --- CtxtDialupIfLoginService Table
         --

         authPapExtTable
      ---

      ctxtDialupIfLoginServiceTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthPapExtEntry CtxtDialupIfLoginServiceEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
                 "This is a concrete PRC used to contain PAP
                 authentication fields. This PRC extends the PRC
                 userAuthExtEntry."
              "Base class."

          ::= { authClasses 4 contextClasses 3 }

         authPapExtEntry

      ctxtDialupIfLoginServiceEntry OBJECT-TYPE
          SYNTAX         AuthPapExtEntry         CtxtDialupIfLoginServiceEntry
          STATUS         current
          DESCRIPTION
              "Entry oid for the AuthPapExtTable PRC. InstanceId's for
                this extended PRC are assigned by of the base PRC [SPPI]."

             EXTENDS ctxtDialupIfLoginServiceTable
              PRC."

          PIB-INDEX { userAuthExtEntry ctxtDialupIfLoginServiceId }
          UNIQUENESS { }

          ::= { authPapExtTable ctxtDialupIfLoginServiceTable 1 }

         AuthPapExtEntry::=

      CtxtDialupIfLoginServiceEntry::= SEQUENCE {
                 authPapExtPwd      OCTET STRING
         }

         authPapExtPwd OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "PAP password octet string."

           ::= { authPapExtEntry 1
          ctxtDialupIfLoginServiceId       InstanceId,
          ctxtDialupIfLoginServiceIpHost   InetAddress
      }

         --
         -- AuthExtResult Table
         --

         authExtResultTable

      ctxtDialupIfLoginServiceId OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthExtResultEntry
             PIB-ACCESS     install         InstanceId
          STATUS         current
          DESCRIPTION
                 "This is a concrete PRC used
              "An index to contain authentication
                 results. This PRC extends the base PRC authExtEntry."

             ::= { authClasses 5 }

         authExtResultEntry OBJECT-TYPE
             SYNTAX         AuthExtResultEntry
             STATUS         current
             DESCRIPTION
               "Entry for the authExtResultTable PRC. InstanceId's for uniquely identify an instance of this extended PRC are assigned by the base PRC AuthExt
                [SPPI]."

             EXTENDS { authExtEntry }
             UNIQUENESS { }
              provisioning class."

          ::= { authExtResultTable ctxtDialupIfLoginServiceEntry 1 }

         AuthExtResultEntry ::= SEQUENCE {
                 authExtResultSuccess           TruthValue
         }

         authExtResultSuccess

      ctxtDialupIfLoginServiceIpHost OBJECT-TYPE
          SYNTAX         TruthValue         InetAddress
          STATUS         current
          DESCRIPTION
                "Set to 'true' if authentication was successful, else
                false."
              "."

          ::= { authExtResultEntry 1 ctxtDialupIfLoginServiceEntry 2 }

         --
         -- AuthEapReqExt

      ---
      --- CtxtDialupIfLoginLat Table
         --

         authEapReqExtTable (Extends
      --- CtxtDialupIfLoginService)
      ---

      ctxtDialupIfLoginLatTable OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthEapReqExtEntry CtxtDialupIfLoginLatEntry
          PIB-ACCESS     notify
          STATUS         current
          DESCRIPTION
               "This is a concrete PRC used to contain EAP
               authentication fields. This PRC extends the base PRC
               authExtEntry. The PEP uses this PRC to send EAP messages
               to the PDP."
              "Extended class."

          ::= { authClasses 6 contextClasses 4 }

         authEapReqExtEntry

      ctxtDialupIfLoginLatEntry OBJECT-TYPE
          SYNTAX         AuthEapReqExtEntry         CtxtDialupIfLoginLatEntry
          STATUS         current
          DESCRIPTION
              "Entry oid for the authEapReqExtTable PRC. InstanceId's
                for this extended PRC are assigned by of the base PRC
                [SPPI]." ctxtDialupIfLoginLatTable PRC."
          EXTENDS { authExtEntry ctxtDialupIfLoginServiceEntry }
          UNIQUENESS { }

          ::= { authEapReqExtTable ctxtDialupIfLoginLatTable 1 }

         AuthEapReqExtEntry::=

      CtxtDialupIfLoginLatEntry::= SEQUENCE {
                 authEapReqExtSpecific
          ctxtDialupIfLoginLatService   OCTET STRING,
          ctxtDialupIfLoginLatNode      OCTET STRING,
          ctxtDialupIfLoginLatGroup     OCTET STRING,
          ctxtDialupIfLoginLatPort      OCTET STRING
      }

         authEapReqExtSpecific

      ctxtDialupIfLoginLatService  OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
                 "Opaque EAP Request octet string."
              "."

          ::= { authEapReqExtEntry ctxtDialupIfLoginLatEntry 1 }

         --
         -- AuthEapRespExt Table
         --

         authEapRespExtTable

      ctxtDialupIfLoginLatNode  OBJECT-TYPE
          SYNTAX         SEQUENCE OF AuthEapRespExtEntry
             PIB-ACCESS     install         OCTET STRING
          STATUS         current
          DESCRIPTION
                 "This is a concrete PRC used to contain EAP
                 authentication fields. This PRC extends the base PRC
                 authExtEntry. The PDP responds using this PRC for EAP
                 exchanges."
              "."

          ::= { authClasses 7 ctxtDialupIfLoginLatEntry 2 }

         authEapRespExtEntry

      ctxtDialupIfLoginLatGroup  OBJECT-TYPE
          SYNTAX         AuthEapRespExtEntry         OCTET STRING
          STATUS         current
          DESCRIPTION
               "Entry oid for the authEapRespExtTable PRC. InstanceId's
               for this extended PRC are assigned by the base PRC
               [SPPI]."

             EXTENDS { authExtEntry }
             UNIQUENESS { }
              "."

          ::= { authEapRespExtTable 1 }
         AuthEapRespExtEntry::= SEQUENCE {
                 authEapRespExtSpecific    OCTET STRING ctxtDialupIfLoginLatEntry 3 }

         authEapRespExtSpecific

      ctxtDialupIfLoginLatPort  OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
                 "Opaque EAP Response octet string."
              "."

          ::= { authEapRespExtEntry 1 ctxtDialupIfLoginLatEntry 4 }

      --
      -- conformance section tbd
      --

   END

9.

13. Security Considerations

   A COPS client-type implemented within the framework outlined in this
   document necessarily transmits sensitive authentication credentials
   between the PEP and the PDP. The COPS protocol provides optional
   message level security for authentication, replay protection, and
   message integrity for communications occurring between the PEP and
   the PDP by the use of the COPS Message Integrity Object [COPS].
   Additionally, COPS optionally reuses existing protocols for security
   such as IPSEC [IPSEC] or TLS to authenticate and secure COPS
   communications. Careful consideration should be given to using these
   mechanisms to reduce the probability of compromising authentication
   credentials. Furthermore, using these mechanisms cannot protect
   communication between an external authentication server and the PDP.
   So, when the PDP acts a proxy for an authentication server,
   consideration must be given to securing communications between the
   PDP and the authentication server as well. A discussion of
   applicable security techniques would be specific to any given
   authentication protocol and is outside the scope of this document.

10.

14. References

   [MODEL] Y. Bernet, S. Blake, A. Smith, D. Grossman, "An Informal
           Management Model for Diffserv Routers,"
           draft-ietf-diffserv-model-06.txt, February 2001. 2002.

   [DSPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C.
           Bell, A. Smith, F. Reichmeyer, "Differentiated
           Services Quality of Service Policy Information Base,"
            draft-ietf-diffserv-pib-05.txt, December
           draft-ietf-diffserv-pib-03.txt, March 2, 2001.

   [FWPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R.
           Sahita, A. Smith, F. Reichmeyer, "Framework _Framework Policy
           Information Base,"
            draft-ietf-rap-frameworkpib-07.txt, January 2002.
           draft-ietf-rap-frameworkpib-04.txt, March 1, 2001.

   [AUTH]  B. Lloyd, W. Simpson, "PPP _PPP Authentication Protocols," Protocols,_
           RFC 1334, October 1992.

   [CHAP]  W. Simpson, "PPP Challenge Handshake Authentication
           Protocol (CHAP)", RFC 1994, August 1996.

   [EAP]   L. Blunk, J. Vollbrecht, "PPP _PPP Extensible Authentication
           Protocol (EAP)", (EAP)_, RFC 2284, March 1998.

   [NAI]   B. Aboba, M. Beadles, "The _The Network Access Identifier," Identifier,_
           RFC 2486, January 1999.

   [IPSEC] R. Atkinson, "Security Architecture for the Internet
           Protocol", RFC 2401, August 1995.

   [COPS]  D. Durham, et al., "The COPS (Common Open Policy Service)
           Protocol", RFC 2748, January 2000.

   [COPSPR] K. Chan, et al., "COPS Usage for Policy Provisioning
            (COPS-PR)", RFC 3084, March 2001.

   [SPPI]   K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn,

   [RSVP]  R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy
            Provisioning Information", RFC 3159,August 2001.

11. Braden, et al., " Resource ReSerVation Protocol (RSVP) _
           Version 1 Functional Specification ", September 1997.

15. Author Information and Acknowledgments

   Walter Weiss
       Ellacoya Networks
       7 Henry Clay Drive
       Merrimack, NH 03054
       Phone: +1 603 879 7364
       E-mail: wweiss@ellacoya.com

   John Vollbrecht
       Interlink Networks, Inc.
       775 Technology Drive, Suite 200
       Ann Arbor, MI  48108
       Phone: +1 734 821 1205
       E-Mail: jrv@interlinknetworks.com

   David Spence
       Interlink Networks, Inc.
       775 Technology Drive, Suite 200
       Ann Arbor, MI  48108
       Phone: +1 734 821 1203
       E-Mail: dspence@interlinknetworks.com

   David Rago
       Interlink Networks, Inc.
       775 Technology Drive, Suite 200
       Ann Arbor, MI  48108
       Phone: +1 734 821 1241
       E-Mail: drago@interlinknetworks.com

   Freek Dijkstra
       Physics and Astronomy Department
       Utrecht University
       Princetonplein 5
       3584 CC Utrecht
       The Netherlands
       Phone: +31 30 2537724
       Email: F.Dijkstra@phys.uu.nl

   Cees de Laat
       Faculty of Science, Informatics Institute,
       University of Amsterdam
       Kruislaan 403
       1098 SJ Amsterdam
       The Netherlands
       Phone: +31 20 5257590
       E-Mail: delaat@science.uva.nl

   Leon Gommans
       Faculty of Science, Informatics Institute,
       University of Amsterdam
       Kruislaan 403
       1098 SJ Amsterdam
       Enterasys Networks EMEA,
       Kerkplein 24
       2841 XM Moordrecht
       The Netherlands
       Phone: +31 20 5257586 182 379278
       E-Mail: lgommans@science.uva.nl leon.gommans@enterasys.com

   Amol Kulkarni
       Intel
       2111 NE 25th Avenue
       Hillsboro, OR 97124
       Phone:  503.712.1168
       E-Mail: Amol.Kulkarni@intel.com

   Ravi Sahita
       Intel
       2111 NE 25th Avenue
       Hillsboro, OR 97124
       Phone:  503.712.1554
       E-Mail: Ravi.Sahita@intel.com

   Kwok Ho Chan
       Nortel Networks, Inc. Networks
       600 Technology Park Drive
       Billerica, MA 01821 USA
       Phone: +1 978 288 8175
       E-Mail: khchan@nortelnetworks.com