P2PSIP Y. Peng Internet-Draft W. Wang Intended status: Informational ZTE Corporation Expires: July 29, 2011 January 25, 2011 Network Management Scenarios for RELOAD draft-peng-p2psip-network-management-scenarios-00 Abstract The RELOAD protocol can be applied in different kinds of scenarios, including Internet, telecommunication network, enterprise network, etc. This document summarizes the network management scenarios by analyzing typical application model for each of the above three kinds of scenarios. 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 July 29, 2011. 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 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. Peng & Wang Expires July 29, 2011 [Page 1] Internet-Draft Network Management Scenarios for RELOAD January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Management Scenarios for RELOAD Applied on The Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Network Management Scenarios for RELOAD Applied on The Telecommunication Network . . . . . . . . . . . . . . . . . . 4 5. Network Management Scenarios for RELOAD Applied on The Enterprise Network . . . . . . . . . . . . . . . . . . . . . . 7 6. Summary of the Network Management Scenarios for RELOAD . . . . 8 7. Relationship between Network Management Protocol and Diagnostic Protocol . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Peng & Wang Expires July 29, 2011 [Page 2] Internet-Draft Network Management Scenarios for RELOAD January 2011 1. Introduction The RELOAD protocol is a peer-to-peer (P2P) signaling protocol, which provides an abstract storage and messaging service between a set of cooperating peers that form the overlay network. It can be applied in different kinds of scenarios, including Internet, telecommunication network, enterprise network, etc. This document summarizes the network management scenarios by analyzing typical application model for each of the above three kinds of scenarios. 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] extensively in this document. SNMP: Simple Network Management Protocol. 3. Network Management Scenarios for RELOAD Applied on The Internet There are a variety of application models for RELOAD on the Internet, this document only analyses one of the typical application model named "Public P2P VoIP Service Providers" [cite P2PVoIP scenario]. As stated in the draft of application scenarios for RELOAD, centralized operation and management is required for RELOAD in this application model. Here we will analyse two aspects of the network management requirements for this application model. From the viewpoint of the service provider, they need to ensure network stability and efficient operation. On the one hand, the provider needs to monitor and control their own devices, and view network utility and load of the devices; on the other hand, because of its openness to user nodes, it is necessary to prevent malicious user nodes from attacking the service network and abnormal user nodes from disturbing the service network, so the action of user nodes need be monitored and controlled. Furthermore, human intervention may be needed when the built-in mechanisms in RELOAD is not able to solve the network problems. From the viewpoint of administrator of enterprise users who use the service from the public P2P VoIP service provider, they need to ensure their own network security, defense external network attacks Peng & Wang Expires July 29, 2011 [Page 3] Internet-Draft Network Management Scenarios for RELOAD January 2011 and viruses; It is needed to prevent commercial secret leakage; It is also needed to limit user function to prevent misuse enterprise VoIP services; It is needed to reasonably distribute traffic flows to improve user experience using limited bandwidth. As an example, Skype plans to provide administration tools for enterprise users to resolve the problem that Skype may be blocked by enterprise networks. (Note: This quotes from http://www.best-voip-review.com/news/ 2010_06_Skype_offers_network_management_tools_to_control_their_softwa re.htmlz) According to the above requirements, we put forward the following network management scenarios for RELOAD used on the Internet: a. Monitoring and controlling the service provider's own devices, such as viewing and modifying the configuration parameters of the devices, monitoring the load and running state of accessed nodes(or super nodes) and the number of client nodes that access accessed nodes(client nodes include RELOAD client and application client). b. Viewing and collecting various network data, such as routing table, the data stored in nodes, real-time status information of nodes, in order to find out the operational status of the network, such as capacity of network, quality of service, network topology information. These are the decision-making basis for optimization and adjustment of the network. c. Alarm for abnormal events, such as congestion, message process failures, routing failures, link failures, etc. d. Disposal of abnormal nodes, for example, finding illegal user nodes and forcing it to exit the network, finding fault nodes that can't perform RELOAD related responsibilities and requiring them to rejoin or forcing them to quit. These ensure the health of the network. e. Providing network management tool for enterprise users. The administrator of the enterprise may control specific data flow through RELOAD nodes, and limit application functions, and configure the communication port by this tool. 4. Network Management Scenarios for RELOAD Applied on The Telecommunication Network DHT-based VoIP service is studied in DSN project of ITU-T (SG13 Q19). Its architecture and processes were developed by referring RELOAD. Although it has not yet been clearly adopted which protocol will be Peng & Wang Expires July 29, 2011 [Page 4] Internet-Draft Network Management Scenarios for RELOAD January 2011 adopted in the project, but it is feasible that RELOAD is used here. And it is very possible that RELOAD is adopted by the VoIP service of DSN. The following figure is the architecture figure defined in DSN. +--------+ +----------------------------------------+ +---------+ | | | /-------\ /-------\ | | | | | | | TOCF |---- -----| NEF | | |Managemet| | | | \-------/ | | \-------/ | | plane | | |--| | | | | | | | | | | | | | | | | /------\ /-------\ |__| | | | | | |---| SCF | | | | |/------\| | | RLF | \-------/ | |/------\ | || EF || | -------| |------- | || MF | | |\------/| | | \------/ |Control plane| |\------/ | | | +-----|--------------------|-------------+ | | | | | | | | | | +-----|--------------------|-------------+ | | | | | | | Data plane | | | | | | /-------\ /-------\ | | | | |--| | CDF |-------------| RF | |--| | | | | \-------/ \-------/ | | | +--------+ +----------------------------------------+ +---------+ RLF in the above figure is equivalent to the peer of RELOAD. And NEF is equivalent to the Enrollment server of RELOAD. And MF is the function of network management. The specific descriptions of every function are as follows: RLF (Resource Location Functions): Resource registration; Locate resources (content, Relay Node, subscription data, service capability, etc.); Store and maintain resource information; Routing of DSN message; Construction and management (such as updating routing tables, transferring resources when a new node joins the overlay network, and so on.)of overlay network; Retrieve optimization information from TOCF(Traffic Optimization Control Functions). Peng & Wang Expires July 29, 2011 [Page 5] Internet-Draft Network Management Scenarios for RELOAD January 2011 NEF (Node Enrolment Functions): Provide bootstrap information for the DSN Node to join the DSN; Assign DSN Node ID to the DSN Nodes; Configure parameters and information related to joining of the DSN Node; Apply Authentication/Authorization to DSN Node; Maintain the Node profile of all enrolled nodes (e.g. Node ID, Zone information and etc), which can be requested by RLF; MF (Management Functions): DSN network and service administration DSN monitoring and diagnosis Statistics and Accounting which includes collection of information related to usage and contribution of DSN services. Inter-operator policy management It is a telecommunication class application network built by telecommunication operators, and the Management Function is clearly defined in the architecture draft so as to achieve network management. In this kind of applications, the core network devices are provided by telecommunication operators. As the number of the devices is large and network topology changes frequently, it is very difficult to manage devices one by one, so the need for centralized operation and management is obvious. Moreover, the existing telecommunication networks were equipped with the appropriate network management systems. In this kind of application model, we will analyze the needs for network management mainly from the perspective of network operators: Firstly, in order to ensure network stability and efficient operation, the network operators need to monitor and control the network devices to ensure utility and load of the core devices. Secondly, the network operators need to effectively locate failure when an exception occurs in the system. For these requirements, we propose the following specific network management scenarios: Peng & Wang Expires July 29, 2011 [Page 6] Internet-Draft Network Management Scenarios for RELOAD January 2011 a. Monitoring and controlling network devices. Such as viewing and modifying the configuration parameters of the devices, monitoring load and running state of the devices, controlling the functions and roles of these devices in the network. b. Viewing and collecting various network data, such as routing table, the data stored in nodes, real-time status information of nodes, in order to find out the operational status of the network, such as the capacity of network, the quality of service, network topology information. These are the decision-making basis for network optimization and adjustment. c. Abnormal nodes alarm, such as congestion, message process failures, routing failures, link failures, etc. d. When an exception occurs, the operators may find the location and the cause of failure by tracing process flow and signaling. It will provide effective help to resolve the failure. 5. Network Management Scenarios for RELOAD Applied on The Enterprise Network RELOAD can be applied in a variety of application models in controlled private network, which was put forward in the draft of application scenarios for RELOAD. The need for centralized operation and management was clearly stated in the application model named "P2P for Redundant SIP Proxies" in this draft. This document analyses the need of network management only for this kind of application model. Firstly, in order to ensure network stability and efficient operation, the IT department of enterprise needs to monitor and control network devices to ensure reasonable utilization rate and no overload. Secondly, the IT department of enterprise needs to ensure the network security, to defense external network attacks and viruses; It is needed to prevent commercial secret leakage; It is needed to limit user functions to prevent misuse of network resources; It is needed to reasonably distribute traffic flows to improve the user's experience under the limited bandwidth. Thirdly, the network operators need to effectively locate failure when an exception occurs in the system. For these requirements, we propose the following specific network management scenarios: Peng & Wang Expires July 29, 2011 [Page 7] Internet-Draft Network Management Scenarios for RELOAD January 2011 a. Monitoring and controlling the network devices, such as viewing and modifying the configuration parameters of the devices, monitoring load and running state of the accessed nodes(or super nodes) and the number of client nodes that access accessed nodes(client nodes include RELOAD Client and Application Client). b. Viewing and collecting various network data, such as routing table, the data stored in nodes, real-time status information of nodes, in order to find out the operational status of the network, such as the capacity of the network, the quality of service, network topology information. These are the decision- making basis for optimization and adjustment of the network. c. Abnormal nodes alarm, such as congestion, message process failures, routing failures, link failures, etc. d. Disposal of abnormal nodes, for example, finding illegal user nodes and forcing it to exit the network, finding fault nodes that can't perform RELOAD related responsibilities and requiring them to rejoin or forcing them to quit, and doing corresponding treatment. These ensure the health of the network. e. The manager may control specific data flow through RELOAD nodes, and limit application functions, and configure the communication port, in order to control the actions of users. f. When an exception occurs, the operators may find the location and the cause of failure by tracing process flow and signaling. It will provide effective help to resolve the failure. 6. Summary of the Network Management Scenarios for RELOAD According to above analysis, we think whether RELOAD is applied on the Internet or telecommunications network or enterprise network, network management is always involved in some application models and scenarios. So it is necessary to study the network management solution for RELOAD and to define its corresponding implementation protocol. 7. Relationship between Network Management Protocol and Diagnostic Protocol A diagnostic mechanism was proposed in the draft named "P2PSIP Overlay Diagnostics", which is an extension to RELOAD protocol. Compared to the network management protocol, the diagnostic protocol belongs to application protocol, and it is at the same level of the Peng & Wang Expires July 29, 2011 [Page 8] Internet-Draft Network Management Scenarios for RELOAD January 2011 protocol with RELOAD. The diagnostics functions provided by RELOAD can be part of the network management functions. For example, the network management server sends the diagnostic request to the RELOAD Peer through SNMP message. After RELOAD Peer receives the diagnostic request it will do diagnostic test through RELOAD diagnostic message and generate result data. Finally, this REOAD Peer will report the diagnostic result to the network management server through SNMP message. 8. Security Considerations The security requirements of the various application scenarios vary tremendously. They should be discussed in more detail in this document. 9. IANA Considerations This document has no IANA Considerations. 10. 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 "Application Scenarios for Peer-to- Peer Session Initiation Protocol" draft by D. Bryan, E. Shim, B. Lowekamp, S. Dawkins, Ed. Thanks to the many people of the IETF P2PSIP WG whose many drafts we have learned. 11. References 11.1. Normative References [I-D.ietf-p2psip-app-scenarios] Bryan, D., Shim, E., Rescorla, E., Lowekamp, B., Dawkins, S., and Ed. , "Application Scenarios for Peer-to-Peer Session Initiation Protocol", November 2007. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery Peng & Wang Expires July 29, 2011 [Page 9] Internet-Draft Network Management Scenarios for RELOAD January 2011 (RELOAD)Base Protocol", November 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.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 Authors' Addresses YongLin Peng ZTE Corporation Nanjing, 210012 China Phone: +86 25 52878190 Email: peng.yonglin@zte.com.cn Wei Wang ZTE Corporation Nanjing, 210012 China Phone: Email: wang.wei108@zte.com.cn Peng & Wang Expires July 29, 2011 [Page 10]