Internet Engineering Task Force                Walter Weiss
    RAP Working Group                              Ellacoya Networks
    Expiration: February October 2002                       John Vollbrecht
    draft-ietf-rap-access-bind-00.txt
    draft-ietf-rap-access-bind-01.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: 7/13/01 3/1/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].

Weiss et al.                                                  [Page 1]

   Status of this Memo................................................1
   Conventions used in this document..................................1
   Abstract...........................................................4
   1. Introduction....................................................4
   2. Paradigm for the Bind PIB.......................................6
   2.1 Accessor Concepts..............................................6 Event Handler Concepts.........................................6
   2.1.1 Example - Ethernet IP Address Authorization..................9
   2.2 Accessor Management Paradigm..................................10
   2.3.
   2.2. Context Data.................................................16
   2.4. Data.................................................10
   2.3. Policy Distribution and Management...........................17
   2.5. Management...........................11
   2.4. Interactions with DiffServ model.............................18
   2.6. model.............................11
   2.5. Interactions with RSVP model.................................19 model.................................12
   3. Supporting various client Authentication Protocols.............19 Protocols.............14
   3.1. Provisioning.................................................14
   3.2. EAP Authentication...........................................20
   3.1.1. Authentication...........................................15
   3.2.1. EAP Message sequence.......................................20
   3.1.2. AuthEapReXXExt sequence.......................................15
   3.2.2. AuthEapReqExt and AuthEapRespExt data structures.............................22
   3.2. structures...........17
   3.3. PAP Authentication...........................................23
   3.2.1. Authentication...........................................17
   3.3.1. PAP Connection sequence....................................23
   3.2.2. sequence....................................18
   3.3.2. AuthPapExtEntry datastructure..............................24
   3.3. datastructure..............................19
   3.4. CHAP Authentication..........................................24
   3.3.1. Authentication..........................................20
   3.4.1. CHAP Connection sequence...................................25
   3.3.2. sequence...................................20
   3.4.2. AuthChapExtEntry datastructure.............................26
   3.4. datastructure.............................22
   3.5. HTTP Authentication..........................................26 Authentication..........................................23
   4. Data Structures................................................27 Structures................................................24
   4.1. Accessor class...............................................27 Event class..................................................24
   4.2. AccessorElement class........................................28 EventHandler class...........................................24
   4.3. AccessorSessionScope class...................................29 EventHdlrElement class.......................................25
   4.4. AccessorAuthProtocol class...................................30 EventHdlrEventScope class....................................26
   4.5. ContextData class............................................30 EventHdlrHandleScope class...................................28
   4.6. Session class................................................31 Behavior of the Event and Handle Scope classes...............29
   4.7. AuthExt class................................................32
   4.7.1. AuthEapReqExt class........................................33
   4.7.2. AuthEapRespExt class.......................................33
   4.7.3. AuthPapExt class...........................................33
   4.7.4. AuthChapExt class..........................................34 EventHdlrAuthProtocol class..................................30
   4.8. DatapathEventHdlr Class......................................31
   4.9. ContextData classes..........................................34
   4.8.1. class............................................31
   4.10. ContextData classes.........................................32
   4.10.1. CtxtL3Hdr class............................................34
   4.8.2. class...........................................32
   4.10.2. Ctxt802Hdr class...........................................36
   4.8.3. class..........................................33
   4.10.3. CtxtDialupInterface class..................................36
   4.8.3.1 class.................................34
   4.10.4 CtxtDialupIfFramedProtocol class..........................37
   4.8.3.2 class...........................35
   4.10.5 CtxtDialupIfLoginService class............................38
   4.8.3.3 class.............................36
   4.10.6 CtxtDialupIfLoginLat class................................39 class.................................36
   4.11. AuthExt class...............................................37
   4.11.1. UserAuthExt class.........................................37
   4.11.2. AuthChapExt class.........................................37
   4.11.3. AuthPapExt class..........................................38
   4.11.4. AuthExtResult class.......................................38
   4.11.5. AuthEapReqExt class.......................................38
   4.11.6. AuthEapRespExt class......................................39
   5. Message Types..................................................40
   5.1. Accessor Event Handler Provisioning Decisions..............................40 Decisions.........................40
   5.2. Provisioning Report..........................................41 Decision........................................41
   5.3. PEP Access Request...........................................41 Event Message............................................41
   5.4. PDP Access Response..........................................41 Provisioning Decision....................................42
   5.5. Session-specific ContextData Request.........................42 PDP fetching Event-specific ContextData......................42
   5.6. Session-specific Event-specific ContextData Response........................43 Response..........................43
   5.7. Opaque Decision..............................................43
   5.8. Opaque Report................................................43
   6. Combining Data Structures in Messages..........................43

Weiss et al.             Expires October 2000                 [Page 2] Messages..........................45
   6.1. Combining Context Data in Event Messages.....................45
   7. Access Request and Session-specific ContextData
   messages..........................................................44
   6.2. Combining Bind Usage Examples.....................................46
   7.1 Wireless LAN (802.11 Access Response and Provisioning Decision messages.44
   7. Point) Usage Example..............46
   7.1.1 Wireless LAN Access Event Handler Provisioning..............47
   7.1.2 Wireless LAN Access Event Handling..........................48
   7.1.3 Wireless LAN Access Event Decision..........................48
   7.2 RSVP Usage Example............................................49
   8. The AccessBind PIB Module......................................44
   8. Security Considerations........................................74 Module......................................56
   9. References.....................................................75 Security Considerations.......................................104
   10. References...................................................105
   11. Author Information and Acknowledgments........................76

Weiss et al.             Expires October 2000                 [Page 3] Acknowledgments.......................106

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 a dynamic authorization
   requests 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. 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. 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

Weiss et al.             Expires October 2000                 [Page 4]
   honored, specific provisioning actions may be taken to bound 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 Access Requests÷ "PEP Events" to denote the fact that PEP are requesting access to is
   generating an event indicating a request for some type of service.

   In order to support the broad variety of potential PEP Access
   Requests, Events, there
   must be a way of provisioning the criteria for generating the PEP Access Request.
   Event. In the most common case the PEP
   Access Request Event is generated as a
   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: PEP Access Requests 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 Access Request Event by reusing elements from
   the model like the qosDatapathTable table and the qosClfrTable table
   in the DiffServ PIB.

   Another consideration is the variety of information that can
   potentially be included in a PEP Access Request. Event. For instance, a PEP
   Access Request 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 Access Request. Event. Given the amount of information
   that could be sent with the PEP Access
   Request, 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 Access Request. Event.

   PEP Access Requests 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

Weiss et al.             Expires October 2000                 [Page 5] reservation should be
   accepted or not. The enhancements provided by this PIB not only
   allow RSVP messages to generate access requests, but also explicitly
   provision QoS resources, using 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 access requests Events and associated
   provisioning need to be negotiated quickly. Mobile-IP applications
   in particular require speedy resolution of PEP Access Requests. Events. This implies
   that the combination of PEP Access Requests Events and provisioning needs to be
   completed with the minimum number of communication legs (round
   trips).

   One of the problems discovered with existing PIBs [DSPIB, FPIB] was
   that it was difficult to support two-phase classification. In

2. Paradigm for the
   general case, PEP Access Requests will be used to grant
   authenticated clients access to specific resources. As such, many
   clients Bind PIB

   There are likely several key aspects to share various combinations of resources.
   However each resource this PIB. First there is likely the
   ability to be provisioned once and shared by
   a set of clients. For example, provisioning for future authorization events, known as
   PEP Events. Second, there is a set of clients may share access tables that used to
   a Virtual Private Network while a set notify the
   PDP of overlapping clients may
   share access to a Voice over IP service, and a third set of
   overlapping clients may be given access to a set of premium
   services. The problem is that provisioning policies for each
   combination of client and resource creates an n-square policy table
   that is difficult to maintain and to scale. Provisioning the
   resources independent of the consumer of the resources and binding
   the two is a far more efficient approach allowing either resources
   or clients to be managed independently of each other. However, this
   requires approach requires two-phase classification, classifying the
   client independent of the resource. This PIB will define incremental
   structures to support this model.

2. Paradigm for the Bind PIB

   There are several key aspects to this PIB. First there is the
   ability to provisioning for future authorization request, known as
   PEP Access requests. Second, there is a set of tables that used to
   notify the PDP of an attempt 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
   dynamically binding sessions to determining which PEP Events require a set of policies. This section
   describes the approach taken for supporting each of these
   structures. new
   COPS Request Handle and which should use existing handles.

2.1 Accessor Event Handler Concepts

   This section introduces the concepts concept of an Accessor and Sessions
   associated with an Accessor. Event Handler. Much of
   what is described in this paper is based on the Accessors, the sessions that Accessors create, and
   the way Accessors match data with sessions, creating new sessions
   when there is no match.

Weiss et al.             Expires October 2000                 [Page 6] 
   Accessors Event Handler.

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

   Once an Accessor Event Handler is provisioned it is responsible for
   identifying packets that should be treated as a session, generating access
   requests to authorize the session when it detects require the first packet
   of a session, and then applying a specific policy for all packets in
   a session. PDP to be notified with an
   Event Message.

   The general model for access Event Messages 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 Accessor Event
   Handler is the part of the PEP that is responsible for recognizing
   the conditions for client authorization, forwarding generating the Request Event
   Message to the PDP, and communicating with the Client, if necessary,
   to get identity or other information.

   The Accessor Event Handler takes a signal or message from the client and
   translates it into an Access Request Event Message to send to the PDP. It takes the Access
   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 access request Event Message is sent from the PEP to the PDP. The PDP attempts
   to authorize uses the request (which
   Event Message to determine the appropriate provisioning steps. In
   some cases identity verification may require sending some
   intermediate messages to authenticate the client), and then returns
   an access Decision for client prior to
   provisioning the session. 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 |                  |    |-Access Notification->|    |-Event Message---------->|    |
   |  I | <-(optional)->   |PEP | <-(optional)->          |PDP |
   |  E |                  |    |<-Access    |<-Provisioning Decision ----| -|    |
   |  N |<-Access Decision-|    |                         |    |
   |__T_|                  |____|
   |  T |                  |    | --> Access Report -->|____| ----->|    |

                Fig. 2.1        Access Control Protocol Sequence

   This paper is primarily concerned with the function of the Accessor 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 Access Request Event Message and PDP Access Response 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

Weiss et al.             Expires October 2000                 [Page 7] 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 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 Accessor Event Handler is a data path element in the PEP. Each Accessor Event
   Handler has a
   ˘selector÷ "selector" that identifies packets that should be assigned by the
   accessor to a session cause
   Event Messages (See section 4.3 ű - Filter Entries). The selector
   essentially divides all packets into two sets, one set the
   Accessor Event
   Handler is responsible for assigning to a session; generating Event Messages; the other set
   it just passes to the next data path element. For example, if an
   AccessorĂs
   Event HandlerĂs selector is Destination TCP Port = 80, "All new source IP addresses", an
   incoming packetĂs Destination port Source IP address is examined and if Destination Port it is not
   80, old,
   the packet passed on without further processing. If the
   Destination Port source IP
   address is 80, each packet new or unknown, an Event Message is associated with generated.

   Event Messages are grouped by COPS Request Handles. Each Event
   Message may cause a ˘session÷
   and the session policy is applied new COPS Request Handle to it. If be generated or a packet is the first set
   of
   a session, Event Messages may all share the Accessor will initiate an Access same COPS Request to authorize
   and request provisioning for the new session.

   Every session has a ˘session criteria÷ defining which packets are to
   be part of that session. Handle (note:
   see section 4.3. 4.3-4.6).  The distinction between selector and session criteria is not well Event
   Handle spelled out in
   4.3, 4.3-4.6, and will be worked on in the next
   revision of this draft). Each
   Accessor also has a ˘session matcher÷ Attributes in the Access Bind PIB are
   provided to identify what how Event Messages are bound to COPS
   Request Handles.

   Event Handlers are designed to detect conditions in the PEP that checks session criteria
   result in the sending of Event Messages to determine if the PDP. The Access Bind
   PIB defines a packet is part of class to specify the criteria for generating an existing session.

   There has been event.
   In some discussion of what cases an event is appropriate every time the session criteria should
   be. One possibility is
   met. In other instances an event is appropriate only on the first
   occurrence. The provisioning event criteria can be difficult since
   it is often the case that there would be a definition of scope by
   a set of attributes (e.g. every Source IP and Destination IP address
   combination) and that the PDP canĂt anticipate what the PEP will
   see. For instance, when it is desirable to generate events every unique element that
   time a new user or device is recognized, the PDP canĂt anticipate
   which devices will be recognized or the order in which they will
   occur. Filter expressions can be constructed that enable the scope
   would
   description of a set of packet fields that must match and a set of
   packet fields that collectively represent a new, unique combination.
   This expressive capability allows the PDP to indicate to the PEP
   that one event should be generated the first time a session. 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 defined
   in the COPS Framework PIB
   [FWPIB]. [FWPIB], this PIB and other PIBs. For
   example, if a FilterEntry 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
   session. Handle. The session criterion is that all packets for this example, any packet with a SRC IP address
   that have generates a
   unique value within the scope are assigned to new Event Message will use the (unique) session
   associated with existing handle if
   that unique value. (We expect discussion on how the
   scope is defined, especially handle was already defined for situations that involve signaling
   rather than inspecting packet headers) specific SRC IP address.

   When a packet arrives, arrives at the Accessor Event Handler, it first checks if it
   meets the
   general criteria for sessions it is managing. 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. If not selected, it is 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 session. If it does match a
   session criteria, the policy for that session is applied. COPS
   Request Handle.

   If it does not match the criteria for an existing session, COPS Request
   Handle, then it the PEP instantiates a new session, marks the session as ˘pending÷ Request Handle and sends

Weiss et al.             Expires October 2000                 [Page 8] an Access Request
   Event Message to the PDP. The PDP authorizes using the request, 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 session, then sends an Access Decision ű either
   an ˘Enable÷ (accept)
   new address. If authentication was performed, a final Authentication
   Result object is sent to the PEP to indicate the authentication was
   successful or ˘Disable÷ (reject) ű not. This is needed to allow the PEP. The Access
   Decision may also contain other provisioning data piggybacked with PAP, CHAP and EAP
   authentication processes to report success back to the Access Decision.
   authenticating user.

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 two policies used by
   Accessor sessions to direct traffic from two sets of authorized IP a classifier that has
   explicit entries for each source address that has already be
   authenticated and a default classifier element matching all addresses
   to an appropriate data path, one points to an Event Handler. Since the preferred queue, default classifier element
   is only used if none of the other to classifier elements match, the best effort queue. Packets from
   Event Handler is only invoked for new Src IP addresses that have not
   included in either set of authorized
   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"
   users are assigned a high QoS while the addresses of "normal" users
   are assigned best effort QoS. Since the Event Handler is not
   terminating any packets, the Event Handler passes all packets through
   to be dropped. the Best Effort Queue.

   When the PEP comes up it sends information about its Accessors Event Handlers
   to the PDP in a capabilities table. The PDP returns an Accessor Provisioning
   Decision which instructs After capability negotiation is
   complete, the PEP to install PDP provisions a set of policies that configure the Accessor
   Event Handlers behind the Ethernet interfaceĂs datapath, and AccessorSessionScope Tables. datapath. Each
   Accessor Event
   Handler Table will have a pointer to a (tagged) set of
   AccessorSessionScope
   EventHandlerElement Tables that provide Selector Filter matching and Session
   Matching setup information. COPS
   Request Handle matching rules. In this case, the AccessorSessionScope EventHandlerElement
   table will contain be provisioned generate unique Request Handles and Events
   the first time it matches a range of ˘SourceIPAddresses.÷ new "SourceIPAddresses."

   Once the Accessor Event Handler is setup, it is able to process packets
   arriving at the Ethernet
   Interface are processed by the Accessor. If the packet is not from
   EthernetPort 1, then it is passed immediately to the next data path
   element behind the Accessor. Interface. The Accessor Event Handler looks at remaining all
   packets with Src IP addresses that have not been explicitly been
   defined in the upstream Classifier and uses the session event matching rules
   to check if the packet is part of contains an existing session. In this
   example packets from each unique Source unknown Src IP address will be separate
   sessions. within the
   configured range. If the packet is not part of matches an existing session, event matching rule, the
   Accessor
   Event Handler checks what information the PDP requires from the
   Client (e.g. username and credential), gets the information, instantiates and collects this
   information. The PEP then checks to see if it should use an existing
   Request Handle or create a new (pending) session with one. In this Source IP address, and sends an
   Access 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.
   PDP containing the user information including address, port, and
   credential information.

   The PDP checks the packet, information passed in the Event Message,
   authenticates the client (if required), and decides which policy
   should apply to that IP address. It sends a
   Access Decision Provisioning Decision,
   containing the appropriate policy (assign to "premium" queue) to the
   PEP including using the Session Table with state
   set newly created Request Handle.

   Additional examples using the Access Bind PIB to ˘Enabled÷ support RSVP,
   802.11, and a pointer to appropriate policy (e.g. best
   effort or preferred).

Weiss et al.             Expires October 2000                 [Page 9] 
   Future drafts will expand on this example and add other examples.
   Current plan is to add examples for dial access and QoS flow
   authorization.

2.2 Accessor Management Paradigm

   Figures 2.2 through 2.6 below show a number of diagrams representing
   a sequence of steps involved protocols are described in section 7.

2.2. Context Data

   As mentioned previously, Event Messages frequently require
   information beyond just the authorization, authentication
   and provisioning phase. The semantics of this are shown as layout identity of
   switches and Connections. Switches, Accessor and Policy components
   in a topology that describe certain traffic classifications
   represent access to Service capabilities enforced by the PEP.

   The following diagrams represent client. Information
   about the semantic components within physical interface, the
   PEP. Each (A) represents an Accessor. An Accessor is a logical
   component inside protocols being used, and the PEP that can
   protocol bindings (VLANs, IP addresses, etc.) may also be created and/or configured
   during the PEP initialization phase or it gets instantiated as the
   result of an unsolicited Provision Decision from required
   to provide enough information to the PDP.

   An Accessor is configured PDP to act on certain messages or interface
   events (as described in section 2.1). After matching provide proper
   provisioning guidance. Therefore a packet and
   determining mechanism is required that no session exists for it, the Accessor in the PEP
   will create a new session and assert allows
   the start of an authorization
   phase by sending an Access Request PDP to specify what information is needed.

   With the PDP (or AAA server). This
   authorization phase may include authentication as well.

   The configuration of an Accessor will include a list advent of Tunnels, the types of
   authentication methods (PAP/CHAP/ EAP/HTTP etc.) to same headers can be used. Each
   (S) repeated
   (nested) within a single client message. This makes identification
   of specific attributes such as IP Addresses difficult because it is
   unclear whether the topology represents an active unique session created
   by the PEP, replacing PDP needs the Accessor symbol when IP Address in the session is
   activated (as will be explained later). A single Accessor component
   is capable of creating multiple Session instances that each
   represent a unique session as represented in the subsequent example.
   The (P) symbols represent provisioned policies. Policies are created
   and/or made accessible innermost or inaccessible
   outermost header. This gets even more complicated when more than two
   layers are involved (i.e. VLAN and label stacking). The ContextData
   class, described in more detail below, allows the PEP based on
   Provisioning Decisions from PDP to explicitly
   specify the PDP. Provisioning Decisions set of nested headers that it needs more details on.
   This can either be
   sent on request by specified in from the PEP outermost header or can be sent unsolicited by the PDP.

   Switches: closed or ON: --o---o--.
                               \
             open or OFF : --o  \o--

   In this example there are two kinds
   innermost header, as well as all headers of switches:

   - Accessor Switches: --(An)---o--

   A logical switch that is connected to a particular type.

   Since the Accessor and volume of information can be seen
   as quite large and is very PEP
   and interface specific, it is appropriate to organize the
   information into manageable chunks. This approach was a kind 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 master switch information. The second
   alternative is very configuration intensive, particularly for header
   data that enables a must distinguish inner and outer headers. The choice to
   group of Services context data into classes and request the data at once.
   Under normal circumstances the switch remains open until an explicit
   access response class
   level is sent by the PDP. This allows not without problems. If the PDP to perform
   preemptive provisioning prior to providing closing the switch.

Weiss et al.             Expires October 2000                [Page 10] 
   - A Policy Switch: --o---o--(Pn)  Service/Resource

   (Pn) is only interested in a logical switch that represents a policy. The (Pn) open
   switch defines a policy that denies resources and
   single attribute within a closed switch
   describes policies that enable services. The figures simplify
   policies given class, there is no way to specify
   this. Hence the PEP has to permit fill in the entire class and deny. In practice a policy provisioned by the PDP can express QoS semantics, tunnel semantics, or even high level
   services such as telephony services. In figures 2.2 through 2.6,
   these services are represented as branches.

   The Accessor Switch can be explicitly operated by a response has
   to parse the
   PEP Access Request. This response will hereafter be referred entire class to as a
   ˘PDP access response÷ message.

   DISABLE
   Link    \
   ----(A1) \o-- Access Request
   Activity

   Fig 2.2: The PEP waits find the appropriate attribute.

   In order for traffic that initiates a PEP Access
   Request.

   Figure 2.2 shows the PEP Accessor A1 is waiting PDP to receive an event
   that will initiate specify which chunks of context data it
   needs, this PIB defines a PEP Access Request to table called the PDP. This Accessor
   (A1) can be configured by ContextData class that
   allows the PDP either at boot time or to specify the tables it could
   exist permanently needs. This table is
   discussed in the non-volatile memory of the PEP after a one-
   time configuration more detail in section 4.9. The messages used to send
   ContextData are discussed in sections 5.1, 5.2, 5.3, and 6.1.

2.3. Policy Distribution and Management

   One of the PEP. For the purposes of this example, we
   will assume that Accessor (A1) has been instantiated a new Session
   due paper is to link activity demonstrate how
   authorization and a PEP Access Request message has been sent authentication can be bound to traditional COPS
   provisioning. Stated somewhat differently, this paper provides the PDP.

                 HTTP      ENABLE
                |----------o---o---(P1) tunnel to content filter
                |
                |          DISABLE
                |Non IP      \
                |----------o  \o---(P2) drop
                |
        DISABLE |10.x.x.x  ENABLE
           \    |----------o---o---(P3) tunnel corporate traffic
   ----(S1) \o--|
                |24.x.x.x    \
                |-------(A2)  \o--- Access Request
                |
                |All other
                |traffic   ENABLE
                |----------o---o---(P4) default QoS

   Fig 2.3: The PDP provisions policies P1, P2, P3 & P4
   means for seamlessly integrating outsourcing with provisioning using
   only PIBs. Authorization, Authentication, and Accessor
   A2.

Weiss et al.             Expires October 2000                [Page 11] 
   The PEP Access Request generated by (A1) can be configured such that
   it sends specific information about the client including physical
   link characteristics, L2, L3 & tunnel information, as well as
   authentication credentials. For some authentication protocols there
   may be sufficient information to allow the PDP to authorize the
   access request. If additional information is required, a number COPS/RSVP are all
   forms of
   data structures outsourcing because they are defined all triggered by events in the PIB to allow additional
   negotiation for either the authentication or
   PEP and depend on decision support from the authorization to be
   completed. These structures are discussed in more PDP. Earlier sections
   have gone into fair detail in describing how the next
   section.

   When the PDP is ready to grant access, it PEP can choose generate
   Event Messages. However, we have not yet discussed how these
   semantics integrate with traditional COPS PR provisioning semantics.

   There are two aspects to provision
   specific services for the session bound provisioning that need to the access request. These
   service policies can be dynamically bound to the session via considered.
   First is the
   NextElement attribute in provisioning of the Session table (discussed in Event Handlers themselves. Section
   2.1 went into some detail in
   section 4.5). This attribute allows sessions, generated by PEP
   Access Requests, to be bound to other data path elements describing how Event Handlers are
   provisioned using policy decisions. More details on the necessary configuration to support additional service policies.

   The example Event
   Handler tables can be found in Figure 2.3 replaces sections 4.1, 4.2, and 4.3. In
   addition the Accessor (A1) with Session
   (S1) provisioning messages used to demonstrate that the policy bindings configure Event Handlers
   are at the session
   level rather than at the Accessor level. For simplicityĂs sake the
   Accessor is not shown also described in the figure. In this example the Session is
   followed by a classifier, and a set section 5.1.

   The second aspect of QoS and tunneling services
   are defined provisioning is the use standard provisioning
   decisions to provide access bind policies to authorized clients. The goal in
   binding events to services defined with policies P1,
   P3 & P4, was to minimize reconfiguration.
   Therefore, this PIB has been designed to provision Event Handlers as
   well as explicit deny policy P2. Policies once and bind them together dynamically.

   The diagram shows that
   services such as tunnels process for certain traffic types (P1/P3) and a
   default QoS treatment (P4) this binding is enabled 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 access of Non-IP
   Request Handle would typically operate on all traffic to with that
   source IP address. Note that the network is denied (P2). The PDP criteria that scope a Request
   Handle could also provisions be a new
   Accessor (A2) unique protocol, unique VLAN, or each unique
   RSVP RESV message. It is also worth noting that will trigger the generation of a new PEP Access Request if/when traffic is destined for IP subnet 24.x.x.x.

   This ability to support multiple Accessors as well as Handle
   bounding criteria could also be a hierarchy unique combination of
   Accessors is field values
   such as a key capability of this model. There are many
   scenarios where multiple authorizations are required for VLAN and TCP Port Number.

   With the same
   client. Further any scope of these authorizations a Handle specified, the Event Handler can require incremental
   authentication.

