Subject: ForCES MIB: 1st draft

From: Robert Haas <[email-masked]>
Date: Tue, 11 Oct 2005 15:03:55 +0200

All,
I'm currently putting together a first draft of the ForCES MIB (a 
requirement to proceed with our protocol draft), and will submit it it 
by Monday.
Below are the major points, please comment.

The ForCES MIB is a read-only MIB used to monitor the state of 
associations in an NE. For each association identified by the pair CE ID 
and FE ID, the following information is shown:

- Current state of the association:

   UP:           the CE(s) indicated by the CE ID and FE(s) indicated by 
the FE ID are associated.
   DOWN:   the CE(s) indicated by the CE ID and FE(s) indicated by the 
FE ID are not associated AND the CE(s) indicated by the CE ID is sending 
Association Setup messages.
Note that associations that are DOWN and for which no Association Setup 
messages are being sent by the CE are NOT listed in the MIB (otherwise 
how do we decide which old associations to remove from the MIB ?)

- Association history:
   Date/time when the association came to the UP state.
   (Number of commands executed or some indications of the ForCES 
control traffic ?)

- Hearbeat timers values of the FE and CE for this association.

- Heartbeat timer settings of the FE and CE for this association: 

   ENABLED:  hearbeats are transmitted (by default virtual piggybacking 
is used)
   DISABLED: heartbeats are not transmitted
 
- Backup information: the FE(s)/CE(s) that are configured to work as 
backups for this association (necessary ? useful ?)

Regards,

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha

---

From: Guo xiaoyi <[email-masked]>
Date: Thu, 13 Oct 2005 16:00:35 +0800

hi, Robert,

i am a newer come in this group and wish i wont give a bad comment  ;)

i have not seen the draft yet, but i want to express some suggestions.

There are two way to get the MIB information , one way is each time CE query FE(s) and FE(s) return the 
neccesary informaiton to CE. Another way is FE(s) send the information to CE  within a time interval. 

If we use the first method , then we could get the real-time information of FE(s) , but we chould not 
decide which old associations to remove from the MIB in time. If we use the latter one , we can decide it but we
maybe can not  get real-time information , its just the old informaiton of the last time interval.

cheers
Xiaoyi Guo

----- Original Message ----- 
From: " Robert Haas <[email-masked]>
Subject: ForCES MIB: 1st draft

> S?umerstrasse 4

---

From: Robert Haas <[email-masked]>
Date: Thu, 13 Oct 2005 16:29:12 +0200

Hi Xiaoyi,

>neccesary informaiton to CE. Another way is FE(s) send the information to CE  within a time interval. 
Correct, this can for instance apply to packet counters, etc, that are 
maintained at the FE. The CE must somehow retrieve this information from 
the FE in order to reflect the current value in the corresponding MIB. I 
suppose you implied that ForCES is used to retrieve this information. 
Which of the two methods (real-time or periodical) to use is an 
implementation issue.

>maybe can not  get real-time information , its just the old informaiton of the last time interval.

I am not sure I understand what you mean by "we should not decide which 
old associations to remove from the MIB in time".  Maybe take a look at 
the draft I am sending now (more specifically Section 3) and please 
rephrase your point.

Regards,
-Robert

---

From: Robert Haas <[email-masked]>
Date: Thu, 13 Oct 2005 16:33:53 +0200

All,

Below is the 1st draft, which raises a few issues.

Regards,
-Robert

ForCES MIB

(draft version 00-a)

0. Abstract

This document specifies the ForCES MIB.

1. Introduction

The ForCES MIB is a read-only MIB that captures information related to 
the ForCES protocol. This includes state information about the 
associations between CE(s) and FE(s) in the NE.
[Note: anything else besides associations that the MIB should include?]

The ForCES MIB does not include information that is specified in other 
MIBs, such as packet counters for interfaces, etc.

The information in the ForCES MIB relative to associations includes more 
specifically:

- identifiers of the elements in the association
- state of the association
- configuration parameters of the association
- statistics of the association

The relevant references from the ForCES requirements and architecture 
documents are repeated below:

