NETCONF Working Group T. Iijima Internet-Draft Hitachi, Ltd. Intended status: Informational Y. Atarashi Expires: September 5, 2011 H. Higuchi Alaxala Networks Corp. Mar 04, 2011 NETCONF Notification over WebSocket draft-iijima-netconf-websocket-ps-00 Abstract This memo proposes transporting NETCONF Notification over WebSocket protocol[I-D.ietf-hybi-thewebsocketprotocol]. RFC5277[RFC5277] specifies that NETCONF Notification must be sent over SSH, BEEP, SSL and console from an NETCONF server to NETCONF clients. When NETCONF Notification was defined, this transport mapping was a reasonable decision. Bi-directional capability is necessary for transporting NETCONF Notification. But at present, WebSocket protocol, which is based on HTTP and has a bi-directional capability, is available. This memo describes the way in which NETCONF Notification is sent over WebSocket protocol. 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 September 5, 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 Iijima, et al. Expires September 5, 2011 [Page 1] Internet-Draft NETCONF Notification over WebSocket Mar 2011 (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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Complementing NETCONF over SOAP/HTTP/TLS . . . . . . . . . 6 3.2. Using NETCONF in cloud computing . . . . . . . . . . . . . 6 4. WebSocket Messages for NETCONF Notifications . . . . . . . . . 7 4.1. WebSocket Message from NETCONF client to NETCONF server . 7 4.2. WebSocket Message from NETCONF server to NETCONF client . 8 5. NETCONF Messages over WebSocket . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Iijima, et al. Expires September 5, 2011 [Page 2] Internet-Draft NETCONF Notification over WebSocket Mar 2011 1. Introduction RFC5277[RFC5277] specifies that NETCONF Notification must be sent over SSH, BEEP, SSL and console from an NETCONF server to NETCONF clients. When NETCONF Notification was defined, this transport mapping was a reasonable decision. Bi-directional capability is necessary for transporting NETCONF Notification. But at present, WebSocket protocol, which is based on HTTP and has a bi-directional capability, is available[I-D.ietf-hybi-thewebsocketprotocol]. This memo proposes transporting NETCONF Notification over WebSocket protocol. Iijima, et al. Expires September 5, 2011 [Page 3] Internet-Draft NETCONF Notification over WebSocket Mar 2011 2. Problem Statement Figure 1 is an architecture of NETCONF Notification extracted from RFC5277[RFC5277]. NETCONF Notification is defined to be sent over BEEP, SSH, SSL, or console. Layer Example +-------------+ +-------------------------------------------+ | Content | | Configuration data | +-------------+ +-------------------------------------------+ | | +-------------+ +-------------------------------------------+ | Operations | |, , | +-------------+ +-------------------------------------------+ | | | +-------------+ +-----------------------------+ | | RPC | | , | | +-------------+ +-----------------------------+ | | | | +-------------+ +-------------------------------------------+ | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-------------------------------------------+ Figure 1: NETCONF Event Notification At the time of standardizing NETCONF Notification, there were no transport protocols other than BEEP, SSH, SSL, or console for transporting NETCONF Notification. Bi-directional capability is necessary for that purpose. This is the reason why SOAP/HTTP/TLS, one of the transport protocol for NETCONF as defined in RFC4741[RFC4741], is excluded from this figure. SOAP/HTTP/TLS lacks bi-directional capability. Although Ajax and Comet technologies were considered as solutions, it was excluded from this figure after all. But at present, WebSocket protocol is available. It is based on HTTP and has a bi-directional capability. Although standardization of the protocol is still underway in IETF, there are already some implementations. For example, Jetty[Jetty], Kaazing[Kaazing], and Apache/pywebsocket are available as WebSocket servers. And, Chrome[Chrome] and FireFox[FireFox] are available as WebSocket clients. WebSocket protocol is expected to replace Ajax and Comet technologies, which are used widely in the current Web applications. And it can enable realtime communications between WebSocket servers Iijima, et al. Expires September 5, 2011 [Page 4] Internet-Draft NETCONF Notification over WebSocket Mar 2011 and clients. Thus, supporting WebSocket protocol for transporting NETCONF Notification will enable realtime event notification from an NETCONF server to NETCONF clients. Iijima, et al. Expires September 5, 2011 [Page 5] Internet-Draft NETCONF Notification over WebSocket Mar 2011 3. Use cases 3.1. Complementing NETCONF over SOAP/HTTP/TLS As mentioned in the previous chapter, SOAP was excluded from the transport protocol of NETCONF Notification. Therefore, when SOAP/ HTTP/TLS was used as a transport protocol of NETCONF messages, NETCONF Notification needs to be sent over BEEP, SSH, SSL, or console. But BEEP, SSH, SSL don't work closely enough to SOAP/HTTP/ TLS. On the other hand, WebSocket protocol is HTTP-based. SOAP and WebSocket can share HTTP. Both an exchange of NETCONF messages over SOAP/HTTP/TLS and NETCONF Notification over WebSocket are handled by one single HTTP daemon. This helps developers implement NETCONF Notification. 3.2. Using NETCONF in cloud computing Using WebSocket protocol is not necessarily limited to transporting NETCONF Notification. WebSocket protocol is used for exchanging NETCONF messages specified in RFC4741[RFC4741]. In fact, some vendors are implementing configuration mechanism which sends XML over HTTP. The part of HTTP can be easily replaced by WebSocket. By replacing HTTP by WebSocket, vendors can support configuration and notification mechanisms that are conducted on a single WebSocket connection. Furthermore, WebSocket is defining APIs[WebSocket API], which is tailored for JavaScript and is supported by several Web browsers. Currently, various APIs are available for controlling cloud resources and are provided on the assumption that they are used in Web environment. For example, DMTF (Distributed Management Task Force) is standardizing REST APIs in CMWG (Cloud Management Working Group) for controlling cloud resources[DMTF]. REST APIs is used in Web environement. Consequently, supporting WebSocket protocol as a transport protocol of NETCONF helps developers develop NETCONF clients that works together with cloud computing technologies. Iijima, et al. Expires September 5, 2011 [Page 6] Internet-Draft NETCONF Notification over WebSocket Mar 2011 4. WebSocket Messages for NETCONF Notifications This section specifies the messages exchanged between NETCONF server and an NETCONF client when WebSocket protocol is used for NETCONF Notification. 4.1. WebSocket Message from NETCONF client to NETCONF server WebSocket handshake is necessary before establishing an NETCONF session for NETCONF Notification. WebSocket handshake needs to be initiated by an NETCONF client. Figure 2 is an example of WebSocket message sent from an NETCONF client to an NETCONF server. C: GET /netconf HTTP/1.1 C: Host: netconfdevice C: Upgrade: websocket C: Connection: Upgrade C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== C: Sec-WebSocket-Origin: http://example.com C: Sec-WebSocket-Protocol: netconf Figure 2: WebSocket message from NETCONF client to NETCONF server As written in [I-D.ietf-hybi-thewebsocketprotocol], GET instead of POST needs to be specified in the WebSocket header. And, fields of 'Upgrade' and 'Connection' need to be specified as 'websocket' and 'Upgrade' respectively, so that an HTTP daemon residing in the NETCONF server understands that it needs to work as an WebSocket daemon. Futhremore, the field of 'Sec-WebSocket-Protocol' should be specified as 'netconf', so that the WebSocket daemon understands that it needs to hand over messages sent over this connection to the NETCONF server. In the case of using WebSocket API in Chrome or FireFox, for example, an establishment of WebSocket connection and specification of "netconf" is made by the following APIs. vas wsURL = "ws://" + host + "/netconf"; ws = new WebSocket(wsURL, "netconf"); Figure 3: WebSocket API for specifying protocol in NETCONF clients Iijima, et al. Expires September 5, 2011 [Page 7] Internet-Draft NETCONF Notification over WebSocket Mar 2011 4.2. WebSocket Message from NETCONF server to NETCONF client Figure 4 is an example of WebSocket message sent from an NETCONF server to an NETCONF client. S: HTTP/1.1 101 Switching Protocols S: Upgrade: websocket S: Connection: Upgrade S: Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= S: Sec-WebSocket-Nonce: AQIDBAUGBwgJCgsMDQ4PEC== S: Sec-WebSocket-Protocol: netconf Figure 4: WebSocket message from NETCONF server to NETCONF client In this case too, fields of 'Upgrade' and 'Connection' need to be specified as 'websocket' and 'Upgrade' respectively, in order to let the NETCONF client know that an HTTP daemon is running as the WebSocket daemon. Futhremore, the field of 'Sec-WebSocket-Protocol' should be specified as 'netconf', in order to let the NETCONF client know that the WebSocket daemon accepts NETCONF messages. Iijima, et al. Expires September 5, 2011 [Page 8] Internet-Draft NETCONF Notification over WebSocket Mar 2011 5. NETCONF Messages over WebSocket After above WebSocket handshake, an NETCONF client and an NETCONF server should start exchanges of NETCONF messages. In the case of NETCONF Notification, capability exchange between an NETCONF client and a server and subsequent subscription request from the NETCONF client to the server should be sent after WebSocket connection is established. During this period, HTTP header is unnecessary anymore. NETCONF messages as well as NETCONF Notifications should be encapusulated according to the Data Framing specified in WebSocket protocol[I-D.ietf-hybi-thewebsocketprotocol]. Iijima, et al. Expires September 5, 2011 [Page 9] Internet-Draft NETCONF Notification over WebSocket Mar 2011 6. Security Considerations The security considerations of [RFC4741] and [RFC5277] are applicable to this document. Implementers or users should take these considerations into account. Transport-level security, such as authentication of users and encryption of transport protocol, has to be ensured by TLS (Transport Layer Security). That is, security has to be provided in the form of NETCONF/WSS(WebSocket over TLS). Iijima, et al. Expires September 5, 2011 [Page 10] Internet-Draft NETCONF Notification over WebSocket Mar 2011 7. IANA Considerations This document has no actions for IANA. Iijima, et al. Expires September 5, 2011 [Page 11] Internet-Draft NETCONF Notification over WebSocket Mar 2011 8. Acknowledgements This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]. Iijima, et al. Expires September 5, 2011 [Page 12] Internet-Draft NETCONF Notification over WebSocket Mar 2011 9. References 9.1. Normative References [I-D.ietf-hybi-thewebsocketprotocol] Fette, I., "The WebSocket protocol", draft-ietf-hybi-thewebsocketprotocol-06 (work in progress), February 2011. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [WebSocket API] "The WebSocket API". 9.2. Informative References [Chrome] "Chrome". [DMTF] "CLOUD | DMTF". [FireFox] "FireFox". [I-D.moffitt-xmpp-over-websocket] Moffitt, J. and E. Cestari, "An XMPP Sub-protocol for WebSocket", draft-moffitt-xmpp-over-websocket-00 (work in progress), December 2010. [Jetty] "Jetty WebServer". [Kaazing] "Kaazing". Iijima, et al. Expires September 5, 2011 [Page 13] Internet-Draft NETCONF Notification over WebSocket Mar 2011 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Iijima, et al. Expires September 5, 2011 [Page 14] Internet-Draft NETCONF Notification over WebSocket Mar 2011 Authors' Addresses Tomoyuki Iijima Hitachi, Ltd. 292 Yoshida-cho, Totsuka-ku Yokohama, Kanagawa 244-0817 Japan Phone: +81-45-860-2156 Email: tomoyuki.iijima.fg@hitachi.com Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Hidemitsu Higuchi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: hidemitsu.higuchi@alaxala.com Iijima, et al. Expires September 5, 2011 [Page 15]