Internet DRAFT - draft-peng-p2psip-snmp
draft-peng-p2psip-snmp
P2PSIP Y. Peng
Internet-Draft W. Wang
Intended status: Informational Z. Hao
Expires: April 21, 2013 Y. Meng
ZTE Corporation
October 18, 2012
An SNMP Usage for RELOAD
draft-peng-p2psip-snmp-05
Abstract
This document defines an SNMP Usage for REsource LOcation And
Discovery(RELOAD). The objective of SNMP Usage is to provide the
functionality of managing the RELOAD network. In particular, the
SNMP Usage provides the following functions: (a) defining the method
that allow the registrations to map a network manager's name to a
host node reachable in the overlay, and (b) providing lookup service
for the node hosts the network manager in the overlay. Then the
AppAttach method is used to exchange addresses between nodes to
establish a direct connection through which SNMP messages are
exchanged.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 21, 2013.
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
Peng, et al. Expires April 21, 2013 [Page 1]
Internet-Draft An SNMP Usage for RELOAD October 2012
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Network Management Requirements . . . . . . . . . . . . . . . 4
4. Basic Operations and SNMP . . . . . . . . . . . . . . . . . . 5
5. Overview of SNMP Usage . . . . . . . . . . . . . . . . . . . . 5
6. SNMP Usage Architecture . . . . . . . . . . . . . . . . . . . 6
7. Abstract Service Interfaces(ASI) . . . . . . . . . . . . . . . 7
7.1. SNMP-RELOAD Application Primitive . . . . . . . . . . . . 7
7.1.1. getNodeForResource ASI . . . . . . . . . . . . . . . . 7
7.1.2. returnNodeForResource ASI . . . . . . . . . . . . . . 7
7.1.3. getAddressForNode ASI . . . . . . . . . . . . . . . . 8
7.1.4. returnAddressForNode ASI . . . . . . . . . . . . . . . 8
7.2. RELOAD Node(M-Node/O-Node) primitive . . . . . . . . . . . 8
7.2.1. getNodeForResource ASI . . . . . . . . . . . . . . . . 8
7.2.2. returnNodeForResource ASI . . . . . . . . . . . . . . 9
7.2.3. exchangeCandidateAddressList ASI . . . . . . . . . . . 9
7.2.4. registerManagerReq ASI . . . . . . . . . . . . . . . . 9
7.2.5. registerManagerAns ASI . . . . . . . . . . . . . . . . 10
8. Managed Object Definitions for RELOAD . . . . . . . . . . . . 10
9. Network Manager Registration and Lookup . . . . . . . . . . . 15
10. An SNMP Entity Forms a Direct Connection with Another SNMP
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. O-Node information Collection . . . . . . . . . . . . . . . . 19
12. O-Node Lookup by the Network Manager for a Resource . . . . . 20
13. Definition of SNMP-REGISTRATION Kind . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . . 23
17.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Peng, et al. Expires April 21, 2013 [Page 2]
Internet-Draft An SNMP Usage for RELOAD October 2012
1. Introduction
This document defines an SNMP Usage for RELOAD, which can be used to
manage the RELOAD network. It can provide important network
management functions, such as changing the network configuration,
monitoring the performance of the network, collecting real-time
status/failure information, etc. These network management functions
are essential for stable operation and high-quality services offered
by the network. Since the traditional network management protocols
(e.g., SNMP) cannot be directly applied to RELOAD network management,
it is necessary to introduce new RELOAD usage of SNMP.
As defined in [I-D.ietf-p2psip-base], there are two kinds of network
elements in RELOAD network: centralized servers, such as the
Enrollment Server; distributed nodes, such as Peer and Client. The
management function of centralized servers can be carried out by
traditional management methods, and aren't discussed in this
document. We focus on the management of the distributed nodes called
as RELOAD Nodes in this draft.
When the manager starts up, it needs to register the mapping between
its name and Node-ID into the RELOAD network, in order to be
recognized and found by the managed RELOAD Nodes. So only the name
of manager needs be fixed, and needs be known beforhand by RELOAD
Nodes. Then, the RELOAD Nodes can get the manager's address and
connect with it. Then the Nodes and the manager can exchange
management messages through this link.
Not only RELOAD Nodes are managed object, but a RELOAD resource is a
managed object as well, such as some data stored in RELOAD network by
SNMP-RELOAD application.
The basic mechanism of SNMP Usage is the same as SIP Usage for
RELOAD[I-D.draft-ietf-p2psip-sip]. It is easier to understood the
SNMP Usage, if someone has the backgroud of SIP Usage draft.
2. Terminology
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 [RFC2119].
In this document, we use the definitions from Concepts and
Terminology as described in the following drafts:
Peer to Peer SIP [I-D.ietf-p2psip-concepts], RELOAD Base Protocol
[I-D.ietf-p2psip-base], SNMPv3 [RFC3411], TLS TM for SNMP [RFC5953] .
Peng, et al. Expires April 21, 2013 [Page 3]
Internet-Draft An SNMP Usage for RELOAD October 2012
SNMP: Simple Network Management Protocol.
Entity: SNMP Entity, including both Manager and Agent, which
resides in RELOAD Node.
Manager: SNMP Manager, which resides in RELOAD Node.
Agent: SNMP Agent, which resides in RELOAD Node.
LCD: Local Configuration Datastore.
Node: RELOAD Node, including both Peer and Client, which SNMP
manager or agent resides in.
ReDiR: Recursive Distributed Rendezvous.
M-Node: Management Node, which is the RELOAD Node which SNMP
Manager resides in.
O-Node: Objective Node, which is the RELOAD Node managed by a
network manager, which SNMP agent resides in.
R-Node: Responsible Node, which is the RELOAD Node responsible
for storing the data according to P2P algorithm.
SNMP-RELOAD Application: It provides the functions related to
RELOAD for SNMP applications, such as getting available address for
Node-ID and getting Node-ID for Resource ID. SNMP applications can
implement the management for RELOAD network by SNMP-RELOAD
Application.
3. Network Management Requirements
SNMP usage SHOULD or MAY provide the following functions and
mechanisms:
i. SNMP usage for RELOAD SHOULD provide the management functions for
RELOAD Nodes. Such as setting node name, software version or other
configuration information, monitoring the number of the messages
initiated, forwarded or processed by nodes, reporting program
failure, message forwarding failure or other error on nodes.
ii. SNMP usage for RELOAD SHOULD provide the management functions
for RELOAD resource. Such as tracking the RELOAD messages is
forwarded, processing flows of resources.
iii. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP
Peng, et al. Expires April 21, 2013 [Page 4]
Internet-Draft An SNMP Usage for RELOAD October 2012
entities to discover each other based on RELOAD Node-ID.
iv. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP
entities to establish a secure connection between each other.
v. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP manager
to discover the RELOAD NodeID associated to a given Resource-ID.
vi. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP
entities to traverse the NAT in front of the SNMP entities which they
will connect to.
vii. SNMP usage for RELOAD MAY provide mechanisms for SNMP entities
to discover the SNMP manager based on manager names or functions.
4. Basic Operations and SNMP
Management interactions between nodes can be abstracted into the
following basic operations: a) the network manager requests data of
nodes and resources; b) the network manager sets data of nodes and
resources; c) nodes initiate data reports to the network manager. A
variety of management functions can be carried out by these basic
operations or their combinations. This document adopts SNMP as a
RELOAD Usage to achieve the management of the RELOAD network. The
basic operations described above can be implemented by messages
defined in SNMP, such as GetRequest, GetNextRequest, GetBulkRequest,
Response, SetRequest, Trap, and InformRequest.
5. Overview of SNMP Usage
The SNMP entity is deployed as an application on RELOAD Nodes in the
SNMP usage for RELOAD. In other words, each SNMP entity is
associated with a RELOAD Node. SNMP entities discover other entities
(agents or managers) by RELOAD mechanisms and connect with other SNMP
entities. Therefore, SNMP entities talk to each other using SNMP
protocol on dedicated connections, while RELOAD protocols are used
for Node discovery and connection setup. The following figure shows
the system composition and protocol:
Peng, et al. Expires April 21, 2013 [Page 5]
Internet-Draft An SNMP Usage for RELOAD October 2012
+------------------------------------------------+
| RELOAD Network |
| |
| |
| +------------+ +------------+ |
| | | SNMP | | |
| | Manager |------------------| Agent | |
| | | | | |
| +------------+ +------------+ |
| | | RELOAD | | |
| | Node |------------------| Node | |
| | | | | |
| +------------+ +------------+ |
| |
+------------------------------------------------+
The following figure shows SNMP Usage's position in the RELOAD
Architecture:
Application
+-------+ +-------+ +-------+
| SIP | | XMPP | | SNMP | ...
| Usage | | Usage | | Usage |
+-------+ +-------+ +-------+
------------------------------------------- Messaging API
RELOAD
6. SNMP Usage Architecture
This document defines SNMP Usage Architeture, which includes SNMP-
RELOAD application and SNMP applications in the Simple Network
Management Protocol (SNMP) architecture defined in [RFC3411]. The
SNMP-RELOAD Application will provide the functions related to RELOAD,
such as getting available address for Node-ID and getting Node-ID for
Resource-ID, to SNMP applications to implement the management for
RELOAD network. This document identifies and describes some key
aspects that need to be considered for SNMP usage for RELOAD. The
following figure depicts SNMP usage architecture.
Peng, et al. Expires April 21, 2013 [Page 6]
Internet-Draft An SNMP Usage for RELOAD October 2012
+------------------------------------------+
| SNMP Usage |
| |
| +------------+ +------------+ |
| | SNMP | |SNMP-RELOAD | |
| |applications|<---------->|application | |
| | | | | |
| +------------+ +------------+ |
| ^ ^ |
+------|--------------------------|--------+
| |
| |
v v
+-----------+ +------------+
| SNMP | | RELOAD |
| Engine | | (M/O-Node) |
|(with DTLS)| | |
+-----------+ +------------+
7. Abstract Service Interfaces(ASI)
Abstract service interfaces describe only the conceptual interfaces
between SNMP-RELOAD application and the other subsystems, and it is
intended to help clarify the externally observable behavior. They
should not be interpreted as APIs or as requirements statements for
APIs. More description about abstract service interfaces is in
[RFC3411].
7.1. SNMP-RELOAD Application Primitive
7.1.1. getNodeForResource ASI
The getNodeForResource ASI is provided for SNMP applications by SNMP-
RELOAD application, and it is used to get the Node-ID of the RELOAD
Node that is responsible for a resource.
getNodeForResource(
IN resourceName -- managed resource name
)
7.1.2. returnNodeForResource ASI
The returnNodeForResource ASI is used to return the Node-ID of RELOAD
Node that is responsible for resource to SNMP applications by SNMP-
RELOAD application.
Peng, et al. Expires April 21, 2013 [Page 7]
Internet-Draft An SNMP Usage for RELOAD October 2012
result = -- SUCCESS or errorIndication
returnNodeForResource(
IN resourceName -- managed resource name
IN nodeID -- node that responsible for managed resource
name
)
7.1.3. getAddressForNode ASI
The getAddressForNode ASI is provided for SNMP applications (e.g.
Command Application, Notification Application) by SNMP-RELOAD
application, and it is used to get the address of the other side for
SNMP communication.
getAddressForNode(
IN nodeID -- destination node
)
7.1.4. returnAddressForNode ASI
The returnNodeForResource ASI is used to return the address of the
other side for SNMP communication.
result = -- SUCCESS or errorIndication
returnAddressForNode(
IN nodeID -- destination node
IN transportAddress -- destination network address
)
7.2. RELOAD Node(M-Node/O-Node) primitive
7.2.1. getNodeForResource ASI
The getNodeForResource ASI is provided for SNMP-RELOAD application by
RELOAD Node(M-Node/O-Node), and it is used to get Node-ID of RELOAD
Node that is responsible for resource. The difinition of
getNodeForResource is above.
Peng, et al. Expires April 21, 2013 [Page 8]
Internet-Draft An SNMP Usage for RELOAD October 2012
7.2.2. returnNodeForResource ASI
The returnNodeForResource ASI is used to return the Node-ID of RELOAD
Node that is responsible for resource to SNMP-RELOAD application by
RELOAD Node. The difinition of returnNodeForResource is above.
7.2.3. exchangeCandidateAddressList ASI
The exchangeCandidateAddressList ASI is used by SNMP-RELOAD
application and RELOAD Node to exchange the address list with each
other for SNMP communication, and these address lists will be used
for NAT traversal by the ICE.
exchangeCandidateAddressList(
IN nodeID -- destination node
IN ufrag -- the username fragment (from ICE)
IN password -- the ICE password
IN candidateAddressList -- sender's candidate address
list
)
the Elements of candidateAddress of candidateAddressList including:
IP address, LinkType, etc.
In order to implement ICE, these items need to be added into
LCD(Local Configuration Datastore):
Ufrag
Password
LinkType: DTLS-UDP-NO-ICE, DTLS-UDP-ICE, TLS-TCP-NO-ICE.
7.2.4. registerManagerReq ASI
The registerManagerReq ASI is provided for SNMP-RELOAD application by
RELOAD M-Node, and it is used to register the Node-ID of the RELOAD
Node which hosts the Manager.
registerManagerReq(
IN managerName -- the name of Manager
Peng, et al. Expires April 21, 2013 [Page 9]
Internet-Draft An SNMP Usage for RELOAD October 2012
IN nodeID -- the Node-ID of the RELOAD Node which Manager
resides in
)
7.2.5. registerManagerAns ASI
The registerManagerAns ASI is used to return the result of
registering to SNMP-RELOAD application by RELOAD M-Node.
result = -- SUCCESS or errorIndication
8. Managed Object Definitions for RELOAD
SNMP-RELOAD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, Counter32,
Gauge32, Integer32, NOTIFICATION-TYPE
FROM SNMPv2-SMI -- RFC 2578 or any update thereof
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC 2580 or any update thereof
TimeStamp
FROM SNMPv2-TC -- RFC 2579 or any update thereof
;
snmpReloadMIB MODULE-IDENTITY
LAST-UPDATED "201202280000Z"
ORGANIZATION "P2PSIP Working Group"
CONTACT-INFO "WG-EMail: p2psip@ietf.org"
DESCRIPTION "
SNMP Usage for RELOAD MIB
Copyright (c) 2011 IETF Trust and the persons identified as
the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201202280000Z"
Peng, et al. Expires April 21, 2013 [Page 10]
Internet-Draft An SNMP Usage for RELOAD October 2012
DESCRIPTION "This version of this MIB module is part of
draft-peng-p2psip-snmp-04; see the draft itself
for full legal notices."
::= { mib-2 199 }
-- ************************************************
-- subtrees of the SNMP-RELOAD-MIB
-- ************************************************
snmpReloadNotifications OBJECT IDENTIFIER ::= { snmpReloadMIB 0 }
snmpReloadObjects OBJECT IDENTIFIER ::= { snmpReloadMIB 1 }
snmpReloadConformance OBJECT IDENTIFIER ::= { snmpReloadMIB 2 }
-- ************************************************
-- snmpReloadObjects - Objects
-- ************************************************
-- Configuration Objects
snmpReloadConfig OBJECT IDENTIFIER ::= { snmpReloadObjects 1 }
snmpReloadConfigVersion OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version of snmpReloadConfigItem."
::= { snmpReloadConfig 1 }
snmpReloadConfigLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime.0 when the snmpReloadConfigItem was
last modified through any means, or 0 if it has not been
modified since the command responder was started."
::= { snmpReloadConfig 2 }
snmpReloadConfigItem OBJECT IDENTIFIER ::= { snmpReloadConfig 3 }
snmpReloadNodeName OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The name of RELOAD Node."
::= { snmpReloadConfigItem 1 }
Peng, et al. Expires April 21, 2013 [Page 11]
Internet-Draft An SNMP Usage for RELOAD October 2012
snmpReloadNodeId OBJECT-IDENTITY
STATUS current
DESCRIPTION
"node-id-length This element contains the length of
a NodeId(NodeIdLength) in bytes. This value MUST be
between 16 (128 bits) and 20 (160 bits). If this
element is not present, the default of 16 is used."
::= { snmpReloadConfigItem 2 }
snmpReloadNodeType OBJECT-TYPE
SYNTAX Integer32(0..9)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"the type of RELOAD Node.
Definition of values as follows:
Client(0),
Peer(1)
"
::= { snmpReloadConfigItem 3 }
snmpReloadLogPrintLevel OBJECT-TYPE
SYNTAX Integer32(0..9)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"the type of RELOAD Node.
Definition of values as follows:
debug(3),
info(2),
warn(1),
error(0)
"
::= { snmpReloadConfigItem 4 }
snmpReloadNotificationEnable OBJECT-TYPE
SYNTAX Integer32(0..9)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Whether are notifications sent.
Definition of values as follows:
Disable(0),
Enable(1)
"
::= { snmpReloadConfigItem 5 }
Peng, et al. Expires April 21, 2013 [Page 12]
Internet-Draft An SNMP Usage for RELOAD October 2012
-- The snmpReloadFailures Group
snmpReloadFailures OBJECT IDENTIFIER ::= { snmpReloadObjects 2 }
snmpReloadMessageForwardFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times RELOAD message failed to be forwarded,
for any reason."
::= { snmpReloadFailures 1 }
snmpReloadDataUpdateFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times RELOAD data failed to be updated,
for any reason."
::= { snmpReloadFailures 2 }
-- ****************************************************
-- snmpReloadNotifications - Notifications Information
-- ****************************************************
snmpReloadMessageForwardFailNotification NOTIFICATION-TYPE
OBJECTS { snmpReloadMessageForwardFailures }
STATUS current
DESCRIPTION
"Notification that RELOAD message failed to be forwarded."
::= { snmpReloadNotifications 1 }
snmpReloadDataUpdateFailNotification NOTIFICATION-TYPE
OBJECTS { snmpReloadDataUpdateFailures }
STATUS current
DESCRIPTION
"Notification that RELOAD data failed to be updated."
::= { snmpReloadNotifications 2 }
-- ************************************************
-- snmpReloadCompliances - Conformance Information
-- ************************************************
snmpReloadCompliances OBJECT IDENTIFIER ::= {snmpReloadConformance 1}
snmpReloadGroups OBJECT IDENTIFIER ::= { snmpReloadConformance 2 }
Peng, et al. Expires April 21, 2013 [Page 13]
Internet-Draft An SNMP Usage for RELOAD October 2012
-- ************************************************
-- Compliance statements
-- ************************************************
snmpReloadCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines that support
the SNMP-RELOAD-MIB"
MODULE
MANDATORY-GROUPS { snmpReloadConfigGroup,
snmpReloadFailuresGroup,
snmpReloadNotificationGroup }
::= { snmpReloadCompliances 1 }
-- ************************************************
-- Units of conformance
-- ************************************************
snmpReloadConfigGroup OBJECT-GROUP
OBJECTS {
snmpReloadConfigVersion,
snmpReloadConfigLastChanged,
snmpReloadNodeType,
snmpReloadLogPrintLevel,
snmpReloadNotificationEnable
}
STATUS current
DESCRIPTION
"A collection of objects for maintaining configuration
information of an SNMP engine that implements
the SNMP Usage for RELOAD."
::= { snmpReloadGroups 1 }
snmpReloadFailuresGroup OBJECT-GROUP
OBJECTS {
snmpReloadMessageForwardFailures,
snmpReloadDataUpdateFailures
}
STATUS current
DESCRIPTION
"A collection of objects for failures
information of an SNMP engine that implements
the SNMP Usage for RELOAD."
::= { snmpReloadGroups 2 }
Peng, et al. Expires April 21, 2013 [Page 14]
Internet-Draft An SNMP Usage for RELOAD October 2012
snmpReloadNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
snmpReloadMessageForwardFailNotification,
snmpReloadDataUpdateFailNotification
}
STATUS current
DESCRIPTION
"Notifications"
::= { snmpReloadGroups 3 }
END
9. Network Manager Registration and Lookup
The Node-ID of the network manager which acts as a provider of
management service should be discovered by agents on RELOAD nodes, so
that the agents can send messages to the manager. The Node-ID of
network manager may not be fixed or predefined in advance. So a
recognizable name is necessary and the managed nodes should find the
Node-ID of the manager through this fixed name. Therefore, it is
necessary for the manager to register itself in the network after
joining the network. In other words, the manager needs to store the
mapping between its name and its Node-ID in the RELOAD network. When
an agent wants to contact the manager, it needs to first look up the
manager's Node-ID corresponding to the predefined management service
name. This registration is achieved by storing the name of the
network manager and the structure of SnmpRegistration into the RELOAD
network. The corresponding SNMP-REGISTRATION Kind-ID will be
formally defined in the following chapter. It is proposed to store
the mapping of the manager's name to a destination list in this
document. Therefore, a single Node-ID as a special case for a
destination list. The contents of a SnmpRegistration structure are
as follows
struct {
opaque contact_prefs<0..2^16-1>;
Destination destination_list<0..2^16-1>;
} SnmpRegistrationData;
struct {
uint16 length;
Peng, et al. Expires April 21, 2013 [Page 15]
Internet-Draft An SNMP Usage for RELOAD October 2012
SnmpRegistrationData data;
} SnmpRegistration;
The contents of the SnmpRegistration PDU are:
length
the length of the rest of the PDU
data
the contents of the registration data is an opaque string
containing the network manager's contact preferences and a
destination list for the peer.
When an agent needs to contact a network manager, it must perform a
query of SnmpRegistration by FetchReq message to get the manager's
Node-ID.
The process for Network Manager Registration and Lookup is as shown
the following figure:
Peng, et al. Expires April 21, 2013 [Page 16]
Internet-Draft An SNMP Usage for RELOAD October 2012
+------------------------+ +-------------++-------------+
|Manager | | R-Node || Agent |
| | | || |
|SNMP-RELOAD RELOAD | | RELOAD || RELOAD |
|application M-Node | | R-Node || O-Node |
| | | || |
| | | | | | || | |
+------------------------+ +-------------++-------------+
| | | |
| | | |
+---------------------------------+ |
|1.Manager Registering: | | |
| | | | |
| |registerManagerReq | | |
| |------------->| | | |
| | | | | |
| | |StoreReq | | |
| | |------------->| | |
| | | | | |
| | |StoreAns | | |
| | |<-------------| | |
| | | | | |
| |registerManagerAns | | |
| |<-------------| | | |
+---------------------------------+ |
| | | |
| | +---------------------+
| | |2.Manager Lookup: |
| | | | | |
| | | | FetchReq | |
| | | |<-------------| |
| | | | | |
| | | | FetchAns | |
| | | |------------->| |
| | +---------------------+
| | | |
| | | |
10. An SNMP Entity Forms a Direct Connection with Another SNMP Entity
Note that the targets of the management tasks and reports of RELOAD
network are Node-ID of RELOAD or snmeEngineID of SNMP. (Note: In
this document, snmeEngineID constructed from Node-ID.) When a SNMP
Entity needs to send SNMP messages to another SNMP Entity, it must
get the other side of available IP address firstly. Due to the
existence of NAT, they need to exchange ICE addresses with each other
and check for connectivity, and then selects a pair of available IP
Peng, et al. Expires April 21, 2013 [Page 17]
Internet-Draft An SNMP Usage for RELOAD October 2012
address to establish the connection(of course, if a connection has
been established between this pair of IP address, the initiator node
will directly send messages to the target node.) The process of
establishing a direct connection between SNMP Entities is as shown
below:
+---------------------------------------+ +-----------------------+
|Entity 1 | | Entity 2 |
| | | |
| SNMP SNMP-RELOAD RELOAD | | RELOAD SNMP-RELOAD|
|applications application M/O-Node | | O/M-Node application|
| | | |
| | | | | | | | |
+---------------------------------------+ +-----------------------+
| | | | |
| | | | |
|getAddressForNode | | |
|------------->| | | |
| | | | |
| | | | |
| +---------------+ | | |
| |Get ICE ufrag/ | | | |
| |password from | | | |
| |LCD, collect | | | |
| |candidate | | | |
| |address list | | | |
| +---------------+ | | |
| | | | |
| | | | |
| |exchangeCandidateAddressList | |
| |------------->| | |
| | | | |
| | | exchangeCandidateAddressList
| | | AppAttach | |
| | |<------------>|<------------>|
| | | | |
| | | | |
| |exchangeCandidateAddressList | |
| |<-------------| | |
| | | | |
| | | | |
| | | | |
| | ICE Check | | |
| |<------------------------------------------>|
| | | | |
| | | | |
| | | | |
Peng, et al. Expires April 21, 2013 [Page 18]
Internet-Draft An SNMP Usage for RELOAD October 2012
| +----------------+ | | |
| |Select available| | | |
| |address from | | | |
| |candidate list | | | |
| +----------------+ | | |
| | | | |
| | | | |
|returnAddressForNode | | |
|<-------------| | | |
| | | | |
| | | | |
+-------------+ | | | |
|If agent, | | | | |
|store address| | | | |
|into MIB | | | | |
|(snmpTarget | | | | |
|AddrTable) | | | | |
+-------------+ | | | |
| | | | |
11. O-Node information Collection
Before a network manager performs management tasks for nodes, it must
first collect the Node-ID and the status information of managed
nodes. The manager collects the information about RELOAD nodes
(including Peer and Client) using the following method: when an agent
starts up(or is activated), its associated RELOAD node joins the
RELOAD network, and it needs to obtain the name of a network manager
by some method. Such as: a) the name of the network manager is set
in the configuration file in configuration server, and the managed
nodes can obtain the name from the configuration file, b) build the
tree struture of the names of the network manager according to ReDiR,
and the managed nodes can obtain the name by the method of ReDiR
service discovery (note: an entry is added in ReDiR Namespaces
Registry, its detail is in the section of IANA Considerations), c)
the name of the network manager is set in the LCD in the managed
node, and the managed node can obtain the name from its LCD. Then
this node connects to the network manager and registers its own
information, such as node name, Node-ID, status, etc., to the
manager. The procedure for finding the manager and connecting to it
has been introduced in the previous section. There are many other
ways to collect the information about managed nodes, which could be
studied further in future.
Peng, et al. Expires April 21, 2013 [Page 19]
Internet-Draft An SNMP Usage for RELOAD October 2012
12. O-Node Lookup by the Network Manager for a Resource
When a network manager needs to send a management task for resource,
it is necessary that the network manager first gets the Node-ID of
the O-Node responsible for the resource in order to determine whether
there is a connection with the O-Node. One way for the manager to
get the Node-ID of the O-Node responsible for the resource is to
acquire the Node-ID of the O-NODE responsible for the target resource
through the via_list of Forwarding Header in FindAns. The process is
as follows:
First, the network manager sends a FindReq to the RELOAD network with
the target Reource-ID put into the destination_list of the FindReq.
Then the RELOAD network routes FindReq to the node responsible for
the target Resource ID according to its routing algorithm.
Second, the O-Node returns FindAns to the network manager through the
RELOAD network. The first Node-ID in the via_list of the Forwarding
Header of the FindAns is the Node-ID of the O-Node responsible for
the target resource.
The process which Network Manger utilizes when Looking up the O-Node
for a Resource is as shown below:
Peng, et al. Expires April 21, 2013 [Page 20]
Internet-Draft An SNMP Usage for RELOAD October 2012
+---------------------------------------+ +-------------+
|Manager | | Agent |
| | | |
| SNMP SNMP-RELOAD RELOAD | | RELOAD |
|applications application M-Node | | O-Node |
| | | |
| | | | | | | |
+---------------------------------------+ +-------------+
| | | |
| | | |
|getNodeForResource | |
|------------->| | |
| | | |
| | | |
| | | |
| |getNodeForResource |
| |------------->| |
| | | |
| | | |
| | | Find |
| | |<------------>|
| | | |
| | | |
| |returnNodeForResource |
| |<-------------| |
| | | |
| | | |
| | | |
|returnNodeForResource | |
|<-------------| | |
| | | |
After the network manager gets the Node-ID of O-Node, it can
determine whether there is a connection between itself and the
O-Node. If the connection exists, the network manager may directly
send SNMP message to the O-Node, otherwise it is required to
establish a new connection to the O-Node.
13. Definition of SNMP-REGISTRATION Kind
This section defines the SNMP-REGISTRATION kind.
Name: SNMP-REGISTRATION
Kind ID: The Resource Name for the SNMP-REGISTRATION Kind-ID is
the Name of the network manager. The data stored is a
SnmpRegistrationData, which can contain a destination list and
Peng, et al. Expires April 21, 2013 [Page 21]
Internet-Draft An SNMP Usage for RELOAD October 2012
contact preferences to the peer which is acting for the network
manager.
Data Model: The data model for the SNMP-REGISTRATION Kind-ID is
single value.
Access Control: USER-NODE-MATCH.
Data stored under the SNMP-REGISTRATION kind is of type
SnmpRegistration. A destination list can be used to reach the
network manager.
14. Security Considerations
The threats to SNMP Usage for RELOAD are the same with the SNMP, and
which are described specifically in RFC5953. We won't repeat it in
this document.
There are three solutions can solve the security issues in SNMP Usage
for RELOAD. The first option is to use a shared key based solution
which is utilized in SNMPv3 security solution (USM). The second
option is a PKI based security solution, which is to use the
certificate of RELOAD to authenticate and encrypt the SNMP messages.
The third option is (D)TLS based security solution, which uses the
secure (D)TLS links to transfer the SNMP message.
USM was designed to be independent of other existing security
infrastructures. USM therefore uses a separate principal and key
management infrastructure. Many operators have reported that
deploying another principal and key management infrastructure in
order to use SNMPv3 is a deterrent to deploying SNMPv3[RFC5590]. We
note that the second option may not be as efficient as expected by
the service providers. So we recommend the third option.
The special detail of (D)TLS based security for SNMP is defined in
RFC5953, and it won't be described again in this document. In short,
we propose to use RELOAD certificate for setting up the connection
using (D)TLS based security. When the Mapping of certificate's
subjectAltName to a tmSecurityName is used in the SNMP-TLS-TM-MIB's
snmpTlstmCertToTSNTable, tmSecurityName is derived from the user name
value of the SubjectAltName field in RELOAD certificate.
15. IANA Considerations
In case of multiple managers and single administration domain, the
managed Nodes may get the manager's name by the method of ReDiR
Peng, et al. Expires April 21, 2013 [Page 22]
Internet-Draft An SNMP Usage for RELOAD October 2012
service discovery. And an entry added in ReDiR Namespaces Registry
is below.
+----------------+----------+
| Namespace | RFC |
+----------------+----------+
| snmp-manager | RFC-AAAA |
+----------------+----------+
16. Acknowledgments
This draft is based on "REsource LOcation And Discovery (RELOAD) Base
Protocol" draft by C. Jennings, B. Lowekamp, E. Rescorla, S. Baset
and H. Schulzrinne.
This draft make a reference to "A SIP Usage for RELOAD" draft by C.
Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne.
This draft is based on "Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks" RFC by Harrington,
D., Presuhn, R., and B. Wijnen.
This draft is based on "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)" RFC by
Hardaker, W..
Thanks to David Harrington, Juergen Schoenwaelder, Dan Romascanu, Tom
Petch, Marc Petit-Huguenin, and others in P2PSIP and Network WG who
offered significant advice on earlier versions of this draft.
Thank the many people of the IETF P2PSIP WG and Network WG whose many
drafts and RFCs we have learned.
17. References
17.1. Normative References
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD)Base Protocol", August 2010.
[I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)", October 2012.
Peng, et al. Expires April 21, 2013 [Page 23]
Internet-Draft An SNMP Usage for RELOAD October 2012
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD", July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 5953, August 2010.
17.2. Informative References
[I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP",
July 2008.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
Appendix A. Additional Stuff
Peng, et al. Expires April 21, 2013 [Page 24]
Internet-Draft An SNMP Usage for RELOAD October 2012
Authors' Addresses
YongLin Peng
ZTE Corporation
Nanjing, 210012
China
Phone: +86 13776637274
Email: peng.yonglin@zte.com.cn
Wei Wang
ZTE Corporation
Nanjing, 210012
China
Phone: +86 13851658076
Email: wang.wei108@zte.com.cn
ZhenWu Hao
ZTE Corporation
Nanjing, 210012
China
Phone: +86 13382087596
Email: hao.zhenwu@zte.com.cn
Yu Meng
ZTE Corporation
Nanjing, 210012
China
Phone: +86 18651806839
Email: meng.yu@zte.com.cn
Peng, et al. Expires April 21, 2013 [Page 25]
