[IPFIX] ipfix mib export and context information
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 30 June 2011 09:39 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A537021F87B7 for <ipfix@ietfa.amsl.com>; Thu, 30 Jun 2011 02:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level:
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfMG4Z7Y1Pl9 for <ipfix@ietfa.amsl.com>; Thu, 30 Jun 2011 02:39:08 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8365621F87DB for <ipfix@ietf.org>; Thu, 30 Jun 2011 02:39:07 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB85F20BF4 for <ipfix@ietf.org>; Thu, 30 Jun 2011 11:39:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RdHzQ0UMfQtM; Thu, 30 Jun 2011 11:39:05 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D51220BD4; Thu, 30 Jun 2011 11:39:05 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 15892197B186; Thu, 30 Jun 2011 11:39:05 +0200 (CEST)
Date: Thu, 30 Jun 2011 11:39:05 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: ipfix@ietf.org
Message-ID: <20110630093904.GB3317@elstar.local>
Mail-Followup-To: ipfix@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [IPFIX] ipfix mib export and context information
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 09:39:08 -0000
Hi, as explained in section 3.3 of RFC 3411, MIB objects (identified by an OID) always exist in a context. A context is identified by a contextEngineID and a contextName. In colloquial terms, the contextEngineID identifies an SNMP agent and a contextName identifies an OID tree accessible on that agent. In short, within a management domain, a unique name of a MIB object is the following 4-tuple: (contextEngineID, contextName, object-type OID, instance-identifier) | | | | +-----------+------------+ +--------------+-----------------+ | | context OID Many agents only have one context (the so called default context) and hence this is mostly invisible for many people. However, in certain situations, contexts are used. The classic example are bridges that have an instance of the BRIDGE-MIB for each VLAN (in this case the contextName used to distinguish BRIDGE-MIB instances is usually the VLAN name). For exporting MIB objects in IPFIX, we need to deal with the representation of contexts: a) If a MIB object exists in the default context (zero length contextName), then the contextName is not carried in IPFIX. b) If a MIB object exists in a non-default context, then the contextName needs to be carried in IPFIX. There are again two options: b.1) The contextName is associated to the template. This means all MIB objects in an IPFIX flow record must belong to the same SNMP context. Continuing the example mentioned above, you would not be able to have flow record that carries a MIB object for multiple VLANs. (Note that a similar restriction exists in SNMP since a PDU is always scoped to one context.) The trade-off here is that flow records are smaller at the expense of having to deal with more template options in cases where many contexts are used. b.2) The contextName is associated to a MIB object in a flow record. This allows to have objects existing in different SNMP contexts on the same "agent" to be carried in a single flow record. However, there is a price for this flexibility since context information is now repeated in every flow record. Independent of the options a), b.1), and b.2) above, there is a question whether the contextEngineID should be carried somewhere? This would disambiguate things if a device has multiple SNMP agents running concurrently. If the contextEngineID is carried, then this should likely be part of the template information, not the flow records. So the main question at this point (sorry for the lengthy explanation): Should we go for b.1) or b.2) or even allow both b.1) and b.2)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
- [IPFIX] ipfix mib export and context information Juergen Schoenwaelder
- Re: [IPFIX] ipfix mib export and context informat… Benoit Claise
- Re: [IPFIX] ipfix mib export and context informat… Juergen Schoenwaelder
- Re: [IPFIX] ipfix mib export and context informat… Romascanu, Dan (Dan)
- Re: [IPFIX] ipfix mib export and context informat… Benoit Claise