Weiss et al.             Expires October 2000                [Page 12] 
                 HTTP      ENABLE
                |----------o---o---(P1) tunnel to content filter
                |
                |          DISABLE
                |Non IP      \
                |----------o  \o---(P2) drop
                |
                |10.x.x.x  ENABLE
        ENABLE  |----------o---o---(P3) tunnel corporate traffic
   ----(S1)--o--|
                |        DISABLE
                |24.x.x.x    \
                |-------(A2)  \o-- Access Request
                |
                |All other
                |traffic   ENABLE
                |----------o---o---(P4) default QoS

   Fig 2.4: The PDP enables services by sending a PDP Access Response.

   Figure 2.4 above shows
   instantiate new Handles in conjunction with the state Event Message.

2.4. Interactions with DiffServ model

   The DiffServ model [MODEL] and PIB [DSPIB] allow for flexible
   addition of new Data Path Functional Elements. The Event Handler is
   one such new Data Path Functional Element.  Previous sections have
   already described how this PIB extends the data path after the
   authorization has been completed. After any incremental data path
   provisioning performed by existing DiffServ
   Informal Model and the PDP, DiffServ PIB. However, it is worth describing
   how this PIB enhances the PDP sends an explicit
   response to basic DiffServ model. First and foremost,
   this new PIB provides a means for scaling the PEP Access Request. This response, referred basic DiffServ model
   to as the ˘PDP Access Response,÷ notifies edges of the PEP network that traffic is now
   allowed to pass through the session (S1) created with Accessor (A1).
   Once the Session is enabled, traffic can now proceed to have many interfaces and many
   specialized services. Previous PIBs only supported the
   classifier static
   configuration of data paths. This meant that will forward traffic on dynamic events such as
   binding of new clients to the specified policies
   (P1, P3 & P4) existing or cause a new PEP Access Request for (A2).

Weiss et al.             Expires October 2000                [Page 13] 
                 HTTP      ENABLE
                |----------o---o---(P1) tunnel services were difficult to content filter
                |
                |          DISABLE
                |Non IP      \
                |----------o  \o---(P2) drop
                |
                |10.x.x.x  ENABLE
        ENABLE  |----------o---o---(P3) tunnel corporate traffic
   ----(S1)--o--|
                |                 24.20.x.x ENABLE
                |                |----------o---o---(P5) high QoS
                |        DISABLE |
                |24.x.x.x   \    |24.1.x.x  ENABLE
                |-------(S2) \o--|----------o---o---(P6) low QoS
                |                |
                |                |          DISABLE
                |                |TELNET      \
                |                |----------o  \o---(P7) drop
                |All other
                |traffic   ENABLE
                |----------o---o---(P4) default QoS

   Fig 2.5: Accessor 2 triggers
   support because there was no way to anticipate new PEP Access Request resulting in PDP
   Provision Decisions installing policies P5, P6, & P7.

   In figure 2.5, above, the second Accessor (A2) (shown as S2) has
   been triggered with clients and
   because most provisioning was managing classifiers on a packet from the per client to subnet 24.x.x.x
   resulting in a PEP Access Request and
   per service basis did not scale well.

   This PIB addresses this problem by preserving the basic data path
   semantics but separating the creation of dynamic (event driven)
   policies into a new Session
   (S1) by data path component. This provides a stable data
   path for the PEP. Figure 4 generation of authorizations while also demonstrates the PDPĂs ability to
   incrementally apply additional provisioning decisions. In supporting a
   stable data path for the
   example, additional classification and provisioning components are
   provisioned behind services that various clients may make use
   of. The linchpin of this PIB is the Event Handler that provides a
   new session (S2) to apply more selective QoS
   to specific types type of demultiplexor that separates streams of traffic via policies P5 and P6.

Weiss et al.             Expires October 2000                [Page 14] 
                 HTTP      ENABLE
                |----------o---o---(P1) tunnel to content filter
                |
                |          DISABLE
                |Non IP      \
                |----------o  \o---(P2) drop
                |
                |10.x.x.x  ENABLE
        ENABLE  |----------o---o---(P3) tunnel corporate traffic
   ----(S1)--o--|
                |                 10.20.x.x ENABLE
                |                |----------o---o---(P5) high QoS
                |                |
                |        ENABLE  |10.1.x.x  ENABLE
                |-------(S2)--o--|----------o---o---(P6) low QoS
                |                |
                |                |          DISABLE
                |                |TELNET      \
                |                |----------o  \o---(P7) drop
                |All other
                |traffic   ENABLE
                |----------o---o---(P4) default QoS

   Fig 2.6: into
   individually grouped triggers that in turn support dynamic
   authorization. The PEP receives PDP Access Response and enables S2.

   In figure 2.6, after all Provision Decisions have been reported
   successfully, the PDP will send a PDP Access Response policy provisioning that will
   enable access results from these
   events can be bound back to all pre-defined policies to minimize the services behind Session S2.

   Services and Accessors are provisioned and given a certain state
   either as
   changes required to support new clients. As a default during the first contact phase result, with the PDP this PIB,
   modifications to service policies can be added or
   during the operational period as updates from removed at the PDP driven by PEP
   Access Requests. Typically the default configurations are requested
   by the PEP at startup time and the PDP returns Provision Decisions
   based on
   session level rather than the context raw data described in the Request.

   Provision Decisions may arrive at the PEP solicited (after path level.

   So far we have only discussed the PEP
   sends value of authorizing a Provision Request) or unsolicited. Provision Decisions that
   are sent unsolicited to client when
   the PEP may create additional switches
   (services), enable or disable switches or it may remove a Service
   Switch or even an Accessor Switch. In addition, link notices new IP address. However, it is also possible
   for an existing, enabled Accessor Switch to be disabled dynamically.
   Provision Reports subsequently sent from the PEP to the PDP will
   confirm that a particular switch is created, has a certain status or
   is removed.

   A Provision Report does not always imply worth noting that
   because the endpoint of a
   particular service Event Handler is operational since PEP only controls the access
   to a particular service.

   After a particular client has been identified to part of the PDP, data path definition, it is
   far more flexible. For instance, the PDP
   will decide which Services will be provisioned to this particular

Weiss et al.             Expires October 2000                [Page 15] 
   client. There may Event Handler can be placed
   behind a set of Provision Decisions that must be
   ˘Reported÷ as successfully installed Classifier to the PDP before the PDP sends
   a PDP Access Response explicitly authorize access to control all (or a set of) services. For
   example a certain set specific
   part of security settings must be in place before
   the PEP is allowed to have the client send any packet to the network
   behind the PEP.

   A solicited or unsolicited Provision Decision may specific services. The Event Handler can also create new
   Accessors as illustrated in Figures 2.2 through 2.6. Provisioning
   additional Accessors may
   be seen as an extension to the original
   access and provision sequence or may be seen as an independent
   event.

   A use case for multiple Accessors might be that the first Accessor
   causes FailNext element behind a default service to be provisioned that only requires very
   basic authorization (e.g. based on source IP address) and that more
   elaborate authentication is only required when the client accesses
   web servers meter resulting in a certain IP address range. For this reason, an authorization
   for the
   second Accessor may be configured to trigger on any HTTP packet to a
   certain range use of IP addresses out-of-profile traffic. Bandwidth Brokers can use
   this approach or it could be configured an Event Handler trapping RSVP RESV messages to trigger
   on a specific HTTP GET request.
   support dynamic bandwidth allocation decisions.

   The PDP may subsequently create integration of Event Handler as a
   service switch Data Path Functional Element
   allows seamless integration with DiffServ provisioning.
   DiffServ network device mechanism policy control continues to a specific IP address for port 80 marking be
   supported with the
   traffic for a High QoS.

   Additional Accessors may trigger PEP/PDP Access Request/Response
   sequences on behalf use of different parties. This is part DiffServ PIB [DSPIB] with added
   functionality at the edge of the
   Accessor configuration provided by network with usage of the PDP. Event
   Handler.  This can now be totally controlled via the use of COPS-PR.

   The PDP may create
   Accessors without explicit knowledge Policy Server level interaction with DiffServ comes naturally
   with the integration of Event Handler as a Data Path Functional
   Element when the client.

   As stated previously, network data model is common and scoped
   appropriately in order for the PEP to generate schema level, with the Event Handler becoming
   stimuli for DiffServ provisioning.

2.5. Interactions with RSVP model

   The Event Handler model provides a PEP Access
   Request, means for detecting RSVP RESV
   messages. This means that the PEP must traditional COPS outsourcing model
   could eventually be configured not only to generate the request
   under phased out in favor of the proper circumstances, but also what physical interface provisioning model
   and
   transport header information should be passed with the request. This
   configuration must also include the authentication rules that may be
   supported. The semantics use of the PEP Access Request are this PIB. This is discussed in more detail in sections 5.1 and 6.1.

2.3. Context Data

   As mentioned previously, access requests frequently require
   information beyond just section
   7.2.

3. Supporting various client Authentication Protocols

   In the identity operational model for this PIB, the Authentication Server is
   a specific function of the client. Information
   about PDP. The main purpose of the physical interface,
   authentication portions of this PIB is to verify the protocols being used, validity of
   client credentials by an Authentication Server. The verification
   process itself may do this whilst ensuring some level of
   authenticity, confidentiality and the
   protocol bindings (VLANs, IP addresses, etc.) integrity. Messages exchanged
   between a Client and Authentication Server (PDP) may remain
   confidential to PEP's and Proxy Servers. The message integrity may also
   be required ensured by some hashing algorithm so PEP's and Proxy's may
   inspect but not modify the content of authentication messages.
   Clients, PEP's, Proxy's and PDP's will always need some security
   method to complete an access request. Therefore ensure message authenticity.

   Some authentication protocols explicitly consider proxies by
   allowing the payload to be carried over a mechanism is required
   that allows variety of transports.
   Others depend on the PDP termination point of the connection to specify what information
   explicitly proxy the authentication, when that is needed.

   With necessary. In
   order to demonstrate the advent general utility of Tunnels, the same headers can be repeated
   (nested) within this model, a single client message. This makes identification variety of specific attributes such as IP Addresses difficult because it is
   unclear whether the PDP needs the IP Address
   client authentication protocols will be considered in this document.
   For each protocol, the innermost or
   outermost header. This gets even more complicated when more than two
   layers are involved (i.e. VLAN and label stacking). The ContextData
   class, negotiation mechanism will be described in more detail below, allows and
   the PDP mapping to explicitly

Weiss et al.             Expires October 2000                [Page 16] 
   specify this framework will be detailed.

3.1. Provisioning

   The PEP will not start an authentication sequence with the set of nested headers that client if
   it needs more details on.
   This can either be specified in from hasnĂt been told to do that. It will only do so when a specific
   event occurs. The PDP tells the outermost header or PEP exactly when this event should
   be triggered. This process is called provisioning.

   The provisioning starts with the
   innermost header, as well as all headers of a particular type.

   Since initial Provisioning Request, which
   is typically sent at boot time. The PEP sends up capability PRCĂs
   indicating the volume types of information authentication it can be quite large 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
   and an additional PRC instance referred to by the
   eventhdlrEventScopeFilter in the eventhdlrEventScope table,
   indicating how the signaling trigger is very recognized.

   In case the PDP wants the PEP
   and interface specific, it to perform an authentication when an
   event is appropriate triggered, it should set dpeventhdlrRequestAuth in the
   dpEventHdlr to organize true and optionally let the
   information into manageable chunks. This approach was dpEventHdlrAuthProtocol
   field point to 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 dpEventHdlrAuthProtocol to new types of information. The second
   alternative is very configuration intensive, particularly indicate which
   authentication protocol should be used 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 authentication.

   As soon as the PDP is only interested in a
   single attribute within a given class, there is no way to specify
   this. Hence has provisioned the PEP has to fill in the entire class and watch for certain
   traffic that triggers an event, the PDP has PEP is ready to parse start an
   authentication.

3.2. EAP Authentication

   The most significant aspect distinguishing EAP [EAP] from other
   authentication protocols is that EAP assumes the entire class to find negotiation is
   between the appropriate attribute.

   In order for client and the PDP to specify which chunks authentication server. In anticipation of context data it
   needs, this PIB defines a table called
   the ContextData class fact that
   allows the PDP to specify the tables it needs. This table terminating point of a connection such as PPP or
   L2TP is
   discussed not necessarily the same as the agent managing client
   authentication, EAP encapsulates itĂs negotiation process in more detail a
   separate header that can be forwarded in section 4.4. The messages used entirety to send
   ContextData are discussed in sections 5.1, 5.2, and 5.3.

2.4. Policy Distribution and Management

   One of the purposes of this memo is to demonstrate how authorization
   and authentication can be bound to traditional COPS provisioning.
   Stated somewhat differently, this memo server.
   This mechanism 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 extra security by events in the PEP preventing intermediate
   proxies from monitoring or managing authentication credentials.

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

   The terminology used in [EAP] differs from the PDP. Earlier sections have gone
   into a fair bit terminology used in
   this document. In particular, the peer, as defined in section 1.2 of detail
   [EAP], is referred to as "Client" in describing how this document. Similarly, the
   "authenticator" is called a PEP can generate
   access requests. However, we have not yet discussed how these
   semantics integrate with traditional COPS PR provisioning semantics.

   There are two aspects to provisioning that need to be considered.
   First in this document and "back-end
   server" is called the provisioning Authentication Server function of the Accessors themselves. Section PDP (or
   just PDP) in this document.

3.2.1. EAP Message sequence

   The generic sequence of transmissions between the PEP and PDP has
   already been described in section 2. In particular, figure 2.1
   went into some detail describing how Accessors are provisioned using
   policy decisions. More details on gives
   an overview of the Accessor tables can be found messages involved between the Client workstation,
   PEP and PDP. EAP messages are embedded in sections 4.1, 4.2, PPP packets in the
   communication between the Client and 4.3. the PEP. In addition the provisioning communication
   between the PEP and PDP, the EAP messages
   used to configure Accessors are also described embedded in section 5.1.

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

   The process for this binding is as follows. An Accessor can be
   configured to generate sessions and trigger a PEP Access Requests

Weiss et al.             Expires October 2000                [Page 17] 
   based on specific criteria. These criteria explicitly scope the
   session. For example, if the criteria were one per unique source IP
   address, then there would be one session for each unique source IP
   address and all policies bound to that session would operate on all
   traffic with that source IP address flowing into that Accessor. Note
   that the criteria that scope a session could also be a unique
   protocol, unique VLAN, or each unique RSVP RESV message. It is also
   worth noting that the session bounding criteria could also be a
   unique combination of field values such as a VLAN COPS
   Request, COPS Decision and TCP Port
   Number.

   With the scope of a session specified, the Accessor can instantiate
   new sessions in conjunction with the PEP Access Request. When the
   PDP authorizes a new session, it must bind specific policies to the
   session in order to specify COPS Report messages. Figure 3.1 shows
   how the session-specific traffic should
   be processed. If no specialized handling is required for the
   individual sessions, the sessions EAP may all be lumped back into a
   single data path. Normally the next data path element will be a
   classifier that de-multiplexes specific or aggregate session traffic used to retrieve credentials from the various service policies configured behind client
   workstation by the classifier. As
   such an Accessor performs a sort 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 classification function that
   instantiates additional more specific policies, provisioned in EAP messages between the
   PEP.  This can be viewed as a boot strapping process for handling
   session specific access control.

2.5. Interactions with DiffServ model

   The DiffServ model [MODEL] Client workstation
   and PIB [DSPIB] allow for flexible
   addition of new Data Path Functional Elements. Accessor is one such
   new Data Path Functional Element.  Previous sections have already
   described how this PIB extends the existing DiffServ Informal Model PEP, and between the DiffServ PIB. However, it is worth describing how this PIB
   enhances the basic DiffServ model. First PEP and foremost, this new PIB
   provides a means for scaling the basic DiffServ model PDP. The EAP messages may be
   opaque to the edges
   of PEP.

   Typically, when the network that can have many interfaces PEP boots up, it sends itĂs capabilities to the
   PDP in a COPS message and many specialized
   services. Previous PIBs only supported is than configured by the static configuration of
   data paths. This meant that dynamic events such as binding of new
   clients to existing PDP with one or new services were difficult to support
   because there was no way to anticipate new clients and because most
   provisioning was managing classifiers on a per client per service
   basis did not scale well.

   This PIB addresses
   more datapathEventHandlers specifying the criteria for generating
   PEP Event Messages. The first message after this problem by preserving provisioning
   process from the basic data path
   semantics but separating PEP to the creation of sessions into PDP is a new data
   path component. This provides Event Message. The PEP
   sends a stable data path for COPS request to the generation
   of sessions (and authorizations) while also supporting PDP containing a stable data
   path for new instance of the services that various sessions may make use of.
   Event table. The
   linchpin of this PIB is eventEventHdlr attribute in the Accessor Event table entry
   is a ReferenceId that provides points to a new form dpeventHandler entry indicating
   (by means of a
   demultiplexor the dpEventHdlrAuthProtocol) that separates streams of traffic into individually
   authorizable sessions. These sessions can in turn be bound EAP is a valid
   protocol to pre-
   configured services. Further, with use for this PIB, modifications to
   service policies can added or removed at Event. Also, the session level rather
   than the raw data path level.

Weiss et al.             Expires October 2000                [Page 18] 
   So far we have only discussed the value of authorizing a session
   when eventCause attribute in
   the link notices new IP address. However, it Event table entry is worth noting a ReferenceId that because the Accessor is part points to an
   eventhdlrElement indication of which Filter (by means of the data path definition, it is
   far more flexible. For instance,
   eventhdlrEventScope) triggered the Accessor can be placed behind a
   Classifier event.

   All EAP messages necessary to explicitly authorize access complete the authentication process
   will be forwarded to a specific part the PDP. All of the
   network or specific services. The Accessor can also be negotiation occurs between
   the FailNext
   element behind a meter resulting in an authorization Client and the PDP and should, except for the use of
   out-of-profile traffic. Bandwidth Brokers could use this approach or
   an Accessor trapping RSVP RESV messages EAP message code
   field, not be examined by the PEP. In order to support dynamic bandwidth
   allocation decisions.

   The integration of Accessor multiple EAP
   protocols, this PIB supports a generic EAP request class and Session as Data Path Functional
   Elements allows seamless integration with DiffServ provisioning.
   DiffServ network device mechanism policy control continues to be
   supported with EAP
   response class. Each class has a single string attribute
   (authEapReqExtSpecific and authEapRespExtSpecific, respectively)
   within which the use of DiffServ PIB [DSPIB] with added
   functionality at entire EAP message is passed.

   Although figure 3.1 shows two EAP messages going from the edge of PDP to the network with usage of Accessor
   Client and
   Session.  Totally controlled via two EAP messages being returned from the use of COPS-PR.

   The Policy Server level interaction with DiffServ comes naturally
   with client to the integration
   PDP, the actual number of Accessor and Session messages exchanged can be any amount. The
   PDP may continue to retrieve additional credentials from the client
   for as long as it wishes. As soon as Data Path Functional
   Elements when the network data model is common and scoped
   appropriately in PDP has all the schema level, with necessary
   credentials from the Accessor becoming
   stimuli for DiffServ provisioning.

2.6. Interactions client, the PDP may continue to provision the
   PEP with RSVP model

   The Accessor model provides a means for detecting RSVP RESV
   messages. policies. This means that the traditional COPS outsourcing model
   could eventually be phased out is action is not shown in favor of the provisioning model
   and figure 3.1.

   The PDP should end the use of this PIB. Before this option is fully realized one
   issue will need to be addressed. Because RSVP uses EAP negotiation with an EAP Success or an EAP
   Failure message. If the same message
   to create PDP sends a reservation as it does to modify EAP Success, the reservation, new
   hooks will need to be supplied in PEP must from
   then on use the Accessor in order matchNext Prid to detect
   modified reservations for existing sessions.

3. Supporting various client Authentication Protocols

   In determine the operational model next processing
   filter for this PIB, data defined by the Authentication Server is
   a specific function of values described using the PDP.
   eventhdlrEventScope.

3.2.2. AuthEapReqExt and AuthEapRespExt data structures

   The main purpose of EAP messages are embedded in COPS by sending an
   authentication portions instance of this PIB is to verify the validity of
   client credentials by
   authEapReqExt or authEapRespExt table, which each have an Authentiation Server. attribute
   (Specific) to encapsulate the appropriate EAP messages necessary for
   the authentication mechanism. The verification
   process itself may do this whilst ensuring some level of
   authenticity, confidentiality and integrity. Messages exchanged
   between a Client authEapReqExt table is owned and Authentication Server (PDP) may remain
   confidential to PEP's
   managed by the PEP, while the authEapReqExt table is owned and Proxy Servers. The message integrity may
   be ensured
   managed by some hashing algorithm so PEP's the PDP. Put another way, the PDP generates authEapReqExt
   instances that it sends in Decision messages and Proxy's may
   inspect but not modify the content of authentication PEP generates
   authEapRespExt instances that it sends in Report messages.
   Clients, PEP's, Proxy's and PDP's will always need some security
   method to ensure message authenticity.

Weiss et al.             Expires October 2000                [Page 19] 
   Some authentication protocols explicitly consider proxies by
   allowing Since
   neither the payload PEP nor the PDP needs to be carried over a variety of transports.
   Others depend on maintain the termination point 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 connection to
   explicitly proxy
   AuthExt class, they both inherit the authentication, when that attributes of AuthExt.

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

   Fig 3.2: Data elements in AuthEapReqExt and AuthEapRespExt tables

   The AuthEapReXXExt class contains three attributes. The instanceId
   is necessary. In
   order used to demonstrate uniquely define the general utility of this model, a variety of
   client authentication protocols will be considered instance in this document.
   For each protocol, the negotiation mechanism will table. However, since
   EAP messages are meant to be described and opaque, they should not be referenced.
   Because the mapping purpose of the classes is to this framework will be detailed.

3.1. carry EAP Authentication messages and each
   message is transient instances of these tables are temporary and
   should not be referred to. The most significant aspect distinguishing Event attribute points to the Event
   table entry for which EAP [EAP] from other
   authentication protocols is that being negotiated. The format of EAP assumes
   packages being passed by the negotiation AuthEapReXXExt classes is
   between the client and the authentication server. In anticipation of
   the fact that the terminating point described in
   [EAP].

3.3. PAP Authentication

   PAP (Password Authentication Protocol), as described in section 2 of
   [AUTH] is a connection such as PPP or
   L2TP very simple authentication mechanism used over PPP. It
   is not necessarily the same as the agent managing client
   authentication, EAP encapsulates itĂs negotiation process in a
   separate header that can be forwarded in entirety considered to be a secure mechanism, since it sends passwords
   over the server.
   This mechanism provides extra wire in clear text format. However, where one-time
   passwords are used, this security by preventing intermediate
   proxies from monitoring or managing authentication credentials.

   EAP supports a number of different authentication mechanisms
   including MD5, TLS, concern is mitigated. It is
   described here nonetheless for illustration purposes and One-Time-Password authentication. because it
   may still be used among ISPs, or in situations where another layer
   already performs encryption for security.

   The terminology used in [EAP] [AUTH] differs from the terminology used in
   this document. In particular, the peer, peer as defined in section 1.2 of
   [EAP],
   [AUTH] is referred to as 'Client' "Client" in this document. Similar, the
   'authenticator'
   "authenticator" is called a PEP in this document and 'back-end
   server' is called the Authentication Server function of the PDP (or
   just PDP) in this document.

3.1.1. EAP Message sequence

   The generic

3.3.1. PAP Connection sequence of transmissions between the PEP and PDP has
   already been described in section 2. In particular, figure
   (reference to the figure on slide 3) gives an overview of the
   messages involved between the Client workstation, PEP and PDP. EAP
   messages are embedded in PPP packets in the communication between
   the Client and the PEP. In the communication between the PEP and
   PDP, the EAP messages are embedded in COPS Request, COPS Decision
   and COPS Report messages. Figure 3.1 shows how EAP may be used

   Figure 3.3 shows how PAP may be used to retrieve credentials from
   the client workstation by the PDP.

Weiss et al.             Expires October 2000                [Page 20]

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

   Fig 3.1: 3.3: Embedding of EAP PAP messages between the Client workstation
   and the PEP, and between the PEP and PDP. The EAP messages may be
   opaque to the PEP.

   Typically, when the PEP boots up, it is configured with one or more
   Accessor decisions specifying the criteria for generating an PEP
   Access Request. The first message from the PEP to the PDP is a
   request to initiate a new Session. The PEP sends a COPS request to
   the PDP containing a new instance of the Session table. The
   sessionAccessor attribute in the Session table entry is a
   ReferenceId that points to an AccessorTable entry indicating that
   EAP is a valid protocol to use in this Session.

   When the Accessor dpEventHandler has been configured to require
   authentication, a PEP session request Event message will not be generated until
   after a minimal set of credentials have been negotiated with the
   client. For EAP, PAP, this means that a PEP Access Request Event Message will not be
   generated until after the sessionRealm authRealm and sessionUsername authUsername have been
   determined. This means that that the PEP must receive an EAP Identity Response a PAP Identity
   message before it can send the PEP Access Request.

       Session table attribute    Attribute type
       -------                    -------
       sessionId                  InstanceId
       sessionStatus              INTEGER
       sessionRealm               OCTET STRING
       sessionUsername            OCTET STRING
       sessionDataPath            Prid
       sessionBinding             ReferenceId
       sessionAccessor            ReferenceId

   Figure 3.2: Data elements of Event Message.

   The Client will send the Session datastructure.

