idnits 2.17.1 draft-peng-p2psip-snmp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 766 has weird spacing: '.../M-Node appl...' -- The document date (October 18, 2012) is 4208 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-ietf-p2psip-sip' is mentioned on line 126, but not defined == Missing Reference: 'RFC5590' is mentioned on line 948, but not defined == Unused Reference: 'I-D.ietf-p2psip-service-discovery' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-p2psip-sip' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'RFC3414' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 1050, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5953 (Obsoleted by RFC 6353) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Y. Peng 3 Internet-Draft W. Wang 4 Intended status: Informational Z. Hao 5 Expires: April 21, 2013 Y. Meng 6 ZTE Corporation 7 October 18, 2012 9 An SNMP Usage for RELOAD 10 draft-peng-p2psip-snmp-05 12 Abstract 14 This document defines an SNMP Usage for REsource LOcation And 15 Discovery(RELOAD). The objective of SNMP Usage is to provide the 16 functionality of managing the RELOAD network. In particular, the 17 SNMP Usage provides the following functions: (a) defining the method 18 that allow the registrations to map a network manager's name to a 19 host node reachable in the overlay, and (b) providing lookup service 20 for the node hosts the network manager in the overlay. Then the 21 AppAttach method is used to exchange addresses between nodes to 22 establish a direct connection through which SNMP messages are 23 exchanged. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Network Management Requirements . . . . . . . . . . . . . . . 4 62 4. Basic Operations and SNMP . . . . . . . . . . . . . . . . . . 5 63 5. Overview of SNMP Usage . . . . . . . . . . . . . . . . . . . . 5 64 6. SNMP Usage Architecture . . . . . . . . . . . . . . . . . . . 6 65 7. Abstract Service Interfaces(ASI) . . . . . . . . . . . . . . . 7 66 7.1. SNMP-RELOAD Application Primitive . . . . . . . . . . . . 7 67 7.1.1. getNodeForResource ASI . . . . . . . . . . . . . . . . 7 68 7.1.2. returnNodeForResource ASI . . . . . . . . . . . . . . 7 69 7.1.3. getAddressForNode ASI . . . . . . . . . . . . . . . . 8 70 7.1.4. returnAddressForNode ASI . . . . . . . . . . . . . . . 8 71 7.2. RELOAD Node(M-Node/O-Node) primitive . . . . . . . . . . . 8 72 7.2.1. getNodeForResource ASI . . . . . . . . . . . . . . . . 8 73 7.2.2. returnNodeForResource ASI . . . . . . . . . . . . . . 9 74 7.2.3. exchangeCandidateAddressList ASI . . . . . . . . . . . 9 75 7.2.4. registerManagerReq ASI . . . . . . . . . . . . . . . . 9 76 7.2.5. registerManagerAns ASI . . . . . . . . . . . . . . . . 10 77 8. Managed Object Definitions for RELOAD . . . . . . . . . . . . 10 78 9. Network Manager Registration and Lookup . . . . . . . . . . . 15 79 10. An SNMP Entity Forms a Direct Connection with Another SNMP 80 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 11. O-Node information Collection . . . . . . . . . . . . . . . . 19 82 12. O-Node Lookup by the Network Manager for a Resource . . . . . 20 83 13. Definition of SNMP-REGISTRATION Kind . . . . . . . . . . . . . 21 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 86 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 87 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 17.1. Normative References . . . . . . . . . . . . . . . . . . . 23 89 17.2. Informative References . . . . . . . . . . . . . . . . . . 24 90 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 This document defines an SNMP Usage for RELOAD, which can be used to 96 manage the RELOAD network. It can provide important network 97 management functions, such as changing the network configuration, 98 monitoring the performance of the network, collecting real-time 99 status/failure information, etc. These network management functions 100 are essential for stable operation and high-quality services offered 101 by the network. Since the traditional network management protocols 102 (e.g., SNMP) cannot be directly applied to RELOAD network management, 103 it is necessary to introduce new RELOAD usage of SNMP. 105 As defined in [I-D.ietf-p2psip-base], there are two kinds of network 106 elements in RELOAD network: centralized servers, such as the 107 Enrollment Server; distributed nodes, such as Peer and Client. The 108 management function of centralized servers can be carried out by 109 traditional management methods, and aren't discussed in this 110 document. We focus on the management of the distributed nodes called 111 as RELOAD Nodes in this draft. 113 When the manager starts up, it needs to register the mapping between 114 its name and Node-ID into the RELOAD network, in order to be 115 recognized and found by the managed RELOAD Nodes. So only the name 116 of manager needs be fixed, and needs be known beforhand by RELOAD 117 Nodes. Then, the RELOAD Nodes can get the manager's address and 118 connect with it. Then the Nodes and the manager can exchange 119 management messages through this link. 121 Not only RELOAD Nodes are managed object, but a RELOAD resource is a 122 managed object as well, such as some data stored in RELOAD network by 123 SNMP-RELOAD application. 125 The basic mechanism of SNMP Usage is the same as SIP Usage for 126 RELOAD[I-D.draft-ietf-p2psip-sip]. It is easier to understood the 127 SNMP Usage, if someone has the backgroud of SIP Usage draft. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 In this document, we use the definitions from Concepts and 136 Terminology as described in the following drafts: 138 Peer to Peer SIP [I-D.ietf-p2psip-concepts], RELOAD Base Protocol 139 [I-D.ietf-p2psip-base], SNMPv3 [RFC3411], TLS TM for SNMP [RFC5953] . 141 SNMP: Simple Network Management Protocol. 143 Entity: SNMP Entity, including both Manager and Agent, which 144 resides in RELOAD Node. 146 Manager: SNMP Manager, which resides in RELOAD Node. 148 Agent: SNMP Agent, which resides in RELOAD Node. 150 LCD: Local Configuration Datastore. 152 Node: RELOAD Node, including both Peer and Client, which SNMP 153 manager or agent resides in. 155 ReDiR: Recursive Distributed Rendezvous. 157 M-Node: Management Node, which is the RELOAD Node which SNMP 158 Manager resides in. 160 O-Node: Objective Node, which is the RELOAD Node managed by a 161 network manager, which SNMP agent resides in. 163 R-Node: Responsible Node, which is the RELOAD Node responsible 164 for storing the data according to P2P algorithm. 166 SNMP-RELOAD Application: It provides the functions related to 167 RELOAD for SNMP applications, such as getting available address for 168 Node-ID and getting Node-ID for Resource ID. SNMP applications can 169 implement the management for RELOAD network by SNMP-RELOAD 170 Application. 172 3. Network Management Requirements 174 SNMP usage SHOULD or MAY provide the following functions and 175 mechanisms: 177 i. SNMP usage for RELOAD SHOULD provide the management functions for 178 RELOAD Nodes. Such as setting node name, software version or other 179 configuration information, monitoring the number of the messages 180 initiated, forwarded or processed by nodes, reporting program 181 failure, message forwarding failure or other error on nodes. 183 ii. SNMP usage for RELOAD SHOULD provide the management functions 184 for RELOAD resource. Such as tracking the RELOAD messages is 185 forwarded, processing flows of resources. 187 iii. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP 188 entities to discover each other based on RELOAD Node-ID. 190 iv. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP 191 entities to establish a secure connection between each other. 193 v. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP manager 194 to discover the RELOAD NodeID associated to a given Resource-ID. 196 vi. SNMP usage for RELOAD SHOULD provide mechanisms for SNMP 197 entities to traverse the NAT in front of the SNMP entities which they 198 will connect to. 200 vii. SNMP usage for RELOAD MAY provide mechanisms for SNMP entities 201 to discover the SNMP manager based on manager names or functions. 203 4. Basic Operations and SNMP 205 Management interactions between nodes can be abstracted into the 206 following basic operations: a) the network manager requests data of 207 nodes and resources; b) the network manager sets data of nodes and 208 resources; c) nodes initiate data reports to the network manager. A 209 variety of management functions can be carried out by these basic 210 operations or their combinations. This document adopts SNMP as a 211 RELOAD Usage to achieve the management of the RELOAD network. The 212 basic operations described above can be implemented by messages 213 defined in SNMP, such as GetRequest, GetNextRequest, GetBulkRequest, 214 Response, SetRequest, Trap, and InformRequest. 216 5. Overview of SNMP Usage 218 The SNMP entity is deployed as an application on RELOAD Nodes in the 219 SNMP usage for RELOAD. In other words, each SNMP entity is 220 associated with a RELOAD Node. SNMP entities discover other entities 221 (agents or managers) by RELOAD mechanisms and connect with other SNMP 222 entities. Therefore, SNMP entities talk to each other using SNMP 223 protocol on dedicated connections, while RELOAD protocols are used 224 for Node discovery and connection setup. The following figure shows 225 the system composition and protocol: 227 +------------------------------------------------+ 228 | RELOAD Network | 229 | | 230 | | 231 | +------------+ +------------+ | 232 | | | SNMP | | | 233 | | Manager |------------------| Agent | | 234 | | | | | | 235 | +------------+ +------------+ | 236 | | | RELOAD | | | 237 | | Node |------------------| Node | | 238 | | | | | | 239 | +------------+ +------------+ | 240 | | 241 +------------------------------------------------+ 243 The following figure shows SNMP Usage's position in the RELOAD 244 Architecture: 246 Application 248 +-------+ +-------+ +-------+ 249 | SIP | | XMPP | | SNMP | ... 250 | Usage | | Usage | | Usage | 251 +-------+ +-------+ +-------+ 252 ------------------------------------------- Messaging API 254 RELOAD 256 6. SNMP Usage Architecture 258 This document defines SNMP Usage Architeture, which includes SNMP- 259 RELOAD application and SNMP applications in the Simple Network 260 Management Protocol (SNMP) architecture defined in [RFC3411]. The 261 SNMP-RELOAD Application will provide the functions related to RELOAD, 262 such as getting available address for Node-ID and getting Node-ID for 263 Resource-ID, to SNMP applications to implement the management for 264 RELOAD network. This document identifies and describes some key 265 aspects that need to be considered for SNMP usage for RELOAD. The 266 following figure depicts SNMP usage architecture. 268 +------------------------------------------+ 269 | SNMP Usage | 270 | | 271 | +------------+ +------------+ | 272 | | SNMP | |SNMP-RELOAD | | 273 | |applications|<---------->|application | | 274 | | | | | | 275 | +------------+ +------------+ | 276 | ^ ^ | 277 +------|--------------------------|--------+ 278 | | 279 | | 280 v v 281 +-----------+ +------------+ 282 | SNMP | | RELOAD | 283 | Engine | | (M/O-Node) | 284 |(with DTLS)| | | 285 +-----------+ +------------+ 287 7. Abstract Service Interfaces(ASI) 289 Abstract service interfaces describe only the conceptual interfaces 290 between SNMP-RELOAD application and the other subsystems, and it is 291 intended to help clarify the externally observable behavior. They 292 should not be interpreted as APIs or as requirements statements for 293 APIs. More description about abstract service interfaces is in 294 [RFC3411]. 296 7.1. SNMP-RELOAD Application Primitive 298 7.1.1. getNodeForResource ASI 300 The getNodeForResource ASI is provided for SNMP applications by SNMP- 301 RELOAD application, and it is used to get the Node-ID of the RELOAD 302 Node that is responsible for a resource. 304 getNodeForResource( 306 IN resourceName -- managed resource name 308 ) 310 7.1.2. returnNodeForResource ASI 312 The returnNodeForResource ASI is used to return the Node-ID of RELOAD 313 Node that is responsible for resource to SNMP applications by SNMP- 314 RELOAD application. 316 result = -- SUCCESS or errorIndication 318 returnNodeForResource( 320 IN resourceName -- managed resource name 322 IN nodeID -- node that responsible for managed resource 323 name 325 ) 327 7.1.3. getAddressForNode ASI 329 The getAddressForNode ASI is provided for SNMP applications (e.g. 330 Command Application, Notification Application) by SNMP-RELOAD 331 application, and it is used to get the address of the other side for 332 SNMP communication. 334 getAddressForNode( 336 IN nodeID -- destination node 338 ) 340 7.1.4. returnAddressForNode ASI 342 The returnNodeForResource ASI is used to return the address of the 343 other side for SNMP communication. 345 result = -- SUCCESS or errorIndication 347 returnAddressForNode( 349 IN nodeID -- destination node 351 IN transportAddress -- destination network address 353 ) 355 7.2. RELOAD Node(M-Node/O-Node) primitive 357 7.2.1. getNodeForResource ASI 359 The getNodeForResource ASI is provided for SNMP-RELOAD application by 360 RELOAD Node(M-Node/O-Node), and it is used to get Node-ID of RELOAD 361 Node that is responsible for resource. The difinition of 362 getNodeForResource is above. 364 7.2.2. returnNodeForResource ASI 366 The returnNodeForResource ASI is used to return the Node-ID of RELOAD 367 Node that is responsible for resource to SNMP-RELOAD application by 368 RELOAD Node. The difinition of returnNodeForResource is above. 370 7.2.3. exchangeCandidateAddressList ASI 372 The exchangeCandidateAddressList ASI is used by SNMP-RELOAD 373 application and RELOAD Node to exchange the address list with each 374 other for SNMP communication, and these address lists will be used 375 for NAT traversal by the ICE. 377 exchangeCandidateAddressList( 379 IN nodeID -- destination node 381 IN ufrag -- the username fragment (from ICE) 383 IN password -- the ICE password 385 IN candidateAddressList -- sender's candidate address 386 list 388 ) 390 the Elements of candidateAddress of candidateAddressList including: 391 IP address, LinkType, etc. 393 In order to implement ICE, these items need to be added into 394 LCD(Local Configuration Datastore): 396 Ufrag 398 Password 400 LinkType: DTLS-UDP-NO-ICE, DTLS-UDP-ICE, TLS-TCP-NO-ICE. 402 7.2.4. registerManagerReq ASI 404 The registerManagerReq ASI is provided for SNMP-RELOAD application by 405 RELOAD M-Node, and it is used to register the Node-ID of the RELOAD 406 Node which hosts the Manager. 408 registerManagerReq( 410 IN managerName -- the name of Manager 411 IN nodeID -- the Node-ID of the RELOAD Node which Manager 412 resides in 414 ) 416 7.2.5. registerManagerAns ASI 418 The registerManagerAns ASI is used to return the result of 419 registering to SNMP-RELOAD application by RELOAD M-Node. 421 result = -- SUCCESS or errorIndication 423 8. Managed Object Definitions for RELOAD 425 SNMP-RELOAD-MIB DEFINITIONS ::= BEGIN 427 IMPORTS 428 MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, Counter32, 429 Gauge32, Integer32, NOTIFICATION-TYPE 430 FROM SNMPv2-SMI -- RFC 2578 or any update thereof 431 MODULE-COMPLIANCE, OBJECT-GROUP, 432 NOTIFICATION-GROUP 433 FROM SNMPv2-CONF -- RFC 2580 or any update thereof 434 TimeStamp 435 FROM SNMPv2-TC -- RFC 2579 or any update thereof 436 ; 438 snmpReloadMIB MODULE-IDENTITY 439 LAST-UPDATED "201202280000Z" 440 ORGANIZATION "P2PSIP Working Group" 441 CONTACT-INFO "WG-EMail: p2psip@ietf.org" 443 DESCRIPTION " 444 SNMP Usage for RELOAD MIB 446 Copyright (c) 2011 IETF Trust and the persons identified as 447 the document authors. All rights reserved. 449 Redistribution and use in source and binary forms, with or 450 without modification, is permitted pursuant to, and subject 451 to the license terms contained in, the Simplified BSD License 452 set forth in Section 4.c of the IETF Trust's Legal Provisions 453 Relating to IETF Documents 454 (http://trustee.ietf.org/license-info)." 456 REVISION "201202280000Z" 457 DESCRIPTION "This version of this MIB module is part of 458 draft-peng-p2psip-snmp-04; see the draft itself 459 for full legal notices." 460 ::= { mib-2 199 } 462 -- ************************************************ 463 -- subtrees of the SNMP-RELOAD-MIB 464 -- ************************************************ 466 snmpReloadNotifications OBJECT IDENTIFIER ::= { snmpReloadMIB 0 } 467 snmpReloadObjects OBJECT IDENTIFIER ::= { snmpReloadMIB 1 } 468 snmpReloadConformance OBJECT IDENTIFIER ::= { snmpReloadMIB 2 } 470 -- ************************************************ 471 -- snmpReloadObjects - Objects 472 -- ************************************************ 474 -- Configuration Objects 475 snmpReloadConfig OBJECT IDENTIFIER ::= { snmpReloadObjects 1 } 477 snmpReloadConfigVersion OBJECT-TYPE 478 SYNTAX Gauge32 479 MAX-ACCESS read-only 480 STATUS current 481 DESCRIPTION 482 "The version of snmpReloadConfigItem." 483 ::= { snmpReloadConfig 1 } 485 snmpReloadConfigLastChanged OBJECT-TYPE 486 SYNTAX TimeStamp 487 MAX-ACCESS read-only 488 STATUS current 489 DESCRIPTION 490 "The value of sysUpTime.0 when the snmpReloadConfigItem was 491 last modified through any means, or 0 if it has not been 492 modified since the command responder was started." 493 ::= { snmpReloadConfig 2 } 495 snmpReloadConfigItem OBJECT IDENTIFIER ::= { snmpReloadConfig 3 } 497 snmpReloadNodeName OBJECT-IDENTITY 498 STATUS current 499 DESCRIPTION 500 "The name of RELOAD Node." 501 ::= { snmpReloadConfigItem 1 } 503 snmpReloadNodeId OBJECT-IDENTITY 504 STATUS current 505 DESCRIPTION 506 "node-id-length This element contains the length of 507 a NodeId(NodeIdLength) in bytes. This value MUST be 508 between 16 (128 bits) and 20 (160 bits). If this 509 element is not present, the default of 16 is used." 510 ::= { snmpReloadConfigItem 2 } 512 snmpReloadNodeType OBJECT-TYPE 513 SYNTAX Integer32(0..9) 514 MAX-ACCESS read-write 515 STATUS current 516 DESCRIPTION 517 "the type of RELOAD Node. 518 Definition of values as follows: 519 Client(0), 520 Peer(1) 521 " 522 ::= { snmpReloadConfigItem 3 } 524 snmpReloadLogPrintLevel OBJECT-TYPE 525 SYNTAX Integer32(0..9) 526 MAX-ACCESS read-write 527 STATUS current 528 DESCRIPTION 529 "the type of RELOAD Node. 530 Definition of values as follows: 531 debug(3), 532 info(2), 533 warn(1), 534 error(0) 535 " 536 ::= { snmpReloadConfigItem 4 } 538 snmpReloadNotificationEnable OBJECT-TYPE 539 SYNTAX Integer32(0..9) 540 MAX-ACCESS read-write 541 STATUS current 542 DESCRIPTION 543 "Whether are notifications sent. 544 Definition of values as follows: 545 Disable(0), 546 Enable(1) 547 " 548 ::= { snmpReloadConfigItem 5 } 550 -- The snmpReloadFailures Group 551 snmpReloadFailures OBJECT IDENTIFIER ::= { snmpReloadObjects 2 } 553 snmpReloadMessageForwardFailures OBJECT-TYPE 554 SYNTAX Counter32 555 MAX-ACCESS read-only 556 STATUS current 557 DESCRIPTION 558 "The number of times RELOAD message failed to be forwarded, 559 for any reason." 560 ::= { snmpReloadFailures 1 } 562 snmpReloadDataUpdateFailures OBJECT-TYPE 563 SYNTAX Counter32 564 MAX-ACCESS read-only 565 STATUS current 566 DESCRIPTION 567 "The number of times RELOAD data failed to be updated, 568 for any reason." 569 ::= { snmpReloadFailures 2 } 571 -- **************************************************** 572 -- snmpReloadNotifications - Notifications Information 573 -- **************************************************** 575 snmpReloadMessageForwardFailNotification NOTIFICATION-TYPE 576 OBJECTS { snmpReloadMessageForwardFailures } 577 STATUS current 578 DESCRIPTION 579 "Notification that RELOAD message failed to be forwarded." 580 ::= { snmpReloadNotifications 1 } 582 snmpReloadDataUpdateFailNotification NOTIFICATION-TYPE 583 OBJECTS { snmpReloadDataUpdateFailures } 584 STATUS current 585 DESCRIPTION 586 "Notification that RELOAD data failed to be updated." 587 ::= { snmpReloadNotifications 2 } 589 -- ************************************************ 590 -- snmpReloadCompliances - Conformance Information 591 -- ************************************************ 593 snmpReloadCompliances OBJECT IDENTIFIER ::= {snmpReloadConformance 1} 594 snmpReloadGroups OBJECT IDENTIFIER ::= { snmpReloadConformance 2 } 595 -- ************************************************ 596 -- Compliance statements 597 -- ************************************************ 599 snmpReloadCompliance MODULE-COMPLIANCE 600 STATUS current 601 DESCRIPTION 602 "The compliance statement for SNMP engines that support 603 the SNMP-RELOAD-MIB" 604 MODULE 605 MANDATORY-GROUPS { snmpReloadConfigGroup, 606 snmpReloadFailuresGroup, 607 snmpReloadNotificationGroup } 608 ::= { snmpReloadCompliances 1 } 610 -- ************************************************ 611 -- Units of conformance 612 -- ************************************************ 614 snmpReloadConfigGroup OBJECT-GROUP 615 OBJECTS { 616 snmpReloadConfigVersion, 617 snmpReloadConfigLastChanged, 618 snmpReloadNodeType, 619 snmpReloadLogPrintLevel, 620 snmpReloadNotificationEnable 621 } 622 STATUS current 623 DESCRIPTION 624 "A collection of objects for maintaining configuration 625 information of an SNMP engine that implements 626 the SNMP Usage for RELOAD." 627 ::= { snmpReloadGroups 1 } 629 snmpReloadFailuresGroup OBJECT-GROUP 630 OBJECTS { 631 snmpReloadMessageForwardFailures, 632 snmpReloadDataUpdateFailures 633 } 634 STATUS current 635 DESCRIPTION 636 "A collection of objects for failures 637 information of an SNMP engine that implements 638 the SNMP Usage for RELOAD." 639 ::= { snmpReloadGroups 2 } 641 snmpReloadNotificationGroup NOTIFICATION-GROUP 642 NOTIFICATIONS { 643 snmpReloadMessageForwardFailNotification, 644 snmpReloadDataUpdateFailNotification 645 } 646 STATUS current 647 DESCRIPTION 648 "Notifications" 649 ::= { snmpReloadGroups 3 } 651 END 653 9. Network Manager Registration and Lookup 655 The Node-ID of the network manager which acts as a provider of 656 management service should be discovered by agents on RELOAD nodes, so 657 that the agents can send messages to the manager. The Node-ID of 658 network manager may not be fixed or predefined in advance. So a 659 recognizable name is necessary and the managed nodes should find the 660 Node-ID of the manager through this fixed name. Therefore, it is 661 necessary for the manager to register itself in the network after 662 joining the network. In other words, the manager needs to store the 663 mapping between its name and its Node-ID in the RELOAD network. When 664 an agent wants to contact the manager, it needs to first look up the 665 manager's Node-ID corresponding to the predefined management service 666 name. This registration is achieved by storing the name of the 667 network manager and the structure of SnmpRegistration into the RELOAD 668 network. The corresponding SNMP-REGISTRATION Kind-ID will be 669 formally defined in the following chapter. It is proposed to store 670 the mapping of the manager's name to a destination list in this 671 document. Therefore, a single Node-ID as a special case for a 672 destination list. The contents of a SnmpRegistration structure are 673 as follows 675 struct { 677 opaque contact_prefs<0..2^16-1>; 679 Destination destination_list<0..2^16-1>; 681 } SnmpRegistrationData; 683 struct { 685 uint16 length; 686 SnmpRegistrationData data; 688 } SnmpRegistration; 690 The contents of the SnmpRegistration PDU are: 692 length 694 the length of the rest of the PDU 696 data 698 the contents of the registration data is an opaque string 699 containing the network manager's contact preferences and a 700 destination list for the peer. 702 When an agent needs to contact a network manager, it must perform a 703 query of SnmpRegistration by FetchReq message to get the manager's 704 Node-ID. 706 The process for Network Manager Registration and Lookup is as shown 707 the following figure: 709 +------------------------+ +-------------++-------------+ 710 |Manager | | R-Node || Agent | 711 | | | || | 712 |SNMP-RELOAD RELOAD | | RELOAD || RELOAD | 713 |application M-Node | | R-Node || O-Node | 714 | | | || | 715 | | | | | | || | | 716 +------------------------+ +-------------++-------------+ 717 | | | | 718 | | | | 719 +---------------------------------+ | 720 |1.Manager Registering: | | | 721 | | | | | 722 | |registerManagerReq | | | 723 | |------------->| | | | 724 | | | | | | 725 | | |StoreReq | | | 726 | | |------------->| | | 727 | | | | | | 728 | | |StoreAns | | | 729 | | |<-------------| | | 730 | | | | | | 731 | |registerManagerAns | | | 732 | |<-------------| | | | 733 +---------------------------------+ | 734 | | | | 735 | | +---------------------+ 736 | | |2.Manager Lookup: | 737 | | | | | | 738 | | | | FetchReq | | 739 | | | |<-------------| | 740 | | | | | | 741 | | | | FetchAns | | 742 | | | |------------->| | 743 | | +---------------------+ 744 | | | | 745 | | | | 747 10. An SNMP Entity Forms a Direct Connection with Another SNMP Entity 749 Note that the targets of the management tasks and reports of RELOAD 750 network are Node-ID of RELOAD or snmeEngineID of SNMP. (Note: In 751 this document, snmeEngineID constructed from Node-ID.) When a SNMP 752 Entity needs to send SNMP messages to another SNMP Entity, it must 753 get the other side of available IP address firstly. Due to the 754 existence of NAT, they need to exchange ICE addresses with each other 755 and check for connectivity, and then selects a pair of available IP 756 address to establish the connection(of course, if a connection has 757 been established between this pair of IP address, the initiator node 758 will directly send messages to the target node.) The process of 759 establishing a direct connection between SNMP Entities is as shown 760 below: 762 +---------------------------------------+ +-----------------------+ 763 |Entity 1 | | Entity 2 | 764 | | | | 765 | SNMP SNMP-RELOAD RELOAD | | RELOAD SNMP-RELOAD| 766 |applications application M/O-Node | | O/M-Node application| 767 | | | | 768 | | | | | | | | | 769 +---------------------------------------+ +-----------------------+ 770 | | | | | 771 | | | | | 772 |getAddressForNode | | | 773 |------------->| | | | 774 | | | | | 775 | | | | | 776 | +---------------+ | | | 777 | |Get ICE ufrag/ | | | | 778 | |password from | | | | 779 | |LCD, collect | | | | 780 | |candidate | | | | 781 | |address list | | | | 782 | +---------------+ | | | 783 | | | | | 784 | | | | | 785 | |exchangeCandidateAddressList | | 786 | |------------->| | | 787 | | | | | 788 | | | exchangeCandidateAddressList 789 | | | AppAttach | | 790 | | |<------------>|<------------>| 791 | | | | | 792 | | | | | 793 | |exchangeCandidateAddressList | | 794 | |<-------------| | | 795 | | | | | 796 | | | | | 797 | | | | | 798 | | ICE Check | | | 799 | |<------------------------------------------>| 800 | | | | | 801 | | | | | 802 | | | | | 803 | +----------------+ | | | 804 | |Select available| | | | 805 | |address from | | | | 806 | |candidate list | | | | 807 | +----------------+ | | | 808 | | | | | 809 | | | | | 810 |returnAddressForNode | | | 811 |<-------------| | | | 812 | | | | | 813 | | | | | 814 +-------------+ | | | | 815 |If agent, | | | | | 816 |store address| | | | | 817 |into MIB | | | | | 818 |(snmpTarget | | | | | 819 |AddrTable) | | | | | 820 +-------------+ | | | | 821 | | | | | 823 11. O-Node information Collection 825 Before a network manager performs management tasks for nodes, it must 826 first collect the Node-ID and the status information of managed 827 nodes. The manager collects the information about RELOAD nodes 828 (including Peer and Client) using the following method: when an agent 829 starts up(or is activated), its associated RELOAD node joins the 830 RELOAD network, and it needs to obtain the name of a network manager 831 by some method. Such as: a) the name of the network manager is set 832 in the configuration file in configuration server, and the managed 833 nodes can obtain the name from the configuration file, b) build the 834 tree struture of the names of the network manager according to ReDiR, 835 and the managed nodes can obtain the name by the method of ReDiR 836 service discovery (note: an entry is added in ReDiR Namespaces 837 Registry, its detail is in the section of IANA Considerations), c) 838 the name of the network manager is set in the LCD in the managed 839 node, and the managed node can obtain the name from its LCD. Then 840 this node connects to the network manager and registers its own 841 information, such as node name, Node-ID, status, etc., to the 842 manager. The procedure for finding the manager and connecting to it 843 has been introduced in the previous section. There are many other 844 ways to collect the information about managed nodes, which could be 845 studied further in future. 847 12. O-Node Lookup by the Network Manager for a Resource 849 When a network manager needs to send a management task for resource, 850 it is necessary that the network manager first gets the Node-ID of 851 the O-Node responsible for the resource in order to determine whether 852 there is a connection with the O-Node. One way for the manager to 853 get the Node-ID of the O-Node responsible for the resource is to 854 acquire the Node-ID of the O-NODE responsible for the target resource 855 through the via_list of Forwarding Header in FindAns. The process is 856 as follows: 858 First, the network manager sends a FindReq to the RELOAD network with 859 the target Reource-ID put into the destination_list of the FindReq. 860 Then the RELOAD network routes FindReq to the node responsible for 861 the target Resource ID according to its routing algorithm. 863 Second, the O-Node returns FindAns to the network manager through the 864 RELOAD network. The first Node-ID in the via_list of the Forwarding 865 Header of the FindAns is the Node-ID of the O-Node responsible for 866 the target resource. 868 The process which Network Manger utilizes when Looking up the O-Node 869 for a Resource is as shown below: 871 +---------------------------------------+ +-------------+ 872 |Manager | | Agent | 873 | | | | 874 | SNMP SNMP-RELOAD RELOAD | | RELOAD | 875 |applications application M-Node | | O-Node | 876 | | | | 877 | | | | | | | | 878 +---------------------------------------+ +-------------+ 879 | | | | 880 | | | | 881 |getNodeForResource | | 882 |------------->| | | 883 | | | | 884 | | | | 885 | | | | 886 | |getNodeForResource | 887 | |------------->| | 888 | | | | 889 | | | | 890 | | | Find | 891 | | |<------------>| 892 | | | | 893 | | | | 894 | |returnNodeForResource | 895 | |<-------------| | 896 | | | | 897 | | | | 898 | | | | 899 |returnNodeForResource | | 900 |<-------------| | | 901 | | | | 903 After the network manager gets the Node-ID of O-Node, it can 904 determine whether there is a connection between itself and the 905 O-Node. If the connection exists, the network manager may directly 906 send SNMP message to the O-Node, otherwise it is required to 907 establish a new connection to the O-Node. 909 13. Definition of SNMP-REGISTRATION Kind 911 This section defines the SNMP-REGISTRATION kind. 913 Name: SNMP-REGISTRATION 915 Kind ID: The Resource Name for the SNMP-REGISTRATION Kind-ID is 916 the Name of the network manager. The data stored is a 917 SnmpRegistrationData, which can contain a destination list and 918 contact preferences to the peer which is acting for the network 919 manager. 921 Data Model: The data model for the SNMP-REGISTRATION Kind-ID is 922 single value. 924 Access Control: USER-NODE-MATCH. 926 Data stored under the SNMP-REGISTRATION kind is of type 927 SnmpRegistration. A destination list can be used to reach the 928 network manager. 930 14. Security Considerations 932 The threats to SNMP Usage for RELOAD are the same with the SNMP, and 933 which are described specifically in RFC5953. We won't repeat it in 934 this document. 936 There are three solutions can solve the security issues in SNMP Usage 937 for RELOAD. The first option is to use a shared key based solution 938 which is utilized in SNMPv3 security solution (USM). The second 939 option is a PKI based security solution, which is to use the 940 certificate of RELOAD to authenticate and encrypt the SNMP messages. 941 The third option is (D)TLS based security solution, which uses the 942 secure (D)TLS links to transfer the SNMP message. 944 USM was designed to be independent of other existing security 945 infrastructures. USM therefore uses a separate principal and key 946 management infrastructure. Many operators have reported that 947 deploying another principal and key management infrastructure in 948 order to use SNMPv3 is a deterrent to deploying SNMPv3[RFC5590]. We 949 note that the second option may not be as efficient as expected by 950 the service providers. So we recommend the third option. 952 The special detail of (D)TLS based security for SNMP is defined in 953 RFC5953, and it won't be described again in this document. In short, 954 we propose to use RELOAD certificate for setting up the connection 955 using (D)TLS based security. When the Mapping of certificate's 956 subjectAltName to a tmSecurityName is used in the SNMP-TLS-TM-MIB's 957 snmpTlstmCertToTSNTable, tmSecurityName is derived from the user name 958 value of the SubjectAltName field in RELOAD certificate. 960 15. IANA Considerations 962 In case of multiple managers and single administration domain, the 963 managed Nodes may get the manager's name by the method of ReDiR 964 service discovery. And an entry added in ReDiR Namespaces Registry 965 is below. 967 +----------------+----------+ 968 | Namespace | RFC | 969 +----------------+----------+ 970 | snmp-manager | RFC-AAAA | 971 +----------------+----------+ 973 16. Acknowledgments 975 This draft is based on "REsource LOcation And Discovery (RELOAD) Base 976 Protocol" draft by C. Jennings, B. Lowekamp, E. Rescorla, S. Baset 977 and H. Schulzrinne. 979 This draft make a reference to "A SIP Usage for RELOAD" draft by C. 980 Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. 982 This draft is based on "Architecture for Describing Simple Network 983 Management Protocol (SNMP) Management Frameworks" RFC by Harrington, 984 D., Presuhn, R., and B. Wijnen. 986 This draft is based on "Transport Layer Security (TLS) Transport 987 Model for the Simple Network Management Protocol (SNMP)" RFC by 988 Hardaker, W.. 990 Thanks to David Harrington, Juergen Schoenwaelder, Dan Romascanu, Tom 991 Petch, Marc Petit-Huguenin, and others in P2PSIP and Network WG who 992 offered significant advice on earlier versions of this draft. 994 Thank the many people of the IETF P2PSIP WG and Network WG whose many 995 drafts and RFCs we have learned. 997 17. References 999 17.1. Normative References 1001 [I-D.ietf-p2psip-base] 1002 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1003 H. Schulzrinne, "REsource LOcation And Discovery 1004 (RELOAD)Base Protocol", August 2010. 1006 [I-D.ietf-p2psip-service-discovery] 1007 Maenpaa, J. and G. Camarillo, "Service Discovery Usage for 1008 REsource LOcation And Discovery (RELOAD)", October 2012. 1010 [I-D.ietf-p2psip-sip] 1011 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1012 H. Schulzrinne, "A SIP Usage for RELOAD", July 2010. 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, March 1997. 1017 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1018 Architecture for Describing Simple Network Management 1019 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1020 December 2002. 1022 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1023 (USM) for version 3 of the Simple Network Management 1024 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1026 [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport 1027 Model for the Simple Network Management Protocol (SNMP)", 1028 RFC 5953, August 2010. 1030 17.2. Informative References 1032 [I-D.ietf-p2psip-concepts] 1033 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 1034 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 1035 July 2008. 1037 [I-D.narten-iana-considerations-rfc2434bis] 1038 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1039 IANA Considerations Section in RFCs", 1040 draft-narten-iana-considerations-rfc2434bis-09 (work in 1041 progress), March 2008. 1043 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1044 June 1999. 1046 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1047 Text on Security Considerations", BCP 72, RFC 3552, 1048 July 2003. 1050 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1051 Documents", BCP 111, RFC 4181, September 2005. 1053 Appendix A. Additional Stuff 1054 Authors' Addresses 1056 YongLin Peng 1057 ZTE Corporation 1058 Nanjing, 210012 1059 China 1061 Phone: +86 13776637274 1062 Email: peng.yonglin@zte.com.cn 1064 Wei Wang 1065 ZTE Corporation 1066 Nanjing, 210012 1067 China 1069 Phone: +86 13851658076 1070 Email: wang.wei108@zte.com.cn 1072 ZhenWu Hao 1073 ZTE Corporation 1074 Nanjing, 210012 1075 China 1077 Phone: +86 13382087596 1078 Email: hao.zhenwu@zte.com.cn 1080 Yu Meng 1081 ZTE Corporation 1082 Nanjing, 210012 1083 China 1085 Phone: +86 18651806839 1086 Email: meng.yu@zte.com.cn