Internet DRAFT - draft-iijima-netconf-websocket-ps
draft-iijima-netconf-websocket-ps
NETCONF Working Group T. Iijima
Internet-Draft Hitachi, Ltd.
Intended status: Experimental H. Kimura
Expires: April 20, 2013 Y. Atarashi
H. Higuchi
Alaxala Networks Corp.
Oct 17, 2012
NETCONF over WebSocket
draft-iijima-netconf-websocket-ps-04
Abstract
This memo proposes a way of transporting NETCONF over WebSocket
protocol. Web-related technologies are advancing and number of Web-
based systems are increasing. Management systems that adopt Web-
related technologies or that have browser-based management interface
are getting common. It is natural to expect that there is a standard
network operation and management protocol to be used over HTTP.
Currently, however, there are few efforts in this area. Although
NETCONF[RFC6241] once defined itself to be sent over SOAP/
HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of
bi-directional capability, such efforts aren't successful
enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. But now,
WebSocket protocol, the update of HTTP equipped with bi-directional
capability, is available[RFC6455]. This memo describes how NETCONF
should be treated 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 April 20, 2013.
Copyright Notice
Iijima, et al. Expires April 20, 2013 [Page 1]
Internet-Draft NETCONF over WebSocket Oct 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Concerns about Using HTTP and WebSocket . . . . . . . . . . . 7
5. Handling of NETCONF Username . . . . . . . . . . . . . . . . . 8
6. Transporting NETCONF Messages over WebSocket Protocol . . . . 9
6.1. Message Sequence . . . . . . . . . . . . . . . . . . . . . 9
6.2. WebSocket Message at Handshake from NETCONF Client . . . . 11
6.3. WebSocket Message at Handshake from NETCONF Server . . . . 12
6.4. NETCONF Message over WebSocket at NETCONF Client . . . . . 12
6.5. NETCONF Message over WebSocket at NETCONF Server . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Iijima, et al. Expires April 20, 2013 [Page 2]
Internet-Draft NETCONF over WebSocket Oct 2012
1. Introduction
Web-related technologies are advancing and number of Web-based
systems are increasing. Management systems that adopt Web-related
technologies or have browser-based management interface are getting
common. It is natural to expect that there is a standard network
operation and management protocol to be sent over HTTP. Currently,
however, there are few efforts in this area and, in most cases,
management interface to be used over HTTP are proprietary. Although
NETCONF[RFC6241] once defined itself to be sent over SOAP/
HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of
bi-directional capability, such efforts didn't succeed well
enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. But now,
WebSocket protocol, the update of HTTP equipped with bi-directional
capability, is available[RFC6455]. This memo describes how NETCONF
should be exchanged over WebSocket protocol.
This memo does not intend to make WebSocket as a mandatory transport
protocol for NETCONF. NETCONF specifies that it is mandatory to be
sent over SSH[RFC6241]. But [RFC6241] also specifies in its section
2 that "the NETCONF protocol can be layered on any transport protocol
that provides the required set of functionality." According to the
specification, those required set of functionality are "Connection-
Oriented Operation" and "Authentication, Integrity, and
Confidentiality." WebSocket protocol meets those requirements. It
is 'connection-oriented.' And, as written in the section 10.5 of
[RFC6455], 'authentication' is ensured by mechanisms available to a
generic HTTP server, such as cookies, HTTP Authentication, or TLS.
Moreover, as written in the section 10.6 of [RFC6455], 'integrity and
confidentiality' are ensured by running WebSocket protocol over TLS.
For these reasons, WebSocket protocol coupled with TLS meets the
requirements of transport protocol for NETCONF.
Iijima, et al. Expires April 20, 2013 [Page 3]
Internet-Draft NETCONF over WebSocket Oct 2012
2. Problem Statement
Web-related technologies, such as JavaScript and JSON(JavaScript
Orient Notation), are widely used. And number of Web-based systems,
such as those provided for IaaS (Infrastructure as a Service), are
increasing. There are systems that are providing management
interface in a form of REST API(Application Programming Interface).
It is natural to expect that there is a standard network operation
and management protocol to be sent over HTTP. Currently, however,
there are few efforts in this area. And, in most of the cases,
management interface are proprietary.
NETCONF[RFC6241] once defined itself to be sent over SOAP/
HTTPS[RFC4743], as drawn in Figure 1. But, supposedly due to
unfamiliarity to SOAP or lack of bi-directional capability, such
efforts haven't been successful
enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic].
Layer Example
+-------------+ +-----------------+ +----------------+
(4) | Content | | Configuration | | Notification |
| | | data | | data |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------+ |
(3) | Operations | | <edit-config> | |
| | | | |
+-------------+ +-----------------+ |
| | |
+-------------+ +-----------------+ +----------------+
(2) | Messages | | <rpc>, | | <notification> |
| | | <rpc-reply> | | |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------------------------------+
(1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
| Transport | | |
+-------------+ +-----------------------------------------+
Figure 1: NETCONF Protocol Layers
As of now, however, WebSocket protocol is available[RFC6455]. It is
based on HTTP, which is familiar to all. And, it has a bi-
directional capability. Thus, by using WebSocket protocol, it's
possible to realize NETCONF that is used over HTTP with ease and that
supports notification mechanism specified in [RFC5277].
Iijima, et al. Expires April 20, 2013 [Page 4]
Internet-Draft NETCONF over WebSocket Oct 2012
Some WebSocket implementations already exist today. As examples of
WebSocket server implementation, Jetty[Jetty], Kaazing[Kaazing], and
the like are available. And, as examples of WebSocket client
implementation, Jetty[Jetty] is available. Moreover, as examples of
Web-browsers that can work as WebSocket client, Chrome[Chrome], and
FireFox[FireFox] and the like are available.
WebSocket server and client implementations mentioned above are
providing libraries. And WebSocket protocol itself also defines
API[WebSocket API] to be used on Web-browsers. Thus, by using those
libraries and APIs, developers can develop NETCONF server, install-
based NETCONF client, and browser-based NETCONF client with ease that
use WebSocket for transporting NETCONF.
Iijima, et al. Expires April 20, 2013 [Page 5]
Internet-Draft NETCONF over WebSocket Oct 2012
3. Use Case
XML, which NETCONF uses for message encoding, has high compatibility
with HTTP in that XML are easily manipulated on Web-browsers by
JavaScript DOM (Document Object Model) API. Hence, there are cases
in which XML is used over HTTP to manage network devices. But as far
as those XML are proprietary, the way of managing network devices and
items to manage are different from network device to network device.
If NETCONF, instead of proprietary XML, and its data models are used
for above cases, it will provide a way of managing various network
devices in a same manner.
Browser-based network management systems don't require installation
on computers. For this reason, some operators prefer browser-based
network management systems. This trend might accelerate in the age
of tablet computers. In this respect, it is rational for NETCONF to
have an option to be used through browser-based network management
system. Operators will be able to manage network devices from any
computers without installation.
Iijima, et al. Expires April 20, 2013 [Page 6]
Internet-Draft NETCONF over WebSocket Oct 2012
4. Concerns about Using HTTP and WebSocket
There are some drawbacks inherent in HTTP as mentioned in the section
2.4 of [RFC4743], which describes the way of transporting NETCONF
over SOAP/HTTPS. But, for these drawbacks, the same section makes
suggestions. Those suggestions are effective when WebSocket is used
for transporting NETCONF. That is, intermediate proxies SHOULD not
be used since it may close idle connections. And, the fields of
'Cache-Control' and 'Pragma' in HTTP header, which is sent before or
during WebSocket opening handshake, SHOULD be specified as 'no-
cache.'
WebSocket has had several security concerns. But it incorporated its
own security mechanisms such as origin header and masking, as stated
in the Security Considerations section of [RFC6455]. In any case,
using TLS is necessary for ensuring authentication and
confidentiality, when WebSocket is used for transporting NETCONF.
Iijima, et al. Expires April 20, 2013 [Page 7]
Internet-Draft NETCONF over WebSocket Oct 2012
5. Handling of NETCONF Username
NETCONF[RFC6241] mandates underlying transport protocol to carry
NETCONF username and to provide it to NETCONF server. In the case of
transporting NETCONF over WebSocket, this memo proposes that NETCONF
username SHOULD be carried and provided in compliance with NETCONF
over TLS[I-D.badra-netconf-rfc5539bis].
In the case of transporting NETCONF over WebSocket, TLS is necessary
for the user authentication. In order to ensure that NETCONF access
control is done consistently with TLS authentication, NETCONF
username SHOULD be matched with TLS authentication data. At present,
[I-D.badra-netconf-rfc5539bis] is proposing ways of extracting
NETCONF username from TLS authentication data. Being compliant with
these approaches is the most efficient. At least, it is confirmed
that NETCONF server using WebSocket/TLS for underlying protocol can
see TLS Certificate at the time of TLS handshake and can extract
NETCONF username from the Certificate.
Iijima, et al. Expires April 20, 2013 [Page 8]
Internet-Draft NETCONF over WebSocket Oct 2012
6. Transporting NETCONF Messages over WebSocket Protocol
This section specifies how NETCONF messages are exchanged between
NETCONF client and server over WebSocket protocol.
6.1. Message Sequence
Simplified overall message sequence is depicted in Figure 2. This
sequence is depicting the case in which NETCONF client runs on a Web-
browser. However, it must be noted that there is also a case in
which NETCONF client runs as an install-based software developed with
WebSocket client library.
+---------------------------+ +---------------------------+
| Network Management System | | Network Device |
| | | (e.g. 192.168.1.1) |
| +---------++-----------+ | | +-----------++---------+ |
| | NETCONF || WebSocket | | | | WebSocket || NETCONF | |
| | Client || (HTTP) | | | | (HTTP) || Server | |
| | || Client | | | | Server || | |
| +---------++-----------+ | | +-----------++---------+ |
+------|-----------|--------+ +--------|-----------|------+
| | | |
|Load *.html| | |
|---------->| Hello(TLS) | |
| / |------------------->| |
| | | Server Certificate | |
| TLS |<-------------------| |
| handshake | Client Certificate | |
| | |------------------->|NETCONF username
| | | Finished(TLS) |---------->|
| \ |<-------------------| |
| | | |
| | GET(HTTP) | |
| |------------------->| |
| | 200 OK(HTTP) | |
| |<-------------------| |
|<----------| | |
....
|Call WebSocket() API | |
|---------->| | |
| |Connection: Upgrade | |
| / |------------------->| |
| WebSocket |Connection: Upgrade | |
| opening |<-------------------| |
| handshake | ACK(TCP) | |
| \ |------------------->| |
Iijima, et al. Expires April 20, 2013 [Page 9]
Internet-Draft NETCONF over WebSocket Oct 2012
|Invoke onopen = function() { } | |
|<----------| | |
| | | |
|<hello>(NETCONF) | |
|---------->| | |
| |------------------->| |
| | |---------->|
| | | <hello> |
| | |<----------|
| |<-------------------| |
|<----------| | |
....
|<create-subscription>(NETCONF) | |
|---------->| | |
| |------------------->| |
| | |---------->|
| | | <ok> |
| | |<----------|
| |<-------------------| |
|<----------| | |
....
| | <notification>(NETCONF)|
| | |<----------|
| |<-------------------| |
|<----------| | |
| | | |
Figure 2: Message Sequence
First of all, a browser starts loading of an html file, which imports
the code of NETCONF client, over TLS. This invokes TLS handshake.
At the time of TLS handshake, NETCONF server can extract NETCONF
username from Certificate according to the algorithm described in
[I-D.badra-netconf-rfc5539bis]. After TLS handshake is complete, the
html file is loaded onto the browser.
The loaded html file works as NETCONF client and it initiates
WebSocket opening handshake. When NETCONF server receives a
WebSocket connection request, it notifies the client of whether
WebSocket handshake has succeeded. After WebSocket connection is
established, NETCONF client starts sending NETCONF messages over the
connection.
NETCONF <hello> messages are exchanged between NETCONF client and
server, at first, so that a NETCONF session is established and a
NETCONF session ID is allocated by NETCONF server to the NETCONF
client. Then, NETCONF <rpc> messages are exchanged. After NETCONF
Iijima, et al. Expires April 20, 2013 [Page 10]
Internet-Draft NETCONF over WebSocket Oct 2012
<rpc> message of <create-subscription> request is approved by the
NETCONF server, NETCONF <notification> messages are sent from NETCONF
server asynchronously.
When WebSocket server shuts down, NETCONF session as well as
WebSocket connection is killed. Since NETCONF notification
subscription is associated with NETCONF session ID as written in
section 3.5 of NETCONF notification mechanism[RFC5277], subscription
status is lost when WebSocket server shuts down. Thus, it is
necessary to redo WebSocket opening handshake, NETCONF session
establishment, and NETCONF notification subscription after WebSocket
server reboots.
Without any indications, TCP port numbers of 443 is automatically
used for transporting NETCONF messages over WebSocket over TLS. When
port number other than 443 needs to be used, the number SHOULD be
specified at both NETCONF client and server respectively.
6.2. WebSocket Message at Handshake from NETCONF Client
WebSocket opening handshake is necessary for the establishment of an
WebSocket connection, which is used for NETCONF message exchange.
The WebSocket handshake is initiated by a NETCONF client. Figure 3
is an example of WebSocket message sent from the NETCONF client at
the time of WebSocket handshake.
C: GET /netconf HTTP/1.1
C: Host: 192.168.1.1
C: Upgrade: websocket
C: Connection: Upgrade
C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
C: Origin: http://192.168.1.1
C: Sec-WebSocket-Protocol: netconf
C: Sec-WebSocket-Version: 13
Figure 3: WebSocket Message from NETCONF Client
Most of the fileds in Figure 3 are generated automatically by
WebSocket client. The only field that the NETCONF client needs to
specify is 'Sec-WebSocket-Protocol' field, so-called subprotocol
field. The NETCONF client has to specify the field as 'netconf,' for
example, so that the NETCONF server understands that messages sent
over this connection is directed towards NETCONF server.
Aforementioned establishment of the WebSocket connection and
specification of subprotocol is made by using WebSocket API in the
Iijima, et al. Expires April 20, 2013 [Page 11]
Internet-Draft NETCONF over WebSocket Oct 2012
html file of the NETCONF client as depicted in Figure 4.
var wssURL = "wss://" + location.host;
var wss = new WebSocket(wssURL, "netconf");
Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake
6.3. WebSocket Message at Handshake from NETCONF Server
Figure 5 is an example of WebSocket message sent from the NETCONF
server to the NETCONF client at the time of WebSocket handshake.
S: HTTP/1.1 101 Switching Protocols
S: Upgrade: websocket
S: Connection: Upgrade
S: Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
S: Sec-WebSocket-Protocol: netconf
Figure 5: WebSocket Message from NETCONF Server
Most of the fields in Figure 5 are generated automatically by
WebSocket server, too. The only field that the NETCONF server needs
to specify is 'Sec-WebSocket-Protocol' field. The NETCONF server has
to specify the field as 'netconf,' for example, in order to let the
NETCONF client know that the WebSocket server in the network device
accepts NETCONF messages.
Unlike the WebSocket client, there's no standardized WebSocket API
for WebSocket server. But, there are some WebSocket server
implementations as mentioned in section 2. Thus, it's possible to
develop a part of WebSocket opening handshake at NETCONF server with
ease by using libraries provided by those implementations.
6.4. NETCONF Message over WebSocket at NETCONF Client
NETCONF message exchange between NETCONF client and server starts
after an WebSocket connection is established. <hello> messages are
exchanged, first, for the establishment of a NETCONF session and
allocation of NETCONF session ID. Then, <rpc> messages like <edit-
config> are sent from NETCONF client to NETCONF server for NETCONF
configurations. And <rpc> messages like <create-subscription> are
sent from NETCONF client to NETCONF server for subscription of
NETCONF notification. Moreover, messages like <notification> are
sent asynchronously from NETCONF server to NETCONF client for NETCONF
Iijima, et al. Expires April 20, 2013 [Page 12]
Internet-Draft NETCONF over WebSocket Oct 2012
notification. During this data transfer period, both NETCONF
configuration messages and NETCONF notification messages are
encapsulated as a payload of WebSocket protocol according to the Data
Framing specified in the section 5.2 of WebSocket protocol[RFC6455].
This encapsulation is made by WebSocket layer.
Sending and receiving of NETCONF messages at NETCONF client is made
by using WebSocket API. The example is illustrated in Figure 6.
wss.onopen = function() {
// WebSocket connection has been established.
// Thus, NETCONF <hello> can be sent here
// by send() method.
wss.send("message to send");
....
};
wss.onmessage = function (evt) {
// NETCONF message has arrived.
// Thus, NETCONF message can be parsed here by DOM APIs.
var parser = new DOMParser();
var dom = parser.parseFromString(evt.data, "text/xml");
....
if(dom.documentElement.nodeName == "hello"){
// The NETCONF message turned out to be
// NETCONF <hello>.
// Subsequent NETCONF message can be sent here
// by send() method.
wss.send("message to send");
...
}
};
Figure 6: WebSocket API in NETCONF Client for Sending Messages
As shown in Figure 6, NETCONF messages are sent from NETCONF client
by using WebSocket API of "wss.send()." And, NETCONF messages are
received at NETCONF client by using WebSocket API of
"wss.onmessage()."
The contents of NETCONF messages exchanged through above API might be
either a hand-written XML messages typed into network management
system or XML messages created by JavaScript DOM API according to the
data set on the network management system. It must be noted that in
the case of transporting NETCONF over WebSocket, <rpc> parts need to
Iijima, et al. Expires April 20, 2013 [Page 13]
Internet-Draft NETCONF over WebSocket Oct 2012
be created by NETCONF client, unlike the case of transporting NETCONF
over SOAP/HTTPS, in which <rpc> parts are generated in SOAP layer.
6.5. NETCONF Message over WebSocket at NETCONF Server
Unlike the WebSocket client, the way of sending and receiving NETCONF
message at NETCONF server is proprietary since there's no
standardized API for WebSocket server. But, there are some WebSocket
server implementations as mentioned in section 2. Thus, it's
possible to develop NETCONF server with ease by using libraries
provided by those implementations.
Iijima, et al. Expires April 20, 2013 [Page 14]
Internet-Draft NETCONF over WebSocket Oct 2012
7. Security Considerations
It is necessary to use TLS (Transport Layer Security) in order to
ensure Transport-level security, such as authentication of users and
encryption of data transfer. That is, NETCONF has to be sent in the
form of NETCONF over WebSocket over TLS (WSS).
In addition, the security considerations of NETCONF
protocol[RFC6241], NETCONF Notification mechanism[RFC5277], and
WebSocket protocol[RFC6455] are applicable to this document.
Implementers or users SHOULD take these considerations into account.
Iijima, et al. Expires April 20, 2013 [Page 15]
Internet-Draft NETCONF over WebSocket Oct 2012
8. IANA Considerations
As written in section 11.5 of WebSokcet protocol[RFC6455], NETCONF's
Subprotocol Common Name, to be exchanged in 'Sec-WebSocket-Protocol'
field at WebSocket opening handshake, coupled with Identifier and
Definition need to be registered with the WebSocket Subprotocol Name
Registry.
Iijima, et al. Expires April 20, 2013 [Page 16]
Internet-Draft NETCONF over WebSocket Oct 2012
9. Acknowledgements
This document was written using the xml2rfc tool described in
[RFC2629].
Iijima, et al. Expires April 20, 2013 [Page 17]
Internet-Draft NETCONF over WebSocket Oct 2012
10. References
10.1. Normative References
[I-D.badra-netconf-rfc5539bis]
Badra, M., "NETCONF Over Transport Layer Security (TLS)",
draft-badra-netconf-rfc5539bis-02 (work in progress),
April 2012.
[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]
Wijnen, B., "RFC4743 and RFC4744 to Historic status",
draft-ietf-netconf-rfc4743-rfc4744-to-historic-00 (work in
progress), September 2012.
[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.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011.
[WebSocket API]
"The WebSocket API".
<http://dev.w3.org/html5/websockets/>
10.2. Informative References
[Chrome] "Chrome".
<http://www.google.com/chrome/?hl=en>
[FireFox] "FireFox".
<http://www.mozilla.org/>
[Jetty] "Jetty WebServer".
<http://jetty.codehaus.org/jetty/>
[Kaazing] "Kaazing".
Iijima, et al. Expires April 20, 2013 [Page 18]
Internet-Draft NETCONF over WebSocket Oct 2012
<http://kaazing.com/>
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Iijima, et al. Expires April 20, 2013 [Page 19]
Internet-Draft NETCONF over WebSocket Oct 2012
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
Hiroyasu Kimura
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: h-kimura@alaxala.net
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 April 20, 2013 [Page 20]