Weiss et al.             Expires October 2000                [Page 21] 
   All EAP messages necessary Identity and Password to complete the authentication process PEP. The PEP
   will be forwarded to the PDP. With the exception of EAP Identity
   messages, embed the negotiation occurs between password into the Client userPapExt datastructure and send
   this to the PDP. In
   order to support multiple EAP protocols, Since 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 datastructure inherits the PDP to fields of the
   Client
   userAuthExt data structure and two EAP messages being returned from the client to extAuth data structure, it will
   also contain the
   PDP, PAP identity attribute inserted into the actual number
   authUsername attribute of messages exchanged can be any amount. this Instance.

   The
   PDP may continue to retrieve additional credentials from the client
   for as long as it wishes. As soon as the PDP has all the necessary
   credentials first connection from the client, the PDP may continue PEP to provision the
   PEP with policies. This is action is not shown in figure 3.1.

   The PDP should not end the EAP negotiation with is an EAP Success or alert that an
   EAP Failure message. Instead, it must send a PDP Access Response,
   which takes the form of a COPS Decision.
   event was triggered. The PDP Access Response
   contains PEP sends an Event Message over COPS to the
   PDP containing a new instance of the SessionTable with the SessionStatus set
   to either ENABLED or DISABLED. Event table. The PEP must upon receipt eventEventHdlr
   attribute in the Event table entry is a ReferenceId that points to a
   dpeventHandler entry indicating (by means of this
   COPS Decision message, send an EAP Success or EAP Failure the
   dpEventHdlrAuthProtocol) that PAP is a valid protocol to use for
   this Event. Also, the
   Client Workstation.

3.1.2. AuthEapReXXExt data structures

   The EAP messages are embedded eventCause attribute in COPS by sending the Event table entry
   is a ReferenceId that points to an eventhdlrElement indication which
   Filter (by means of the eventhdlrEventScope) did trigger the event.
   Along with this new instance of the
   authEapReqExt or authEapRespExt Event table, which each have the PEP must also
   send an attribute
   (Specific) to encapsulate instance of the appropriate EAP messages necessary for AuthPapExt table.

   Besides these required instances, the authentication mechanism. The authEapReqExt table is owned and
   managed PEP might have been configured
   by the PEP, while PDP to sent additional information about the authEapReqExt table is owned and
   managed by client to the
   PDP. Put another way, the PDP generates authEapReqExt
   instances that it sends For example in Decision messages the case of a dialup connection between the
   Client and the PEP generates
   authEapRespExt instances PEP, the PDP might specify using a contextData
   instance that it sends in Report messages. Since
   neither the PEP nor the should also sent an instance of a
   ctxtDialupInterface.

   The PDP needs to maintain performs the messages
   permanently, PAP authentication. When the same instance of each class is used when more than
   one exchange authentication is required in each direction.

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

   Fig 3.3: Data elements in AuthEapReqExt
   complete and AuthEapRespExt tables

   The AuthEapReXXExt class contains three attributes. The instanceId the PDP is used ready to uniquely define authorize the instance in event, the table. However, since
   EAP messages are meant PDP
   optionally provisions the PEP with policies. This sequence of
   messages should terminate 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 be opaque, they either TRUE or FALSE. The PEP must upon receipt of this COPS
   Decision message, send PAP ACK or NACK message to the client. Also,
   if the authExtAuthSuccess attribute was true, then the PEP should not be referenced.
   Because
   keep track of this particular data, defined by the purpose unique values of
   the classes fields specified using the eventhdlrEventScope.

3.3.2. AuthPapExtEntry datastructure

   The PAP information is to carry EAP messages and each

Weiss et al.             Expires October 2000                [Page 22] 
   message embedded in the PEP Event Message by sending
   an instance of the authPapExt table. Since the authPapExt table is transient instances
   an extension of the userAuthExt table, which is an extension of the
   authExt table, the authPapExt inherits the attributes of these tables are temporary
   tables.

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

   Fig 3.4: Attributes of the AuthPapExt table.

   The AuthPapExt contains five attributes. The instanceId is used to
   uniquely define the instance in the table. However, since the PAP
   password is sent to the PDP once and is needed by neither the PDP
   nor the PEP after the client is authenticated, the instance should
   not be referred to. referenced after it is used the first time. The Session Event
   attribute points to the
   Session Event table entry for which EAP PAP is being
   negotiated.

   The format result of
   EAP packages being passed by the AuthEapReXXExt classes is described
   in [EAP].

3.2. PAP Authentication authentication for PAP (Password Authentication Protocol), as described is sent in section 2 of
   [AUTH] the
   AuthExtResult table. Since the authExtResult table is a very simple authentication mechanism used over PPP. It an extension
   of the AuthExt table, it inherits the attributes of AuthExt.

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

   Fig 3.5: Attributes of the AuthExtResult table.

   The AuthExtResult is not considered sent by the PDP to be the PEP. If the
   authentication was successful and the PEP should from now on use the
   matchNext Prid to determine the next processing filter (the next
   component down the internal datapath in the PEP) for all traffic
   defined by the values of the parameters as set in the
   eventhdlrHandlerScope.

3.4. CHAP Authentication

   CHAP (Challenge Authentication Protocol) [CHAP] is a strong security
   authentication mechanism, since it sends
   passwords over which eliminates the wire in clear text format. However, where one-
   time need to send
   passwords are used, this security concern is mitigated. It is
   described here nonetheless for illustration purposes and because it
   may still be used among ISPs, or in situations where another layer
   already performs the clear, like PAP does. With CHAP, the Authenticator
   generates a challenge key, sends it to the Peer (Client) and the
   client responds with a cryptographically hashed response that
   depends upon the Challenge and a secret key. The PDP checks the
   secret key by performing the same encryption for security. and comparing the
   results.

   The terminology used in [AUTH] [CHAP] differs from the terminology used in
   this document. In particular, the peer as defined in section 1.2 of
   [AUTH]
   [CHAP] is referred to as 'Client' "Client" in this document. Similar, the
   'authenticator'
   "authenticator" is called PEP in this document.

3.2.1. PAP

3.4.1. CHAP Connection sequence

   Figure 3.4 3.6 shows how PAP CHAP may be used to retrieve credentials from
   the client workstation by the PDP.

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

   Fig 3.4: 3.6: Embedding of PAP CHAP messages between the Client workstation
   and the PEP, and between the PEP and PDP.

   The Client will send

   As soon as the Identity PEP finished negotiating CHAP as the Authentication
   protocol, it generates a challenge itself, and Password sends this to the PEP.
   Client. The PEP client will embed the password into respond to this authentication request by
   sending his or her identity, an AuthPapExtEntry datastructure identifier and
   send this to the PDP. In addition, response. The
   response is a cryptographically encrypted hash based on the PAP identity attribute will
   challenge and secret key (password).

   The identifier is only used to keep track of CHAP messages, and
   needs to be inserted into used by the sessionUsername attribute of PEP to recover the Session entry. associated challenge.

   The first connection from the PEP to the PDP is a request to
   initiate notice of a new Session.
   Event. The PEP sends a PEP Access Request an Event Message to the PDP containing a new
   instance of the SessionTable. Event Table. The

Weiss et al.             Expires October 2000                [Page 23] 
   sessionAccessor eventEventHdlr attribute in the Session
   Event table entry is a ReferenceId that points to an AccessorTable a dpeventHandler
   entry indicating (by means of the dpEventHdlrAuthProtocol) that
   PAP CHAP
   is a valid protocol to use in for this Session. Event. Also, the eventCause
   attribute in the Event table entry is a ReferenceId 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 Session Event table, the PEP must also send an instance of
   the AuthPapExt AuthChapExt table.

3.2.2. AuthPapExtEntry datastructure

   The PAP information is embedded in

   Note that having the PEP Access Request by sending
   an instance of issue the authPapExt table.

       AuthPapExt table attributes         Attribute type
       ----------------                    ---------
       authExtId                           InstanceId
       authExtSession                      ReferenceId
       authPapExtPwd                       OCTET STRING

   Fig 3.5: Atributes of challenge allows the AuthPapExt entry.

   The AuthPapExtEntry contains three attributes. The instanceId is
   used PEP to uniquely define the instance in the table. However, since
   perpetrate fraud by issuing a replayed request (assuming that the PAP password
   PEP and PDP are in different domains). The only guard against this
   is sent for the PDP to check that multiple authentication requests for
   the same client have unique challenges. This may be slow. PDP once and
   Authentication server developers who feel this is needed a security issue
   may want to use EAP-MD5 authentication rather then CHAP
   authentication, since EAP-MD5 addresses this problem by neither letting the
   PDP nor generate the challenge.

   Besides these required instances, the PEP after might have been configured
   by the PDP to send additional information about the client is authenticated, to the instance
   should not be referenced after it is used
   PDP. For example in the first time. The
   Session attribute points to case of a dialup connection between the Session table entry for which PAP is
   being negotiated.
   Client and the PEP, the PDP might specify using a contextData
   instance that the PEP should also sent an instance of a
   ctxtDialupInterface.

   The PDP performs the PAP CHAP authentication. When the authentication is
   complete and the PDP is ready to authorize the session, client, the PDP may
   optionally
   choose to provision the PEP with policies. policies for this client, which was
   probably the intention of starting this authentication process in
   the first place. This sequence of messages should terminate with a
   PDP Access Provisioning Decision (a COPS-PR Decision message). The PDP Access Response
   Provisioning Decision contains the an instance of the Session AuthExtResult
   table with the SessionStatus authExtAuthSuccess set to either ENABLED TRUE or
   DISABLED. FALSE. The
   PEP must upon receipt of this COPS Decision message, send PAP ACK or
   NACK message to the client.

3.3. CHAP Authentication

   CHAP (Challenge Authentication Protocol) [CHAP] is a strong
   authentication mechanism, which eliminates the need to send
   passwords in Also, if the clear, like PAP does. With CHAP, authExtAuthSuccess
   attribute was true, then the Authenticator
   generates a challenge key, sends it to PEP should keep track of this
   particular data, defined by the Peer (Client) and unique values of the
   client responds with a cryptographically hashed response that
   depends upon fields
   specified using the Challenge and a secret key. eventhdlrEventScope.

3.4.2. AuthChapExtEntry datastructure

   The PDP checks CHAP information is embedded in the
   secret key Event Message by performing sending an
   instance of the same encryption and comparing authChapExt table. Since the
   results. authChapExt table is an
   extension of the userAuthExt table, which is an extension of the
   authExt table, the 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

   Fig 3.7: Data elements of the AuthChapExtEntry datastructure.

   The terminology AuthChapExtEntry contains seven attributes. The instanceId is
   used in [CHAP] differs from to uniquely define the terminology used instance in
   this document. In particular, the peer as defined in section 1.2 of
   [CHAP] table. However, since
   the CHAP information is referred sent to as 'Client' in this document. Similar, the
   'authenticator' PDP once and is called needed by
   neither the PDP nor the PEP in this document.

Weiss et al.             Expires October 2000                [Page 24] 

3.3.1. CHAP Connection sequence

   Figure 3.6 shows how CHAP may after the client is authenticated, the
   instance should not be referenced after it is used the first time.
   The Event attribute points to retrieve credentials the Event table entry for which PAP is
   being negotiated.

   The authChapExtChal attribute is the challenge generated by the PEP.
   The PDP may check the challenge to see if it is different from
   challenges used earlier. This provides an increased level of
   security. The Response and the Id is taken from the CHAP message
   sent by the client workstation and put into the AuthChapExtEntry by the PDP.

   time
    |   +---+                     +---+                          +---+
    |   |   |                     |   |<- COPS-Dec Accessor -----|   |
    |   |   |-- 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 Ses-CHAP ---->|   |
    |   |   |                     |   |-- COPS-Rep CHAP Resp, -->|   |
    |   |   |                     |   |--                Chal -->|   |
    |   |   |                     |   |                          |   |
    |   |   |                     |   |<- COPS-Dec Ses-Enable ---|   |
    |   |   |<- PPP CHAP ack -----|   |                          |   |
    V   +---+                     +---+                          +---+

   Fig 3.6: Embedding PEP.

3.5. HTTP Authentication

   This section will be added in a subsequent version of CHAP messages between this draft.

4. Data Structures

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

4.1. Event class

   Instances of this table represent events that occurred at the PEP, and between PEP.
   The events reference the PEP event handler instance and PDP.

   As soon as the PEP finished negotiating CHAP as specific
   event handler element that the Authentication
   protocol, it generates a challenge itself, and sends event was caught by.

   The attributes of this class are:

        eventId (InstanceId)
           Identifies this object

        eventEventHdlr (ReferenceId)
           This attribute allows a PEP to the
   Client. The client will respond indicate to the PDP that this authentication request by
   sending his or her identity,
           event was generated due to the referenced Event Handler.
           This attribute references an identifier and event handler via the response. The
   response is a cryptographically encrypted hash based on
           indirection PRC frwkReference, since the
   challenge event handler and secret key (password).

   The identifier is only used to keep track of CHAP messages, and
   needs
           event could potentially belong to be used by a different PIB contexts.

        eventCause (ReferenceId)
           This attribute references the PEP specific instance in a group
           of event Handler elements belonging to recover an event Handler that
           resulted in this event. This attribute references a specific
           event handler element via the associated challenge.

   The first connection from indirection PRC frwkReference,
           since the PEP 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 is a request on the PEP to
   initiate a new Session. catch
   specific events. The PEP sends Event Handlers reference a PEP Access Request to group of
   eventHdlrElement PRIs that contain the
   PDP containing a new instance scope of the SessionTable. The
   sessionAccessor attribute in event and
   specify the Session table entry is a
   ReferenceId that points context data to send to the PDP when an AccessorTable entry indicating that
   CHAP event is a valid protocol to use in this Session. Along with this new
   instance caught.

   The attributes of the Session table, the PEP must also send EventHandler Class are as follows:

        eventHandlerId (InstanceId)
           identifies an instance of
   the AuthChapExt table.

   Note that having the PEP issue the challenge allows the PEP this class

        eventHandlerElements (TagReferenceId)
           A reference to
   perpetrate fraud by issuing a replayed request (assuming that group of eventHdlrElement instances, each
           of which determines the
   PEP scope (criteria for generating a new
           request) and PDP are what context information to send in different domains). a request.

        eventHandlerNonMatchNext (Prid)
           The only guard against this
   is data path for "out of scope" traffic that is not matched
           by one of the PDP eventHdlrElementĂs filter clauses.

4.3. EventHdlrElement class

   The purpose of the EventHdlrElement is to check that specify the
   characteristics of the EventHandler. The attributes in the
   EventHdlrElement provide maximal reuse by allowing multiple authentication requests for
   instances of an EventHandler to reuse the same client have unique challenges. This may be slow. PDP and
   Authentication server developers that feel EventHdlrElement
   instance. Each Instance of this is a security issue

Weiss et al.             Expires October 2000                [Page 25] 
   may want PRC belongs to use EAP-MD5 authentication rather then CHAP
   authentication, since EAP-MD5 addresses this problem by letting the
   PDP generate the challenge.

3.3.2. AuthChapExtEntry datastructure a group of
   eventHdlrElement PRIs. The CHAP information group is embedded in identified by the PEP Access Request
   eventHdlrElementGrpId attribute. These are provisioned by
   sending an instance of the authChapExt table.

       AuthChapExt table attributes        Attribute type
       -----------------                   ---------
       authExtId                           InstanceId
       authExtSession                      ReferenceId
       authChapExtId                       Unsigned32
       authChapExtChal                     OCTET STRING
       authChapExtResp                     OCTET STRING

   Fig 3.7: Data elements of PDP on
   the AuthChapExtEntry datastructure.

   The AuthChapExtEntry contains four attributes. The instanceId is
   used PEP to uniquely define catch specific events. This PRC contains the instance in scope of the table. However, since
   event and specifies the CHAP information is sent context data type to send to the PDP once 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 needed why Event objects generated by
   neither the PDP nor the PEP after reference
   both the client Event Handler and the Event Handler Element that generated
   the event.

   One key aspect of the EventHdlrElement is authenticated, the
   instance should not be referenced after it 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. 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 Session Event Criteria attribute points to defines the Session table entry for frequency with which
   PAP is being negotiated.

   The challenge is events
   should be generated. If the challenge Event Criteria is set to One_Time, only
   one event will ever be generated by for that EventHdlrElement when the PEP. The PDP may
   check
   first match occurs, irrespective of the challenge number of subsequent
   matches. If the Event Criteria is set to see if it Every_Time, each match will
   result in an Event Message. A hybrid case is defined called
   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 challenges used
   earlier. This a unique n-tuple in order to provides generate an increased level Event Message. See
   Section 4.6 for more details of security. The
   Response and the Id behavior of the On_Change
   attribute.

   The EventHdlrHandleScope is optional. If it is not specified, itĂs
   behavioral rules are taken from the CHAP message sent by EventHdlrEventScope objects
   associated with the
   client and put into relevant EventHdlrElement. In other words, the AuthChapExtEntry by
   criteria for generating Request Handles will be identical to the PEP.
   criteria for generating Event Messages when the EventHdlrHandleScope
   is not explicitly specified.

   The PDP performs attributes of the CHAP authentication. When EventHdlrElement class are:

        eventHdlrElementId (InstanceId)
           identifies the authentication object
        eventHdlrElementEventCriteria (Unsigned32)
           Indicates when an event is
   complete generated. Valid options are
           one_time, every_time and the PDP is ready on_change. This attribute allows
           event Handlers to authorize the session, distinguish one time events (ignore after
           the PDP may
   optionally choose first match) from recurring events (generate an event
           every time a match occurs).  An enum type is also define to provision the PEP with policies for
           specify that
   session. This sequence of messages a new event should terminate with be generated when a PDP
   Access Decision (a COPS-PR Decision message). The PDP Access
   Response contains the instance of the Session table with the
   SessionStatus specific
           set to either ENABLED or DISABLED. The PEP must upon
   receipt of this COPS Decision message, send CHAP ACK or NACK message fields change. This is important for protocols like
           RSVP because messages are sent both to demonstrate that the client.

3.4. HTTP Authentication

   This section will
           reservation is active and to notify hops of changes to
           reservations. Since only changes need to propagate to the
           PDP, the on_change option indicates that that events should
           be added in 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 subsequent version group of eventHdlrEventScope entries associated
           with this draft.

Weiss et al.             Expires October 2000                [Page 26] 

4. Data Structures 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 classes path for traffic in scope.

4.4. EventHdlrEventScope class

   This PRC defines the scope of an event handler element using
   references to filters defined formally in the Authentication Framework PIB module
   (section 7) or in some other
   PIBs. These filters may describe specific protocol properties for
   which events need to be generated. These filter references are introduced
   grouped using a TagId, and discussed here.

4.1. Accessor class

   The Accessor class models this group is then referenced from the accessor component in
   eventHdlrElement PRC.

   Whenever traffic arrives at the PEP
   discussed in section 2.1. An instance of this class, with EventHandler for which an Event
   Message has not already been generated, it is compared against the aid
   FilterEntry objects of the EventHdlrEventScope objects to which it points, identifies when referenced by
   the PEP should send
   an access (i.e. authorization) request to EventHdlrElement. If it matches the PDP. As a result criteria specified in all of
   this request,
   the FilterEntry objects, a new session may be started. Hence, the Accessor can
   be said Event Message is generated and sent
   to create or remove Session entries. the PDP. The Accessor is installed on the PEP by the PDP and references a
   list of authentication protocols supported (AccessorAuthProtocol)
   and a list value of interface and header class identifiers whose instances
   must be included EventHdlrElementĂs EventCriteria attribute
   in conjunction with the PEP Access Request (the ContextData).

   The attributes value of the Accessor Class are as follows:

        AccessorId (InstanceId)
           identifies Event Scope classĂs ChangeFlag
   attribute determine whether an instance of this class

        AccessorRequestAuth (Boolean)
           True if authentication is required
           False Event Message will be generated.

   For example, if not.

        AccessorAccElmRef (ReferenceId)
           points to the AccessorElement a FilterEntry object (sec. 4.2) for this
           Accessor

        AccessorAuthProtocol (TagReferenceId)
           references AccessorAuthProtocol objects (sec. 4.4). There
           may be several AccessorAuthProtocol objects with this
           TagReferenceId. Each specifies one authentication protocol
           that may be used for client authentication in order to
           satisfy the access request.

        AccessorAuthContext (TagReferenceId)
           references ContextData objects (sec. 4.5). There may be
           several ContextData objects with this TagReferenceId. Each specifies SRC IP address
   (10.20.0.0) and SRC IP Mask (FF.FF.0.0) and the PRI of one interface or header element class
           for which an object instance must be included in access
           requests triggered by this Accessor. This attribute must be
           assigned a valid TagReferenceId when the AccessorRequestAuth
           attribute EventCriteria is set
   to True.

        AccessorDefaultDataPath (PRID) (optional)
           points to One_Time, the next data path element that will process out
           of scope traffic ű that is not one of first address in the following:
           1. Traffic that is part range of 10.20.0.0 and
   10.20.255.255 will generate an established session.
           2. Traffic matching a pending session (one for which event and no events will follow. If
   the PEP

Weiss et al.             Expires October 2000                [Page 27] EventCriteria is waiting set to Every_Time for an access response).
           3. A packet that triggers the creation of same attribute
   settings, each time a session.

4.2. AccessorElement class

   Generally speaking packet contains an IP address within the purpose of range
   an Event Message will be generated. If the AccessorElement EventCriteria is set to specify
   the characteristics of the Accessor. The attributes in
   On_Change and the
   AccessorElement are there eventHdlrEventScopeChangeFlag is set to provide maximal resuse by allowing
   multiple instances of an Accessor to reuse the same AccessorElement
   instance. AccessorElement object is referenced by an Accessor
   object. It specifies a list of one or more AccessorSessionScope
   objects, True, each of which defines a
   new IP address within the range 10.20.0.0 and 10.20.255.255 will
   trigger for creating a Session
   object and generating an access request. It also specifies what to
   do with traffic for new Event Message. However, as soon as a newly created session while 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 PEP
   EventCriteria is
   awaiting a response set to the access request.

   The attributes of the AccessorElement class are:

        AccessorElementId (InstanceId)
           identifies the object

        AccessorElementScope (TagReferenceId)
           references AccessorSessionScope objects (section 4.3). There
           may be one or more AccessorSessionScope objects, each of
           which specifies conditions for creating a Session On_Change and
           generating an access request.

        AccessorElementInterimFwdBehavior (Drop, Forward, Queue)
           specifies what the
   eventHdlrEventScopeChangeFlag is set to do with traffic False for the newly created
           session while awaiting example
   address range, than the response to eventHdlrEventScope instance with the access request.
           Drop means
   ChangeFlag set to drop all packets received for True will determine uniqueness. In this session
           until scenario,
   the PEP receives address range is acting as a PDP Access Response packet. Forward
           means forward interim traffic using the data path specified
           by the AccessorElementDefaultSessionDataPath attribute.
           Queue means strict filter that must be met
   without regard to buffer interim traffic which address in a hold queue to be
           forwarded after access the range is granted by a PDP Access Response
           packet.

           This attribute provides responsible or
   whether that address has been seen previously.

   When multiple fields are specified for a great deal of flexibility
           regarding the treatment filter and the ChangeFlag
   is set to true, each unique combination of interim traffic. field values generates an
   event. For example, it
           may be blocked altogether, it may be passed, but be given
           best effort service, or it may be filtered if the SRC IP is assigned a range of
   10.10.10.224 to go only 10.10.10.255 and DST Ports 80 to a
           particular web server at which authentication will take
           place (see section 3.4)

        AccessorElementDefaultSessionDataPath (Prid)
           specifies the interim data path element that will process
           traffic 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 new sessions created by this accessor while
           awaiting an access response if the value
   construction of the
           AccessorElementInterimFwdBehavior attribute is Forward.

           This attribute also specifies the default data path element
           that will process traffic 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 this session if no other

Weiss et al.             Expires October 2000                [Page 28] 
           element is configured by the PDP.
   a detailed example of filter construction.

   The value attributes of this
           attribute will be used to initialize the value of class are:

        eventHdlrEventScopeId (InstanceId)
           Identifies this object

        eventHdlrEventScopeGroup (TagId)
           Contains the
           SessionDataPath attribute of Session objects created tag by which the EventHdlrElement references
           this
           accessor. The PDP may subsequently override object. This is the
           SessionDataPath attribute if it wishes with means by which a PDP Access
           Reponse message (Section 5.4).

4.3. AccessorSessionScope class

   The AccessorSessionScope class determines the criteria for
   generating list of filters
           can be associated with an EventHandler.

        eventHdlrEventScopeFilter (PRID)
           Points to a new unique session. FilterEntries as FilterEntry object (as defined in the
   framework PIB [FWPIB] allow Framework
           PIB) that specifies the filter for this EventHdlrEventScope
           object

        eventHdlrEventScopePrecedence (Integer)
           Represents the specification precedence of this criterion with respect to
           other criteria within the set of
   header fields that scope each session. Whenever traffic arrives at same group. When the Accessor that precedence is not part of
           unique, the instance represents an established session, it is
   compared against alternative criterion (an
           OR function). When the FilterEntry objects precedence for two or more instances
           of the AccessorSessionScope
   objects referenced by eventHdlrEventScope class is the AccessorElement. If it matches same, the
   criteria specified in attributes
           within all of the FilterEntry objects, instances are treated collectively as a
           single filter criteria.

        eventHdlrEventScopeChangeFlag (TruthValue)
           Boolean value, if set to "True" indicates that a new Session
   object will event
           should be created and a PEP Access generated if any of the assigned fields in the
           associated filter change.