Requirements RFC 3654 http://www.ietf.org/rfc/rfc3654.txt
Section 4, point 4:
   4) A NE MUST support the appearance of a single functional device.
   For example, in a router, the TTL of the packet should be decremented
   only once as it traverses the NE regardless of how many FEs through
   which it passes.  However, external entities (e.g., FE managers and
   CE managers) MAY have direct access to individual ForCES protocol
   elements for providing information to transition them from the pre-
   association to post-association phase.

Section 4, point 14:
1. The ability for a management tool (e.g., SNMP) to be used to read
      (but not change) the state of FE SHOULD NOT be precluded.
2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to
      change the state of a FE in a manner that affects overall NE
      behavior without the CE being notified.

Architecture RFC 3746 http://www.ietf.org/rfc/rfc3746.txt
Section 3.3:
CE managers may be physically and logically separate
   entities that configure the CE with FE information via such
   mechanisms as COPS-PR [7] or SNMP [5].

Section 5.7:
5.7.  Application Layer -- Network Management Protocol

   RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP".
   In general, for the post-association phase, most external management
   tasks (including SNMP) should be done through interaction with the CE
   in order to support the appearance of a single functional device.
   Therefore, it is recommended that an SNMP agent be implemented by CEs
   and that the SNMP messages received by FEs be redirected to their
   CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here
   such that CEs act in the role of master agent to process SNMP
   protocol messages while FEs act in the role of subagent to provide
   access to the MIB objects residing on FEs.  AgentX protocol messages
   between the master agent (CE) and the subagent (FE) are encapsulated
   and transported via ForCES, just like data packets from any other
   application layer protocols.

2. Design of ForCES MIB

As state information is distributed across FEs and CEs, the following 
alternatives may be considered:

1) CE MIBs
Each CE in the NE implements a CE MIB. The external SNMP-based 
management tool must therefore be aware of each CE in order to obtain a 
complete view of the NE by collecting state information obtained from 
each CE MIB.
[Note: this may or may not comply with requirement #4 ("A NE MUST 
support the appearance of a single functional device")]

2) single NE MIB
An entity in the NE implements an NE MIB that aggregates state 
information collected from each CE (CEs are possibly from various 
vendors). This requires a standard protocol in order to support 
multi-vendor environment. AgentX with the NE as the master and the CE(s) 
as the agent(s) may be considered here.
[Note: comments on the suitability of AgentX ?]

[Note: none of the two alternatives are ideal ...]

3. Capturing State Before Association Establishment

The ForCES protocol may be used by the CE to query the FE Protocol LFB 
about some of the configuration parameters. But such queries may 
obviously be issued only once the association is established.

In the ForCES protocol, the FE first issues an Association Setup Request 
message to the CE which in turns responds with an Association Setup 
Response message. It may be useful to capture in the MIB in which state 
the association is seen from each of the FE and the CE sides, as a means 
to detect PL-level communication anomalies. For instance, from the FE 
side, the association is in the ATTEMPT state as long as no response to 
the Association Setup message has been received from the CE. Similarly, 
the association is in the ESTABLISHING state as long as no message has 
been received from the FE after the CE has issued a positive Association 
Setup Response message (this is because configuration mistakes in the FE 
may cause messages from the CE to be ignored, and the MIB could help in 
tracing such errors).

The transient state in the FE until the association is established 
cannot be queried using ForCES.
[Note: If such information is critical, then an FE MIB has to be 
provided that can be queried separately]

4. MIB Definition(s)

For each association identified by the pair CE ID and FE ID, the 
following information is included in the MIB:

[Note: the MIB includes all associations for the particular CE in the 
case of a CE MIB, same for FE MIBs (if any), or all associations in the 
NE in the case of a NE MIB]

  UP:   the CE(s) indicated by the CE ID and FE(s) indicated by
the FE ID are associated.
  ESTABLISHING/ATTEMPT: transient state unitl the association is 
established. See section 3 above for details.

Note that associations that are not UP and for which no association 
setup is in progress are NOT listed in the MIB.
[Note: otherwise how do we decide which old associations to remove from 
the MIB ?]

- Backup information: the FE(s)/CE(s) that are configured to work as
backups for this association.
[Note: is this necessary, useful ?]

- Association statistics:
  Date/time when the association came to the UP state.
[Note: what about the Number of commands executed or some indications of 
the ForCES control traffic ?]

TBD: actual MIB specification.

---

From: Xiaoyi Guo <[email-masked]>
Date: Fri, 14 Oct 2005 18:14:27 +0800

