An SNMP Usage for RELOAD
draft-peng-p2psip-snmp-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | YongLin Peng , Wei Wang , ZhenWu Hao , Yu Meng | ||
| Last updated | 2011-10-24 (Latest revision 2011-07-11) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-peng-p2psip-snmp-03
P2PSIP Y. Peng
Internet-Draft W. Wang
Intended status: Informational Z. Hao
Expires: April 27, 2012 Y. Meng
ZTE Corporation
October 25, 2011
An SNMP Usage for RELOAD
draft-peng-p2psip-snmp-03
Abstract
This document defines a SNMP Usage for REsource LOcation And
Discovery(RELOAD), The SNMP Usage provides the functionality of
managing the RELOAD network. The SNMP Usage provides lookup service
for the network manager's address stored in the overlay. The SNMP
Usage also defines the method that allow the registrations to map a
network manager'name to a specific node reachable through the
overlay. The AppAttach method is used to establish a direct
connection between nodes 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 27, 2012.
Copyright Notice
Copyright (c) 2011 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
Peng, et al. Expires April 27, 2012 [Page 1]
Internet-Draft An SNMP Usage for RELOAD October 2011
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 . . . . . . . . . . . . . . . . . . 4
5. Overview of SNMP Usage . . . . . . . . . . . . . . . . . . . . 5
6. SNMP Usage Architecture . . . . . . . . . . . . . . . . . . . 6
7. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 6
7.1. SNMP-RELOAD Application Primitive . . . . . . . . . . . . 7
7.1.1. getNodeForResource ASI . . . . . . . . . . . . . . . . 7
7.1.2. returnNodeForResource ASI . . . . . . . . . . . . . . 7
7.1.3. getAddressForNode ASI . . . . . . . . . . . . . . . . 7
7.1.4. returnAddressForNode ASI . . . . . . . . . . . . . . . 7
7.2. RELOAD Node(M-Node/O-Node) primitive . . . . . . . . . . . 8
7.2.1. getNodeForResource ASI . . . . . . . . . . . . . . . . 8
7.2.2. returnNodeForResource ASI . . . . . . . . . . . . . . 8
7.2.3. exchangeCandidateAddressList ASI . . . . . . . . . . . 8
7.2.4. registerManagerReq ASI . . . . . . . . . . . . . . . . 9
7.2.5. registerManagerAns ASI . . . . . . . . . . . . . . . . 9
8. Network Manager Registering and Looking up . . . . . . . . . . 9
9. An SNMP Entity Forms a Direct Connection with Another SNMP
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. O-Node information Collection . . . . . . . . . . . . . . . . 13
11. Network Manger Looks up the O-Node for a Resource . . . . . . 13
12. SNMP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Peng, et al. Expires April 27, 2012 [Page 2]
Internet-Draft An SNMP Usage for RELOAD October 2011
1. Introduction
This document defines an SNMP Usage for REsource LOcation And
Discovery (RELOAD),which can be used to manage the RELOAD network.
It can provide important network management functions, such as
adjusting the network configuration, monitoring the performance of
the network, collecting real-time failure information, etc. These
network management functions are essential for stable operation and
high-quality services of the network. As 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 nodes 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, so we don't discuss the management of the centralized server
in this document, and only focus on the management of the distributed
nodes.
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].
We use the terminology and definitions from Concepts and Terminology
for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base
Protocol [I-D.ietf-p2psip-base] and SNMPv3 [RFC3411] and TLS TM for
SNMP [RFC5953] extensively in this document.
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.
Node: RELOAD Node, including both Peer and Client, which SNMP
manager or agent resides in.
M-Node: Management Node, which is the RELOAD Node which SNMP
Manager resides in.
Peng, et al. Expires April 27, 2012 [Page 3]
Internet-Draft An SNMP Usage for RELOAD October 2011
O-Node: Objective Node, which is the RELOAD Node managed by a
network manager, which SNMP agent resides in.
R-Node: Responsibility Node, which is the RELOAD Node responsible
for storing the data according to P2P algorithm.
3. Network Management Requirements
SNMP usage SHOULD or MAY provide these functions and mechanisms as
below:
1. 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.
2. SNMP usage for RELOAD SHOULD provide the management functions for
RELOAD resource. Such as tracing forwarded the RELOAD messages,
processing flows of resources.
3. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP entities
to discover each other based on RELOAD NodeID.
4. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP entities
to establish a secure connection between each other.
5. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP manager
to discover the RELOAD NodeID associated to a given ResourceID.
6. 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.
7. 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
The management interactions between nodes can be abstracted into a
few basic operations: 1). the network manager requests data of nodes
and resources; 2). the network manager sets data of nodes and
resources; 3). 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
Peng, et al. Expires April 27, 2012 [Page 4]
Internet-Draft An SNMP Usage for RELOAD October 2011
basic operations described above can be implemented by messages
defined in SNMP, such as GetRequest, GetNextRequest, GetBulkRequest,
Response, SetRequest, Trap, 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 to set up connects 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 diagram of
system composition and protocol is as follow:
+------------------------------------------------+
| RELOAD Network |
| |
| |
| +------------+ +------------+ |
| | | SNMP | | |
| | Manager |------------------| Agent | |
| | | | | |
| +------------+ +------------+ |
| | | RELOAD | | |
| | Node |------------------| Node | |
| | | | | |
| +------------+ +------------+ |
| |
+------------------------------------------------+
SNMP Usage's position in the RELOAD Architecture diagram is as
follow:
Peng, et al. Expires April 27, 2012 [Page 5]
Internet-Draft An SNMP Usage for RELOAD October 2011
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 diagram depicts SNMP usage architecture.
+------------------------------------------+
| SNMP Usage |
| |
| +------------+ +------------+ |
| | SNMP | |SNMP-RELOAD | |
| |applications|<---------->|application | |
| | | | | |
| +------------+ +------------+ |
| ^ ^ |
+------|--------------------------|--------+
| |
| |
v v
+-----------+ +------------+
| SNMP | | RELOAD |
| Engine | | (M/O-Node) |
|(with DTLS)| | |
+-----------+ +------------+
7. Abstract Service Interfaces
Peng, et al. Expires April 27, 2012 [Page 6]
Internet-Draft An SNMP Usage for RELOAD October 2011
7.1. SNMP-RELOAD Application Primitive
7.1.1. getNodeForResource ASI
The getNodeForResource ASI is provided for SNMP application by SNMP-
RELOAD application, and it is used to get Node ID of RELOAD Node that
is responsible for 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.
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.
Peng, et al. Expires April 27, 2012 [Page 7]
Internet-Draft An SNMP Usage for RELOAD October 2011
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.
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 each other
for SNMP communication, and these address lists will be uesd to do
NAT traversal by the way of 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.
Peng, et al. Expires April 27, 2012 [Page 8]
Internet-Draft An SNMP Usage for RELOAD October 2011
In order to implement ICE, these items need to be added into LCD:
Ufrag
Password
LinkType: DTLS-UDP-NO-ICE, DTLS-UDP-ICE, TLS-TCP-NO-ICE, TLS-TCP-ICE.
7.2.4. registerManagerReq ASI
The gregisterManagerReq ASI is provided for RELOAD Application by
RELOAD M-Node, and it is used to register the Node ID of the RELOAD
Node which Manager resides in.
gregisterManagerReq(
IN managerName -- the name of Manager
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. Network Manager Registering and Looking up
The Node ID of the network manager which acts as a provider of
management service should be able to be found by agents on RELOAD
nodes, thus 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
Peng, et al. Expires April 27, 2012 [Page 9]
Internet-Draft An SNMP Usage for RELOAD October 2011
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;
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 to a network manager, it must perform
a query of SnmpRegistration by FetchReq message to get the manager's
Node ID.
The process diagram for Network Manager Registering and Looking up is
as follow:
Peng, et al. Expires April 27, 2012 [Page 10]
Internet-Draft An SNMP Usage for RELOAD October 2011
+------------------------+ +-------------++-------------+
|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 Looking up:|
| | | | | |
| | | | FetchReq | |
| | | |<-------------| |
| | | | | |
| | | | FetchAns | |
| | | |------------->| |
| | +---------------------+
| | | |
| | | |
9. An SNMP Entity Forms a Direct Connection with Another SNMP Entity
Because 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.) So 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 each other and
checks connectivity, then selects a pair of available IP address to
Peng, et al. Expires April 27, 2012 [Page 11]
Internet-Draft An SNMP Usage for RELOAD October 2011
establish 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 Forming a
direct connect between SNMP Entities 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 | |
| |------------->| | |
| | | | |
| | | | |
| | | AppAttach | AppAttach |
| | |<------------>|<------------>|
| | | | |
| | | | |
| |exchangeCandidateAddressList | |
| |<-------------| | |
| | | | |
| | | | |
| | | | |
| | ICE Check | | |
| |<------------------------------------------>|
| | | | |
| | | | |
| | | | |
| +----------------+ | | |
Peng, et al. Expires April 27, 2012 [Page 12]
Internet-Draft An SNMP Usage for RELOAD October 2011
| |Select available| | | |
| |address from | | | |
| |candidate list | | | |
| +----------------+ | | |
| | | | |
| | | | |
|returnAddressForNode | | |
|<-------------| | | |
| | | | |
| | | | |
+-------------+ | | | |
|If agent, | | | | |
|store address| | | | |
|into MIB | | | | |
|(snmpTarget | | | | |
|AddrTable) | | | | |
+-------------+ | | | |
| | | | |
10. O-Node information Collection
Before a network manager performs management tasks for nodes, it must
first collect the Node ID and its status information of managed
nodes. The way of a manager collecting the information of RELOAD
nodes (including Peer and Client) is as follows: when an agent starts
up, its associated RELOAD Node joins the RELOAD network, it needs to
get the name of a network manager from its configuration or an
Enrollment Server; 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 of finding the manager and
connecting to it has been introduced in the previous section. There
are many other ways to collect information of managed nodes, which
could be studied in future documents.
11. Network Manger Looks up the O-Node 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 so as to judge 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
via_list of Forwarding Header in FindAns. The process is as follows:
Firstly, the network manager sends an FindReq to the RELOAD network,
the target Reource ID is put into the destination_list of the
Peng, et al. Expires April 27, 2012 [Page 13]
Internet-Draft An SNMP Usage for RELOAD October 2011
FindReq. Then the RELOAD network routes FindReq to the node
responsible for the target Resource ID according to its routing
algorithm.
Secondly, 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 diagram for Network Manger Looking up the O-Node for a
Resource is as below:
+---------------------------------------+ +-------------+
|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 will be able
to judge whether there is a connection between itself and the O-Node.
If the connection exists, the network manager may directly send SNMP
Peng, et al. Expires April 27, 2012 [Page 14]
Internet-Draft An SNMP Usage for RELOAD October 2011
message to the O-Node, otherwise it is necessary to establish a new
connection to the O-Node.
12. SNMP-REGISTRATION Kind Definition
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
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.
13. Security Considerations
There are three solutions to the security problem in SNMP Usage for
RELOAD. The first option is shared key based solution, which is
SNMPv3 security solution (USM). The second option is 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. Operators have reported that deploying
another principal and key management infrastructure in order to use
SNMPv3 is a deterrent to deploying SNMPv3. [RFC5590] And the
efficiency of the second option is questionable. 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 RELAOD certificate for setting up the connection
using (D)TLS based security. When the Mapping certificate's
Peng, et al. Expires April 27, 2012 [Page 15]
Internet-Draft An SNMP Usage for RELOAD October 2011
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.
14. IANA Considerations
This document has no IANA Considerations.
15. 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 and the many people who give us much
significative advice.
Thanks to the many people of the IETF P2PSIP WG and Network WG whose
many drafts and RFCs we have learned.
16. References
16.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-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
Peng, et al. Expires April 27, 2012 [Page 16]
Internet-Draft An SNMP Usage for RELOAD October 2011
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.
16.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.
Appendix A. Additional Stuff
Peng, et al. Expires April 27, 2012 [Page 17]
Internet-Draft An SNMP Usage for RELOAD October 2011
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 27, 2012 [Page 18]