4.5. EventHdlrHandleScope class

   This PRC defines the scope of Request will be sent Handles generated by the PEP
   due to events caught by the
   PDP. For example, if a FilterEntry object specifies SRC IP address
   (10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address within Event Handler Element. Each instance of
   this PRC references filters defined in the range 10.20.0.0 and 10.20.255.255 will trigger 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 session.
   Further after a session has been allocated for a specific SRC IP
   address like 10.20.15.109, all subsequent traffic will COPS Request
   Handles must be forwarded
   from created by the Accessor PEP based on protocol properties. The
   Event Handler may be set up to the data path assigned be sensitive to the newly created
   session.

   When multiple fields are specified for the filter, each unique
   pairing of specific field values gets allocated a distinct session. For
   example, if
   and/or the SRC IP was assigned uniqueness of a range set of 10.10.10.224 to
   10.10.10.255 values considered together. This
   accommodates various behaviors of signaling protocols. These filter
   references are grouped using a TagId, and DST Ports 80 to 90 this group is then 10.10.10.240+80,
   10.10.10.240+81, and 10.10.10.250+80 would all be assigned separate
   sessions.
   referenced from the eventHdlrElement PRC via the
   eventHdlrElementHandleScope TagReference.

   The combination behavior of supporting multiple filters and being
   able the EventHdlrHandleScope class is identical 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
   behavior of 10.10.x.x and VLANs 100 to
   120). the EventHdlrEventScope. The attributes of this class are:

        AccessorSessionScopeId (InstanceId)
           identifies this object

        AccessorSessionScopeGroup (TagId)
           contains only difference is the tag by which
   EventHdlrEventScope determines when new Events are created and the AccessorElement references
           this object.
   EventHdlrHandleScope determines when new COPS Request Handles are
   created. It is important to note that the means by which attributes determining
   when a list of filters can new Handle is created MUST be associated with a Accessor

        AccessorSessionScopeFilter (PRID)
           points to a FilterEntry object (as defined in the Framework
           PIB) that specifies subset of the filter
   attributes and filter values specified for this AccessorSessionScope
           object

Weiss et al.             Expires October 2000                [Page 29] 
        AccessorSessionScopePrecedence (Integer)
           specifies how multiple FilterEntry objects interact

4.4. AccessorAuthProtocol class the EventHdlrEventScope.
   The AccessorAuthProtocol class allows a PDP reason for this is that an Event Message MUST use one of the
   available Request Handles to configure notify the set PDP of
   authentication protocols that an Event. If the
   attributes and values used in the EventHdlrEventScope are allowed for not a given Accessor. The
   instances
   superset of this class are grouped together using the same TagId
   value, attributes and values EventHdlrHandleScope, then
   there may be no valid Handle over which the reference Event Message can be
   sent to which are specified in the Accessor. PDP.

   The attributes EventHdlrHandleScope is optional. If it is not specified, 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 and 4.6 for more details on the operational
   behavior of this class are:

        AccessorAuthProtocolId class.

        eventHdlrHandleScopeId (InstanceId)
   An arbitrary integer index that uniquely identifies this object

        AccessorAuthProtocolGroup an instance of
   the eventHdlrHandleScopeTable class.

        eventHdlrHandleScopeGroup (TagId)
           contains
   Represents the tag by which binding between the Accessor references this
           object.

        AccessorAuthProtocolAuthMechanism (Enum)
           specifies an authentication mechanism 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 in access
           requests triggered by as the Accessor referencing criteria.

        eventHdlrHandleScopePrecedence (INTEGER)
   Represents the precedence of this
           AccessorAuthProtocol object. The value criterion with respect to other
   criteria within the same group. When the precedence is from unique, the
   instance represents an enumerated
           list initially consisting alternative criteria (an ORing function).
   When the precedence for two or more instances of (PAP, CHAP, EAP-MD5, and EAP-
           TLS)

4.5. ContextData class

   The ContextData the
   eventHdlrHandleScope class defines is the same, the attributes within all
   the instances are treated collectively as a single filter criteria.

        eventHdlrHandleScopeChangeFlag (TruthValue)
   Boolean value, if set of interface descriptions or
   packet header data to "True" indicates that a new Handle should
   be included in each PEP Access
   Request for sessions created by the reference Accessor. There may be
   multiple objects generated if any of this class referenced with a tag by an Accessor
   object.

   Note that the ContextData class can be part of either an Accessor
   Provisioning decision message (Section 5.1) or a Session-specific
   ContextData Request message (Section 5.5). assigned fields in the associated filter
   change.

   The attributes PDP installs EventHandlerElements as part of this class are:

        ContextDataId (InstanceId)
           identifies this object

        ContextDataGroup (TagId)
           contains constructing the tag by which an Accessor object references
           objects of this class. This attribute may only
   event handler. EventHandlerElements describe when events will be set for
           ContextData instances that
   generated and which COPS request handles will be bound used to an Accessor. If send the ContextData
   requests.

4.6. Behavior of the Event and Handle Scope classes

   The rules for interpreting Handle Scope and Event Scope are the
   same. One is applied to Handles and the other is applied to Events.

   Each scope class (Event Scope or Handle Scope) instance will be used in has a Session-specific
           ContextData Request, this attribute must be left
           unspecified.

Weiss et al.             Expires October 2000                [Page 30] 
        ContextDataSessionRef (ReferenceId)
           points to a Session object. This attribute may only be used
           for ContextData instances that will be used in a Session-
           specific ContextData Request. This attribute must be left
           unspecified for instances of ContextData instances bound to
           specific Accessors.

        ContextDataIfElement (PRC of interface elements)
           identifies an interface
   precedence value associated with it. When two or header class identifier whoĂs more scope class instance must be populated by
   instances of the PEP and included in
           an access request or a Session-specific ContextData Request.

        ContextDataEncapsulation (Integer)
           distinguishes inner and outer headers same type (event vs handle) have the same
   precedence number, they are considered part of tunnels. the same rule. For
   example, the PRC of table below lists a header element may specify that layer
           3 header information should be sent. When there are tunnels,
           however, there will be header contents (with different IP
           addresses) for the outer header than for the inner header.

           A value of zero means return all layers set of header. A
           negative n means return the nth layer from Event Scope class instances,
   their precedence values and the innermost
           header. A positive n means return filter field names and values
   associated with each instance: (FName is the nth layer from 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
           outermost header.

   In situations where
   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 ContextData is explicitly bound EventCriteria was set to an
   Accessor table entry, the ContextDataGroup attribute (TagId) must "OneTime", then if either 1 or 2 is
   matched, one event will be
   specified generated and the ContextDataSessionRef (ReferenceId) must be Null.
   When this class is used to get specific information for a session,
   the ContextDataSessionRef is used and the ContextDataGroup is Null.
   Under particular Event
   Handler Element will generate no circumstances may an instance of the ContextData class have
   both further events. Note that if
   matches occur but the ReferenceId and "OneTime" event has already been generated,
   the TagId specified.

   For examples of classes that Event Hander Element's MatchNext attribute may be referenced by still determine
   what the ContextData
   class, see section 4.8.

4.6. Session class

   Each instance of next forwarding action is for the Session class represents a session on packet event thought no
   event is generated.

   If the PEP.
   The PEP creates EventCriteria was set to "EveryTime", then every matching
   packet will cause an instance of this class and sends it in event. If the PEP
   Access Request EventCriteria was set to
   "OnChange", then events will be generated the PDP. In the PDP Access Response, the PDP sends first time a success/fail decision back to the PEP. This decision contains the
   same instance unique
   combination of attributes is seen. Setting the Session class, with its SessionStatus field
   filled ChangeFlag in to indicate the outcome of
   EventScope class (denoted by the authorization decision.
   Note that asterisks in the owner previous example),
   identifies the set of attributes for which unique combinations of
   values generated new events.

   Continuing the Session Class is always example above the PEP following table shows a stream of
   packets and the
   PEP always assigns the Instance ID.

   Sessions may whether an event will be linked to each other, meaning that 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 new session may
   be initiated within the context
                                                   matched for W & X)
   6. A=5, B=15, C=11                   Event (Unique pairing of an existing session. A & C)
   7. A=5, B=15, C=10                   No Event (Already have a
                                        matched for A & C)

4.7. EventHdlrAuthProtocol class

   This
   possible dependency is reflected in
   class allows a PDP to configure the Session class. set of authentication mechanisms
   that are allowed for users or devices that must authenticate in
   order to have access policies assigned to them.

   The attributes of the Session this class are:

        SessionId

        EventHdlrAuthProtocolId (InstanceId)

Weiss et al.             Expires October 2000                [Page 31] 
           identifies
           Identifies this object

        SessionStatus (Integer)
           set

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

        EventHdlrAuthProtocolAuthMechanism (Enum)
           Specifies an authentication mechanism to be used in Event
           Messages triggered by the PDP. Indicates whether EventHandler referencing this access attempt
           EventHdlrAuthProtocol object. The value is
           authorized (success) or unauthorized (fail) or whether from an
           authorization decision
           enumerated list initially consisting of (PAP, CHAP, EAP-MD5,
           and EAP-TLS)

4.8. DatapathEventHdlr Class
   This PRC is still pending.

        SessionRealm (Octet String) an extension of the realm field EventHandler PRC. This extension
   illustrates the use of the clientĂs Network Access Identifier
           [NAI]. SessionRealm tells EventHandler PRC concept for
   authentication usage. Instances of this PRC are provisioned by the
   PDP in what administrative
           domain on the client can be authenticated. PEP to catch specific events that require authentication
   processing. This attribute is
           optional, but must be provided PRC references a group of eventHdlrAuthProtocol
   instances that 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 AccessorRequestAuth
           attribute scope of the Accessor object is set to true access event and specify the
           specific authentication protocol supports realms.

        SessionUsername (Octet String)
           the Username field of
   context data to send to the clientĂs NAI [NAI]. PDP when an access event is caught.

   The
           SessionUsername attribute identifies the client for which attributes of this Session is being created. SessionUsername is optional,
           but must be specified class are:
        datapathEventHdlrRequestAuth (TruthValue)
           Boolean flag, if the RequestAuthentication attribute
           of the Accessor is set to true.

        SessionDataPath (PRID)
           points to the first "True" requires authentication data path element
           to process traffic for
           this session. SessionDataPath is initialized by be sent in the PEP Event Message sent to the value PDP.

        datapathEventHdlrAuthProtocol (TagReferenceId)
           References a group of the AccessorElementDefaultSessionDataPath
           attribute eventHdlrAuthProtocol instances, each
           of which specifies an authentication mechanism.

4.9. ContextData class

   This PRC specifies the AccessorElement object. The PDP may assign
           a different value before returning the Session object in the
           PDP Access Response message.

        SessionBinding (ReferenceId)
           If this is a daughter session of another session, the
           SessionBinding attribute points context information to the parent session.
           A hierarchy of sessions is useful where a client has already
           initiated a session but later wants send to access a service for
           which further authorization is needed. An Accessor can be
           created by the PDP in the data path of the parent session to
           trigger when additional service is required. A daughter
           session
   an event is created that points back caught. The context information to the parent session.
           An access request message send is sent by the PEP to the PDP to
           authorize described in
   terms of the new service. Authentication may or may not be
           required PRC data types to establish include in the daughter session.

        SessionAccessor (ReferenceId)
           points to request, the Accessor which created this Session

4.7. AuthExt class

   The AuthExt class contains authentication level of
   encapsulated data passed between the
   PDP and the client such as challenges and responses. An instance interface information for that request.

   The attributes of this class must be included with 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 Session class whose instance in a PEP
   Access Request when is to be included with
           the AccessorRequestAuth PEP request or event-specific ContextData Response.

        ContextDataEncapsulation (Integer)
           This attribute in thee
   Accessor managing the session is set allows one to True.

Weiss et al.             Expires October 2000                [Page 32] 
   The data in this class is passed distinguish between the PDP inner and the client with
   little or no involvement
           outer headers when there are multiple encapsulated headers
           of the PEP except to forward it same type in the
   appropriate AuthExt class instance. The PEP is not meant to store
   AuthExt objects. As such, this class, along with a packet.

               A value of:
               0 means all its extending
   classes, is meant to 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.

4.10. ContextData classes

   This section contains examples of classes that might be 'transient'. Its instances are temporary and
   are deleted referenced
   by the PEP after a certain time or event. The PDP, in
   its decisions, must not refer to instances of this ContextData class as classes that must be included in the
   Event Message for various types of eventHdlrElements.

   There are
   sent by two kinds of ContextData classes depending on the PEP type of
   PEP. Some PEPs receive traffic from many users over a shared port
   such as an Ethernet port.  They recognize new users based on
   information in its requests. Likewise, the PEP must not refer to
   instances sent by headers of incoming packets.  For them, the PDP. Also, since instances are deleted, it
   ContextData will come from packet headers.  The L3HeaderData class
   is
   possible for InstanceIds to an example of this kind of ContextData class.  Other PEPs receive
   traffic from one user per interface.  For them, the context data
   will be reused. information about the interface.  The AuthExt
   CtxtDialupInterfaceFramedProtocol class is extended for each authentication mechanism
   supported. As a base class, it an example of this kind
   of ContextData class.

4.10.1. CtxtL3Hdr class

   This class specifies level three header data. This class is never instantiated. used to
   inform the PDP of the details of the IP header that caused the PEP
   Event Message to be generated.

   The attributes of this class are:

        AuthExtId

        CtxtL3HdrId (InstanceId)
           identifies this object

        AuthExtSession (ReferenceId)
           points to

        CtxtL3HdrSrcAddrType (Enum)
           specifies the Session for which this object contains
           authentication information

4.7.1. AuthEapReqExt class

   The AuthEapReqExt class extends type of the AuthExt class. It contains an
   EAP message. (See sec. 3.1.) Instances packetĂs layer 3 source address

        CtxtL3HdrSrcAddr
           the packetĂs layer 3 source address

        CtxtL3HdrDstAddrType (Enum)
           specifies the type of this class are sent by the
   PDP to packetĂs layer 3 destination
           address

        CtxtL3HdrDstAddr
           the PEP. 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 ECN capable (True) or not
           (False)

        CtxtL3HdrIpOpt
           IP Options

        CtxtL3HdrEncap
           The attributes that Encap allows the PEP to indicate where this class adds header is in
           relation to other IP headers found in the base class are:

        AuthEapReqExtSpecific (Octet String)
           an EAP message [EAP] passed packet (with
           tunnels). This value 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 PDP to innermost
           header. A positive n means return the client via nth layer from the PEP in a COPS-PR Decision message.

4.7.2. AuthEapRespExt
           outermost header.

4.10.2. Ctxt802Hdr class

   The AuthEapRespExt

   This class extends specifies IEEE 802.1 header data. This class is used to
   inform the AuthExt class. It contains an
   EAP message. (See sec. 3.1.) Instances PDP of this class are sent by the details of the 802 header that caused the PEP
   Event Message to the PDP. be generated.

   The attributes that of this class adds to the base class are:

        AuthEapRespExtSpecific (Octet String)
           an EAP message [EAP] passed from

        Ctxt802HdrId (InstanceId)
           identifies this object

        Ctxt802HdrSrcAddr
           the client to frameĂs source MAC address

        Ctxt802HdrDstAddr
           the PDP via frameĂs destination MAC address

        Ctxt802HdrProtocol
           the layer 2 frameĂs protocol field

        Ctxt802HdrPriority
           the layer 2 frameĂs priority field (only used if the frame
           is using the 802.q header extension)

        Ctxt802HdrVlan
           the layer 2 frameĂs VLAN field  (only used if the frame is
           using the 802.q header extension)
        Ctxt802HdrEncap
           The Encap allows the PEP to indicate where this header is in a COPS-PR Report message.

4.7.3. AuthPapExt
           relation to other IP headers found in the packet (with
           tunnels). This value can be either positive or negative
           depending on how the Event Handler (or the explicitly
           requested PDP 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.

4.10.3. CtxtDialupInterface class

   The AuthPapExt CtxtDialupInterface class extends the AuthExt class. It contains the PAP
   Password. (See sec. 3.2.)

Weiss et al.             Expires October 2000                [Page 33] specifies data to be included in Event
   Messages sent by Event Handlers providing dialin services.

   The attributes that of this class adds to are:

        CtxtDialupInterfaceId
           identifies this object

        CtxtDialupInterfaceNASPort
           This attribute indicates the physical port number of
           the NAS which is authenticating the user. 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.  Either
           CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType
           or both SHOULD be specified in a CtxtDialupInterface object,
           if the NAS differentiates among its ports.

        CtxtDialupInterfaceNASPortId
           This attribute contains a text string which identifies the
           port of the NAS which is authenticating the user.  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.
           Either CtxtDialupInterfaceNasPort or
           CtxtDialupInterfaceNasPortId SHOULD be specified in a
           CtxtDialupInterface object, if the NAS differentiates among
           its ports.  CtxtDialupInterfaceNasPortId is intended for use
           by NASes which cannot conveniently number their ports.

        CtxtDialupInterfaceNASPortType (Enum)
           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
           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
           the call came from, using Automatic Number Identification
           (ANI) or similar technology.

        CtxtDialupInterfaceConnectInfo
           This attribute is sent from the NAS to indicate the
           nature 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 be included in an Event Message as information to the
   PDP.  The PDP may change the values of these attributes, however, in
   subsequent provisioning messages.

4.10.4 CtxtDialupIfFramedProtocol class

   The CtxtDialupIfFramedProtocol class is an optional class that may
   be sent if a framed protocol is being used. This class MAY be
   specified in the ContextData PRC by the PDP in a decision message if
   the PDP needs this context information (if it was not already setup
   to be sent in the eventHandler). It MUST 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
           This attribute indicates the framing to be used for
           framed access.

        CtxtDialupIfFramedProtocolMTU
           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).

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

        CtxtDialupIfFramedProtocolPortLimit
           This attribute sets the maximum number of ports to be
           provided to the user by the NAS.  It is intended for use in
           conjunction with Multilink PPP or similar uses.

        CtxtDialupIfFramedProtocolIpAddress
           This attribute indicates the address to be configured for
           the user.  It MAY be used in constructing policies for the
           user.

        CtxtDialupIfFramedProtocolIpNetmask
           This attribute indicates the IP netmask 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 class that may be
   sent if a Login service is being provided. This class MAY be
   specified in the ContextData PRC by the PDP in a decision message if
   the PDP needs this context information (if it was not already setup
   to be sent in the eventHandler). It MUST be sent up to the PDP in a
   request message if it is specified via the ContextData PRC in an
   eventHandler.

   This class contains a single attribute:

        CtxtDialupIfLoginIpHost
           This attribute indicates the system with which to connect he
           user.

4.10.6 CtxtDialupIfLoginLat class
   This class MAY be specified in the ContextData PRC by the PDP in a
   decision message if the PDP needs this context information (if it
   was not already setup to be sent in the eventHandler). It MUST be
   sent up to the PDP in a request message if it is specified via the
   ContextData PRC in an eventHandler.

   The CtxtDialupIfLoginLat class extends the
   CtxtDialupInterfaceLoginService class.  Its attributes are:

        CtxtDialupIfLoginLatService
           This attribute indicates the system with which the user
           is to be connected by LAT.

        CtxtDialupIfLoginLatNode
           This attribute indicates the Node with which the user is to
           be automatically connected by LAT.

        CtxtDialupIfLoginLatGroup
           This attribute contains a string identifying the LAT group
           codes which this user is authorized to use.

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

           Administrators can assign one or more of the group code bits
           at the LAT service provider; it will only accept LAT
           connections that have these group codes set in the bit map.
           The administrators assign a bitmap of authorized group codes
           to each user; LAT gets these from the operating system, and
           uses these in its requests to the service providers.

        CtxtDialupIfLoginLatPort
           This attribute indicates the Port with which 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 of the extended class is created by the PEP
   and sent to the PDP. The PDP may send information back to the PEP or
   may use the information to authenticate the PEP's Event Message.
   This PRC itself should not be instantiated.

   The data in this class is passed between the PDP and the client with
   little or no involvement of the PEP except to forward it in 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 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.

   The attributes of this class are:

        AuthExtId (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 the UserAuthExt class. It contains the
   attributes of the CHAP protocol [CHAP]. (See section 3.3.)

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

        AuthChapExtId (Unsigned32)
           The AuthChapExtId is generated by the PEP. The ID value is
           sent to the client. When the client endpoint (Peer)
           generates a CHAP response it includes the same ID, and the
           ID is then included in this attribute when it is sent to the
           PDP.

        AuthChapExtChal (Octet String)
           The AuthChapExtChal is generated by the PEP. The Challenge
           value is sent to the client, along with the ID. When the
           client generates a CHAP response containing the ID and
           Response (key), the Challenge associated with the ID is
           included in this attribute when it is sent to the PDP.

        AuthChapExtResp (Octet String)
           The Response is calculated by the client and forwarded by
           the PEP to the PDP.

4.11.3. AuthPapExt class

   The AuthPapExt class extends the UserAuthExt class. It contains the
   PAP Password. (See sec. 3.2.)

   The attributes that this class 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
   Authentication result Boolean flag.

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

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

4.11.5. AuthEapReqExt class

   The AuthEapReqExt class extends the AuthExt class. It contains an
   EAP message. (See sec. 3.1.) Instances of this class are sent by the
   PDP to the PEP.

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

        AuthEapReqExtSpecific (Octet String)
           An EAP message [EAP] passed from the PDP to the client via
           the PEP in a COPS-PR Decision message.

4.11.6. AuthEapRespExt class

   The AuthEapRespExt class extends the AuthExt class. It contains an
   EAP message. (See sec. 3.1.) Instances of this class are sent by the
   PEP to the PDP.

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

        AuthEapRespExtSpecific (Octet String)
           An EAP message [EAP] passed from the client to 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 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
   Section 4 are combined to form the various message interactions
   described in sections 2 and 3.

   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.

5.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 a DataPathEventHandler 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.

5.2. Provisioning Decision

   A report must follow all provisioning decisions described in section
   5.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.

5.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 will always include an instance of the Event class. This
   Event instance references which EventHandlerElement instance and
   EventHandler instance caught the event. This tells the PDP what
   events belong to which Event Handler. Other Classes that 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 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 send
   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) is 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.

5.4. 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 will 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
   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 can 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. The PEP can 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. 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.

   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.

5.5. PDP fetching Event-specific ContextData

   The ContextData class can be specified either during the
   configuration of the EventHandler to indicate what context data
   should be sent with each PEP Event Message or it can be used by the
   PDP to get additional context data for an event after it receives a
   Event Message. In the latter case, the PDP may send a solicited
   response 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 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 can 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 to fetch Event-specific ContextData is
   a Provisioning Decision message. The ContextData class instances are
   sent in an updated Event-specific ContextData Request on 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. When the PEP
   receives a message from the PDP asking for Event-specific
   ContextData, it will send an Event-specific ContextData message in a
   COPS Request message back to the PDP.

   The updated Event-specific ContextData Request from the PEP will
   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.

5.6. 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.

5.7. 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. The class used in this message is used to send
   authEapReqExt table instances.

5.8. 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. The class used
   in this message is used to send authEapRespExt table instances.

6. 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 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. This section describes which messages can be
   collapsed, and what the rules are for collapsing 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 the PEP when a packet causing the Event Message, pre-
   provisioned Event Handlers is the preferred approach.

7. 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.

7.1 Wireless LAN (802.11 Access Point) Usage Example

   A wireless LAN Access Point (AP) is pictured in Figure 7.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).

   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------+  |         |        |     |  |            |      |
   |        o    ^    |         V        |     |  |            |      |
   |        o    |    | +-------------+  |     |  |    (3)     |      |
   |        o    |    | |Authenticator|  |     |  | Event Msg  |      |
   |        o    |    | |   (Event    +--+-----+--+----------->|      |
   |        o    |    | |   Handler)  |  |     |  |            |      |
   |        o    |    | |             |  |     |  |    (4)     |      |
   |        o    |    | |             |  |     |  |EAP exchange|      |
   |        o    |    | |             |<-+-----+--+------------+      |
   |        o    |    | |             |--+-----+--+----------->|      |
   |        o    |    | +-----o-------+  |     |  |            |      |
   |        o    |    |       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 the base class are:

        AuthPapExtPwd (Octet String) SM
   sending a one-time password used REQ at boot time to authenticate the client

4.7.4. AuthChapExt class

   The AuthChapExt class extends the AuthExt class. It contains the
   attributes of tell the CHAP protocol [CHAP]. (See section 3.3.)

   The attributes AS that this class adds to the base class are:

        AuthChapExtId (Unsigned32)
           The AuthChapExtId is generated by the PEP. The ID value is
           sent to the client. When the client endpoint (Peer)
           generates a CHAP response it includes the same ID, and the
           ID is then included in this attribute when it is sent to the
           PDP.

        AuthChapExtChal (Octet String)
           The AuthChapExtChal is generated by the PEP. The Challenge
           value is sent to the client, along with the ID. When the
           client generates a CHAP response containing the ID up and
           Response (key), the Challenge associated with the ID is
           included in this attribute when what
   capabilities it is sent to the PDP.

        AuthChapExtResp has.  The Response is calculated by the client and forwarded by
           the PEP PDP returns a configuration to support the PDP.