hi, Robert ,

I read this draft again , and i  think that the single NE MIB is a better choice.  
For in a multi-vendor environment , i prefer a standard protocol to support it.
And i wouldn't have other suggestion on this.

Regards,
Xiaoyi

---

From: Robert Haas <[email-masked]>
Date: Mon, 24 Oct 2005 16:51:50 +0200

Hi All,
The -00 version of the ForCES MIB draft is in the repository:

http://www.ietf.org/internet-drafts/draft-haas-forces-mib-00.txt

Comments and contributions welcome.

Regards,
-Robert

---

From: Tom Petch <[email-masked]>
Date: Tue, 25 Oct 2005 12:51:41 +0200

I would have thought there was a need for an NE MIB which has a table giving
details of the CE and FE, their ids, capabilities and so on, rather than
inferring that from a list of associations

Tom Petch

----- Original Message -----
From: "Robert Haas" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 24, 2005 4:51 PM
Subject: Re: ForCES MIB: 1st draft

Hi All,

Regards,
-Robert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Oct 2005 20:30:49 -0400

I would hope we don't try to duplicate all the ForCES information into the MIB.
While one could imagine trying to use SNMP to remotely control a CE, so as 
to control the FE, I had thought that was not the goal.

Hence, the ForCES MIB is about control the protocol, not the model 
objects.  It would report, as seen by the CE, what the protocol is 
doing.  (I would expect it to include some of the statistics Robert refers 
to in his Note.)
If we want to allow "set"s at all, I suppose we could allow setting the 
heartbeat interval.
We might want to make visible a view FE attributes like the FE 
understanding of the protocol version.

But I hope we are not going to try to get the LFB support information, LFB 
topology, etc into the MIB.

Yours,
Joel

---

From: Tom Petch <[email-masked]>
Date: Wed, 26 Oct 2005 11:16:17 +0200

I agree with the idea that the MIB is not about control and am happy with it
being read only.  What I do find strange is having a table of associations,
which are identified by ids for CE and FE, and that that is all that is visible
about CE and FE; I think there should be a separate table, at the NE level,
giving ids, whether or not they are in an association at present.

Having only associations is a bit like viewing the Internet from a default free
routing table, being unaware of links etc that are not currently preferred ones.

Tom Petch

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 26, 2005 2:30 AM
Subject: Re: ForCES MIB: 1st draft

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Oct 2005 10:10:31 -0400

I must be misunderstanding what you are asking for.
I don't know how the SNMP could be "at the NE level".  As I understand it, 
from a ForCES protocol perspective, here is no NE to talk to.  The SNMP is 
being exchanged with a specific CE.  It may not even know about other CEs 
which are, from the operational perspective, part of the same NE.  From the 
CE Manager or FE Manager there is presumably knowledge of the NE.  But we 
are not defining the CEM and FEM.

Yours,
Joel

---

From: Tom Petch <[email-masked]>
Date: Wed, 26 Oct 2005 16:23:57 +0200

By NE MIB, I was meaning the second of the two choices in the draft, namely,

   2) single NE MIB
   An entity in the NE implements an NE MIB that aggregates state
   information collected from each CE (CEs are possibly from various
   vendors). This requires a standard protocol in order to support
   multi-vendor environment. AgentX with the NE as the master and the
   CE(s) as the agent(s) may be considered here.

seeing that as preferrable to the alternative, CE MIB.  But whichever there is,
I would still hope to see the FE and CE in some more detail than just IDs in the
association table knowing only, from the ID itself, which is CE and which is FE.

I had in mind the sort of information contained in the system group of mib-2.

Tom Petch

---

From: Tom Petch <[email-masked]>
Date: Fri, 28 Oct 2005 18:36:37 +0200

One issue I am curious about is the choice of Date/Time for the associations' up
time.

SNMP requires every agent to have a clock but only an relative time clock with a
resolution of TimeTicks (0.01s), not a ToD clock.  The onus is then on the SNMP
manager to synchronise these relative times and make them absolute when needed.

Why choose DateTime and where is this coming from? (NTP:-)  What resolution is
needed?  If there are multiple clocks with an NE, how are they synchronised?
Even, is there a need for a protocol within the NE for this? (not saying there
is but it is possible depending on the other answers).

Tom Petch