Subject: Re: We're on board

From: Nevil Brownlee <[email-masked]>
Date: Fri, 6 Oct 2000 09:31:52 +1200 (New Zealand Standard Time)

> >You're right, the Meter MIB only does pull behaviour.  But there's 
> >nothing in the RTFM Architecture which imposes that limitation, so I 
> >agree, it would be a good thing to explore this so as to provide a 
> >well-defined 'push' interface, API or whatever.  Good idea.  Let's get 
> >it out on the mailing list / in an I-D!
> 
> That's true the meter MIB doesn't say anything about this... I assume in
> order to have this kind of collection, will require modification within the
> MIB... But also, the meter itself will need to cope with this... Do you
> believe that this a protocol issue only?   

I don't know about it being a 'protocol issue,' but its certainly 
something which has strong effects on the meter design - if one chose 
to stay with SNMP, the meter would have to send event notifications 
(trap messages in SNMPv1), which would of course need changes to the 
MIB.  Building a meter which, for example, could be run as a thread, 
and used via a well-defined API so as to write flow data directly to a 
file or database - now that would be an interesting topic to discuss ..

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P

---

From: Marcelo Pias <[email-masked]>
Date: Fri, 6 Oct 2000 11:08:07 +0000 (UTC)

Hi Nevil,

     comments in line...

> file or database - now that would be an interesting topic to discuss ..

I'd point out now three situations where push mode may be used:

            Accounting protocol               +------------+
    +-------------+--------------+----------->| Acct server| 
    |             |              |            +------------+
    |             |              |
+--------+    +--------+     +--------+       +-------------+
|Reader 1|    |Reader 2| ... |Reader n|------>| Local store |   
+--------+    +--------+     +--------+       +-------------+ 
      ^            ^           ^
       \           |          / 
         \         |        /    Push mode (RTFM push-mode protocol?) 
           \       |      /
             +----------+
             |  Meters  |
             +----------+

	First: Each reader subscribes as a listener to the event: 
"flowdata record  ready". When this event occurs, the meter push the
flowdata record out to the list of listeners through the network... 
Readers may control this through an interface provided by the meter. (e.g. API)

            Accounting protocol               +------------+
    +-------------+--------------+----------->| Acct server| 
    |             |              |            +------------+
    |             |              |
+--------+    +--------+     +--------+
|Reader 1|    |Reader 2| ... |Reader n|  
+--------+    +--------+     +--------+ 
      ^            ^           ^
       \           |          / 
         \         |        /    Push mode (RTFM push-mode Protocol?)
           \       |      /
             +-------------+
             | Application |
             +-------------+
                   ^
                   |  Pull mode (SNMP,HTTP...)
                   v
              +----------+
              |  Meters  |
              +----------+

	Second: this would cope with situations where the meter 
doesn't support push mode... Basically, it's the same as the above
 but with an application translating from pull mode to push mode... 

            Accounting protocol                 +------------+
    +-------------+--------------+------------->| Acct server| 
    |             |              |              +------------+
    |             |              |
+--------+    +--------+     +--------+
|Reader 1|    |Reader 2| ... |Reader n|  
+--------+    +--------+     +--------+ 
      ^            ^           ^
       \           |          / 
         \         |        /    Push mode (Local communication) 
           \       |      /
             +----------+
             |  Meters  |
             +----------+

	Third: the meter and reader would be running on the same
machine. Thus, the communication is local, and the meter may be  
running as a thread as you've suggested... And the reader, would then
send the flow data to appropriate remote/local store such as a file,
remote database, AAA server...

	This is where I can see useful a well-defined API...Actually, we've
done implementations which covers the second and third scenarios above with
very good results... For the first one, we have already started the
design of the appropriate data structure and control needed.

	Any comments from the list?

	Cheers. Marcelo

----------------------------------------------------------
Marcelo Pias - University College London (UCL)
www.cs.ucl.ac.uk/staff/m.pias/

---

From: [email-masked]
Date: Sat, 07 Oct 2000 02:15:14 +0200

Hi Marcelo,

All three situations you describe comply with the RRTFM architecture.
The architecture is not restricted to pull mode. However, the Meter MIB
is, at least so far.

Now it is the question, whether we want to extend the Meter MIB such
that
it offers also push mode communication. Is this another item for the
revived working group's agenda?

If yes, here are some thoughts on this issue:

In general there is no need, because the combination of Expression MIB
(draft-ietf-disman-express-mib-12.txt) and Event MIB
(draft-ietf-disman-event-mib-10.txt) should be sufficent to observe the
flow table and to generate notifications. As far as I kbow, both MIBs
are close to becoming an RFC on the standards track. However, using
these MIBs could be a rather complicated and unflexible way.

So, if we think that push mode is desirable, we should go for a Meter
MIB
extension. But also here I see some problems. If the Meter wants to
notify
some entity via SNMP is has to send an SNMP notification. Where such a
notification is sent to is usually not configurable by the MIB portion
defining the notification, but it is defined either by the SNMP agent's
configuration file or by managed objects in another MIB portion.

In both cases, it might be impossible to configure the destination for a
single notification. Very often, all notifications are sent to the same
set of managers.

Unfortunately, what we would probably like to have is sending
notifications
concerning a specific flow to exactly the set of readers which
(dynamically)
have been registered for this flow. Maybe somebody on the list knows how
to
overcome this problem?

Let's assume we have solved this problem. Then our next step would be
defining conditions on which notifications are generated. I see several
possible conditions, among them

- a new entry in the flow table is generated
- a flow table entry times out, i.e. no new packets for some time
- the number of octets of a flow exceeds a given number
- ...

We have to collect all conditions, that might be required by users of
the
Meter MIB and find ways of integrating them into the MIB.

---

From: [email-masked]
Date: Sat, 07 Oct 2000 02:25:03 +0200

Hi Marcelo,

Now it is the question, whether we want to extend the Meter MIB such
that
it offers also push mode communication. Is this another Item for the
revived working group's agenda?

    Juergen

-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Marcelo Pias <[email-masked]>
Date: Mon, 09 Oct 2000 22:10:12 +0100

Juergen,

>revived working group's agenda?

I'd suggest this as a new work item... I'd be interested to work on this
too...

Maybe, it could follow any of these two paths:

1. Define the appropriate mechanisms and needed changes within the RTFM MIB
to cope with push mode. 

2. Specify a protocol to carry "flow data" between meters and readers using
push mode... This could be multicast from meter to readers using a reliable
multicast protocol or something (assuming the no. of readers are enough to
justify multicasting the data, instead of single unicast sessions...)

I'd appreciate any comment/suggests on this... 

Cheers. Marcelo

------------------------------------------------------------
UCL - University College London

---

From: David Harrington <[email-masked]>
Date: Mon, 09 Oct 2000 23:25:12 -0400

> justify multicasting the data, instead of single unicast sessions...)
I believe SNMPv3, with its Inform, is a protocol capable of handling
push needs.

-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 10 Oct 2000 10:14:13 +0200

> 1. Define the appropriate mechanisms and needed changes within the RTFM MIB

What could such a mechanism be? Any idea?

> justify multicasting the data, instead of single unicast sessions...)

Do you assume multiple readersn of the same information? I doubt. I
think if there are multiple readers, they will use different
information.

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155