4.8. ContextData classes

   This section contains examples of classes that might be referenced
   by the ContextData class as classes that must be included in the
   access request
   SM.  In particular, this configuration includes provisioning
   information for various types of accessors.

   There are two kinds of ContextData classes depending on the type of
   PEP. Some PEPs receive traffic from many users over how to instantiate a shared port
   such as an Ethernet port.  They recognize new users based on PAE and what trigger
   information in should be sent by the headers of incoming packets.  For them, instantiated PAE to the
   ContextData will come from packet headers. PDP.
   The L3HeaderData class
   is an example of this kind provisioning of ContextData class.  Other PEPs receive
   traffic from one user per interface.  For them, the context data
   will be information about Event Handler is supported by the interface.  The
   CtxtDialupInterfaceFramedProtocol class 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.

7.1.2 Wireless LAN Access Event Handling

   When an example of this kind
   of ContextData class.

4.8.1. CtxtL3Hdr class

   This class specifies level three header data. This class 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
   inform the PDP of pass data from the details of access
   port to the IP header external Ethernet.  It is controlled in that caused the PEP
   Access Request to there is a
   switch that must be generated.

Weiss et al.             Expires October 2000                [Page 34] 
   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
           the packetĂs layer 3 source address

        CtxtL3HdrDstAddrType (Enum)
           specifies turned on by the type of authenticator before data can
   flow.  It may also have QoS parameters that can be controlled by the packetĂs layer 3 destination
           address

        CtxtL3HdrDstAddr
   AS.  In its initial state the packetĂs layer 3 destination address

        CtxtL3HdrProtocol controlled port drops all incoming
   frames.

   The uncontrolled port connects to an internal authenticator.  The
   authenticator creates the packetĂs protocol field

        CtxtL3HdrSrcPort initial trigger.  In some cases it may
   need to send an EAP frame back to the packetĂs source port field

        CtxtL3HdrDstPort Station prior to sending the packetĂs destination port field

        CtxtL3HdrDscp
   initial trigger, and other times it may have enough information from
   the packetĂs Type of Service (Diffserv Code Point)field

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

        CtxtL3HdrIpOpt
           IP Options

        CtxtL3HdrEncap ReAssociate to create the trigger
   immediately.

   The Encap allows Event handling is supported by the Access Bind PIB.

   The PEP to indicate where this header is creates an instance of event PRC, with eventEventhdlr
   referencing the eventHandler, and eventCause referencing
   eventhdlrElement provisioned in
           relation Access Event Handler Provisioning
   above.

   This event PRI will be sent by the PEP to other IP headers found in the packet (with
           tunnels). PDP in a REQ using a
   new COPS Request Handle.  This value can be either positive or negative
           depending on REQ message may contain additional
   PRIs as dictated by how a specific signaling protocol should be
   handled.

7.1.3 Wireless LAN Access Event Decision

   The AS/PDP decides whether the Accessor (or trigger contains enough information
   to make an authentication decision.  If not, it may initiate an EAP
   dialog through the Session-specific
           Context Data request) was specified using negative or
           positive numbers.

           A negative n means return authenticator to the nth layer from STATION.

   Once it has enough information the innermost
           header. A positive n means return PDP makes a decision and sends a
   Provisioning message to the nth layer from AP that sets QoS parameters and ŠclosesĂ
   the
           outermost header.

Weiss et al.             Expires October 2000                [Page 35] 

4.8.2. Ctxt802Hdr class

   This class specifies IEEE 802.1 header data. This class switch on the controlled port. Since the controlled and
   uncontrolled port is used easily modeled with a DiffServ Classifier, the
   closing of the switch is simply a matter of a installing a Decision
   in the classifier indicating that subsequent traffic matching the
   specific PAEĂs criteria should be bound to
   inform the set of pre-existing
   policies that are appropriate for that authenticated PAE.

   The decision (DEC) message sent by the PDP of the details of the 802 header that caused to the PEP
   Access Request to will be generated.

   The attributes using
   the same COPS Request Handle created as a result of this class are:

        Ctxt802HdrId (InstanceId)
           identifies this object

        Ctxt802HdrSrcAddr the frameĂs source MAC address

        Ctxt802HdrDstAddr first in
   Access Event.  The content (PRCs) carried by the frameĂs destination MAC address

        Ctxt802HdrProtocol DEC message will
   depend on the layer 2 frameĂs protocol field

        Ctxt802HdrPriority functionality need to be provided.  It may be command
   to ŠcloseĂ the layer 2 frameĂs priority field (only used if switch on the frame controlled port, it may contain QoS
   parameters.

7.2 RSVP Usage Example
   RSVP is using the 802.q header extension)

        Ctxt802HdrVlan
           the layer 2 frameĂs VLAN field  (only a signaling protocol used if 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 frame is
           using hop-by-hop path and the 802.q header extension)

        Ctxt802HdrEncap
           The Encap allows service requirements
   between a sender and one or more receivers.

   Some RSVP messages contain information that helps determine whether
   the PEP reservation should be accepted or not. However, the router may
   not equipped with sufficient context to indicate where this header is take advantage of the
   information in
           relation determining whether to other IP headers found in 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 packet (with
           tunnels). This value can be either positive RSVP message and
   usually determine whether to accept or negative
           depending on how reject the Accessor (or reservation.

   With the Session-specific
           Context Data request) was specified using negative advent of COPS-PR, it became possible to construct more
   sophisticated policies beyond simple accept or
           positive numbers.

           A negative n means return reject messages.
   However, these more sophisticated policies were targeted for
   DiffServ rather than RSVP. With the nth layer from definition of the innermost
           header. A positive n means return AccessBind
   PIB, it becomes possible to provision a router not only to specify
   which RSVP messages should be sent to the nth layer from PDP, but also to use
   existing PIBs to specify how the
           outermost header.

4.8.3. CtxtDialupInterface class

   The CtxtDialupInterface 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 specifies data to detect
   RSVP messages, a number of filter classes must be included in
   access requests sent defined. These
   filter classes are general purpose and could be used both by accessors providing dialin services.

   The attributes of this class are:

        CtxtDialupInterfaceId
           identifies this object

        CtxtDialupInterfaceNASPort
           This attribute indicates
   EventHandlers and by Classifiers although the physical port number semantics of

Weiss et al.             Expires October 2000                [Page 36] the NAS which
   filter class are somewhat different for each. The other group of
   classes is authenticating the user. Note Context Data classes that this is
           using 'port' in its sense pass some or all parts of a physical connection on
   the
           NAS, not in RSVP message to the sense of a TCP or UDP port number.  Either
           CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType
           or both SHOULD be specified in a CtxtDialupInterface object,
           if PDP when the NAS
           differentiates among its ports.

        CtxtDialupInterfaceNASPortId
           This attribute contains 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 text string which identifies unique Context
   Data PRC identifier and the
           port rest of the NAS which is authenticating RSVP objectĂs attributes
   will be part of the user.  Note that
           this is using 'port' PIB class in its sense of a physical connection
           on the NAS, not same order and format as in the sense of a TCP or UDP port number.
           Either CtxtDialupInterfaceNasPort or
           CtxtDialupInterfaceNasPortId SHOULD
   original RSVP object. The actual PRC mappings for these objects can
   be specified found in a
           CtxtDialupInterface object, if the NAS differentiates among
           its ports.  CtxtDialupInterfaceNasPortId is intended for use
           by NASes which cannot conveniently number their ports.

        CtxtDialupInterfaceNASPortType (Enum)
           This attribute indicates PIB definition. For details on the type operation of
   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 physical port
           of relevant
   RSVP common header attributes. The attributes in the NAS 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 authenticating the user.  It can be used instead of or in addition 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
           CtxtDialupInterfaceNasPort attribute.

        CtxtDialupInterfaceCalledStationId
           This attribute allows the NAS 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 send simplify the phone number that process of specifying the user called, using Dialed Number Identification (DNIS)
           or similar technology.  Note that this may set of RSVP objects to be
   included with a COPS-PR Event message. Rather than explicitly
   specifying every context data class that should be different from included with the phone number
   Event message, this class (when referenced by PRC through the call comes in on.

        CtxtDialupInterfaceCallingStationId
           This
   ContextDataIfElement attribute allows the NAS to send of the phone number ContextData class) indicates
   that all RSVP objects, including the call came from, using Automatic Number Identification
           (ANI) or similar technology.

        CtxtDialupInterfaceConnectInfo
           This attribute is sent from common header class described
   above, should be encapsulated and propagated to the NAS PDP. All Refresh
   Reduction related RSVP objects (MESSAGE_ID, MESSAGE_ID_ACK, and
   MESSAGE_ID_NACK) are explicitly excluded from being sent to indicate the
           nature of PDP
   when the user's connection.

   This AllRSVPMessageObjects attribute is a notify-only class. set to True. These attributes
   objects are not write-able by
   the PDP.

   Three additional notify/install classes can be defined.  These
   classes can be included specifically for purpose of synchronizing state between
   RSVP hops and bears no value in an access request as information to the
   PDP.  The PDP may change the values policy decision process.
   However, a context data PIB object is defined for each of these attributes, however,
   classes in
   subsequent provisioning messages.

4.8.3.1 CtxtDialupIfFramedProtocol class

   The CtxtDialupIfFramedProtocol class is an optional class the event that may
   be sent if a framed protocol is being used.

Weiss et al.             Expires October 2000                [Page 37] PDP determines that it needs these
   objects.

   The attributes of this class are:

        CtxtDialupIfFramedProtocolId
           identifies this object

        CtxtDialupIfFramedProtocolProt
           This attribute indicates the framing to be used for
           framed access.

        CtxtDialupIfFramedProtocolMTU
           This attribute indicates the Maximum Transmission Unit EventScope classes have been specified to be
           configured for roughly follow the user, when it is not negotiated by some
           other means (such as PPP).  It MAY be used in access
           response packets.  It MAY be used in an access request
           packet
   same mappings as the Context Data PIB classes. However, since the
   typical criteria for outsourcing a hint by RSVP message are usually rather
   simple, only a subset of the NAS RSVP objects require mappings to the PDP that COPS-
   PR filter classes. If some implementations require support for
   filtering additional objects, it would prefer
           that value, but the PDP is not required trivial to honor extend the hint.

        CtxtDialupIfFramedProtocolCompression (Enum)
           This attribute indicates a compression protocol to be used
           for filters.
   Note that the link.  It MAY be used in access response packets.
           It MAY be used in an access request packet as filters bound to EventHandlers determine whether a hint
   matching packet should generate an Event or not.

   The RSVP objects that will be mapped to filters in this
   specification will include the
           PDP that RSVP common header, the NAS would prefer RSVP Dclass
   object, the RSVP session object, and the RSVP style object. The last
   three are used to use that compression, but describe various characteristics of the PDP data
   traffic for which the reservation is not required to honor being performed. Since the hint.

        CtxtDialupIfFramedProtocolPortLimit
           This attribute sets
   filters can describe both AND and OR semantics, the maximum number challenge is in
   organizing the fields of ports to be
           provided to the user by objects to simplify filter expressions
   as much as possible. Since this is the NAS.  This Attribute MAY be sent
           by primary goal the PDP to appropriate
   attributes of each object have been combined into a single PIB
   class. The RSVP filter PIB class contains the PEP in an access response packet.  It is
           intended for use in conjunction following attributes.
   The fields marked with Multilink PPP or
           similar uses.  It MAY also asterisks will be sent by the NAS represented as masked
   values (for IP addresses) and ranges (for UDP/TCP ports) 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 PDP RSVP refresh model. RSVP
   refresh reduction [REFRESH] is assumed as a hint that that many ports are desired simplifying assumption
   for use, but the PDP
           is not required to honor the hint.

        CtxtDialupIfFramedProtocolIpAddress
           This attribute indicates this application of the address to be configured Access Bind PIB. However, if support for
           the user.  It MAY be used in access response packets.  It
           MAY
   traditional RSVP refresh is desirable, it can be used supported in an access request packet as a hint this
   model by adding explicit filters for the NAS RSVP FlowSpec and RSVP
   Tspec objects as specified in [IntServ].

   In order to support RSVP outsourcing with the PDP that it would prefer that address, but AccessBind PIB the PDP is
           not required
   Event Handler must be provisioned with the appropriate settings to honor
   recognize specific RSVP messages, create new request handles, and
   generate events (outsourcing requests). After we have described how
   this is accomplished, we will show the hint.

        CtxtDialupIfFramedProtocolIpNetmask
           This attribute indicates actual message flows involved
   in the IP netmask RSVP outsourcing process.

   The specific PIB classes that need to be
           configured for the user when provisioned are the user is
   EventHandler, EventhdlrElemenet, ContextData, EventhdlrHandleScope,
   and EventhdlrEventScope. The EventHandler provides a router termination
   point for processing RSVP messages. As RSVP messages arrive, they
   are directed to the EventHandler by a
           network.  It MAY be used in access response packets.  It MAY
           be used in an access request packet classifier. In this scenario
   the EventHandler as behaving as a hint by termination point for all RSVP
   messages. Hence, the NAS to EventHandler class is provisioned with no data
   path elements following the PDP EventHandler. Therefore, the attribute
   eventhdlrNonMatchNext is left unassigned.

   Alternatively, the EventHandler can also be provisioned such that it
   RSVP and non-RSVP packets alike pass through the EventHandler, but
   only RSVP messages invoke events. In this case, the attribute
   eventhdlrNonMatchNext would prefer that netmask, but specify the PDP is next data path element that
   should process any packets not required to honor matching the hint.

4.8.3.2 CtxtDialupIfLoginService class EventHandlerĂs criteria
   (non RSVP packets).

   The CtxtDialupIfLoginService class is an optional class that may be
   sent if a Login service is being provided.

Weiss et al.             Expires October 2000                [Page 38] 
   This EventhdlrElement class contains identifies a single attribute:

        CtxtDialupIfLoginIpHost
           This attribute indicates the system with which specific category of events.
   Suppose one wanted to connect he
           user.  It MAY be used in access response packets.  It MAY generate different Events for PATH messages
   and RESV messages. This could be
           used in an access request packet as done by configuring one
   EventhdlrElement to only match PATH messages and another
   EventhdlrElement to only match RESV messages. Event messages contain
   a hint reference to the PDP that
           the NAS would prefer to use EventhdlrElement that host, but generated the PDP event.
   Therefore, it is not
           required possible to honor generate different events from the hint.

4.8.3.3 CtxtDialupIfLoginLat class same
   EventHandler.

   The CtxtDialupIfLoginLat class extends EventhdlrElement contains two main semantics. First, it
   specifies the
   CtxtDialupInterfaceLoginService class.  Its attributes are:

        CtxtDialupIfLoginLatService
           This attribute indicates criteria for creating new Request Handles. Each
   Request Handle constitutes a unique dialog between the system with which PEP and PDP.
   The second semantic is the user criteria for generating events. In some
   situations, it is desirable to be connected by LAT.  It MAY be used in access
           response packets.  It MAY be 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 in an access request
           packet 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 hint unique COPS-PR
   Request Handle for every new RSVP session. Since EventHandlers are
   typically bound to an interface data path, the PDP, but RSVP Path message and
   the PDP 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 is not required to
           honor
   significant since the hint.

        CtxtDialupIfLoginLatNode
           This attribute indicates provisioning objectives for Path messages are
   different from the Node with which provisioning objectives for Resv messages. For
   RSVP, the user is EventhdlrElement will use the Tag Reference
   EventhdlrElementHandleScope to
           be automatically connected by LAT.  It MAY be used in access
           response packets.  It MAY be used in an access Request
           packet as describe the criteria for creating a hint
   unique handle. Each EventhdlrHandleScope object will contain
   pointers to the PDP, but the PDP is not required RSVP filter objects mentioned earlier to
           honor describe
   the hint.

        CtxtDialupIfLoginLatGroup
           This attribute contains various fields whose combination of values constitute a string identifying unique
   handle.

   Typically, the LAT group
           codes which this user is authorized to use.  It MAY be used
           in access response packets.  It MAY be Filter class used in an access
           request packet as a hint to is the PDP, but RSVP filter class. For this
   class, the PDP is not
           required session attributes (SessionDestIP, SessionDestPort, and
   SessionProtocol) will be assigned wildcard values and all other
   attributes assigned to honor the hint.

           LAT supports 256 different group codes, which LAT uses as a
           form NULL to indicate that any combination of access rights.  LAT encodes the group codes as
   these attributes constitutes a 256
           bit bitmap.

           Administrators can assign one or more of the group code bits
           at unique handle. When various messages
   arrive that require the LAT service provider; it will only accept LAT
           connections generation of an event and that have these group codes set in the bit map.
           The administrators assign a bitmap newly
   unique combination of authorized group codes the filter attribute values, a 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 each user; LAT gets these from pass
   the operating system, and
           uses these in its requests appropriate event to the service providers.

        CtxtDialupIfLoginLatPort PDP.

   The other class pointed to by the EventhdlrElement is the
   EventhdlrEventScope. This attribute indicates class describes the Port criteria for
   generating an event. Typically, the MsgType attribute in conjunction
   with which the user is to
           be connected by LAT.  It MAY session attributes will be used in access response
           packets.  It MAY wildcarded and the other fields
   assigned to NULL to indicate that all RSVP messages should be used in an access request packet as a
           hint sent
   to the PDP, but the PDP is not required to honor PDP. This describes the
           hint.

Weiss et al.             Expires October 2000                [Page 39] 

5. Message Types

   All PIB messages have some form criteria for an event: Every time a
   unique combination of transactional semantics. Most all
   transactions consist of requests and responses. Typical provisioning
   PIBs have the PDP requesting these attributes occurs, generate a provisioning decision new
   event.

   In many cases it may make sense to assign the PEP filter attributes
   (SessionDestIP and SessionDestPort) to the PEP responding with a success or fail. EventhdlrEventScope
   and/or EventhdlrHandleScope class. This PIB uses this
   paradigm in some cases, but would be done when it also uses a paradigm where the PEP
   initiates a request and is
   desirable to notify of the PDP responds with of the need to allocate additional
   resources to a success or fail. The
   specific use set of this paradigm is with reserved flows going to the PEP Access same destination
   but originating from different sources.

   A new COPS-PR Request
   message, which is triggered by Handle MUST only be created when a PEP valid event and requires
   occurs. If a success or
   fail response. This section discusses both paradigms and how the
   various classes defined in Section 4 are combined to form packet matches the
   various message interactions criteria described in sections 2 and 3.

   Each message description in this section will include the purpose of
   the message, the by
   EventhdlrHandleScope but does not match any EventhdlrEventScope
   criteria, a COPS-PR message type, the direction Request Handle must not be generated.

   This version of the message,
   the class instances typically found in the message and the
   request/response message it paper only describes how RSVP can be supported
   when Refresh Reduction [REFRESH] is peered with.

5.1. Accessor Provisioning Decisions being used. The Accessor Provisioning Decision message is a COPS-PR Decision
   message used by the PDP to provision each Accessor in complexity of
   addressing the PEP. It distinction between RSVP refresh messages and
   reservation update messages is
   likely too great to be a piece of a larger Decision addressed in this
   version. Any RSVP message containing bundle messages (MsgType 12)
   MUST be decomposed and each message that provisions
   other data path components that occur either before or after the
   Accessor in the data path. However, it could also bundle must be sent
   iteratively processed through the EventHandler as a part
   of unrelated data path if individual RSVP
   messages were generated from the RSVP neighbor. Whether
   EventhdlrMatchNext applies to the individual sub-messages or other provisioning components. Accessor
   provisioning typically includes the Accessor class, and
   bundled message is beyond the
   AccessorElement class, an optional set scope of AccessorContextData class
   instances, this paper.

   Irrespective of whether Refresh Reduction is in use or not, the RSVP
   daemon is responsible for aging out reservations that are no longer
   valid. As with traditional COPS, when a optional set of AccessorAuthProtocol class instances,
   and an instance of reservation is aged out, the AccessorSessionScope class.

   Because
   RSVP daemon or other entity responsible for aging out reservations
   MUST take responsibility for deleting COPS Request Handles. This
   allows the PDP to clean up state associated with the AccessorElement, AccessorContextData,
   AccessorAuthProtocol, reservation and
   ensures the AccessorSessionScope classes all
   describe configuration details proper removal of the Accessor, any of these class
   instances may policies in the PEP specifically
   assigned through the COPS Request Handle.

   Figure 7.2 shows how the various Event Handler objects would be shared by multiple Accessor instances. Therefore,
   provisioned in many cases, an Accessor Provisioning Decision will contain only
   an Accessor a router to ensure that references instances 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      |   +------------+
                 +->| Id=Hd2      |  |  | DestIP=*   |
                    | Group=HD    |  |  | Protocol=* |
                    | Filter=(R2)-+--+  | DestPort=* |
                    | Precedence=1|     +------------+
                    +-------------+
   Fig 7.2: Representation of an Event Handler for RSVP

   Figure 7.2 represents the other classes defined
   in previous Provisioning Decisions. In addition, these set of PIB classes can
   also that would be
   provisioned individually in anticipation of being applied order to
   an Accessor. indicate to the PEP that RSVP messages
   should generate unique events for any combination of filters or
   sessions. However, because there is a relationship between all messages using the
   classes, there is an order dependency between same unique session will
   share the classes. For
   instance, same COPS Request Handle.

   When an AccessorSessionScope must be provisioned RSVP message arrives at the same
   time or before PEP with an AccessorElement making use new combination of
   session attribute values, the
   AccessorSessionScope. AccessorElement, AccessorAuthProtocol,
   AccessorContextData, and data path class instances referenced by PEP will create a new COPS Request
   Handle. Following this, an
   Accessor must Event message will be provisioned at generated
   containing an Event object with references to EventHandler EH1 and
   EventhdlrElement Elem1. These two pieces of information allow the same time or before
   PDP to determine which provisioned EventHandler and which specific
   event type generated the Accessor
   is provisioned.

   When event. In addition the PEP receives an AccessorProvisioning Decision must always
   respond with Event message also
   contains a Provisioning Report indicating success or failure.

Weiss et al.             Expires October 2000                [Page 40] 

5.2. Provisioning Report

   A report must follow set of Context Data objects. Since the AllRSVPMsgObjects
   class was specified in the ContextData class, all provisioning decisions described RSVP objects are
   encapsulated in section
   5.1. This report may not have any class instances COPS-PR PIB classes and sent to the PDP in it. However, the Event
   message.

   When the PDP receives the Event message, it
   explicitly notifies determines what policies
   to provision in the PEP. Suppose the RSVP message was a reservation
   request for a controlled load service with a bandwidth allocation of
   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 respective bandwidth
   allocations of 20Mb, 40Mb, 30Mb, and 10Mb, the PDP may decide that
   allocating the reservation to queue 3 can satisfy the reservation
   request. Hence, a PDP might generate a provisioning was successful or
   whether 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 failed. If many structures were simultaneously
   provisioned in 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 the Provisioning Decision set of classes to
                   configure generic event handlers, and a failure occurred,
   none outsource
                   events as they occur. One application of the class instances will be accepted by the PEP. Hence it this PIB is
   possible
                   to subsequent Provisioning Decisions bind authorization and authentication to occur with a
   smaller subset of COPS
                   Provisioning."

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

         --
         -- The branch OIDs in the class instances or an alternative set 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 of class
   instances this table represent events that can satisfy occurred at
         -- the service policies defined in PEP. The events reference the PDP.

5.3. PEP Access Request

   A PEP Access Request event handler instance
         -- 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 this class is generated created by the PEP and sent
              to indicate that a new
   class of traffic has been identified by the Accessor and that PDP. As a new
   Session has been allocated. result of this event, The PDP may send
              additional unsolicited decisions to the PEP Access Request message uses after
              sending the mandatory solicited decision for the event."

             ::= { eventClasses 1 }

         eventEntry OBJECT-TYPE
             SYNTAX         EventEntry
             STATUS         current
             DESCRIPTION
                 "An instance of 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 this event."

             ::= { eventEntry 1 }

         eventEventHdlr  OBJECT-TYPE
             SYNTAX         ReferenceId
             PIB-REFERENCES {  frwkReferenceEntry }
             STATUS         current
             DESCRIPTION
              "This attribute allows a
   COPS-PR Request message. The PEP Access Request will always include to indicate to the PDP that
              this event was generated due to the referenced Event
              Handler. This attribute references an event handler via
              the indirection PRC frwkReference, since the event
              handler and event could potentially belong to a different
              PIB contexts."

             ::= { eventEntry 2 }

         eventCause OBJECT-TYPE
             SYNTAX         ReferenceId
             PIB-REFERENCES { frwkReferenceEntry }
             STATUS         current
             DESCRIPTION
              "This attribute references the specific instance in a
              group of the Session class. In order event Handler elements belonging to support multiple PEP
   Access Request messages an event
              Handler that resulted in this event. This attribute
              references a single COPS Request message, all class
   instances associated with specific event handler element via the Session must immediately follow
              indirection PRC frwkReference, since the
   Session class instance. Classes that may be part of a PEP Access
   Request include one or more instances of Header and Interface data
   classes event handler
              element and no more than one instance event could potentially belong to a different
              PIB contexts."

             ::= { eventEntry 3 }

         --
         -- EventHandler Table
         --
         -- Instances of the AuthExt class.

   When authentication protocols such as PAP or CHAP this PRC are in use, the
   PIB assumes that the UserId, Challenge, and Password will all be
   determined provisioned by the PEP prior to generating PDP on the PEP Access Request.
   EAP is an exception
         -- to this rule because EAP assumes catch specific events. The Event Handlers reference a direct
   negotiation between
         -- group of eventHdlrElement PRIs that contain the Endpoint scope of
         -- the event and specify the Authentication server. For
   EAP, it context data to send to the PDP
         -- when an event is assumed that caught.

         eventHandlerTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHandlerEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
               "The eventHandlerTable specifies for what events the Endpoint generates PEP
               should send a response request to the EAP
   Identity Request message before PDP. As a  result of this
               request, the PEP sends may send configuration changes to the Access Request.
   This allows
               PEP. An instance of this class defines the circumstances
               for generating a request, and provides the means for
               specifying the contents of the PEP Request. Hence, the
               eventHandlerTable can be said to fill in 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 of the Username eventHandlerTable class."

            ::= { eventHandlerEntry 1}

          eventHandlerElements OBJECT-TYPE
           SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrElementGrpId }
           STATUS        current
           DESCRIPTION
             "A reference to a group of eventHdlrElement instances,
             each of which  determines the scope (criteria for
             generating a new  request) and Realm what context information to
             send in the Session
   table. However, 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 scenario, it PRC belongs to a group of
         -- eventHdlrElement PRIs. The group is also assumed that the PEP
   Access Request will include identified by the EAP Identity Response in
         -- eventHdlrElementGrpId attribute. These are provisioned by
         -- the
   authEapRespExtSpecific attribute of PDP on the AuthEapRespExtEntry class.
   Subsequent EAP negotiation prior PEP to catch specific events. This PRC
         -- contain the final PDP Access Response
   message will be performed with scope of the Opaque Decision event and Opaque Report
   message types.

