Internet DRAFT - draft-higashiyama-eol2tp
draft-higashiyama-eol2tp
INTERNET DRAFT M. Higashiyama
Expires May 2002 Anritsu
November 2001
Ethernet Over L2TP (EoL2TP)
<draft-higashiyama-eol2tp-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] provides a standard
method for tunneling PPP sessions between a L2TP Access Concentrator
(LAC) and a L2TP Network Server (LNS).
This document defines the mechanism to tunnel Ethernet and IEEE 802.3
media access control (MAC) frames (including [IEEE 802.1Q] VLAN
datagrams) with L2TP.
Expires May 2002 [Page 1]
Internet Draft Ethernet Over L2TP November 2001
Table of Contents
1. Introduction .......................................... 2
2. Conventions ........................................... 3
3. Motivation ............................................ 3
4. EoL2TP framework ...................................... 3
4.1 What is EoL2TP? ................................. 3
4.2 Why use L2TP tunnels? ........................... 4
4.3 Why use PPP? .................................... 4
5. Models for network configuration ...................... 4
5.1 LAN to LAN connection ........................... 4
5.2 HOST to LAN model ............................... 8
5.3 Consideration for xDSL networks ................. 9
6. Requirements for EoL2TP ............................... 10
6.1 Scaling ......................................... 10
6.2 Redundancy and avoiding broadcast loops ......... 10
6.3 Flexibility ..................................... 10
6.4 Reliability ..................................... 11
7. BCP/L2TP versus Direct encapsulation .................. 11
7.1 Header Overhead in frames ....................... 11
7.2 Reliability ..................................... 12
8. Security Considerations ............................... 13
9. Intellectual Property Notice .......................... 13
References ................................................... 13
Authors' Addresses ........................................... 14
1. Introduction
L2TP [RFC2661] defines the procedures for tunneling PPP [RFC1661]
sessions between a so-called L2TP Access Concentrator (LAC) and a
L2TP Network Server (LNS).
BCP [RFC2878] defines the procedures for carrying Ethernet Frames on
PPP connections.
The combination of the two standards allows users to make a remote
connection from a host to a LAN or from a LAN to a LAN transparently.
This technology is used to tunnel Ethernet and IEEE 802.3 media
access control (MAC) frames (including [IEEE 802.1Q] VLAN datagrams)
with L2TP. In this document, we define this technology as Ethernet
over L2TP or EoL2TP.
The issues, requirements, architecture and network model of EoL2TP
are different from those of L2TP. This document intends to provide a
framework for EoL2TP and documents its issues, requirements,
architecture and network model.
Expires May 2002 [Page 2]
Internet Draft Ethernet Over L2TP November 2001
2. Conventions
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 [RFC2119].
3. Motivation
In an intranet, many kind of protocols are used such as DECNET, XNS,
AppleTalk, and Banyan. Some of these may be non-routed protocols, or
they may be protocols that users do not want to route for some
reason. In this situation, they want to bridge these protocols. If
the users's sites are in two different locations, the technology for
tunneling Ethernet frames is applied to connect two or more remote
sites. Tunneling Ethernet frames MAY provide one kind of Virtual
Private Network. But this motivation, usage, requirement,
architecture and network model are different from traditional VPNs.
Users often want to use Virtual LANs as defined in [IEEE 802.1Q]
because VLANs are widely used today and useful to multiplex traffic
from different LANs on one connection.
For this purpose, many tunneling technologies are described in IETF
documents, including "BCP: Bridge Control Protocol over PPP"
[RFC2878] and "Ethernet over ATM" [RFC1483]. Several others have
been proposed in IETF working groups.
Tunneling Ethernet frames over L2TP is usefull because L2TP is well-
designed to Tunneling multi-protocols over Internet or ATM network.
4. EoL2TP framework
4.1 What is EoL2TP?
EoL2TP is a technology that transports Ethernet Frame on L2TP
tunnels. The goal of EoL2TP is to make a connecteion between a
remote site or system and an LNS located at a local LAN via L2TP
tunnels. EoL2TP bridges packets between two different LANs
transparently and safely.
Expires May 2002 [Page 3]
Internet Draft Ethernet Over L2TP November 2001
The EoL2TP architecture model is illustrated in Fig 1.
+----------------------+
| MAC entity |
+----------------------+
| BCP |
+----------------------+
| PPP |
+----------------------+
| L2TP |
+----------------------+
Fig 1: EoL2TP architecture
4.2 Why use L2TP tunnels?
L2TP is the standard protocol that provides a mechanism for
aggregation of multiple Layer 2 connections across packet oriented
data networks. It is widely used to build Remote VPNs. EoL2TP works
on L2TP to provide mechanisms for security, aggregation, and a
multi-service framework.
4.3 Why use PPP?
There are many benefits from using PPP. PPP has LQM (Link Quality
Management) that allows the user to check the health of the path. PPP
has authentication, encryption and compression.
These PPP benefits bring flexibility and reliability to users.
5. Models for network configuration
This section describes some types of models of EoL2TP that we will
consider. The first model is a LAN to LAN connection. A LAN to LAN
connection provides connectivity for many-to-many communication. The
second model is a HOST to LAN connection. A HOST to LAN connection
provides connectivity for one-to-many communication.
5.1 LAN to LAN connection
A LAN to LAN connection assumes the scenario of connecting a remote
LAN to a central LAN. It MAY use a dial connection or a leased line
connection.
Expires May 2002 [Page 4]
Internet Draft Ethernet Over L2TP November 2001
-------------
--------- +-----+ ( ) +-----+ ---------
( Remote )---| NAS |---( IP Backbone )---| GW |---( Central )
( LAN ) +-----+ ( ) +-----+ ( LAN )
--------- ------------- ---------
In this model, we can consider two different types of scenarios. One
is compulsory tunneling and the other is voluntary tunneling.
5.1.1 LAN to LAN: Compulsory tunnel model
Compulsory tunneling refers to the model in which a network node or
gateway connects to a network access server acting as a LAC via a
dial connection or leased-line. The LAC entity in the access server
extends a PPP session across a backbone using L2TP to a remote LNS.
This operation is transparent to the user initiating the PPP session
to the LAC.
In the Compulsory tunneling model, there are a number of different
deployment scenarios possible. In one example, the remote bridge with
PPP is located at the customer edge. The customer edge device may be
a gateway that can act as a router and/or bridge. The PPP and BCP
entity is required on the gateway at the remote LAN in this case.
---------
--------- +----+ +-----+ ( ) +----+ ---------
( Remote )-| GW |----| NAS |---( IP )---| GW |----( Central )
( LAN ) +----+ +-----+ ( Backborn) +----+ ( LAN )
--------- --------- ---------
<---- L2TP Tunnel ----->
<-------------- PPP Session ------->
Fig 3: Compulsory Tunneling Example
Expires May 2002 [Page 5]
Internet Draft Ethernet Over L2TP November 2001
In the example shown in Fig 3, the gateway at the remote LAN is a MAC
bridge defined by [IEEE 802.1D]. The protocol stack of the gateway is
shown below:
Gateway or RAS
+------------------+
| MAC |
+---------+--------+
Gateway | BCP | |
+-------------+ +---------+ LAN |
| MAC | NAS | PPP | Phy |
+------+------+ +--------------+ +---------+ |
| LAN | BCP | | L2TP LAC | | L2TP LNS| |
| Phy +------+ +------+-------+ +---------+ |
| | PPP | | | IP/UDP| | IP/UDP | |
| +------+ | +-------+ +---------+ |
| | Media| | Media| Media | | Media | |
+------+------+ +------+-------+ +---------+--------+
| | | | | |
======= +---------+ +---- . . . --+ ========
Remote Access IP Backbone Central
LAN network LAN
Fig 4: Compulsory Tunneling protocol stack
5.1.2 LAN to LAN: Voluntary tunnel model
The L2TP specification has support for voluntary tunneling. In the
voluntary tunneling model, the LAC entity can be located on a host,
as well as on a network node. Note that such a host MAY have two IP
addresses: one for the LAC-LNS IP tunnel, and the other for the
network to which the host is connecting. If the user isn't running IP
over that tunneled PPP session, then he has no IP address there.
+----+
|Host|----- -------------
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
<-------------- L2TP Tunnel -------------->
with LAC on host
<-------------- PPP Session --------------> LNS on gateway
Fig 5: Voluntary Tunneling
Expires May 2002 [Page 6]
Internet Draft Ethernet Over L2TP November 2001
If we consider the EoL2TP application with voluntary tunneling, the
LAC and PPP entities are implemented on the remote bridge.
---------
--------- +----+ +-----+ ( ) +----+ ---------
( Remote )-| GW |----| NAS |---( IP )---| GW |----( Central )
( LAN ) +----+ +-----+ ( Backbone) +----+ ( LAN )
--------- --------- ---------
<-------------- L2TP Tunnel ------->
with
<-------------- PPP Session ------->
Fig 6: Voluntary Tunneling Example
In the example shown in Fig 6, the gateway at the remote LAN is a MAC
bridge defined by [IEEE 802.1D] and acts as a LAC. The protocol stack
of the gateway is shown below:
Gateway or RAS
+---------------+ +------------------+
| MAC | | MAC |
+------+--------+ +---------+--------+
| | BCP | | BCP | |
| +--------+ +---------+ LAN |
| | PPP | | PPP | Phy |
| +--------+ +---------+ |
| LAN |L2TP LAC| | L2TP LNS| |
| Phy +--------+ +--------------+ +---------+ |
| | IP/UDP | | IP | | IP/UDP | |
| +--------+ +------+-------| +---------+ |
| | Media | | Media| Media | | Media | |
+------+--------+ +------+-------+ +---------+--------+
| | | | | |
======== +-----------+ +---- . . . --+ ========
Remote Access IP Backbone Central
LAN network LAN
Fig 7: Compulsory Tunneling protocol stack
Expires May 2002 [Page 7]
Internet Draft Ethernet Over L2TP November 2001
5.2 HOST to LAN model
A HOST to LAN connection assumes the scenario of connecting a remote
host to a central LAN. It MAY use a dial connection or leased line
connection.
-------------
+------+ +-----+ ( ) +-----+ ---------
| HOST |-----| NAS |---( IP Backbone )---| GW |----( Central )
+------+ +-----+ ( ) +-----+ ( LAN )
------------- ---------
<---------------- L2TP Tunnel ------->
with
<---------------- PPP Session ------->
Fig 8: HOST to LAN Example
In this example, the PPP and BCP entity is located on the remote
host. The protocol stack of the model is shown below:
Remote host
+-----------------+
| IP/IPX/AppleTalk|
| SNA/Banyan/etc | Gateway or RAS
+-----------------+ +------------------+
| MAC | | MAC |
+-----------------+ +---------+--------+
| BCP | | BCP | |
+-----------------+ +---------+ LAN |
| PPP | | PPP | Phy |
+-----------------+ +---------+ |
| L2TP LAC | | L2TP LNS| |
+-----------------+ +--------------+ +---------+ |
| IP/UDP | | IP | | IP/UDP | |
+-----------------+ +------+-------| +---------+ |
| Media | | Media| Media | | Media | |
+------=----------+ +------+-------+ +---------+--------+
| | | | |
+-----------+ +---- . . . --+ ========
Access IP Backbone Central
network LAN
Fig 9: HOST to LAN protocol stack
Expires May 2002 [Page 8]
Internet Draft Ethernet Over L2TP November 2001
5.3 Consideration for xDSL networks
xDSL access networks are popular today. PPP is used in xDSL access.
The configuration and protocol stack are different from dial-up lines
and leased lines as we discussed in section 5.1 and 5.2. An xDSL
modem or xDSL router is used at the edge of the customer network.
Usually, hosts in the customer network connect with the xDSL modem or
xDSL router via Ethernet using PPPoE (Note: PPPoE is not standards-
track protocol). The xDSL line from the customer site is terminated
by DSL access multiplexers (DSLAM) at the provider edge. The DSLAM
forwards traffic to the ISP router. We assume several situations for
how the ISP router deals with traffic:
- ISP router terminates the PPP session.
- ISP router acts as L2TP LAC and tunnels traffic to the central
network.
The protocol stack architecture and a L2TP usage example are below:
Host ISP router
+-----+ +----------------+
| IP | xDSL modem | L2TP LAC |
+-----+ +------+----------+ +----------------+
| PPP | | | AAL5 | DSLAM | PPPoE | IP/UDP |
+-----+ |Ethernet---------+ +--------------+ +-------+--------+
|PPPoE| | | ATM | | ATM | | Ether | |
+-----+ | +----------+ +------+-------| +-------+ Media |
|Ether| | | xDSL | | xDSL | ATM | ATM/AAL5| |
+-----+ +------+----------+ +------+-------+ +-------+--------+
| | | | | | |
============= +-----------+ +--------+ +-----
Ethernet xDSL ATM IP backbone
diagram less useful. For PPPoE, it looks something like this:
We have many options to implement EoL2TP in the xDSL model. One
example shown in below expecting PPPoE will implement on xDSL router
and it function as a Bridge.
Expires May 2002 [Page 9]
Internet Draft Ethernet Over L2TP November 2001
xDSL router
+-----------------+
| MAC |
+------+----------+
| | BCP | ISP router
| +----------+ +----------------+
| | PPP | | L2TP LAC |
| LAN +----------+ +----------------+
| Phy | PPPoE | DSLAM | PPPoE | IP/UDP |
| +----------+ +--------------+ +-------+--------+
| | ATM | | ATM | | Ether | |
| +----------+ +------+-------| +-------+ Media |
| | xDSL | | xDSL | ATM | ATM/AAL5| |
+------+----------+ +------+-------+ +-------+--------+
| | | | | |
===== +-----------+ +--------+ +-------
xDSL ATM IP backbone
6. Requirements for EoL2TP
6.1 Scaling
The device interconnecting LAN and tunneled network using BCP in
EoL2TP framework MUST act as a MAC Bridge defined in [IEEE 802.1D].
To achieve connection of several tens or hundred of LANs, scalability
SHOULD be considered. Especially for Layer 2 connections, the
implementation SHOULD support efficiency for traffic. The learning
and filtering is required for implementation to avoid flooding
unnecessary forwarding traffic across the Internet.
6.2 Redundancy and avoiding broadcast loops
The device interconnecting LAN and tunneled network using BCP in
EoL2TP framework SHOULD act as a MAC Bridge defined in [IEEE 802.1D].
The Spanning Tree Protocol allows the administrator to configure the
network with redundant links while avoiding accidental forwarding
loops.
6.3 Compatibility
The device interconnecting a LAN and a tunneled network using BCP in
EoL2TP framework MUST support 802.1Q. And EoL2TP SHOULD be
independent from future changes to the IEEE 802.1 standards. For
this reason, existing protocols that already track the IEEE standards
are preferred.
Expires May 2002 [Page 10]
Internet Draft Ethernet Over L2TP November 2001
The compatibility to the IEEE 802.1 standards allow many
administrators understand it and know how to use it.
6.4 Reliability
EoL2TP implementation is RECOMMENDED to support PPP LQM. The LQM
allows EoL2TP to fail over in the case where there are redundant
paths with Spanning Tree Protocol or Link Aggregation.
7. BCP/L2TP versus Direct encapsulation
There was an alternate idea that allowed binding an Ethernet frame on
a L2TP message field directly without a PPP header. It is in a work-
in-progress. We call this "Direct encapsulation".
7.1 Header Overhead in frames
A frame format of EoL2TP (with ACFC and PFC enabled and F bit set to
0) looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x31 |0|0|Z|0| Pads | MAC Type | Dest MAC Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest MAC Addr | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires May 2002 [Page 11]
Internet Draft Ethernet Over L2TP November 2001
A frame format of "Direct encapsulation" looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EoL2TP has an added overhead of three octets compared to "Direct
Encapsulation". In the case of a 64 byte minimum packet size, EoL2TP
adds at most 3.8 percent overhead, which is very small. In addition,
if it is not necessary to carry the LAN FCS end to end, the LAN FCS
field in the BCP of EoL2TP is optional. This option can remove the
four octets of LAN FCS, so the result is one octet shorter than
"Direct Encapsulation".
In addition, BCP allows Tinygram compression. This means that EoL2TP
packets with Tinygram compression are more efficient than "Direct
encapsulation" packets.
The many PPP and BCP options that are available bring many benefits
to EoL2TP.
7.2 Reliability
EoL2TP uses a PPP framework, so the PPP LQM is available in EoL2TP.
The LQM allows EoL2TP to fail over in the case where there are
redundant paths with Spanning Tree Protocol or Link Aggregation.
Expires May 2002 [Page 12]
Internet Draft Ethernet Over L2TP November 2001
8. Security Considerations
EoL2TP does not define any specific security mechanism but instead
relies PPP and L2TP. This means security mechanisms in PPP such as
PAP/CHAP/ECP are applicable on EoL2TP. Tunnel authentication of L2TP
is also applicable. Data encryption can be established by IPsec in
the case of L2TP over UDP/IP.
9. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunneling Protocol "L2TP" ",
RFC2661, August 1999.
[IEEE 802.1D] IEEE 802.1D-1998, "Information technology -
Telecommunications and Information exchange between
systems - Local and metropolitan area networks - Common
Specifications - Part 3: Media Access Control (MAC)
Bridges: Revision. This is a revision of ISO/IEC 10038:
1993, 802.1j-1992 and 802.6k-1992. It incorporates
P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.
Expires May 2002 [Page 13]
Internet Draft Ethernet Over L2TP November 2001
[IEEE 802.1Q] IEEE 802.1Q, ANSI/IEEE Standard 802.1Q, "IEEE Standards
for Local and Metropolitan Area Networks: Virtual
Bridged Local Area Networks", 1998.
[RFC2878] Mitsuru H. and Baker, "PPP Bridging Control Protocol
(BCP)", RFC 2878, July 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, Telecom Finland, July
1993.
Authors' Addresses
Mitsuru Higashiyama
Anritsu Corporation
1800 Onna, Atsugi-shi, Kanagawa-prf., 243-8555 Japan
Phone: +81 (46) 296-6625
EMail: Mitsuru.Higashiyama@yy.anritsu.co.jp
Expires May 2002 [Page 14]
