Internet DRAFT - draft-ishikawa-ion-mcatm-mlis
draft-ishikawa-ion-mcatm-mlis
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:16:28 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 09 Aug 1997 03:39:09 GMT
ETag: "2e6d8b-7950-33ebe65d"
Accept-Ranges: bytes
Content-Length: 31056
Connection: close
Content-Type: text/plain
INTERNET-DRAFT Norihiro Ishikawa
Expires: January 1998 NTT
July, 1997
IP Multicast over ATM MLIS using ATM Multicast Routers
<draft-ishikawa-ion-mcatm-mlis-00.txt>
Status of this Memo
This document is an Internet-Draft. 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".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes the specification for IP multicast over ATM
MLIS using ATM multicast routers. This memo specifies the protocol
for providing the functions of IGMP [1] over the ATM networks.
This is the simplest approach among various proposals for IP
multicast over the ATM networks including MARS [2], and it is easy
to implement this specification compared with other proposals.
Ishikawa Expires January 1998 [Page 1]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
1. Introduction
This memo describes the specification for IP multicast over ATM MLIS
(Multicast Logical IP Subnetwork) using ATM multicast routers. The
requirements for this specification for IP multicasting over ATM
MLIS are as follows:
- To interwork with the MBONE (an experimental multicasting network on
the Internet), the specification should be compatible with the basic
specifications for IP multicasting such as RFC 1112 [1] and the
multicast routing protocols such as RFC 1075 [3]. It should also
interwork with routers and hosts in which such specifications are
implemented.
- To be compatible with RFC 1112 on the service interface level with
upper-layer protocol modules so that the existing multicast
applications can operate over ATM networks.
- To accomplish IP multicasting over ATM networks efficiently, the
specification should be able to effectively use the point-to-
multipoint connection that ATM networks provide.
- It should be compatible with the specifications for IP over ATM
networks such as RFC 1577 [4] and RFC1755 [5] and be able to use
these protocols when necessary.
As a mechanism to satisfy above requirements, this memo describes the
specification for IP multicasting over ATM MLIS using ATM multicast
routers.
This memo assumes that "The ATM Forum UNI Specification, V 3.0/3.1" is
used as the interface with ATM networks.
2. Model
A model for IP multicasting over ATM MLIS using ATM multicast routers
is described below.
A sending host sends multicast IP datagrams to an ATM multicast
router, using an ATM point-to-point connection. An ATM multicast
router distributes received multicast IP datagrams toward multiple
receiving hosts, using an ATM point-to-multipoint connection.
A receiving host receives multicast IP datagrams from an ATM
multicast router. An ATM multicast router may send received multicast
IP datagrams to existing IP multicast networks such as MBone, if it
has an existing router function (e.g. by implementing RFC 1075).
When an ATM multicast router with the existing router functions has
interfaces with both ATM networks and the existing LANs such as
Ethernet, the IP multicast communication between those networks
becomes possible.
Ishikawa Expires January 1998 [Page 2]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
3. Overview of IP Multicasting
The overview of IP multicasting specified in RFC 1112 is described
below.
The purpose of IP multicasting is to transfer IP datagrams to host
groups (0 or more hosts identified by a single IP destination
address). Multicast IP datagrams are transferred to all hosts in the
host group. The membership of a host group is dynamic; that is, hosts
may join or leave groups at any time. A multicast IP datagram is
transferred to other networks by a multicast router in the same way
as regular IP datagrams.
There are three levels in the implementation of IP multicasting in
hosts.
(1) Level 0: no support for IP multicasting.
There is obviously no requirement regarding the support. Level 0
hosts discard multicast IP datagrams with class D destination
addresses.
(2) Level 1: support for sending multicast IP datagrams only.
Implementations of Level 1 hosts are relatively easy.
(3) Level 2: full support for IP multicasting.
Level 2 hosts can join or leave host groups. Implementation of
the IGMP (Internet Group Management Protocol) is required.
Host groups are identified by class D IP addresses, i.e., those
starting with 110 Class D IP addresses range from 224.0.0.0
to 239.255.255.255. The address of 224.0.0.0, however, is not
assigned to any group. The address of 224.0.0.1 is always assigned
to a group that includes all hosts in the subnetwork.
4. Overview of Point-to-Multipoint Connection of ATM Networks
The overview of the point-to-multipoint connection specified in the
ATM Forum UNI 3.0/3.1 is described below.
The following restrictions apply in the point-to-multipoint
connection specified in the ATM Forum UNI 3.0/3.1.
- Only a root can set up a point-to-multipoint connection and add
a leaf.
- ATM cells are transferred from the root to the leaves only.
Ishikawa Expires January 1998 [Page 3]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
The specification for IP multicasting over ATM MLIS should be designed
based on the above restrictions.
NOTE: These restrictions may be relaxed in future versions of the
ATM Forum UNI.
The setup and release procedures of the point-to-multipoint connection
are as follows.
(1) The first connection from the root to the leaf is set using a SET
UP/CONNECT message as in the point-to-point connection.
(2) After that, the root can add new leaves at any time using an ADD
PARTY/ADD PARTY RESPONSE message.
(3) The root or leaf can delete new leaves at any time using a DROP
PARTY/DROP PARTY RESPONSE message.
5. Implementation Model
The implementation model of the IP multicasting over ATM MLIS on a
host and an ATM multicast router is shown below. This model is for
expository purpose only, and should not be construed as
constrainind an actual implementation.
| |
| Upper-Layer Protocol Modules |
|______________________________________________________|
--------------- IP Service Interface -----------------------
_______________________________________________________
| | | |
| | ICMP | IGMP-ATM |
| IP |___________|_______________|
| Modules |
|_____________________________________________________|
------------- ATM Service Interface ------------------------
_______________________________________________________
| | | |
| RFC 1577 (IP/ATM | RFC 1755 (ATM | RFC 1483 (IP |
| Address Resolution) | Signalling | Encapsulation)|
|_____________________________________________________|
| |
| ATM |
Ishikawa Expires January 1998 [Page 4]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
The IGMP-ATM is a protocol for IP multicasting over ATM MLIS, based on
IGMP. RFC 1577 is used to resolve IP addresses to ATM addresses. The
LLC encapsulation specified in RFC 1483 is used for IP encapsulation
over ATM networks.
Level 1 hosts must be implemented with the transmission of multicast
IP datagrams. In addition, Level 2 hosts and ATM multicast routers
must be implemented with the reception of multicast IP datagrams.
The transmission and reception procedures of multicast IP datagrams
are described below.
6. Transmission Procedures of Multicast IP Datagrams
The transmission procedures of multicast IP datagrams are the same
as in unicast IP datagrams from the point of view of the upper-layer
protocol module. When transmitting a multicast IP datagram, upper-
layer protocol modules designate a class D IP address identifying
a host group as a destination address.
The IP module of the sending host that has received a request to
transmit a multicast IP datagram sends a multicast IP datagram in the
following procedure:
(1) The ATM address is resolved from the IP address of an ATM
multicast router in the following procedure:
(a) The ATM address is resolved from the IP address by accessing
to the ATMARP server according to RFC 1577.
(2) When a VCC for data transfer has not been set with an ATM
multicast router, a VCC for data transfer will be set
between the sending host and the ATM multicast router using
the ATM address of the ATM multicast router.
(3) A multicast IP datagram is sent using the VCC for data transfer.
If the sending host is also an ATM multicast router, it omits the above
procedure and executes the following:
Ishikawa Expires January 1998 [Page 5]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
The operation of the IP module of the ATM multicast router that has
received a multicast IP datagram from a sending host or a request
to transmit a multicast IP datagram from an upper-layer protocol
module is as follows:
(1) The IP module retrieves the conversion table of the destination
address of the multicast IP datagram (that is, the class D address
that identifies the host group) and the VCC for data transfer,
in order to check whether the VCC for data transfer that transfer
the received multicast IP datagram has been set up.
(2) If the VCC for data transfer has been set up, the multicast IP
datagram will be sent by using the VCC. If the VCC for data
transfer has not been set up, the multicast IP datagram will be
discarded.
NOTE: When there are more than one VCCs for the transfer of the
multicast IP datagram, the multicast IP datagram will be
sent to each of them.
The multicast IP datagram will be locally looped back only when the
sending host is an ATM multicast router and a receiving host at the
same time.
NOTE: When the sending host is also a receiving host but not an ATM
multicast router, the multicast IP datagram will not be
locally looped back. Instead, the transmitted multicast IP
datagram is received from the ATM multicast router.
In addition, when the ATM multicast router also has an existing
multicast router function (e.g. by implementing RFC 1075), it may
send a multicast IP datagram to existing IP multicast networks,
according to the specification for routing of multicast IP
datagrams (e.g. RFC 1075).
NOTE: The specification of interworking with existing IP multicast
networks is out of the scope of this memo.
7. Reception Procedures of Multicast IP Datagrams
The reception procedures of multicast IP datagrams are the same as
in unicast IP datagrams from the point of view of the upper-layer
protocol module. Selection of the upper layer protocol is based on
the protocol field in the IP header, regardless of the IP destination
address. However, before any multicast IP datagrams are received,
an upper-layer protocol must notify the IP module that it will join
the host group. Thus, the IP service interface must be extended to
provide two operations:
- JoinHostGroup (group-address, ATM interface)
- LeaveHostGroup (group-address, ATM interface)
Ishikawa Expires January 1998 [Page 6]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
The JoinHostGroup operation requests that this host becomes a member
of the host group identified by the group-address on the ATM
interface. More than one high layer protocols may request to become
members of the same host group. The LeaveHostGroup operation requests
that this host give up its membership in the host group identified by
the group-address on the ATM interface.
Both operations should return immediately (i.e., they are non-blocking
operations), indicating success or failure. They may fail due to an
invalid group-address or ATM interface. The JoinHostGroup operation
may fail due to lack of local or remote resources. The LeaveHostGroup
operation fails when the receiving host does not belong to the host
group identified by the given group-address on the ATM interface.
The IP module of the receiving host should keep the list of host groups
on each ATM interface to support the reception of multicast IP
datagrams. When a received multicast IP datagram has a destination
address that is not registered in the list of host groups, it will be
discarded. When a eceived multicast IP datagram has a class D IP
address identifies the host group as the source IP address, it will be
discarded. In this case, an ICMP error message will not be generated
as a response.
The list of host groups is updated in response to JoinHostGroup and
LeaveHostGroup requests from upper-layer protocol modules. Each host
group has a counter mechanism to handle multiple requests to join and
leave the same group. The value of the counter increases by one when
a JoinHostGroup request is received and decreases by one when a
LeaveHostGroup request is received. When the value of the counter
becomes zero, the host group will be deleted from the list.
The operation of the IP module that has received a JoinHostGroup
request is as follows:
(1) The IP module will increase the value of the counter by one and
end the operation if the host group that is identified by the
group-address already exists in the list.
(2) The operation in the case where the host group that is identified
by the group-address does not exist in the list is as follows:
(3) When a VCC for control is not set up with the ATM multicast
router, the IP module will set up a VCC for control between the
receiving host and the ATM multicast router by using the ATM
address of the ATM multicast router.
Ishikawa Expires January 1998 [Page 7]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
NOTE: The resolution procedure of the IP address of the ATM
multicast router into its ATM address is the same as the
the procedure specified in section 6.
(4) The IP module sends a Join message of the IGMP-ATM specified in
section 8 using the VCC for control.
(5) The IP module adds the host group that is identified by the
group-address to the list and sets the value of the counter to 1.
The operation of the IP module that has received a LeaveHostGroup
request is as follows:
(1) The IP module decreases the value of the counter of the host
group that is identified by the group-address by one. If the value
of the counter is one or larger, the operation ends here.
(2) The operation in the case where the value of the counter becomes 0
is as follows:
(3) The IP module sends a Host Membership Leave message of the
IGMP-ATM specified in section 8 using the VCC for control.
(4) It deletes the host group that is identified by the group-address
from the list.
(5) When the number of members included in the list becomes zero, the
VCC for control may be released.
NOTE: Whether the VCC for control should be released or not shall
be locally determined by the receiving host.
The ATM multicast router manages the list of the IP addresses of the
hosts joined in the host group for each host group.
The operation of the ATM multicast router that has received a Join
message of the IGMP-ATM is as follows:
(1) The ATM multicast router retrieves the conversion table of the
group-address (i.e. the class D IP address that identifies the
host group) and the VCC for data transfer, in order to check
whether the VCC for data transfer corresponding to the received
group-address exists
Ishikawa Expires January 1998 [Page 8]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
(2) If the VCC for data transfer exists, the ATM multicast router
adds the receiving host as a leaf of the VCC for data transfer
by using the ADD PARTY/ADD PARTY ACK procedure. It also adds
the IP address of the receiving host to the list of the IP
addresses of the hosts that have joined the host group identified
by the received group address.
NOTE: It may set up a new VCC for data transfer for such reasons
as the QOS control.
(3) If the VCC for data transfer does not exist, the ATM multicast
router sets up a VCC for data transfer between the ATM multicast
router and the receiving host by using the ATM address of the
receiving host.
NOTE: The VCC shall be a point-to-multipoint connection.
(4) If the setup of the VCC for data transfer succeeds, the ATM
multicast router sends a Join Ack message of the IGMP-ATM to the
receiving host and adds the relation of the group address with
the VCC for data transfer to the conversion table. It creates a
list of the IP addresses of the hosts that have joined the host
group and adds the IP address of the receiving host to it.
(5) If the setup of the VCC for data transfer fails due to some
reason (e.g. lack of resources etc.), the ATM multicast router
sends a Join Nak message of the IGMP-ATM to the receiving host.
The operation of the ATM multicast router that has received a Host
Membership Leave message of the IGMP-ATM is as follows:
(1) The ATM multicast router deletes the leaf to the receiving host
from the VCC for data transfer that is set up for the received
group address, by using the DROP PARTY/DROP PARTY ACK
procedure.
(2) The ATM multicast router deletes the IP address of the
receiving host from the list of the IP addresses of the hosts
that have joined the host group identified by the received
group-address.
(3) If the number of members in the list becomes zero as a result,
the ATM multicast router deletes the list and releases the VCC
for data transfer. It also deletes the the relation of the
group-address with the VCC for data transfer from the conversion
table.
NOTE: The above is the operation in the case where all leaves are
deleted from the VCC for data transfer.
Ishikawa Expires January 1998 [Page 9]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
8. Protocol Specification (IGMP-ATM)
The protocol (IGMP-ATM) used for IP multicasting over ATM MLIS using
the ATM multicast router is described below. IGMP-ATM is a protocol
for IP multicasting over ATM MLIS, based on IGMP specified in RFC
1112 and hence compatible with IGMP.
IGMP-ATM is used between receiving hosts and ATM multicast routers.
Therefore, Level 2 hosts and ATM multicast routers must implement
IGMP-ATM. IGMP-ATM messages are encapsulated in IP datagrams, with an
IP protocol number of 2 as in IGMP.
8.1 Format of IGMP-ATM Messages
The format of IGMP-ATM messages is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Unused | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1) Version
The version of this specification shall be ?.
(2) Type
The types of IGMP-ATM messages are as follows:
2= Host Membership Join
3= Join Ack
4= Join Nak
5= Host Membership Leave
NOTE: The Host Membership Join (2) is called the Host Membership
Report (2) in IGMP specified in RFC 1112.
(3) Unused
Unused field, zeroed when sent, ignored when received.
(4) Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the IGMP-ATM message. For computing
the checksum, the checksum field is zeroed.
Ishikawa Expires January 1998 [Page 10]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
(5) Group Address
In the case of Host Membership Join (2), the address of the host
group requesting the receiving host to join will be set. In the
case of Join Ack (3) and Join Nak (4), the address of the host
group requested to join by the receiving host will be set. In the
case of Host Membership Leave (5), the address of the host group
requesting the receiving host to leave will be set.
(6) Reason
The reason why joining a host group has failed. This field
(including unused) exists in the case of Join Nak (4) only.
1= Not specified
2= Lack of resources at the ATM multicast router
3= Data of this group-address not received at the ATM multicast
router
4= Authentication of the receiving host has failed.
NOTE: Other values may be defined in future.
(7) Options
The following optional parameters may be set following the
fixed parameters described above. The format of the optional
parameters is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option1 | Option2 | ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thus, padding is added in the end, in order to complete them
in 32-bit boundary. The value of padding is zero.
The format of each optional parameter is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Data Length | Option Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type: An 8-bit identifier of the option type
Option Data Length: Length of the option data in octet
(8 bits)
Option Data: Data specific to each option with
variable length
Ishikawa Expires January 1998 [Page 11]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
The following optional parameters are specified in this memo.
(a) Authentication
This parameter is used to authenticate receiving hosts
and users on them. This parameter can only be used in
the case of Host Membership Join (2).
Option Type: 1
The format of the option data is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Type: An 8-bit identifier of the type of
authentication
Authentication Data: Data specific to each authentication
type with variable length
NOTE: The definition of specific authentication types
is for further study.
8.2 Operation of the Protocol
The IP module of the receiving host that has received a
JoinHostGroup request transmits a Join message to the ATM multicast
router. The IP address of the ATM multicast router is set in the IP
destination address. The address of the host group which the
receiving host requests to join is set in the Group Address
field of the Join message.
The ATM multicast router that has received a Join message sends a
Join Ack message to the receiving host that has transmitted the
Join message, if it succeeds to set up a VCC for data transfer.
It sends a Join Nak message to the receiving host, if it fails to
set up a VCC for data transfer. The IP address of the receiving
host that has transmitted the Join message is set in the IP
destination address field. The same value as that of the Group
Address field in the received Join message is set in the Group
Address field of the Join Ack/Join Nak message. The reason why the
setting of the VCC for data transfer has failed is set in the
Reason field of the Join Nak message.
The ATM multicast router fails to set up a VCC for data transfer
in the following cases:
Ishikawa Expires January 1998 [Page 12]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
- The ATM multicast router could not get enough resources necessary
to set up a VCC for data transfer
- The ATM multicast router could not receive the data toward the
designated group address.
- Authentication of the receiving host failed.
etc
The IP module of the receiving host that has received a
LeaveHostGroup request sends a Host Membership Leave message to the
ATM multicast router. The IP address of the ATM multicast router is
set in its IP destination address field. The address of the host group
which the receiving host requests to leave is set in the Group Address
field of the Host Membership Leave message.
When invalid IGMP-ATM messages as shown below are received, they will
be discarded:
- IGMP-ATM messages with invalid fields
- IGMP-ATM messages received in invalid conditions
9. Security Considerations
The authentication parameter is added to the Host Membership Join
message, so that unauthorized receiving hosts can not join the host
group.
However, the definition of the format of the authentication
parameter for the specific authentication mechanism is for
further study.
Ishikawa Expires January 1998 [Page 13]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
Appendix 1: Differences between IGMP and IGMP-ATM
This appendix describes major differences between IGMP and IGMP-ATM.
(1) Sending and receiving of IP multicast datagrams via an ATM
multicast router
Since IGMP is designed assuming that shared media LANs such as
Ethernet is usually used, a receiving host receives IP multicast
datagrams directly from a sending host on the same local network.
A sending host sends IP multicast datagrams to receiving hosts
via an ATM multicast router in IGMP-ATM, even if receiving hosts
reside on the same MLIS as the sending host. IGMP-ATM does not
support the multicast VC mesh, because the multicast VC mesh
lacks the scalability.
(2) Hard state approach vs Soft state approach
Since IGMP adopts the soft state approach, a multicast router
sends Host Membership Query messages periodically using the
all-hosts group (address 224.0.0.1), to discover which host
groups have members on its attached local network.
Since ATM is a connection oriented network, IGMP-ATM adopts the
hard state approach. IGMP-ATM does not send Host Membership
Query messages. Instead, IGMP-ATM manages receiving hosts on
the attached ATM network, based on the reception of Host
Membership Join messages and Host Membership Leave messages
from receiving hosts.
(3) Authentication of receiving hosts
IGMP does not provide any security functions. IGMP-ATM defines
the authentication parameter as an option parameter of the
Host Membership Join message, so that unauthorized receiving
hosts can not join the host group.
Ishikawa Expires January 1998 [Page 14]
INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997
References
[1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[2] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
ATM Networks", RFC 2022, Bellcore, November 1996.
[3] D. Waitzman, C. Partridge, S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[4] M. Laubach, "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, December 1993.
[5] M. Perez, F. Liaw, D. Grossman, A. Mankin, E. Hoffman,
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755
February 1995.
Acknowledgements
The author would like to thank Brian Carpenter and Yakov
Rekhter for their comments and suggestions.
Authors' Address:
Norihiro Ishikawa
NTT Information and Communication Systems Laboratory
1-1 Hikarino-oka Yokosuka-Shi
Kanagawa 239 Japan
isic@isl.ntt.co.jp
+81 468 59 2434 (tel)
+81 468 59 3796 (fax)
Ishikawa Expires January 1998 [Page 15]