5.4. PDP Access Response

   When the PDP has all specify the necessary information context data
         -- type to send to determine whether the session PDP when an event is authorized or not caught.

         eventHdlrElementTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHdlrElementEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
              "The eventHdlrElementTable specifies a single eventHdlr
              element's scope via a reference to a group of filters and it has completed any
   intermediate
              the context data path PRIs type and encapsulation meta-information
              that the session may be dependent on,
   the PDP will generate a PDP Access Response message. The PDP Access
   Response message only contains 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 of the Session table
   passed in the PEP Access Request. The PDP is capable of modifying
   two attributes in the Session table PRI. One attribute is the
   sessionStatus, which the PDP MUST modify to indicate whether the
   Session 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 authorized or not. The second generated. Valid options are
              one_time, every_time and on_change. This attribute is the
   sessionDataPath, which the PDP may modify allows
              event Handlers to indicate what specific

Weiss et al.             Expires October 2000                [Page 41] 
   packet processing should occur for all traffic matching the session
   criteria.

   The PEP is distinguish one time events (ignore
              after the only entity first match) from recurring events (generate an
              event every time a match occurs).  A enum type was also
              define to specify that knows a new event should be generated
              when traffic is no longer
   flowing through a particular session (either because specific set of a timer
   expiring or fields change. This is important
              for protocols like RSVP because of a physical link termination). Therefore
   lifetime of a Session table instance messages are always controlled by the
   PEP. The PDP may advise the PEP sent both to
              demonstrate that the session reservation is no longer valid.
   However, active and to notify
              hops of changes to reservations. Since only changes need
              to propagate to the ultimate dispensation PDP, the on_change option indicates
              that that events should be generated selectively.

              This criteria controls behavior of both, the Session table EventScope
              and the
   related tables are always determined by HandleScope."

              ::= { eventHdlrElementEntry 2}

         eventHdlrElementGrpId OBJECT-TYPE
           SYNTAX        TagId        -- corresponding Tag Reference in
                                      -- eventHandlerEntry
           STATUS        current
           DESCRIPTION
                "Group identifier. All instances with the PEP. The PDP same group
                identifier belong to one group and can
   indicate that be referenced
                collectively from an eventHandler instance."

              ::= { eventHdlrElementEntry 3}

         eventHdlrElementEventScope OBJECT-TYPE
           SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrEventScopeGroup }
           STATUS        current
           DESCRIPTION
                "Identifies a Session may no longer have access to resources
   either by changing group of eventHdlrEventScope entries
                associated with this eventHdlrElement instance."

              ::= { 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 is
                an optional attribute. If it is not present the sessionStatus attribute to ˘Disabled÷ or by
   modifying
                semantics of the sessionDataPath Handle processing is interpreted as
                identical to drop packets arriving for that
   session. Since setting the sessionStatus to ˘Disabled÷ will result Event Scope handling specified in all packets for the session being dropped, both alternatives
   achieve the same semantics. The PEP can ˘Disable÷ the session simply
   by notifying
                EventScope objects"

              ::= { eventHdlrElementEntry 5}

         eventHdlrElementContext OBJECT-TYPE
           SYNTAX       TagReferenceId
           PIB-TAG       { contextDataGroup }
           STATUS        current
           DESCRIPTION
                "Identifies a 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}

      --
      -- EventHdlrEventScope Table
      --
      -- This PRC defines the PDP that scope of an event handler element using
      -- references to filters defined in the Session instance is no longer valid.
   Since 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 COPS-PR Provisioning Decision TagId, and this group is used send then
      -- referenced from the PDP Access
   Response, eventHdlrElement PRC.

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

           ::= { eventHdlrClasses 3 }

         eventHdlrEventScopeEntry OBJECT-TYPE
           SYNTAX  EventHdlrEventScopeEntry
           STATUS  current
           DESCRIPTION
             "An instance of this class defines an individual criterion
             to be used towards generating an 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 PDP to confirm that binding between the Session is still valid eventHdlrElementEntry
              and that there are no problems with the
   SessionDataPath change requested by eventHdlrEventScope entries. A group of
              eventHdlrEventScope entries constitutes the PDP.

   When criteria for
              partitioning various portions of traffic."

              ::= { eventHdlrEventScopeEntry 2}

         eventHdlrEventScopeFilter   OBJECT-TYPE
           SYNTAX        Prid
           STATUS        current
           DESCRIPTION
                "Pointer to a Session is removed all relating class instances may be
   removed as well. Typically these will include header and
   authentication table instances. Interface table instances may
   continue filter to be valid if multiple Sessions are sharing the same
   interface description.

5.5. Session-specific ContextData Request

   The AccessorContextData class can be used either during as the
   configuration of criteria."
              ::= { eventHdlrEventScopeEntry 3}

         eventHdlrEventScopePrecedence OBJECT-TYPE
           SYNTAX        INTEGER
           STATUS        current
           DESCRIPTION
              "Represents the Accessor to specify what context data should be
   sent precedence of this criterion with each PEP Access Request or it can be used by the PDP respect
              to
   get additional context data for a session after it receives an
   Access Request for that session. In other criteria within the latter case, same group. When the PDP may
   send a Session-specific ContextData Request to retrieve
              precedence is unique, the specific
   information needed to either authorize a pending session or monitor instance represents an active session. Since each ContextData class only retrieves a
   specific subset of
              alternative criteria (an ORing function). When the information regarding a session, a single
   request message can contain multiple
              precedence for two or more instances of the ContextData
   class, thereby supporting the retrieval of as much session-specific
   information as needed in a single message.

   The COPS-PR message type used for a Session-specific ContextData
   Request
              eventHdlrEventScope class is a Provisioning Decision message. Further, when the
   ContextData class is sent in same, the attributes
              within all the instances are treated collectively as a Session-specific ContextData Request,
              single filter criteria with the RefId attribute must contain a valid InstanceId for in following rules:
              1. If the
   Session table (described in section 4.6). It does filters are not matter what
   the current state of the Session table entry is. Since same type, the TagId is
   only used when filters
                 are ANDĂed as a whole eg (RSVP and IP)
              2. If the ContextData class is configured with an Accessor, filter types are the same, the TagId attribute should not 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)."

              ::= { eventHdlrEventScopeEntry 4}

         eventHdlrEventScopeChangeFlag OBJECT-TYPE
           SYNTAX        TruthValue
           STATUS        current
           DESCRIPTION
             "Boolean value, if set when to 'true' indicates that a new
             event should be generated if any of the class is used assigned fields in a
   Session-specific ContextData Request. When
             the PEP receives a

Weiss et al.             Expires October 2000                [Page 42] 
   Session-specific ContextData Request, it will send a Session-
   specific ContextData Response message back to associated filter change."

              ::= { eventHdlrEventScopeEntry 5}

      --
      -- EventHdlrHandleScope Table
      --
      -- This PRC defines the PDP.

   Session-specific ContextData Response will contain a set scope of Header
   and Interface data class instances. However, because these instances
   do not contain a Reference Id request handles generated by the
      -- PEP due to events caught by the Session, we must rely on event handler element. Each
      -- instance of this PRC references filters defined in the
   COPS
      -- Framework PIB or some other signaling-protocol specific filter
      -- PRCs. These filters may describe specific protocol properties
      -- to bind the request with the response. This precludes
   PDP from generating multiple Session-specific ContextData requests
   for different sessions in which this event handler is sensitive. Essentially this
      -- table defines when a new COPS RequestHandle must be created by
      -- the same Decision message.

5.6. Session-specific ContextData Response PEP based on protocol properties. The Session-specific ContextData Response message is used event handler may be
      -- set up to be sensitive to report specific interface field values and/or packet header information back to the PDP.
      -- uniqueness of a set of values considered together. This message
      -- accommodates various behaviors of signaling protocols. These
      -- filters references are grouped using a TagId, and this group
      -- is implemented as then referenced from the eventHdlrElement PRC via the
      -- eventHdlrElementHandleScope TagReference.

         eventHdlrHandleScopeTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHdlrHandleScopeEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
               "This class defines the criteria to be used for
               deciding whether to create a COPS-PR Report message. A Report
   message may include any number of Interface new COPS RequestHandle for
               an event or Header table
   instances. However, because Reference Identifiers to use an existing Handle."

           ::= { eventHdlrClasses 4 }

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

           ::= { eventHdlrHandleScopeTable 1}

         EventHdlrHandleScopeEntry::= SEQUENCE {
           eventHdlrHandleScopeId         InstanceId,
           eventHdlrHandleScopeGroup      TagId,
           eventHdlrHandleScopeFilter     Prid,
           eventHdlrHandleScopePrecedence INTEGER,
           eventHdlrHandleScopeChangeFlag TruthValue
         }

         eventHdlrHandleScopeId    OBJECT-TYPE
           SYNTAX        InstanceId
           STATUS        current
           DESCRIPTION
                "An arbitrary integer index that uniquely identifies an
                instance of the Session
   table are not specified eventHdlrHandleScopeTable class."

              ::= { eventHdlrHandleScopeEntry 1}

         eventHdlrHandleScopeGroup  OBJECT-TYPE
           SYNTAX        TagId   -- corresponding TagReference
                                 -- defined in eventHdlrElementEntry
           STATUS        current
           DESCRIPTION
              "Represents the header or interface data tables, a
   Report message may contain header and interface data for one binding between the eventHdlrElementEntry
              and
   only one Session.

5.7. Opaque Decision

   An Opaque Decision message is used to send specialized
   authentication messages from the PDP to eventHdlrHandleScope entries. A group of
              eventHdlrHandleScope entries constitutes the criteria for
              defining the PEP. Specifically, this
   type scope of COPS-PR Decision message is used the Handles generated."

              ::= { eventHdlrHandleScopeEntry 2}

         eventHdlrHandleScopeFilter   OBJECT-TYPE
           SYNTAX        Prid
           STATUS        current
           DESCRIPTION
                "Pointer to pass EAP request
   messages. The class used in this message is used a filter to send
   authEapReqExt table instances.

5.8. Opaque Report

   An Opaque Report message is be used to send specialized authentication
   messages from as the PEP to criteria."
              ::= { eventHdlrHandleScopeEntry 3}

         eventHdlrHandleScopePrecedence OBJECT-TYPE
           SYNTAX        INTEGER
           STATUS        current
           DESCRIPTION
              "Represents the PDP. Specifically, this type precedence of COPS-PR
   Report message is used to pass EAP response messages. The class used
   in this message is used criterion with respect
              to send authEapRespExt table instances.

6. Combining Data Structures in Messages

   In the most degenerate case, other criteria within the PDP provisions same group. When the Accessor with no
   ContextData. In this case,
              precedence is unique, the PEP will generate instance represents an Access Request
   message. The PDP will then perform a series
              alternative criteria (an ORing function). When the
              precedence for two or more instances of Session-specific
   ContextData Requests. In addition, if EAP authentication the
              eventHdlrHandleScope class is
   required, a sequence of Opaque Decisions and Opaque Reports the same, the attributes
              within all the instances are also
   required. Finally, treated collectively as a
              single filter criteria."

              ::= { eventHdlrHandleScopeEntry 4}

         eventHdlrHandleScopeChangeFlag OBJECT-TYPE
           SYNTAX        TruthValue
           STATUS        current
           DESCRIPTION
             "Boolean value, if new data paths need set to 'true' indicates that a new
             Handle should be provisioned
   (including specialized Accessors), normal Provisioning Decision and
   Report messages must also be exchanged.

   In some environments, it is essential generated to complete send the event request if
             any of the assigned fields in the associated filter
             change."

              ::= { eventHdlrHandleScopeEntry 5}

         --
         -- EventHdlrAuthProtocol Table
         --
         -- This PRC specifies the authorization
   process as quickly as possible. The way Auth Mechanism to accelerate this process use in the Access
         -- request when a data path Event Handler is configured to combine as many messages into a single message as possible.
   This section describes which messages
         -- catch access events.

         eventHdlrAuthProtocolTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF EventHdlrAuthProtocolEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
               "This class lists the authentication protocols that can
               be collapsed, and what the
   rules are used for collapsing the messages.

Weiss et al.             Expires October 2000                [Page 43] 

6.1. Combining Access Request and Session-specific ContextData messages

   Previous sections have discussed at length how Accessors can an access request."

           ::= { eventHdlrClasses 5 }

         eventHdlrAuthProtocolEntry OBJECT-TYPE
           SYNTAX  EventHdlrAuthProtocolEntry
           STATUS  current
           DESCRIPTION
             "An instance of this class describes an authentication
             protocol that may be pre-
   provisioned to generate specific ContextData (Interface and Header
   data) with the PEP Access Request. When the choice used for an access request. Instances
             of what context
   data is not dependent on this class that share the specific semantics same TagId value collectively
             constitute a list of authentication protocols that may be
             used for 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 each session,
   pre-provisioned Accessors is the preferred approach.

6.2. Combining Access Response and Provisioning Decision messages

   What has not been discussed ContextDataTable class."

           ::= { eventHdlrAuthProtocolEntry 1}

         eventHdlrAuthProtocolGroup OBJECT-TYPE
           SYNTAX        TagId  -- corresponding TagReference
                                -- in any detail is how Provisioning
   Decisions can datapathEventHdlrEntry
           STATUS        current
           DESCRIPTION
                "Represents a binding between an datapathEventHdlrTable
                instance and a list of eventHdlrAuthProtocolTable
                instances."

           ::= { eventHdlrAuthProtocolEntry 2}

         eventHdlrAuthProtocolAuthMechanism OBJECT-TYPE
           SYNTAX        INTEGER {
                                     PAP (0),
                                     CHAP (1),
                                     EAP_MD5(2),
                                     EAP_TLS(3)
                                   }
           STATUS        current
           DESCRIPTION
                "The authentication protocol that may be pre-pended to PDP Access Response messages. In
   general the preferred approach used for an
                access request."
              ::= { eventHdlrAuthProtocolEntry 3}

         --
         -- DataPath Event Handler Table
         --
         -- This PRC is to pre-provision as much an extension of the
   data path as possible. However, when this is not possible, the PDP
   Access Response message can be combined with the data path
   Provisioning Decisions that the Session table entry (actually, EventHandler PRC. This
         -- extension illustrates the
   sessionDataPath attribute) in use of the PDP Access Response is dependent
   on. When EventHandler PRC
         -- concept for authentication usage. Instances of this occurs, it is important to note that all Provisioning
   Decisions must report back to the PDP whether the Decision was
   successfully installed.

   Since both PRC are
         -- provisioned by the PDP Access Response message and the Provisioning
   Decision are in on the same message (a Decision message), COPS-PR
   transactional semantics apply PEP to the entire combined message.
   Therefore, if the Decision fails, the Session will remain in the
   ˘Pending÷ state with the sessionDataPath attribute unaltered. Given
   that the sessionDataPath would probably be invalid catch specific access
         -- events. This PRC references a group of
         -- eventHdlrAuthProtocol instances which define a set of
         -- Authentication mechanisms to use if the
   Provisioning Decision failed, this an access event is the appropriate behavior.

7. 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-ROLE-PIB
          InetAddress, InetAddressType
                  FROM INET-ADDRESS-MIB
          TruthValue, PhysAddress
                  FROM SNMPv2-TC;

      accessBindPib  MODULE-IDENTITY
          SUBJECT-CATEGORIES { all }
          LAST-UPDATED "200107101600Z"
          ORGANIZATION "IETF RAP WG"
          CONTACT-INFO "

Weiss et al.             Expires October 2000                [Page 44] 
                        Walter Weiss
                        Ellacoya Networks
                        7 Henry Clay Drive
                        Merrimack, NH 03054
                        Phone: 603-879-7364
                        E-mail: wweiss@ellacoya.com
                      "
         -- 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
         -- access event and specify the context data to send to the
         -- PDP when an access event is caught.

         datapathEventHdlrTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF DatapathEventHdlrEntry
           PIB-ACCESS      install
           STATUS          current
           DESCRIPTION
                  "A PIB module containing
              "The datapathEventHdlrTable specifies for what access
              events the set PEP should send an access request to the PDP.
              As a result of classes this access request, the PEP may send
              configuration changes to bind
                  authorization 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
              datapathEventHdlrTable can be said to COPS
                  Provisioning create eventTable
              entries for user access. "

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

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

      capabilityClasses OBJECT IDENTIFIER ::=

         datapathEventHdlrEntry OBJECT-TYPE
           SYNTAX  DatapathEventHdlrEntry
           STATUS  current
           DESCRIPTION
                "dataPathEventHdlrTable entry."
           EXTENDS { accessBindPib 1 EventHandlerEntry }
      sessionClasses OBJECT IDENTIFIER ::=
           UNIQUENESS { accessBindPib 2    eventHandlerElements,
                           eventHandlerNonMatchNext,
                           datapathEventHdlrRequestAuth
                      }
      accessorClasses OBJECT IDENTIFIER

           ::= { accessBindPib 3 }
      contextClasses OBJECT IDENTIFIER datapathEventHdlrTable 1}

         DatapathEventHdlrEntry ::= SEQUENCE { accessBindPib 4
           datapathEventHdlrRequestAuth    TruthValue,
           datapathEventHdlrAuthProtocol   TagReferenceId
         }
      authClasses OBJECT IDENTIFIER

         datapathEventHdlrRequestAuth    OBJECT-TYPE
           SYNTAX        TruthValue
           STATUS        current
           DESCRIPTION
                "Boolean flag, if set to 'true' requires authentication
                data to be sent in the request sent to the PDP with the
                access event."

            ::= { accessBindPib 5 datapathEventHdlrEntry 1}
         datapathEventHdlrAuthProtocol    OBJECT-TYPE
           SYNTAX        TagReferenceId
           PIB-TAG       { eventHdlrAuthProtocolGroup }
           STATUS        current
           DESCRIPTION
                "References a group of eventHdlrAuthProtocol instances,
                 each of which specifies an authentication mechanism."

            ::= { datapathEventHdlrEntry 2}

     --
     -- 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
     -- Session Table request, the level of encapsulated data and the interface
     --

      sessionTable information for that request.

        contextDataTable OBJECT-TYPE
           SYNTAX          SEQUENCE OF SessionEntry ContextDataEntry
           PIB-ACCESS     install-notify      install
           STATUS          current
           DESCRIPTION
              "An instance of this
                 "This class is created by the PEP and sent points to the PDP. The PDP will fill in the sessionStatus field
               and send the instance back when sending context information to be
                 included with a decision." request."

           ::= { sessionClasses contextClasses 1 }

      sessionEntry

        contextDataEntry OBJECT-TYPE
           SYNTAX         SessionEntry  ContextDataEntry
           STATUS  current
           DESCRIPTION
               "An instance of this class contains the sessionTable PRC." 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 { sessionId contextDataId }
           UNIQUENESS { }

           ::= { sessionTable 1 }

      SessionEntry ::= contextDataTable 1}

         ContextDataEntry::= SEQUENCE {

Weiss et al.             Expires October 2000                [Page 45] 
              sessionId
           contextDataId            InstanceId,
              sessionStatus              INTEGER,
              sessionRealm               OCTET STRING,
              sessionUsername            OCTET STRING,
              sessionDataPath            Prid,
              sessionBinding             ReferenceId,
              sessionAccessor            ReferenceId
           contextDataGroup         TagId,
           contextDataIfElement     PrcIdentifier,
           contextDataEncapsulation INTEGER
         }

      sessionId

         contextDataId   OBJECT-TYPE
           SYNTAX        InstanceId
           STATUS        current
           DESCRIPTION
                "An arbitrary integer index to that uniquely identify identifies an
                instance of this
              provisioning class."

          ::= { sessionEntry 1 }

      sessionStatus OBJECT-TYPE
          SYNTAX         INTEGER {
                                               Pending(0),
                                               Enabled(1),
                                               Disabled(2)
                                           }
          STATUS         current
          DESCRIPTION
              "This attribute is set by the PDP. Set to true(1) if the
              PDP has authorized the session, else set to false(2)." contextDataTable class."

              ::= { sessionEntry 2 }

      sessionRealm contextDataEntry 1}

         contextDataGroup  OBJECT-TYPE
           SYNTAX         OCTET STRING        TagId   --corresponding TagReference
                                 --defined in eventHdlrElement
           STATUS        current
           DESCRIPTION
              "Realm name in which
                "Defines the client is requesting
              access (sometimes referred grouping of contextData instances
                that are applicable to as a domain name."

          ::= { sessionEntry 3 }

      sessionUsername OBJECT-TYPE
          SYNTAX         OCTET STRING
          STATUS         current
          DESCRIPTION
              "Unique user name given eventHdlrElement. When
                instances of this PRC are sent to identify the client requesting
              access."

          ::= { sessionEntry 4 }

      sessionDataPath OBJECT-TYPE
          SYNTAX         Prid
          STATUS         current

Weiss et al.             Expires October 2000                [Page 46] 
          DESCRIPTION
              "This attribute references PEP without the first functional data path
              element to process data flow for
                event Handler information, this session. It attribute is
              first assigned by the PEP with the
              accessorElementDefaultSessionDataPath in the
              accessorElement and may optionally be reassigned by the
              PDP." unused."

              ::= { sessionEntry 5 }

      sessionBinding contextDataEntry 2}

         contextDataIfElement      OBJECT-TYPE
           SYNTAX         ReferenceId
          PIB-REFERENCES { sessionEntry }        PrcIdentifier
           STATUS        current
           DESCRIPTION
              "This attribute allows
              "The OID of a PEP to indicate class whose instance is to be included with
              the PDP that
              this session was generated downstream on the data path
              from a session for which an PEP has previously generated
              an authorization request. This allows the PDP to
              reference additional knowledge acquired from the previous
              session such as the credentials request or interface data. " event-specific ContextData Response."

              ::= { sessionEntry 6 }

      sessionAccessor contextDataEntry 3}

         contextDataEncapsulation OBJECT-TYPE
           SYNTAX         ReferenceId
          PIB-REFERENCES { accessorEntry }        INTEGER
           STATUS        current
           DESCRIPTION
              "This attribute references the instance allows one to distinguish between inner
               and outer headers when there are multiple encapsulated
               headers of the previously
               provisioned Accessor that resulted same type in this PEP Access
               Request." 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."

              ::= { sessionEntry 7 } contextDataEntry 4}

         --
         -- Accessor Table Layer 3 Header Data PRC
         --

      accessorTable

         ctxtL3HdrTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AccessorEntry ctxtL3HdrEntry
             PIB-ACCESS      install     notify
             STATUS         current
             DESCRIPTION
              "The AccessorTable identifies when
                "An instance of this class is created by the PEP should send an
              access or authentication request and
                sent to the PDP. As a
              result of this request, a new session may be started.
              Hence, PDP to provide the AccessorTable can be said PDP with information it
                requested in the ContextData PRC. The PDP uses
                this PRC to create or remove
              SessionTable entries. "

Weiss et al.             Expires October 2000                [Page 47] make Authentication/Provisioning
                decisions."

             ::= { accessorClasses 1 contextClasses 2 }

      accessorEntry

         ctxtL3HdrEntry OBJECT-TYPE
             SYNTAX  AccessorEntry         CtxtL3HdrEntry
             STATUS         current
             DESCRIPTION
             " An
                 "An instance of this class defines the circumstances for
             generating an access request, and provides the means for
             specifying the contents of the PEP Access Request." ctxtL3HdrTable PRC."

             PIB-INDEX { accessorId ctxtL3HdrId }
             UNIQUENESS {    accessorRequestAuth,
                        accessorAccElmRef,
                        accessorAuthProtocol,
                        accessorAuthContext,
                        accessorDefaultDataPath }

             ::= { accessorTable 1}

      AccessorEntry::= ctxtL3HdrTable 1 }

         CtxtL3HdrEntry::= SEQUENCE {
        accessorId
                 ctxtL3HdrId               InstanceId,
        accessorRequestAuth
                 ctxtL3HdrSrcAddrType        InetAddressType,
                 ctxtL3HdrSrcAddr            InetAddress,
                 ctxtL3HdrDstAddrType        InetAddressType,
                 ctxtL3HdrDstAddr            InetAddress,
                 ctxtL3HdrProtocol           Unsigned32,
                 ctxtL3HdrSrcPort            Unsigned32,
                 ctxtL3HdrDstPort            Unsigned32,
                 ctxtL3HdrDscp               Unsigned32,
                 ctxtL3HdrEcn                TruthValue,
        accessorAccElmRef               ReferenceId,
        accessorAuthProtocol            TagReferenceId,
        accessorAuthContext             TagReferenceId,
        accessorDefaultDataPath         Prid
                 ctxtL3HdrIpOpt              OCTET STRING,
                 ctxtL3HdrEncap              Integer32
         }

      accessorId

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

         ::= { accessorEntry 1}

      accessorRequestAuth OBJECT-TYPE
        SYNTAX        TruthValue
        STATUS        current
        DESCRIPTION
             "Indicates whether or not authentication is required for this session. TRUE indicates that authorization is
             required."
                 provisioning class."

             ::= { accessorEntry 2}

      accessorAccElmRef ctxtL3HdrEntry 1 }

         ctxtL3HdrSrcAddrType OBJECT-TYPE
             SYNTAX        ReferenceId
        PIB-REFERENCES { accessorElementEntry }         InetAddressType
             STATUS         current
             DESCRIPTION
             "A reference
              "The address type enumeration value [INETADDR] to an AccessorElementTable instance which

