Network Working Group J. Parello Internet-Draft B. Claise Intended Status: Standards Track Mouli Chandramouli Expires: December 11, 2014 Cisco Systems, Inc. June 11, 2014 Energy Object Context MIB draft-ietf-eman-energy-aware-mib-15 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on December 11, 2014. Expires December 11, 2014 [Page 1] Internet-Draft < Energy Object Context MIB > June 2014 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction............................................. 3 1.1. Energy Management Document Overview..................3 2. The Internet-Standard Management Framework............... 4 3. Terminology.............................................. 4 4. Architecture Concepts Applied to the MIB Module.......... 5 5.1 Energy Object Identification..........................8 5.2 Energy Object Context.................................9 5.3 Links to Other Identifiers...........................10 5.4 Energy Object Relationships..........................11 5.5 Energy Object Identity Persistence...................12 5. MIB Definitions......................................... 12 6. Implementation Status................................... 29 7. Security Considerations................................. 30 Expires December 11, 2014 [Page 2] Internet-Draft < Energy Object Context MIB > June 2014 8. IANA Considerations..................................... 31 9. Acknowledgement......................................... 31 10. References............................................. 32 10.1. Normative References...............................32 10.2. Informative References.............................33 1. Introduction The EMAN standards provide a specification for Energy Management. This document defines a subset of a Management Information Base (MIB) for use with network management protocols for Energy monitoring of network devices and devices attached to the network and possibly extending to devices in the industrial automation setting with a network interface. The focus of the MIB module specified in this document is on the identification of Energy Objects and reporting the context and relationships of Energy Objects as defined in [EMAN-FMWK]. The module addresses Energy Object identification, Energy Object context, and Energy Object relationships. 1.1. Energy Management Document Overview This document specifies the Energy Object Context (ENERGY- OBJECT-CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY- RELATION-MIB) modules. The Energy Object Context MIB module specifies MIB objects for identification of Energy Objects, and reporting context and relationship of an Energy Object. The IANA Energy Relationship MIB module specifies the first version of the IANA-maintained definitions of relationships between Energy Objects. Firstly, to illustrate the importance of energy monitoring in networks and secondly to list some of the important areas to be addressed by the Energy Management Framework, several use cases and network scenarios are presented in the EMAN applicability statement document [EMAN-AS]. In addition, for each scenario, the target devices for energy management, and how those devices powered and metered are also presented. To address the network scenarios, requirements for power and energy monitoring for networking devices are specified in [RFC6988]. Based on the requirements [RFC6988], the [EMAN-FMWK] presents a solution approach. Expires December 11, 2014 [Page 3] Internet-Draft < Energy Object Context MIB > June 2014 Accordingly, the scope of the MIB modules in this document is in accordance to the requirements specified in [RFC6988] and the concepts from [EMAN-FMWK]. This document is based on the Energy Management Framework [EMAN- FMWK] and meets the requirements on identification of Energy Objects and their context and relationships as specified in the Energy Management requirements [RFC6988]. A second MIB module meeting the EMAN requirements [RFC6988] the Power and Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy Objects for Power States, for the Power and Energy consumption. Power State monitoring includes: retrieving Power States, Power State properties, current Power State, Power State transitions, and Power State statistics. In addition, this MIB module provides the Power Characteristics properties of the Power and Energy, along with optional characteristics. The applicability statement document [EMAN-AS] provides the list of use cases, and describes the common aspects of between existing Energy standards and the EMAN standard, and shows how the EMAN framework relates to other frameworks. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Terminology Please refer to [EMAN-FMWK] for the definitions of the following terminology used in this draft. Energy Management Expires December 11, 2014 [Page 4] Internet-Draft < Energy Object Context MIB > June 2014 Energy Management System (EnMS) Energy Monitoring Energy Control electrical equipment non-electrical equipment (mechanical equipment) device component power inlet power outlet energy power demand provide energy receive energy meter (energy meter) battery Power Interface Nameplate Power Power Attributes Power Quality Power State Power State Set 4. Architecture Concepts Applied to the MIB Module This section describes the basic concepts specified in the Energy Management Architecture [EMAN-FMWK], with specific information related to the MIB modules specified in this document. The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module in this document specifies MIB objects for identification of Energy Objects, and reporting context and relationship of an Energy Object. The managed objects are contained in two tables eoTable and eoRelationTable. The first table eoTable focuses on the link to the other MIB modules, and secondly on identification, context of the Energy Object. The second table eoRelationTable specifies the relationships between Energy Objects. This is a simplified representation of relationship between Energy Objects. A "smidump-style" tree presentation of the MIB modules contained in the draft is presented. The meaning of the three symbols in Expires December 11, 2014 [Page 5] Internet-Draft < Energy Object Context MIB > June 2014 is a compressed representation of the object's MAX-ACCESS clause which may have the following values: "not-accessible"->"---" "accessible-for-notify"->"--n" "read-only"->"r-n" "read-write"->"rwn" +- eoTable(1) | +- eoEntry(1) [entPhysicalIndex] | +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1) +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2) +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3) +-- rwn MacAddress eoMgmtMacAddress(4) +-- r-n InetAddressType eoMgmtAddressType(5) +-- r-n InetAddress eoMgmtAddress(6) +-- r-n OCTET STRING eoMgmtDNSName(7) +-- rwn SnmpAdminString eoDomainName(8) +-- rwn SnmpAdminString eoRoleDescription(9) +-- rwn EnergyObjectKeywordList eoKeywords(10) +-- rwn Integer32 eoImportance(11) +-- r-n INTEGER eoPowerCategory(12) +-- rwn SnmpAdminString eoAlternateKey(13) +-- r-n INTEGER eoPowerInterfaceType(14) +- eoRelationTable(2) | +- eoRelationEntry(1) [entPhysicalIndex, eoRelationIndex] | +-- --n Integer32 eoRelationIndex(1) +-- rwn UUIDorZero eoRelationID(2) +-- rwn IANAEnergyRelationship eoRelationship(3) +-- rwn RowStatus eoRelationStatus(4) +-- rwn StorageType eoRelationStorageType(5) The following UML diagram illustrates the relationship of the MIB objects in the eoTable, eoRelationTable and ENTITY-MIB. The MIB objects describe the identity, context and relationship of an Energy Object. The UML diagram furthermore contains objects from the ENTITY-MIB [RFC6933]. +--------------------------+ | EO Context Information | Expires December 11, 2014 [Page 6] Internet-Draft < Energy Object Context MIB > June 2014 | ------------------------ | | eoRoleDescription | | eoKeywords | | eoImportance | | eoPowerCategory | | eoPowerInterfaceType | | eoDomainName | +--------------------------+ ^ | | +------------------------------+ |--- | EO Identification | | | ---------------------------- | | | entPhysicalIndex (*) | | | entPhysicalName (*) | | | entPhysicalUUID (*) | | | entPhysicalClass (*) | | -------------------------------- | | +------------------------------+ |---> | Link to other identifiers | | |------------------------------| | | eoEthPortIndex (**) | | | eoEthPortGrpIndex (**) | | | eoLldpPortNumber (***) | | | | | | eoMgmtMacAddress (optional) | | | eoMgmtAddressType (optional) | | | eoMgmtAddress (optional) | | | eoMgmtDNSName (optional) | | | eoAlternateKey | | +------------------------------+ | | +------------------------------+ |---> | EO Relationship | | ---------------------------- | | eoRelationIndex | | eoRelationID | | eoRelationship | | eoRelationStatus | | eoRelationStorageType | +------------------------------+ (*) Compliance with entity4CRCompliance ENTITY MIB[RFC6933] (**) Link with the Power over Ethernet MIB [RFC3621] (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] Expires December 11, 2014 [Page 7] Internet-Draft < Energy Object Context MIB > June 2014 Figure 1: MIB Objects Grouping As displayed in figure 1, the MIB objects can be classified in different logical grouping of MIB objects. 1) The Energy Object Identification. See Section 5.1 "Energy Object Identification". Devices and their sub-components are characterized by the power-related attributes of a physical entity present in the ENTITY MIB [RFC6933]. 2) The Context Information. See Section 5.2 "Energy Object Context" 3) The links to other MIB modules. See Section 5.3 "Links to other Identifiers" 4) The Energy Object Relationships specific information. See Section 5.4 5) The Energy Object Identity Persistence. See Section 5.5 "Energy Object Identity Persistence" 5.1 Energy Object Identification Refer to the "Energy Object Information" section in [EMAN-FMWK] for background information about Energy Objects. Every Energy Object MUST implement the unique index, entPhysicalIndex, entPhysicalName, entPhysicalClass, and entPhysicalUUID from the ENTITY MIB [RFC6933]. Module Compliance with respect to entity4CRCompliance of ENTITY-MIB MUST be supported which require a limited number of objects supported (entPhysicalIndex, entPhysicalName, entPhysicalClass, and entPhysicalUUID). entPhysicalIndex is used as index for the Energy Object in the ENERGY-OBJECT-CONTEXT-MIB module. Every Energy Object MUST have a printable name assigned to it. Energy Objects MUST implement the entPhysicalName object specified in the ENTITY-MIB [RFC6933], which must contain the Energy Object name. For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy Object instance MUST implement the entPhysicalUUID from the ENTITY MIB [RFC6933]. As displayed in [RFC4122], the following is an example of the string representation of a UUID as a URN: urn:uuid:f81d4fae- 7dec-11d0-a765-00a0c91e6bf6. Expires December 11, 2014 [Page 8] Internet-Draft < Energy Object Context MIB > June 2014 For example, to understand the relationship between Energy Object Components and Energy Objects, the ENTITY-MIB physical containment tree [RFC6933] MUST be implemented. A second example deals with one of the ENTITY-MIB extensions: if the Energy Object temperature is required, the managed objects from the ENTITY-SENSOR-MIB [RFC3433] should be supported. Each Energy Object MUST belong to a single Energy Management Domain or in other words, an Energy Object cannot belong to more than one Energy Management Domain. Refer to the "Energy Management Domain" section in [EMAN-FMWK] for background information. The eoDomainName, which is an element of the eoTable, is a read-write MIB object. The Energy Management Domain should map 1-1 with a metered or sub-metered portion of the network. The Energy Management Domain MUST be configured on the Energy Object. The Energy Object MAY inherit the some of the domain parameters (possibly domain name, some of the context information such as role or keywords, importance) from the Energy Object or the Energy Management Domain MAY be configured directly in an Energy Object. When an Energy Object acts as a Power Aggregator, the Energy Objects for which Power should be aggregated MUST be members of the same Energy Management Domain, specified by the eoDomainName MIB Object. 5.2 Energy Object Context Refer to the "Energy Object Context" section in [EMAN-FMWK] for background information. An Energy Object must provide a value for eoImportance in the range of 1...100 to help differentiate the use or relative value of the device. The importance range is from 1 (least important) to 100 (most important). The default importance value is 1. An Energy Object can provide a set of eoKeywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Energy Management Domains. An Energy Object can have Power Interfaces and those interfaces can be classified as Power Inlet, Power Outlet or both. An Energy Object can be classified based on the physical properties of the Energy Object. That Energy Object can be Expires December 11, 2014 [Page 9] Internet-Draft < Energy Object Context MIB > June 2014 classified as consuming power or supplying power to other devices or that Energy Object can perform both of those functions and finally, an Energy Object can be a passive meter. Additionally, an Energy Object can provide an eoRoleDescription string that indicates the purpose the Energy Object serves in the network. 5.3 Links to Other Identifiers While the entPhysicalIndex is the primary index for all MIB objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy Management Systems (EnMS) must be able to make the link with the identifier(s) in other supported MIB modules. If the Energy Object is a Power over Ethernet (PoE) port, and if the Power over Ethernet MIB [RFC3621] is supported by the SNMP agent managing the Energy Object, then the Energy Object eoethPortIndex and eoethPortGrpIndex MUST contain the corresponding values of pethPsePortIndex and pethPsePortGroupIndex [RFC3621]. If the LLDP-MED MIB [LLDP-MIB] is supported by the Energy Object SNMP agent, then the Energy Object eoLldpPortNumber MUST contain the corresponding lldpLocPortNum from the LLDP MIB. The intent behind the links to the other MIB module identifier(s) is to correlate the instances in the different MIB modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB module to reference other MIB modules in cases where the Power over Ethernet and the LLDP MIB modules are supported by the SNMP agent. Some use cases may not implement any of these two MIB modules for the Energy Objects. However, in situation where any of these two MIB modules are implemented, the EnMS must be able to correlate the instances in the different MIB modules. The eoAlternateKey object specifies an alternate key string that can be used to identify the Energy Object. Since an EnMS may need to correlate objects across management systems, this alternate key is provided to facilitate such a link. This optional value is intended as a foreign key or alternate identifier for a manufacturer or EnMS to use to correlate the unique Energy Object Id in other systems or namespaces. If an alternate key is not available or is not applicable then the value is the zero-length string. Expires December 11, 2014 [Page 10] Internet-Draft < Energy Object Context MIB > June 2014 An Energy Object can have additional MIB objects that can be used for easier identification by the EnMS. The optional objects eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName can be used to help identify the relationship between the Energy Objects and other NMS objects. These objects can be used as an alternate key to help link the Energy Object with other keyed information that may be stored within the EnMS(s). For the optional objects that may not be included in some vendor implementations, the expected behavior when those objects are polled is a response noSuchInstance. 5.4 Energy Object Relationships Refer to the "Energy Object Relationships" section in [EMAN- FMWK] for the definition and background information.In order to link two Energy Objects a separate table (eoRelationTable) has been introduced in this MIB module. Each Energy object can have one or more Energy Object relationships with other Energy Objects. The relationship between Energy Objects are specified in eoRelationTable. The relationship between the Energy Objects is specified with the entPhysicalIndex of the Energy Object and the UUID of the remote Energy Object. The UUID MUST comply to the RFC 4122 specifications. It is important to note that it is possible that an Energy Object may not have an Energy Object relationship with other Energy Objects. The following relationships between Energy objects have been considered in the eoRelationTable. Metering Relationship -> meteredBy / metering Power Source Relationship -> poweredBy / powering Aggregation Relationship -> aggregatedBy / aggregating An Energy Object B has "meteredBy" relationship with Energy Object A, if the energy consumption of Energy Object B is measured by Energy Object A. Equivalently, it is possible to indicate that Energy Object A has "metering" relationship with Energy Object B. An Energy Object B has "poweredBy" relationship with Energy Object A, if the power source of Energy Object B Energy Object Expires December 11, 2014 [Page 11] Internet-Draft < Energy Object Context MIB > June 2014 A. Equivalently, it is possible to indicate that Energy Object A has "powering" relationship with Energy Object B. An Energy Object B has "aggregatedBy" relationship with Energy Object A, if Energy Object A is an aggregation point for energy usage of Energy Object B. Equivalently, it is possible to indicate that Energy Object A has "aggregating" relationship with Energy Object B. The IANA Energy Relationship MIB module in Section 6 below specifies the first version of the IANA-maintained definitions of relationships. This way, for Energy Relationships, new textual conventions can be specified, without updating the primary Energy Object Context MIB module. 5.5 Energy Object Identity Persistence In some situations, the Energy Object identity information should be persistent even after a device reload. For example, in a static setup where a switch monitors a series of connected PoE phones, there is a clear benefit for the EnMS if the Energy Object Identification and all associated information persist, as it saves a network discovery. However, in other situations, such as a wireless access point monitoring the mobile user PCs, there is not much advantage to persist the Energy Object Information. The identity information of an Energy Object should be persisted and there is value in the writable MIB objects persisted. 5. MIB Definitions -- ************************************************************ -- -- -- This MIB is used for describing the identity and the -- context information of Energy Objects in network -- -- -- ************************************************************* ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN Expires December 11, 2014 [Page 12] Internet-Draft < Energy Object Context MIB > June 2014 IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32 FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION, MacAddress, TruthValue, RowStatus, StorageType FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC3411 InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC3291 entPhysicalIndex FROM ENTITY-MIB -- RFC6933 UUIDorZero FROM UUID-TC-MIB -- RFC6933 IANAEnergyRelationship FROM IANA-ENERGY-RELATION-MIB; energyObjectContextMIB MODULE-IDENTITY LAST-UPDATED "201406110000Z" ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO "WG Charter: http://datatracker.ietf.org/wg/eman/charter/ Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Editors: John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Expires December 11, 2014 [Page 13] Internet-Draft < Energy Object Context MIB > June 2014 Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore 560103 IN Phone: +91 80 4429 2409 Email: moulchan@cisco.com" DESCRIPTION "This MIB is used for describing the identity and the context information of Energy Objects" REVISION "201406110000Z" DESCRIPTION "Initial version, published as RFC YYY." ::= { mib-2 xxx1 } -- RFC Editor, please replace xxx1 with the IANA allocation -- for this MIB module and YYY with the number of the -- approved RFC energyObjectContextMIBNotifs OBJECT IDENTIFIER ::= { energyObjectContextMIB 0 } energyObjectContextMIBObjects OBJECT IDENTIFIER ::= { energyObjectContextMIB 1 } energyObjectContextMIBConform OBJECT IDENTIFIER ::= { energyObjectContextMIB 2 } Expires December 11, 2014 [Page 14] Internet-Draft < Energy Object Context MIB > June 2014 -- Textual Conventions PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the pethPsePortIndex convention, which defines a greater than zero value used to identify a power Ethernet PSE port. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) PethPsePortGroupIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the pethPsePortGroupIndex convention from the Power Over Ethernet MIB RFC 3621, which defines a greater than zero value used to identify group containing the port to which a power Ethernet PSE is connected. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) LldpPortNumberOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the LldpPortNumber convention specified in the LLDP MIB, Expires December 11, 2014 [Page 15] Internet-Draft < Energy Object Context MIB > June 2014 which defines a greater than zero value used to uniquely identify each port contained in the chassis (that is known to the LLDP agent) by a port number. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32(0..4096) EnergyObjectKeywordList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of keywords that can be used to group Energy Objects for reporting or searching. If multiple keywords are present, then this string will contain all the keywords separated by the ',' character. All alphanumeric characters and symbols (other than a comma), such as #, (, $, !, and &, are allowed. White spaces before and after the commas are ignored, as well as within a keyword itself. For example, if an Energy Object were to be tagged with the keyword values 'hospitality' and 'guest', then the keyword list will be 'hospitality,guest'." SYNTAX OCTET STRING (SIZE (0..2048)) -- Objects eoTable OBJECT-TYPE SYNTAX SEQUENCE OF EoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Energy Objects." ::= { energyObjectContextMIBObjects 1 } eoEntry OBJECT-TYPE SYNTAX EoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires December 11, 2014 [Page 16] Internet-Draft < Energy Object Context MIB > June 2014 "An entry describes the attributes of an Energy Object. Whenever a new Energy Object is added or an existing Energy Object is deleted, a row in the eoTable is added or deleted." INDEX {entPhysicalIndex } ::= { eoTable 1 } EoEntry ::= SEQUENCE { eoEthPortIndex PethPsePortIndexOrZero, eoEthPortGrpIndex PethPsePortGroupIndexOrZero, eoLldpPortNumber LldpPortNumberOrZero, eoMgmtMacAddress MacAddress, eoMgmtAddressType InetAddressType, eoMgmtAddress InetAddress, eoMgmtDNSName OCTET STRING, eoDomainName SnmpAdminString, eoRoleDescription SnmpAdminString, eoKeywords EnergyObjectKeywordList, eoImportance Integer32, eoPowerCategory INTEGER, eoAlternateKey SnmpAdminString, eoPowerInterfaceType INTEGER } eoEthPortIndex OBJECT-TYPE SYNTAX PethPsePortIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the power Ethernet port to which a Power over Enternet device is connected . If the Power over Ethernet MIB RFC 3621 is supported by the SNMP agent managing the Energy Object, then the Energy Object eoethPortIndex MUST contain the corresponding value of pethPsePortIndex. f such a power Ethernet port cannot be specified or is not known then the object is zero." REFERENCE "RFC 3621 " DEFVAL { 0 } ::= { eoEntry 1 } eoEthPortGrpIndex OBJECT-TYPE SYNTAX PethPsePortGroupIndexOrZero MAX-ACCESS read-only STATUS current Expires December 11, 2014 [Page 17] Internet-Draft < Energy Object Context MIB > June 2014 DESCRIPTION "This variable uniquely identifies the group containing the port to which a power over Ethernet device PSE is connected [RFC3621]. If the Power over Ethernet MIB RFC 3621 is supported by the SNMP agent managing the Energy Object, then the Energy Object eoEthPortGrpIndex MUST contain the corresponding value of eoethPortGrpIndex. If such a power Ethernet port cannot be specified or is not known then the object is zero." REFERENCE "RFC 3621" DEFVAL { 0 } ::= { eoEntry 2 } eoLldpPortNumber OBJECT-TYPE SYNTAX LldpPortNumberOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the port component (contained in the local chassis with the LLDP agent) as defined by the lldpLocPortNum in the [LLDP-MIB] and [LLDP-MED-MIB]. If the [LLDP-MIB] is supported by the SNMP agent managing the Energy Object, then the Energy Object eoLldpPortNumber MUST contain the corresponding value of lldpLocPortNum from the [LLDP-MIB]. If such a port number cannot be specified or is not known then the object is zero." REFERENCE "LLDP MIB, IEEE 802.1AB-2005, LLDP-MED-MIB, ANSI/TIA-1057 " DEFVAL { 0 } ::= { eoEntry 3 } eoMgmtMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies a MAC address of the Energy Object." ::= { eoEntry 4 } eoMgmtAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION Expires December 11, 2014 [Page 18] Internet-Draft < Energy Object Context MIB > June 2014 "This object specifies the eoMgmtAddress type, i.e. an IPv4 address or an IPv6 address. This object MUST be populated when eoMgmtAddress is populated." ::= { eoEntry 5 } eoMgmtAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the management address as an IPv4 address or IPv6 address of Energy Object. The IP address type, i.e. IPv4 or IPv6, is determined by the eoMgmtAddressType value. This object can be used as an alternate key to help link the Energy Object with other keyed information that may be stored within the EnMS(s)." ::= { eoEntry 6 } eoMgmtDNSName OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies a DNS name of the eoMgmtAddress. This object can be used as an alternate key to help link the Energy Object with other keyed information that may be stored within the EnMS(s). A DNS Name must always be a fully qualified name. This MIB uses the same encoding as the DNS protocol." REFERENCE "RFC-1034 section 3.1." ::= { eoEntry 7 } eoDomainName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the name of an Energy Management Domain for the Energy Object. By default, this object should be an empty string. The value of eoDomainName must remain constant at least from one re-initialization of the entity local management system to the next re- initialization." ::= { eoEntry 8 } eoRoleDescription OBJECT-TYPE Expires December 11, 2014 [Page 19] Internet-Draft < Energy Object Context MIB > June 2014 SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned name to indicate the purpose an Energy Object serves in the network. For example, we can have a phone deployed to a lobby with eoRoleDescription as 'Lobby phone'. This object specifies that the value is the zero-length string value if no role description is configured. The value of eoRoleDescription must remain constant at least from one re-initialization of the entity local management system to the next re-initialization. " ::= { eoEntry 9 } eoKeywords OBJECT-TYPE SYNTAX EnergyObjectKeywordList MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a list of keywords that can be used to group Energy Objects for reporting or searching. The value is the zero-length string if no keywords have been configured. If multiple keywords are present, then this string will contain all the keywords separated by the ',' character. For example, if an Energy Object were to be tagged with the keyword values 'hospitality' and 'guest', then the keyword list will be 'hospitality,guest'. If write access is implemented and a value is written into the instance, the agent must retain the supplied value in the eoKeywords instance associated with the same physical entity for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the local management agent. " ::= { eoEntry 10 } eoImportance OBJECT-TYPE SYNTAX Integer32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION Expires December 11, 2014 [Page 20] Internet-Draft < Energy Object Context MIB > June 2014 "This object specifies a ranking of how important the Energy Object is (on a scale of 1 to 100) compared with other Energy Objects in the same Energy Management Domain. The ranking should provide a business or operational context for the Energy Object as compared to other similar Energy Objects. This ranking could be used as input for policy-based network management. Although network managers must establish their own ranking, the following is a broad recommendation: 90 to 100 Emergency response 80 to 90 Executive or business critical 70 to 79 General or Average 60 to 69 Staff or support 40 to 59 Public or guest 1 to 39 Decorative or hospitality The value of eoImportance must remain constant at least from one re-initialization of the Energy Object local management system to the next re-initialization. " DEFVAL { 1 } ::= { eoEntry 11 } eoPowerCategory OBJECT-TYPE SYNTAX INTEGER { consumer(0), producer(1), meter(2), distributor(3), store(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the Energy Object category, which indicates the expected behavior or physical property of the Energy Object, based on its design. An Energy Object can be a consumer(0), producer(1), meter(2), distributor(3) or store(4). In some cases, a meter is required to measure the power consumption. In such a case, this meter Energy Object category is meter(2). If a device is distributing electric Energy, the category of the Energy Object is distributor (3). If a device is storing electric Energy, the category of the device can be store (4). " Expires December 11, 2014 [Page 21] Internet-Draft < Energy Object Context MIB > June 2014 ::= { eoEntry 12 } eoAlternateKey OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The eoAlternateKey object specifies an alternate key string that can be used to identify the Energy Object. Since Energy Management Systems (EnMS) and Network Management Systems (NMS) may need to correlate objects across management systems, this alternate key is provided to provide such a link. This optional value is intended as a foreign key or alternate identifier for a manufacturer or EnMS/NMS to use to correlate the unique Energy Object Id in other systems or namespaces. If an alternate key is not available or is not applicable then the value is the zero-length string. The value of eoAlternateKey must remain constant at least from one re-initialization of the entity local management system to the next re-initialization. " ::= { eoEntry 13 } eoPowerInterfaceType OBJECT-TYPE SYNTAX INTEGER { inlet(0), outlet(1), both(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the Power Interface for an Energy Object. A Power Interface is an interface at which a Energy Object is connected to a power transmission medium, at which it can in turn receive power, provide power, or both. A Power Interface type can be an inlet(0) or outlet(1) or both(2), respectively." ::= { eoEntry 14 } eoRelationTable OBJECT-TYPE SYNTAX SEQUENCE OF EoRelationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the relationships between Energy Objects." ::= { energyObjectContextMIBObjects 2 } Expires December 11, 2014 [Page 22] Internet-Draft < Energy Object Context MIB > June 2014 eoRelationEntry OBJECT-TYPE SYNTAX EoRelationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table specifies the Energy relationship between Energy objects. Energy relations between two Energy objects are defined in the EMAN-FMWK." REFERENCE "EMAN-FMWK, Energy Management Framework, RFC abcs, Jan 2014" INDEX { entPhysicalIndex, eoRelationIndex } ::= { eoRelationTable 1 } EoRelationEntry ::= SEQUENCE { eoRelationIndex Integer32, eoRelationID UUIDorZero, eoRelationship IANAEnergyRelationship, eoRelationStatus RowStatus, eoRelationStorageType StorageType } eoRelationIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an arbitrary index to identify the Energy Object related to another Energy Object" ::= { eoRelationEntry 1 } eoRelationID OBJECT-TYPE SYNTAX UUIDorZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the Universally Unique Identifier (UUID) of the peer (other) Energy Object. The UUID must comply the specifications of UUID in UUID-TC-MIB. If UUID of the energy object is unknown or non-existent, the eoRelationID will be set to a zero-length string instead. It is preferable that the value of entPhysicalUUID from ENTITY-MIB is used for values for Expires December 11, 2014 [Page 23] Internet-Draft < Energy Object Context MIB > June 2014 this object." REFERENCE "RFC 6933, Entity MIB - version 4, May 2013 " ::= { eoRelationEntry 2 } eoRelationship OBJECT-TYPE SYNTAX IANAEnergyRelationship MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes the relations between Energy objects. For each Energy object, the relations between the other Energy objects are specified using the bitmap." ::= { eoRelationEntry 3 } eoRelationStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status controls and reflects the creation and activation status of a row in this table to specify energy relationship between Energy objects. An entry status may not be active(1) unless all objects in the entry have the appropriate values. No attempt to modify a row columnar object instance value in the eoRelationTable should be issued while the value of eoRelationStatus is active(1). The data can be destroyed by setting up the eoRelationStatus to destroy(2)." ::= { eoRelationEntry 4 } eoRelationStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this row." DEFVAL { nonVolatile } ::= {eoRelationEntry 5 } Expires December 11, 2014 [Page 24] Internet-Draft < Energy Object Context MIB > June 2014 -- Conformance energyObjectContextMIBCompliances OBJECT IDENTIFIER ::= { energyObjectContextMIBConform 1 } energyObjectContextMIBGroups OBJECT IDENTIFIER ::= { energyObjectContextMIBConform 2 } energyObjectContextMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-write, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB. Module Compliance of ENTITY-MIB with respect to entity4CRCompliance MUST be supported." MODULE -- this module MANDATORY-GROUPS { energyObjectContextMIBTableGroup, energyObjectRelationTableGroup } GROUP energyObjectOptionalMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement. " ::= { energyObjectContextMIBCompliances 1 } energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-write (i.e. in read-only mode), then such an implementation can claim read-only compliance. Such a device can then be monitored but cannot be Configured with this MIB. Module Compliance of ENTITY-MIB with respect to entity4CRCompliance MUST be supported." MODULE -- this module MANDATORY-GROUPS { energyObjectContextMIBTableGroup, energyObjectRelationTableGroup } Expires December 11, 2014 [Page 25] Internet-Draft < Energy Object Context MIB > June 2014 GROUP energyObjectOptionalMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement the managed objects in this GROUP. " ::= { energyObjectContextMIBCompliances 2 } -- Units of Conformance energyObjectContextMIBTableGroup OBJECT-GROUP OBJECTS { eoDomainName, eoRoleDescription, eoAlternateKey, eoKeywords, eoImportance, eoPowerCategory, eoPowerInterfaceType } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the EnergyObject. " ::= { energyObjectContextMIBGroups 1 } energyObjectOptionalMIBTableGroup OBJECT-GROUP OBJECTS { eoEthPortIndex, eoEthPortGrpIndex, eoLldpPortNumber, eoMgmtMacAddress, eoMgmtAddressType, eoMgmtAddress, eoMgmtDNSName } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Energy Object." ::= { energyObjectContextMIBGroups 2 } energyObjectRelationTableGroup OBJECT-GROUP OBJECTS { eoRelationID, eoRelationship, Expires December 11, 2014 [Page 26] Internet-Draft < Energy Object Context MIB > June 2014 eoRelationStatus, eoRelationStorageType } STATUS current DESCRIPTION "This group contains the collection of all objects specifying the relationship between Energy Objects." ::= { energyObjectContextMIBGroups 3 } END IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaEnergyRelationMIB MODULE-IDENTITY LAST-UPDATED "201406110000Z" -- June 11, 2014 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1-310-823-9358 EMail: iana&iana.org" DESCRIPTION "This MIB module defines a TEXTUAL-CONVENTION that describes the relationships between Energy Objects. Copyright (C) The IETF Trust (2013). The initial version of this MIB module was published in RFC YYY; for full legal notices see the RFC itself. Supplementary information may be available at http://www.ietf.org/copyrights/ianamib.html" REVISION "201406110000Z" -- June 11, 2014 DESCRIPTION "Initial version of this MIB as published in RFC YYY." ::= { mib-2 xxx2 } Expires December 11, 2014 [Page 27] Internet-Draft < Energy Object Context MIB > June 2014 -- RFC Editor, please replace xxx2 with the IANA allocation -- for this MIB module and YYY with the number of the -- approved RFC -- Textual Conventions IANAEnergyRelationship ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumerated value specifying the type of relationship between an Energy Object A, on which the relationship is specified, with the Energy Object B, identified by the UUID. The enumeration 'poweredBy' is applicable if the Energy Object A is poweredBy Energy Object B. The enumeration 'powering' is applicable if the Energy Object A is powering Energy Object B. The enumeration 'meteredBy' is applicable if the Energy Object A is meteredBy Energy Object B. The enumeration 'metering' is applicable if the Energy Object A is metering Energy Object B. The enumeration 'aggregatedBy' is applicable if the Energy Object A is aggregatedBy Energy Object B. The enumeration 'aggregating' is applicable if the Energy Object A is aggregating Energy Object B." SYNTAX INTEGER { poweredBy(1), -- power relationship powering(2), meteredBy(3), -- meter relationship metering(4), aggregatedBy(5), -- aggregation relationship aggregating(6) } END Expires December 11, 2014 [Page 28] Internet-Draft < Energy Object Context MIB > June 2014 6. Implementation Status [Note to RFC Editor: Please remove this section and the reference to [RFC6982] before publication.] This section records the status of known implementations of the EMAN-Monitoring MIB at the time of posting of this Internet- Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. 11.1 SNMP Research Organization: SNMP Research, Inc. Maturity: Prototype based upon early drafts of the MIBs. We anticipate updating it to more recent documents as development schedules allow. Coverage: Code was generated to implement all MIB objects in ENTITY-MIB (Version 4), ENERGY-OBJECT-CONTEXT-MIB, ENERGY-OBJECT-MIB, POWER-CHARACTERISTICS-MIB, and BATTERY-MIB. Implementation experience: The documents are implementable. Comments: Technical comments about the ENERGY-OBJECT-CONTEXT-MIB, ENERGY-OBJECT-MIB, and BATTERY-MIB were submitted to the EMAN Working Group E-mail list. Licensing: Proprietary, royalty licensing Contact: Alan Luchuk, luchuk at snmp.com URL: http://www.snmp.com/ 11.2 Python Priyanka Rao has mentioned on the mailing list (http://www.ietf.org/mail-archive/web/eman/current/msg02063.html) Expires December 11, 2014 [Page 29] Internet-Draft < Energy Object Context MIB > June 2014 that she has a python implementation. 7. Security Considerations Some of the readable objects in these MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read- create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following are the tables and objects and their sensitivity/vulnerability: . Unauthorized changes to the eoDomainName, entPhysicalName, eoRoleDescription, eoKeywords, and/or eoImportance MAY disrupt power and energy collection, and therefore any predefined policies defined in the network. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. Expires December 11, 2014 [Page 30] Internet-Draft < Energy Object Context MIB > June 2014 8. IANA Considerations The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- energyObjectContextMIB { mib-2 xxx1 } Editor's Note (to be removed prior to publication): IANA is requested to assign a value for "xxx1 " under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "xxx1" (here and in the MIB module) with the assigned value and to remove this note. This document defines the first version of the IANA-maintained IANA-ENERGY-RELATION-MIB module, which allows new definitions of relationships between Energy Objects. A Specification Required as defined in RFC 5226 [RFC5226], is REQUIRED for each modification of the energy relationships. The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry. Descriptor OBJECT IDENTIFIER value ---------- ----------------------- ianaEnergyRelationMIB { mib-2 xxx2 } Editor's Note (to be removed prior to publication): IANA is requested to assign a value for "xxx2 " under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "xxx2" (here and in the MIB module) with the assigned value and to remove this note. 9. Acknowledgement We would like to thank Juergen Quittek and Juergen Schoenwalder for their suggestions on the new design of eoRelationTable which Expires December 11, 2014 [Page 31] Internet-Draft < Energy Object Context MIB > June 2014 was a proposed solution for the open issue on the representation of Energy Object as a UUIDlist. Many thanks to Juergen Quittek for many comments on the wording, text and design of the MIB thus resulting in an improved draft. Many thanks to Alan Luchuk for the review of the MIB and his comments. In addition the authors thank Bill Mielke for his multiple reviews, Brad Schoening and Juergen Schoenwaelder for their suggestions and Michael Brown for dramatically improving this draft. And finally thanks the EMAN WG chairs: Nevil Brownlee and Tom Nadeau. 10. References 10.1. Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", RFC3621, December 2003. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace ", RFC 4122, July 2005. Expires December 11, 2014 [Page 32] Internet-Draft < Energy Object Context MIB > June 2014 [RFC6933] Bierman, A. Romascanu,D. Quittek, J. and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 2013. [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base module for LLDP configuration, statistics, local system data and remote systems data components", May 2005. [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J., Dietz, T., and B. Claise "Power and Energy Monitoring MIB", draft-ietf-eman-energy-monitoring-mib-10, June 2014. 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", RFC 3410, December 2002. [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, "Guidelines for Writing an IANA Considerations Section in RFCs ", BCP 26, RFC 5226, May 2008. [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Energy Management", RFC 6988, September 2013. [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf- eman-framework-19, work in progress, April, 2014. [EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-ietf-eman-applicability-statement-05.txt, work in progress, April 2014. Expires December 11, 2014 [Page 33] Internet-Draft < Energy Object Context MIB > June 2014 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013. Authors' Addresses Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore 560103 IN Phone: +91 80 4429 2409 Email: moulchan@cisco.com Expires December 11, 2014 [Page 34]