Weiss et al.             Expires October 2000                [Page 48] 
             determines specify
               the scope (criteria for generating a new
             request) and interim forwarding behavior." type of the packet's source L3 address)."
             ::= { accessorEntry 3}

      accessorAuthProtocol ctxtL3HdrEntry 2 }

         ctxtL3HdrSrcAddr OBJECT-TYPE
             SYNTAX        TagReferenceId
        PIB-TAG       { accessorAuthProtocolGroup }         InetAddress
             STATUS         current
             DESCRIPTION
             "Identifies a list of accessorAuthProtocolTable entries
             associated with this accessor instance."
                 " The packet's source L3 address."

             ::= { accessorEntry 4}

      accessorAuthContext ctxtL3HdrEntry 3 }

         ctxtL3HdrDstAddrType OBJECT-TYPE
             SYNTAX       TagReferenceId
        PIB-TAG       { contextDataGroup }         InetAddressType
             STATUS         current
             DESCRIPTION
             "Identifies a list
              "The address type enumeration value [INETADDR] to specify
               the type of ContextDataTable entries
             associated with this accessor instance." the packet's destination L3 address."

             ::= { accessorEntry 5}

      accessorDefaultDataPath ctxtL3HdrEntry 4 }

         ctxtL3HdrDstAddr OBJECT-TYPE
             SYNTAX        Prid         InetAddress
             STATUS         current
             DESCRIPTION
                 "The data path for Šout of scopeĂ traffic." packet's destination L3 address."

             ::= { accessorEntry 6}

      --
      -- AccessorElement Table
      --

      accessorElementTable ctxtL3HdrEntry 5 }

         ctxtL3HdrProtocol OBJECT-TYPE
             SYNTAX          SEQUENCE OF AccessorElementEntry
        PIB-ACCESS      install         Unsigned32
             STATUS         current
             DESCRIPTION
              "This table defines the criteria to be used to generate
              an access request. It also defines the interim forwarding
              behavior pending a decision from the server."
                 "The packet's protocol field."

             ::= { accessorClasses 2 ctxtL3HdrEntry 6 }

     accessorElementEntry

         ctxtL3HdrSrcPort  OBJECT-TYPE
             SYNTAX  AccessorElementEntry         Unsigned32
             STATUS         current
             DESCRIPTION
             "An instance of
                 "This attribute binds an existing upstream session to
                 this class defines request trigger
             criteria and interim forwarding behavior for packets."

Weiss et al.             Expires October 2000                [Page 49] 
        PIB-INDEX { accessorElementId }
        UNIQUENESS { accessorElementScope }

        ::= { accessorElementTable 1}

      AccessorElementEntry::= SEQUENCE session instance."

             ::= {
        accessorElementId                      InstanceId,
        accessorElementScope                   TagReferenceId,
        accessorElementInterimFwdBehavior      INTEGER,
        accessorElementDefaultSessionDataPath  Prid ctxtL3HdrEntry 7 }

      accessorElementId

         ctxtL3HdrDstPort  OBJECT-TYPE
             SYNTAX        InstanceId         Unsigned32
             STATUS         current
             DESCRIPTION
             "An arbitrary integer index that uniquely identifies
                 "This attribute binds an
             instance of the accessorElementTable class." existing upstream session to
                 this session instance."
             ::= { accessorElementEntry 1}

      accessorElementScope ctxtL3HdrEntry 8 }

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

             ::= { accessorSessionScopeGroup ctxtL3HdrEntry 9 }

         ctxtL3HdrEcn  OBJECT-TYPE
             SYNTAX         TruthValue
             STATUS         current
             DESCRIPTION
             "Identifies a list of AccessorSessionScopeTable instances
             associated with an instance of
                 "PEP sets this class. This list
             defines the criteria for partitioning various portions of
             traffic into distinct sessions." attribute to true(1) if ECN capable."

             ::= { accessorElementEntry 2}

      accessorElementInterimFwdBehavior ctxtL3HdrEntry 10 }

         ctxtL3HdrIpOpt  OBJECT-TYPE
             SYNTAX INTEGER {
                          DROP (0),
                          FORWARD (1),
                          QUEUE (2)
                        }         OCTET STRING
             STATUS         current
             DESCRIPTION
             "The forwarding behavior to use while awaiting a PDP
             Access Response message."
                 "IP Options field in the packet."

             ::= { accessorElementEntry 3}

      accessorElementDefaultSessionDataPath ctxtL3HdrEntry 11 }

         ctxtL3HdrEncap  OBJECT-TYPE
             SYNTAX        Prid         Integer32
             STATUS         current
             DESCRIPTION
             "The default data path for each session while waiting for
              "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
             PDP Access Response message."

Weiss et al.             Expires October 2000                [Page 50]
              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."

             ::= { accessorElementEntry 4} ctxtL3HdrEntry 12 }

      --
      -- AccessorSessionScope Table 802.1 Header Data PRC
      --

      accessorSessionScopeTable
         ctxt802HdrTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AccessorSessionScopeEntry Ctxt802HdrEntry
             PIB-ACCESS      install     notify
             STATUS         current
             DESCRIPTION
              "This
              "An instance of this class defines is created by the criteria PEP and sent
               to be used for
              partitioning various portions of traffic into distinct
              sessions." the PDP to provide the PDP with information it
               requested in the ContextData PRC. The PDP uses this PRC
               to make Authorization/Provisioning decisions."

             ::= { accessorClasses contextClasses 3 }

      accessorSessionScopeEntry

         ctxt802HdrEntry OBJECT-TYPE
             SYNTAX  AccessorSessionScopeEntry         Ctxt802HdrEntry
             STATUS         current
             DESCRIPTION
                 "An instance of this class defines an individual criterion
             to be used towards generating an access request." the ctxt802HdrTable PRC."

             PIB-INDEX { accessorSessionScopeId ctxt802HdrId }
             UNIQUENESS { accessorSessionScopeGroup,
                     accessorSessionScopeScopeRef }

             ::= { accessorSessionScopeTable 1}

      AccessorSessionScopeEntry::= ctxt802HdrTable 1 }

         Ctxt802HdrEntry::= SEQUENCE {
        accessorSessionScopeId
                 ctxt802HdrId               InstanceId,
        accessorSessionScopeGroup      TagId,
        accessorSessionScopeFilter     Prid,
        accessorSessionScopePrecedence INTEGER
                 ctxt802HdrSrcAddr          PhysAddress,
                 ctxt802HdrDstAddr          PhysAddress,
                 ctxt802HdrProtocol         Unsigned32,
                 ctxt802HdrPriority         Unsigned32,
                 ctxt802HdrVlan             Unsigned32,
                 ctxt802HdrEncap            Integer32
         }

      accessorSessionScopeId

         ctxt802HdrId  OBJECT-TYPE
             SYNTAX         InstanceId
             STATUS         current
             DESCRIPTION
                 "An arbitrary integer index that to uniquely identifies identify an instance of the accessorSessionScopeTable this
                 provisioning class."

             ::= { accessorSessionScopeEntry 1}

      accessorSessionScopeGroup ctxt802HdrEntry 1 }

         ctxt802HdrSrcAddr OBJECT-TYPE
             SYNTAX        TagId         PhysAddress
             STATUS         current
             DESCRIPTION
             "Represents the binding between the accessorElementTable
              and the accessorSessionScope entries. A group of

Weiss et al.             Expires October 2000                [Page 51] 
              accessorSessionScope entries constitutes the criteria for
              partitioning various portions of traffic into distinct
              sessions."
                 " The packet's source MAC address."

             ::= { accessorSessionScopeEntry 2}

      accessorSessionScopeFilter ctxt802HdrEntry 2 }

         ctxt802HdrDstAddr OBJECT-TYPE
             SYNTAX        Prid         PhysAddress
             STATUS         current
             DESCRIPTION
             "Pointer to a filter to be used as
                 "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 criteria." 802.1q header extension."

             ::= { accessorSessionScopeEntry 3}

      accessorSessionScopePrecedence ctxt802HdrEntry 5 }

         ctxt802HdrVlan OBJECT-TYPE
             SYNTAX        INTEGER         Unsigned32 (1..4094)
             STATUS         current
             DESCRIPTION
             "Represents
              "The L2 packet's VLAN field. This attribute is only valid
               for packets using the precedence of 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 criterion with respect
             to other criteria within value will be the same group. When
              as the
             precedence is unique, value specified in the ContextData
              instance represents an
             alternative criteria (an ORing function). When the
             precedence for two or more 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
             accessorSessionScope class is 'n'th header starting
              from the same, outermost,
              negative number 'n' means the attributes
             within all 'n'th header starting from
              the instances are treated collectively as a
             single filter criteria." innermost."
             ::= { accessorSessionScopeEntry 4} ctxt802HdrEntry 7 }

         --
         -- AccessorAuthProtocol CtxtDialupInterface Table
         --

      accessorAuthProtocolTable

         ctxtDialupInterfaceTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AccessorAuthProtocolEntry CtxtDialupInterfaceEntry
             PIB-ACCESS      install     notify
             STATUS         current
             DESCRIPTION
              "This class lists the authentication protocols that can
              be used for an access request originating from a
              particular instance of the accessorTable."
                 "Dialup Interface context data."

             ::= { accessorClasses contextClasses 4 }

      accessorAuthProtocolEntry

         ctxtDialupInterfaceEntry OBJECT-TYPE
             SYNTAX  AccessorAuthProtocolEntry         CtxtDialupInterfaceEntry
             STATUS         current
             DESCRIPTION
             "An instance of this class describes an authentication
             protocol that may be used for an access request. Instances

Weiss et al.             Expires October 2000                [Page 52]
                 "Entry oid 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" ctxtDialupInterfaceTable PRC."

             PIB-INDEX { accessorAuthProtocolId ctxtDialupInterfaceId }
             UNIQUENESS { accessorAuthProtocolGroup,
                     accessorAuthProtocolAuthMechanism }

             ::= { accessorAuthProtocolTable 1}

      AccessorAuthProtocolEntry::= ctxtDialupInterfaceTable 1 }

         CtxtDialupInterfaceEntry::= SEQUENCE {
        accessorAuthProtocolId
                 ctxtDialupInterfaceId                InstanceId,
        accessorAuthProtocolGroup       TagId,
        accessorAuthProtocolAuthMechanism INTEGER
                 ctxtDialupInterfaceNASPort           Integer32,
                 ctxtDialupInterfaceNASPortId         OCTET STRING,
                 ctxtDialupInterfaceNASPortType       INTEGER,
                 ctxtDialupInterfaceCalledStationId   OCTET STRING,
                 ctxtDialupInterfaceCallingStationId  OCTET STRING,
                 ctxtDialupInterfaceConnectInfo       OCTET STRING
         }

      accessorAuthProtocolId

         ctxtDialupInterfaceId  OBJECT-TYPE
             SYNTAX         InstanceId
             STATUS         current
             DESCRIPTION
                 "An arbitrary integer index that to uniquely identifies identify an instance of the ContextDataTable this
                 provisioning class."

             ::= { accessorAuthProtocolEntry 1}

      accessorAuthProtocolGroup OBJECT-TYPE
        SYNTAX        TagId
        STATUS        current
        DESCRIPTION
             "Represents a binding between an accessorTable instance
             and a list of accessorAuthProtocolTable instances."

        ::= { accessorAuthProtocolEntry 2}

      accessorAuthProtocolAuthMechanism OBJECT-TYPE
        SYNTAX        INTEGER {
                                  PAP (0),
                                  CHAP (1),
                                  EAP-MD5(2),
                                  EAP-TLS(3) ctxtDialupInterfaceEntry 1 }
        STATUS        current
        DESCRIPTION
             "The authentication protocol that may be used for an
             access request."
           ::= { accessorAuthProtocolEntry 3}

      --
      -- ContextData Table
      --

Weiss et al.             Expires October 2000                [Page 53] 
   contextDataTable

         ctxtDialupInterfaceNASPort  OBJECT-TYPE
             SYNTAX          SEQUENCE OF ContextDataEntry
        PIB-ACCESS      install         Integer32
             STATUS         current
             DESCRIPTION
              "This class points to Attribute indicates the physical port number of the
              NAS which is authenticating the context information to be
              included with an access request." 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 1 ctxtDialupInterfaceEntry 2 }

     contextDataEntry

         ctxtDialupInterfaceNASPortId  OBJECT-TYPE
             SYNTAX  ContextDataEntry         OCTET STRING
             STATUS         current
             DESCRIPTION
             "An instance of this class
               "This Attribute contains a text string which identifies
               the type description
             (COPS-PR OID) port of the class NAS which needs to be filled in by is authenticating the PEP user. It
               is only used in Access-Request and included with Accounting-Request
               packets.  Note that this is using 'port' in its sense of
               a PEP access request."
        PIB-INDEX { contextDataId }
        UNIQUENESS { } physical connection on the NAS, not in the sense of a
               TCP or UDP port number. "

             ::= { contextDataTable 1}

      ContextDataEntry::= SEQUENCE {
        contextDataId            InstanceId,
        contextDataGroup         TagId,
        contextDataSessionRef    ReferenceId,
        contextDataIfElement     PrcIdentifier,
        contextDataEncapsulation INTEGER ctxtDialupInterfaceEntry 3 }

      contextDataId

         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 contextDataTable class."

           ::= { contextDataEntry 1}

      contextDataGroup  OBJECT-TYPE
        SYNTAX        TagId
        STATUS        current
        DESCRIPTION
             "Defines the grouping NAS via some
                   transport protocol, instead of contextData instances
             that are applicable 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 given Accessor. This attribute
             MUST NOT be specified when hint to the instance 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
             Session-specific contextData Request message." 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 of 'radWirelessOther(18)' indicates Wireless
                   - Other.

                   A value of 'radWirelessIEEE80211(19)' indicates
                   Wireless - IEEE 802.11."
             ::= { contextDataEntry 2}

      contextDataSessionRef ctxtDialupInterfaceEntry 4 }

         ctxtDialupInterfaceCalledStationId  OBJECT-TYPE
             SYNTAX        ReferenceId

Weiss et al.             Expires October 2000                [Page 54] 
        PIB-REFERENCES { sessionEntry }         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "This attribute is used Attribute allows the NAS to specify send in the Session for which Access-
                 Request packet the ContextData is being requested with a Session-
              specific ContextData Request. This attribute MUST NOT phone number that the user called,
                 using Dialed Number Identification (DNIS) or similar
                 technology.  Note that this may be
              specified when different from the instance of
                 phone number the ContextData class call comes in on.  It is only used in an Accessor Provisioning Decision message."

           ::= { contextDataEntry 3}

      contextDataIfElement      OBJECT-TYPE
        SYNTAX        PrcIdentifier
        STATUS        current
        DESCRIPTION
             "The OID of a class whose instance is to be included with
             the PEP access request or Session-specific ContextData
             Response."
                 Access-Request packets. "
             ::= { contextDataEntry 4}

      contextDataEncapsulation ctxtDialupInterfaceEntry 5 }

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

              A value of:
              0 means all headers,
              positive number ŠnĂ means the ŠnĂth header starting
              from Access-
              Request packet the outermost,
              negative phone number ŠnĂ means that the ŠnĂth header starting user is calling
              from, using Dialed Number Identification (DNIS) or
              similar technology.  Note that this may be different from
              the innermost." phone number called.  It is only used in
              Access-Request packets. "
             ::= { contextDataEntry 5}

      --
      -- Layer 3 Header Data PRC
      --

      ctxtL3HdrTable ctxtDialupInterfaceEntry 6 }

         ctxtDialupInterfaceConnectInfo  OBJECT-TYPE
             SYNTAX         SEQUENCE OF ctxtL3HdrEntry
          PIB-ACCESS     notify         OCTET STRING
             STATUS         current
             DESCRIPTION
              "An instance of this class is created by
               "This Attribute allows the PEP and sent NAS to send in the PDP to provide Access-
               Request packet the PDP with information it
               requested in phone number that the ContextData PRC. The PDP uses
               this PRC to make Authentication/Provisioning decisions."

Weiss et al.             Expires October 2000                [Page 55] 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
                 "."

             ::= { contextClasses 2 5 }

      ctxtL3HdrEntry

         ctxtDialupIfFramedProtocolEntry OBJECT-TYPE
             SYNTAX         CtxtL3HdrEntry         CtxtDialupIfFramedProtocolEntry
             STATUS         current
             DESCRIPTION
              "An instance
                "Entry oid of the ctxtL3HdrTable ctxtDialupIfFramedProtocolTable PRC."

             PIB-INDEX { ctxtL3HdrId ctxtDialupIfFramedProtocolId }
             UNIQUENESS { }

             ::= { ctxtL3HdrTable ctxtDialupIfFramedProtocolTable 1 }

      CtxtL3HdrEntry::=

         CtxtDialupIfFramedProtocolEntry ::= SEQUENCE {
              ctxtL3HdrId
                 ctxtDialupIfFramedProtocolId           InstanceId,
              ctxtL3HdrSrcAddrType        InetAddressType,
              ctxtL3HdrSrcAddr            InetAddress,
              ctxtL3HdrDstAddrType        InetAddressType,
              ctxtL3HdrDstAddr            InetAddress,
              ctxtL3HdrProtocol           Unsigned32,
              ctxtL3HdrSrcPort            Unsigned32,
              ctxtL3HdrDstPort            Unsigned32,
              ctxtL3HdrDscp
                 ctxtDialupIfFramedProtocolProt         INTEGER,
                 ctxtDialupIfFramedProtocolMTU          Integer32,
                 ctxtDialupIfFramedProtocolCompression  INTEGER,
                 ctxtDialupIfFramedProtocolPortLimit    Unsigned32,
              ctxtL3HdrEcn                TruthValue,
              ctxtL3HdrIpOpt              TruthValue,
              ctxtL3HdrEncap              Integer32
                 ctxtDialupIfFramedProtocolIpAddress    InetAddress,
                 ctxtDialupIfFramedProtocolIpNetmask    InetAddress
         }

      ctxtL3HdrId

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

             ::= { ctxtL3HdrEntry ctxtDialupIfFramedProtocolEntry 1 }

      ctxtL3HdrSrcAddrType

         ctxtDialupIfFramedProtocolProt  OBJECT-TYPE
             SYNTAX         InetAddressType  INTEGER {
                              radPPP(1),
                              radSLIP(2),
                              radARAP(3),
                              radGandalf(4),
                              radXylogics(5),
                              radX75Synchronous(6)
                      }
             STATUS         current
             DESCRIPTION
              "The address type enumeration value [INETADDR] to specify
               "This Attribute indicates the type framing to be used for
               framed access. It MAY be used in both Access-Request and
               Access-Accept packets.

                    A value of the packet's source L3 address)." '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."

             ::= { ctxtL3HdrEntry ctxtDialupIfFramedProtocolEntry 2 }

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

Weiss et al.             Expires October 2000                [Page 56] 
          ::= { ctxtL3HdrEntry 3 }

      ctxtL3HdrDstAddrType

         ctxtDialupIfFramedProtocolMTU  OBJECT-TYPE
             SYNTAX         InetAddressType         Integer32
             STATUS         current
             DESCRIPTION
              "The address type enumeration value [INETADDR]
              "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 specify the type of server that it
              would prefer that value, but the packet's destination L3 address." server is not required
              to honor the hint."

             ::= { ctxtL3HdrEntry 4 ctxtDialupIfFramedProtocolEntry 3 }

      ctxtL3HdrDstAddr

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

          ::=  INTEGER { ctxtL3HdrEntry 5
                              radNone(0),
                              radVJ(1),
                              radIPXheader(2),
                              radStacLZS(3)
                      }

      ctxtL3HdrProtocol OBJECT-TYPE
          SYNTAX         Unsigned32
             STATUS         current
             DESCRIPTION
              "The packet's
              "This Attribute indicates a compression protocol field." 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."

             ::= { ctxtL3HdrEntry 6 ctxtDialupIfFramedProtocolEntry 4 }

      ctxtL3HdrSrcPort

         ctxtDialupIfFramedProtocolPortLimit  OBJECT-TYPE
             SYNTAX         Unsigned32
             STATUS         current
             DESCRIPTION
               "This attribute binds 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 existing upstream session 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
              this session instance." the server as a hint that that many ports
               are desired for use, but the server is not required to
               honor the hint."

             ::= { ctxtL3HdrEntry 7 ctxtDialupIfFramedProtocolEntry 5 }

      ctxtL3HdrDstPort

         ctxtDialupIfFramedProtocolIpAddress  OBJECT-TYPE
             SYNTAX         Unsigned32         InetAddress
             STATUS         current
             DESCRIPTION
               "This attribute binds Attribute indicates the address to be configured
               for the user.  It MAY be used in Access-Accept packets.
               It MAY be used in an existing upstream session Access-Request packet as a hint by
               the NAS to
              this session instance."

          ::= { ctxtL3HdrEntry 8 }

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

Weiss et al.             Expires October 2000                [Page 57] 
          ::= { ctxtL3HdrEntry 9 }

      ctxtL3HdrEcn  OBJECT-TYPE
          SYNTAX         TruthValue
          STATUS         current
          DESCRIPTION
              "PEP sets this attribute the server that it would prefer that address,
               but the server is not required to true(1) if ECN capable."

          ::= { ctxtL3HdrEntry 10 }

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

             ::= { ctxtL3HdrEntry 11 ctxtDialupIfFramedProtocolEntry 6 }

      ctxtL3HdrEncap

         ctxtDialupIfFramedProtocolIpNetmask  OBJECT-TYPE
             SYNTAX         Integer32         InetAddress
             STATUS         current
             DESCRIPTION
              "This attribute specifies which encapsulated header is
              being described. The sign on this value will be the same
              as Attribute indicates the value specified in IP netmask to be configured
              for the ContextData
              instance that requested this header. If user when the original
              ContextData instance specified user is a
              ContextDataEncapsulation value of zero (meaning
              return all headers), then all instances of this attribute
              MUST router to a network.  It
              MAY be expressed used in Access-Accept packets.  It MAY be used in
              an Access-Request packet as positive numbers.

              A value of:

              positive number ŠnĂ means a hint by the ŠnĂth header starting
              from NAS to the outermost,
              negative number ŠnĂ means
              server that it would prefer that netmask, but the ŠnĂth header starting from server
              is not required to honor the innermost." hint."
             ::= { ctxtL3HdrEntry 12 }

   --
   -- 802.1 Header Data PRC
   --

   ctxt802HdrTable ctxtDialupIfFramedProtocolEntry 7 }

         ---
         --- CtxtDialupIfLoginService Table
         ---

         ctxtDialupIfLoginServiceTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF Ctxt802HdrEntry CtxtDialupIfLoginServiceEntry
             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

Weiss et al.             Expires October 2000                [Page 58] 
               this PRC to make Authorization/Provisioning decisions."
                 "Base class."

             ::= { contextClasses 3 6 }

      ctxt802HdrEntry

         ctxtDialupIfLoginServiceEntry OBJECT-TYPE
             SYNTAX         Ctxt802HdrEntry         CtxtDialupIfLoginServiceEntry
             STATUS         current
             DESCRIPTION
              "An instance
                 "Entry oid of the ctxt802HdrTable ctxtDialupIfLoginServiceTable PRC."

             PIB-INDEX { ctxt802HdrId ctxtDialupIfLoginServiceId }
             UNIQUENESS { }

             ::= { ctxt802HdrTable ctxtDialupIfLoginServiceTable 1 }

      Ctxt802HdrEntry::=

         CtxtDialupIfLoginServiceEntry::= SEQUENCE {
              ctxt802HdrId
                 ctxtDialupIfLoginServiceId       InstanceId,
              ctxt802HdrSrcAddr          PhysAddress,
              ctxt802HdrDstAddr          PhysAddress,
              ctxt802HdrProtocol         Unsigned32,
              ctxt802HdrPriority         BITS,
              ctxt802HdrVlan             Unsigned32,
              ctxt802HdrEncap            Integer32
                 ctxtDialupIfLoginServiceIpHost   InetAddress
         }

      ctxt802HdrId

         ctxtDialupIfLoginServiceId 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

Weiss et al.             Expires October 2000                [Page 59] 
          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 uniquely identify an
              ContextDataEncapsulation value of zero (meaning
              return all headers), then all instances instance 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."
                 provisioning class."

             ::= { ctxt802HdrEntry 7 ctxtDialupIfLoginServiceEntry 1 }

      --
      -- CtxtDialupInterface

         ctxtDialupIfLoginServiceIpHost OBJECT-TYPE
             SYNTAX         InetAddress
             STATUS         current
             DESCRIPTION
                 "."
             ::= { ctxtDialupIfLoginServiceEntry 2 }

         ---
         --- CtxtDialupIfLoginLat Table
      --

      ctxtDialupInterfaceTable (Extends
         --- CtxtDialupIfLoginService)
         ---

         ctxtDialupIfLoginLatTable OBJECT-TYPE

Weiss et al.             Expires October 2000                [Page 60]
             SYNTAX         SEQUENCE OF CtxtDialupInterfaceEntry CtxtDialupIfLoginLatEntry
             PIB-ACCESS     notify
             STATUS         current
             DESCRIPTION
              "."
                 "Extended class."

             ::= { contextClasses 4 7 }

      ctxtDialupInterfaceEntry

         ctxtDialupIfLoginLatEntry OBJECT-TYPE
             SYNTAX         CtxtDialupInterfaceEntry         CtxtDialupIfLoginLatEntry
             STATUS         current
             DESCRIPTION
                 "Entry oid of the ctxtDialupInterfaceTable ctxtDialupIfLoginLatTable PRC."

          PIB-INDEX
                EXTENDS { ctxtDialupInterfaceId ctxtDialupIfLoginServiceEntry }
             UNIQUENESS { }

             ::= { ctxtDialupInterfaceTable ctxtDialupIfLoginLatTable 1 }

      CtxtDialupInterfaceEntry::=

         CtxtDialupIfLoginLatEntry::= SEQUENCE {
              ctxtDialupInterfaceId                InstanceId,
              ctxtDialupInterfaceNASPort           Integer32,
              ctxtDialupInterfaceNASPortId
                 ctxtDialupIfLoginLatService   OCTET STRING,
              ctxtDialupInterfaceNASPortType       INTEGER,
              ctxtDialupInterfaceCalledStationId
                 ctxtDialupIfLoginLatNode      OCTET STRING,
              ctxtDialupInterfaceCallingStationId
                 ctxtDialupIfLoginLatGroup     OCTET STRING,
              ctxtDialupInterfaceConnectInfo
                 ctxtDialupIfLoginLatPort      OCTET STRING
         }

      ctxtDialupInterfaceId

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

             ::= { ctxtDialupInterfaceEntry ctxtDialupIfLoginLatEntry 1 }

      ctxtDialupInterfaceNASPort

         ctxtDialupIfLoginLatNode  OBJECT-TYPE
             SYNTAX         Integer32         OCTET STRING
             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."
                 "."

             ::= { ctxtDialupIfLoginLatEntry 2 }
         ctxtDialupIfLoginLatGroup  OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "."

             ::= { ctxtDialupIfLoginLatEntry 3 }

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

             ::= { ctxtDialupIfLoginLatEntry 4 }

       --
       -- 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 { }

           ::= { ctxtDialupInterfaceEntry 2 rsvpFilterTable 1 }

      ctxtDialupInterfaceNASPortId  OBJECT-TYPE

Weiss et al.             Expires October 2000                [Page 61] 
          SYNTAX

   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
              "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
          "An arbitrary integer index that this is using 'port' in its sense uniquely identifies an
          instance of
              a physical connection on the NAS, not in the sense of a
              TCP or UDP port number. " class."
       ::= { ctxtDialupInterfaceEntry 2 rsvpFilterEntry 1 }

      ctxtDialupInterfaceNASPortType

   rsvpFilterFlags 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)
                   }       OCTET STRING
       STATUS       current
       DESCRIPTION
              "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 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.

Weiss et al.             Expires October 2000                [Page 62] 
                   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 Flags carried in the
                   Access-Request might include radNasPortType =
                   Virtual as a hint 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 RADIUS server that the user message was not on a physical port.

                   A 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 'radPIAFS(6)' indicates PIAFS. PIAFS is a
                   form 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 wireless ISDN commonly used in Japan, and
                   stands a mask 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 the matching of 'radIdsl(14)' indicates IDSL ű ISDN
                   Digital Subscriber Line. 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 'radEthernet(15)' indicates Ethernet.

                   A -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 'radXdsl(16)' indicates xDSL - Digital
                   Subscriber Line of unknown type.

                   A value 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 'radCable(17)' indicates Cable.

                   A value a mask for the matching of 'radWirelessOther(18)' indicates Wireless
                   - Other.

                   A value 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 }

   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 'radWirelessIEEE80211(19)' indicates
                   Wireless - IEEE 802.11." the class."
       ::= { ctxtDialupInterfaceEntry ctxtRsvpEntry 1 }

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

Weiss et al.             Expires October 2000                [Page 63] 
      ctxtDialupInterfaceCalledStationId

   ctxtRsvpFlags OBJECT-TYPE
       SYNTAX       OCTET STRING
       STATUS       current
       DESCRIPTION
              "This Attribute allows the NAS to send
          "The RSVP flags contained in the Access-
              Request packet the phone number that the user called,
              using Dialed Number Identification (DNIS) or similar
              technology.  Note that this may message header. They are
          currently undefined and should be different from the
              phone number the call comes in on.  It is only used in
              Access-Request packets. " set to zero."
       ::= { ctxtDialupInterfaceEntry 2 ctxtRsvpEntry 3 }

      ctxtDialupInterfaceConnectInfo

   ctxtRsvpSendTTL OBJECT-TYPE
       SYNTAX         OCTET STRING       Unsigned32 (0..255)
       STATUS       current
       DESCRIPTION
              "This Attribute allows the NAS to send in the Access-
              Request packet the phone number that the call came from,
              using Automatic Number Identification (ANI) or similar
              technology.  It is only used in Access-Request packets."
          "The IP TTL value."
       ::= { ctxtDialupInterfaceEntry 2 ctxtRsvpEntry 4 }

      ---
      --- CtxtDialupInterfaceFramedProtocol Table
      ---

      ctxtDialupIfFramedProtocolTable

   ctxtRsvpInIntfId OBJECT-TYPE
       SYNTAX         SEQUENCE OF CtxtDialupIfFramedProtocolEntry
          PIB-ACCESS     notify       Unsigned32
       STATUS       current
       DESCRIPTION
              "."
          "The Interface Id."
       ::= { contextClasses ctxtRsvpEntry 5 }

      ctxtDialupIfFramedProtocolEntry

   ctxtRsvpInIntfAddrType OBJECT-TYPE
       SYNTAX         CtxtDialupIfFramedProtocolEntry       InetAddressType
       STATUS       current
       DESCRIPTION
              "Entry oid
          "The address type enumeration value [INETADDR] to specify the
          type of the ctxtDialupIfFramedProtocolTable PRC."

          PIB-INDEX { ctxtDialupIfFramedProtocolId }
          UNIQUENESS In Interface IP address."
       ::= { ctxtRsvpEntry 6 }

   ctxtRsvpInIntfAddr OBJECT-TYPE
       SYNTAX       InetAddress
       STATUS       current
       DESCRIPTION
          "The In Interface IP address."
       ::= { ctxtDialupIfFramedProtocolTable 1 ctxtRsvpEntry 7 }

      CtxtDialupInterfaceEntry::= SEQUENCE

   ctxtRsvpOutIntfId OBJECT-TYPE
       SYNTAX       Unsigned32
       STATUS       current
       DESCRIPTION
          "The Out Interface Id."
       ::= {
              ctxtDialupIfFramedProtocolId           InstanceId,
              ctxtDialupIfFramedProtocolProt         INTEGER,

Weiss et al.             Expires October 2000                [Page 64] 
              ctxtDialupIfFramedProtocolMTU          Integer32,
              ctxtDialupIfFramedProtocolCompression  INTEGER,
              ctxtDialupIfFramedProtocolPortLimit    Unsigned32,
              ctxtDialupIfFramedProtocolIpAddress    IpAddress,
              ctxtDialupIfFramedProtocolIpNetmask    IpAddress ctxtRsvpEntry 8 }

      ctxtDialupIfFramedProtocolId

   ctxtRsvpOutIntfAddrType OBJECT-TYPE
       SYNTAX         InstanceId       InetAddressType
       STATUS       current
       DESCRIPTION
              "An index
          "The address type enumeration value [INETADDR] to uniquely identify an instance specify the
          type of this
              provisioning class." the Out Interface IP address."
       ::= { ctxtDialupIfFramedProtocolEntry 1 ctxtRsvpEntry 9 }

      ctxtDialupIfFramedProtocolProt

   ctxtRsvpOutIntfAddr OBJECT-TYPE
       SYNTAX  INTEGER {
                           radPPP(1),
                           radSLIP(2),
                           radARAP(3),
                           radGandalf(4),
                           radXylogics(5),
                           radX75Synchronous(6)
                   }       InetAddress
       STATUS       current
       DESCRIPTION
              "This Attribute indicates the 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."
          "The Out Interface IP address."
       ::= { ctxtRsvpEntry 10 }

   --
   -- RSVP Path Context Data
   --
   ctxtRsvpPathTable OBJECT-TYPE
           SYNTAX  SEQUENCE OF CtxtRsvpPathEntry
           PIB-ACCESS      notify
           STATUS               current
           DESCRIPTION
                   ""

           ::= { ctxtDialupIfFramedProtocolEntry 2 contextClasses 9 }

      ctxtDialupIfFramedProtocolMTU

   ctxtRsvpPathEntry OBJECT-TYPE
           SYNTAX         Integer32

Weiss et al.             Expires October 2000                [Page 65]  CtxtRsvpPathEntry
           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
                   ""

           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 value, but uniquely identifies an
          instance of the server is not required
              to honor class."
       ::= { ctxtRsvpPathEntry 1 }
   ctxtRsvpPathTokenRate OBJECT-TYPE
       SYNTAX       Unsigned32
       STATUS       current
       DESCRIPTION
          "The token bucket rate for the hint." TSPEC."
       ::= { ctxtDialupIfFramedProtocolEntry 3 ctxtRsvpPathEntry 2 }

      ctxtDialupIfFramedProtocolCompression

   --
   -- RSVP PathErr Context Data
   --

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

           ::= {
                           radNone(0),
                           radVJ(1),
                           radIPXheader(2),
                           radStacLZS(3) contextClasses 10 }

   ctxtRsvpPathErrEntry OBJECT-TYPE
           SYNTAX  CtxtRsvpPathErrEntry
           STATUS  current
           DESCRIPTION
              "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."
                   ""

           PIB-INDEX { ctxtRsvpPathErrId }
           UNIQUENESS { }

           ::= { ctxtDialupIfFramedProtocolEntry 4 ctxtRsvpPathErrTable 1 }

      ctxtDialupIfFramedProtocolPortLimit

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

   ctxtRsvpPathErrId OBJECT-TYPE
       SYNTAX         Integer32       InstanceId
       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 arbitrary integer index that uniquely identifies an Access-Accept

Weiss et al.             Expires October 2000                [Page 66] 
              packet.  It is intended for use in conjunction with
              Multilink PPP [10] or similar uses.  It MAY also be sent
              by the NAS to
          instance of the server as a hint that that many ports
              are desired class."
       ::= { ctxtRsvpPathErrEntry 1 }

   ctxtRsvpPathErrTokenRate OBJECT-TYPE
       SYNTAX       Unsigned32
       STATUS       current
       DESCRIPTION
          "The token bucket rate for use, but the server is not required to
              honor the hint." TSPEC."
       ::= { ctxtDialupIfFramedProtocolEntry 5 ctxtRsvpPathErrEntry 2 }

      ctxtDialupIfFramedProtocolIpAddress

   ctxtRsvpPathErrErrorAddrType OBJECT-TYPE
       SYNTAX         IpAddress       InetAddressType
       STATUS       current
       DESCRIPTION
              "This Attribute indicates the
          "The address type IP address to be configured
              for the user.  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 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 }

   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 address,
              but the server is not required to honor uniquely identifies an
          instance of the hint." class."
       ::= { ctxtDialupIfFramedProtocolEntry 6 ctxtRsvpResvEntry 1 }

      ctxtDialupIfFramedProtocolIpNetmask

   ctxtRsvpResvFSpecGrp OBJECT-TYPE
       SYNTAX         IpAddress       TagReferenceId
       PIB-TAG { ctxtRsvpFilterSpecTagId }
       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
          "Identifies a hint by the NAS to the
              server that it would prefer that netmask, but group of Filter Spec entries."
       ::= { ctxtRsvpResvEntry 2 }

   ctxtRsvpResvSvcType OBJECT-TYPE
       SYNTAX       INTEGER {
                                        Controlled_Load(1),
                                        Guaranteed(2)
                                }
       STATUS       current
       DESCRIPTION
          "An enum describing the server
              is not required to honor type of service."
       ::= { ctxtRsvpResvEntry 3 }

   ctxtRsvpResvTokenRate OBJECT-TYPE
       SYNTAX       Unsigned32
       STATUS       current
       DESCRIPTION
          "The token bucket rate for the hint." TSPEC."
       ::= { ctxtDialupIfFramedProtocolEntry 7 ctxtRsvpResvEntry 4 }

      ---
      --- CtxtDialupIfLoginService Table
      ---

      ctxtDialupIfLoginServiceTable

   --
   -- RSVP ResvErr Context Data
   --
   ctxtRsvpResvErrTable OBJECT-TYPE
           SYNTAX  SEQUENCE OF CtxtDialupIfLoginServiceEntry CtxtRsvpResvErrEntry
           PIB-ACCESS      notify
           STATUS               current
           DESCRIPTION
              "Base class."
                   ""

           ::= { contextClasses 6 12 }

      ctxtDialupIfLoginServiceEntry
   ctxtRsvpResvErrEntry OBJECT-TYPE
           SYNTAX         CtxtDialupIfLoginServiceEntry  CtxtRsvpResvErrEntry
           STATUS  current

Weiss et al.             Expires October 2000                [Page 67]
           DESCRIPTION
              "Entry oid of the ctxtDialupIfLoginServiceTable PRC."
                   ""

           PIB-INDEX { ctxtDialupIfLoginServiceId ctxtRsvpResvErrId }
           UNIQUENESS { }

           ::= { ctxtDialupIfLoginServiceTable ctxtRsvpResvErrTable 1 }

      CtxtDialupIfLoginServiceEntry::=

   CtxtRsvpResvErrEntry ::= SEQUENCE {
              ctxtDialupIfLoginServiceId       InstanceId,
              ctxtDialupIfLoginIpHost          IpAddress
                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 }

      ctxtDialupIfLoginServiceId

   ctxtRsvpResvErrErrorCode OBJECT-TYPE
       SYNTAX         InstanceId       Unsigned32
       STATUS       current
       DESCRIPTION
              "An index to uniquely identify an instance of this
              provisioning class."
          "The RSVP error code."
       ::= { ctxtDialupIfLoginServiceEntry 1 ctxtRsvpResvErrEntry 7 }

      ctxtDialupIfLoginIpHost

   ctxtRsvpResvErrErrorValue OBJECT-TYPE
       SYNTAX         IpAddress       Unsigned32
       STATUS       current
       DESCRIPTION
              "."
          "The RSVP error value."
       ::= { ctxtDialupIfLoginServiceEntry 2 ctxtRsvpResvErrEntry 8 }

      ---
      --- CtxtDialupIfLoginLat Table (Extends CtxtDialupIfLoginService)
      ---

      ctxtDialupIfLoginLatTable

   --
   -- RSVP Filter Spec Context Data
   --

   ctxtRsvpFilterSpecTable OBJECT-TYPE
         SYNTAX  SEQUENCE OF CtxtDialupIfLoginLatEntry CtxtRsvpFilterSpecEntry
           PIB-ACCESS      notify
           STATUS               current
           DESCRIPTION
              "Extended class."
                   ""

           ::= { contextClasses 7 13 }

      ctxtDialupIfLoginLatEntry

   ctxtRsvpFilterSpecEntry OBJECT-TYPE
           SYNTAX         CtxtDialupIfLoginLatEntry  CtxtRsvpFilterSpecEntry
           STATUS  current
           DESCRIPTION
              "Entry oid of the ctxtDialupIfLoginLatTable PRC."

Weiss et al.             Expires October 2000                [Page 68] 
             EXTENDS
                   ""

           PIB-INDEX { ctxtDialupIfLoginServiceEntry ctxtRsvpFilterSpecId }
           UNIQUENESS { }
           ::= { ctxtDialupIfLoginLatTable ctxtRsvpFilterSpecTable 1 }

      CtxtDialupIfLoginLatEntry::=

   CtxtRsvpFilterSpecEntry::= SEQUENCE {
              ctxtDialupIfLoginLatService   OCTET STRING,
              ctxtDialupIfLoginLatNode      OCTET STRING,
              ctxtDialupIfLoginLatGroup     OCTET STRING,
              ctxtDialupIfLoginLatPort      OCTET STRING
                ctxtRsvpFilterSpecId            InstanceId,
                ctxtRsvpFilterSpecTagId         TagId,
                ctxtRsvpFilterSpecAddrType      InetAddressType,
                ctxtRsvpFilterSpecAddr          InetAddress,
                ctxtRsvpFilterSpecPort          Unsigned32
   }

      ctxtDialupIfLoginLatService

   ctxtRsvpFilterSpecId OBJECT-TYPE
       SYNTAX         OCTET STRING       InstanceId
       STATUS       current
       DESCRIPTION
              "."
          "An arbitrary integer index that uniquely identifies an
          instance of the class."
       ::= { ctxtDialupIfLoginLatEntry ctxtRsvpFilterSpecEntry 1 }

      ctxtDialupIfLoginLatNode

   ctxtRsvpFilterSpecTagId OBJECT-TYPE
       SYNTAX         OCTET STRING       TagId
       STATUS       current
       DESCRIPTION
              "."
          "Identifies the group of Filter Spec PRIs that this PRI
          belongs to."
       ::= { ctxtDialupIfLoginLatEntry ctxtRsvpFilterSpecEntry 2 }

      ctxtDialupIfLoginLatGroup

   ctxtRsvpFilterSpecAddrType OBJECT-TYPE
       SYNTAX         OCTET STRING       InetAddressType
       STATUS       current
       DESCRIPTION
              "."
          "The address type enumeration value [INETADDR] to specify the
          type of the IP address."
       ::= { ctxtDialupIfLoginLatEntry ctxtRsvpFilterSpecEntry 3 }

      ctxtDialupIfLoginLatPort

   ctxtRsvpFilterSpecAddr OBJECT-TYPE
       SYNTAX         OCTET STRING       InetAddress
       STATUS       current
       DESCRIPTION
              "."
          "The Filter Spec IP address."
       ::= { ctxtDialupIfLoginLatEntry ctxtRsvpFilterSpecEntry 4 }

   ctxtRsvpFilterSpecPort OBJECT-TYPE
       SYNTAX       Unsigned32 (0..65535)
       STATUS       current
       DESCRIPTION
          "The packet's Layer 4 destination port."
       ::= { ctxtRsvpFilterSpecEntry 5 }

         --
         -- Authentication Extension Tables
         --
         --

Weiss et al.             Expires October 2000                [Page 69]
         -- AuthExtensions Base Table
         --

         authExtTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AuthExtEntry
             PIB-ACCESS     install-notify
             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 the PEP and sent to the PDP. The PDP
              may send information back to the PEP or may uses the
              information to authenticate the PEP's access request.
              This  PRC itself should not be instantiated.

              This is a ŠtransientĂ '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."

             ::= { authClasses 1 1 }

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

             PIB-INDEX { authExtId }
             UNIQUENESS { }

             ::= { authExtTable 1 }

         AuthExtEntry ::= SEQUENCE {
                 authExtId                InstanceId
         }

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

             ::= { authExtEntry 1 }

         --
         -- UserAuthExt Table
         --
         userAuthExtTable OBJECT-TYPE
             SYNTAX         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."

             ::= { authClasses 2 }

      authExtEntry

         userAuthExtEntry OBJECT-TYPE
             SYNTAX         AuthExtEntry         UserAuthExtEntry
             STATUS         current
             DESCRIPTION
               "Entry oid for the AuthExtTable PRC."

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

             EXTENDS { authExtId authExtEntry }
             UNIQUENESS { }

             ::= { authExtTable userAuthExtTable 1 }

      AuthExtEntry

         UserAuthExtEntry ::= SEQUENCE {
              authExtId                InstanceId,
              authExtSession           ReferenceId
                 userAuthExtRealm      OCTET STRING,
                 userAuthExtUsername   OCTET STRING
         }

      authExtId

         userAuthExtRealm OBJECT-TYPE
             SYNTAX         InstanceId         OCTET STRING
             STATUS         current
             DESCRIPTION
              "An index to uniquely identify an instance of the
               entended provisioning class."
                 "user realm octet string."

             ::= { authExtEntry userAuthExtEntry 1 }

      authExtSession

         userAuthExtUsername OBJECT-TYPE
             SYNTAX         ReferenceId
          PIB-REFERENCES { sessionEntry }         OCTET STRING
             STATUS         current
             DESCRIPTION
              "This attribute is set by the PEP to reference the

Weiss et al.             Expires October 2000                [Page 70] 
               session for which authentication is being requested."
                 "Username octet string."

             ::= { authExtEntry userAuthExtEntry 2 }

         --
         -- AuthChapExt Table
         --
         authChapExtTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AuthChapExtEntry
             PIB-ACCESS     notify
             STATUS         current
             DESCRIPTION
               "This is a concrete PRC used to contain CHAP
               authentication fields. This PRC extends the base PRC
              authExtEntry."
               userAuthExtEntry."

             ::= { authClasses 2 3 }

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

             EXTENDS { authExtEntry 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."

             ::= { authChapExtEntry 1 }

         authChapExtChal OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current

Weiss et al.             Expires October 2000                [Page 71]
             DESCRIPTION
               "CHAP Challenge octet string. The challenge is generated
               by the PEP."

             ::= { authChapExtEntry 2 }

         authChapExtResp OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "CHAP Challenge Response octet string. The challenge
                 response is sent to the PDP along with the challenge."
             ::= { authChapExtEntry 3 }

         --
         -- AuthPapExt Table
         --

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

             ::= { authClasses 3 4 }

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

             EXTENDS { authExtEntry userAuthExtEntry }
             UNIQUENESS { }

             ::= { authPapExtTable 1 }

         AuthPapExtEntry::= SEQUENCE {
                 authPapExtPwd      OCTET STRING
         }

         authPapExtPwd OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "PAP password octet string."

Weiss et al.             Expires October 2000                [Page 72]

           ::= { authPapExtEntry 1 }

         --
         -- AuthExtResult Table
         --

         authExtResultTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AuthExtResultEntry
             PIB-ACCESS     install
             STATUS         current
             DESCRIPTION
                 "This is a concrete PRC used 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
                this extended PRC are assigned by the base PRC AuthExt
                [SPPI]."

             EXTENDS { authExtEntry }
             UNIQUENESS { }

             ::= { authExtResultTable 1 }

         AuthExtResultEntry ::= SEQUENCE {
                 authExtResultSuccess           TruthValue
         }

         authExtResultSuccess OBJECT-TYPE
             SYNTAX         TruthValue
             STATUS         current
             DESCRIPTION
                "Set to '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 PRC to send EAP messages
               to the PDP."

             ::= { authClasses 4 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 { }

             ::= { authEapReqExtTable 1 }

         AuthEapReqExtEntry::= SEQUENCE {
                 authEapReqExtSpecific    OCTET STRING
         }

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

             ::= { authEapReqExtEntry 1 }

         --
         -- AuthEapRespExt Table
         --

         authEapRespExtTable OBJECT-TYPE
             SYNTAX         SEQUENCE OF AuthEapRespExtEntry
             PIB-ACCESS     install
             STATUS         current

Weiss et al.             Expires October 2000                [Page 73]
             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 5 7 }

         authEapRespExtEntry OBJECT-TYPE
             SYNTAX         AuthEapRespExtEntry
             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
         }

         authEapRespExtSpecific OBJECT-TYPE
             SYNTAX         OCTET STRING
             STATUS         current
             DESCRIPTION
                 "Opaque EAP Response octet string."

             ::= { authEapRespExtEntry 1 }

      --
      -- conformance section tbd
      --

      END

8.

9. 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

Weiss et al.             Expires October 2000                [Page 74]
   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.

9.

10. References

   [MODEL]  Y. Bernet, S. Blake, A. Smith, D. Grossman, "An Informal
            Management Model for Diffserv Routers,"
            draft-ietf-diffserv-model-06.txt, February 2002. 2001.

   [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-03.txt, March 2,
            draft-ietf-diffserv-pib-05.txt, December 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-04.txt, March 1, 2001.
            draft-ietf-rap-frameworkpib-07.txt, January 2002.

   [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)",
            (COPS-PR)", RFC 3084, March 2001.

Weiss et al.             Expires October 2000                [Page 75] 

10.

   [SPPI]   K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn,
            R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy
            Provisioning Information", RFC 3159,August 2001.

11. 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

Weiss et al.             Expires October 2000                [Page 76]
   Leon Gommans
       Enterasys Networks EMEA,
       Kerkplein 24
       2841 XM Moordrecht
       Faculty of Science, Informatics Institute,
       University of Amsterdam
       Kruislaan 403
       1098 SJ Amsterdam
       The Netherlands
       Phone: +31 182 379278 20 5257586
       E-Mail: leon.gommans@enterasys.com lgommans@science.uva.nl

   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.
       600 Technology Park Drive
       Billerica, MA 01821 USA
       Phone: +1 978 288 8175
       E-Mail: khchan@nortelnetworks.com

Weiss et al.             Expires October 2000                [Page 77]