INTERNET-DRAFT T. Ogura
Expires: September 2004 M. Maruyama
NTT Network Innovation Labs
T. Yoshida
Werk Mikro Systems
March 2004
A Multicast Extension to MAPOS NSP (Node Switch Protocol)
<draft-ogura-mapos-nsp-multiexp-03.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited. Please send comments to the
authors <ogura@core.ecl.net> <mitsuru@core.ecl.net> and
<yoshida@peta.arch.ecl.net>.
Abstract
Multiple Access Protocol over SONET/SDH (MAPOS) is a link-layer
protocol for transmitting network-layer datagrams encapsulated in
High-Level Data Link Control (HDLC) frames over Synchronous Optical
NETwork/Synchronous Digital Hierarchy (SONET/SDH).
This document describes an extension to the Node Switch Protocol
(NSP) of MAPOS. NSP is a protocol for automatically assigning
addresses to MAPOS network interfaces of nodes. The extension NSP+
enables the nodes to provide their directly connected switches with
information about the multicast groups to which the MAPOS network
Ogura, et al. Expires September 2004 [Page 1]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
interfaces of the nodes belong, so a switch forwards only required
multicast frames to the network interfaces.
1. Introduction
Multiple Access Protocol over SONET/SDH (MAPOS) [1][2] is a
link-layer protocol for transmitting High-Level Data Link Control
(HDLC) frames over SONET/SDH [6][7]. In MAPOS, HDLC frames (MAPOS
frames) are switched according to their destination addresses and
eventually delivered to the destination network interfaces of nodes.
(The term "nodes" means components other than switches in MAPOS
networks; nodes are usually hosts or IP routers.)
In addition to unicasting, MAPOS also supports multicasting. Namely,
the destination address field of an HDLC frame can include a
multicast address which indicates that the frame must be delivered to
one or more network interfaces of nodes. Conventionally, even when an
optimized multicast transmission tree had been built in the network
layer (layer 3), MAPOS switches forwarded multicast frames to all
ports except for receiving ports regardless of their destination
addresses because there were no specifications to restrict
unnecessary multicast-frame transmission in MAPOS. However, it is
preferable for the switches to forward multicast frames only to ports
to which the frames really need to be forwarded, instead of flooding
all ports with them.
This document describes NSP+, which eliminates unnecessary
multicast-frame transmission between a MAPOS switch and its directly
connected nodes. Similar to NSP [3], NSP+ is a protocol which enables
addresses to be automatically assigned to each MAPOS network
interface of nodes. In addition, NSP+ enables nodes to provide their
directly connected switches with information about the multicast
groups to which the MAPOS network interfaces of the nodes belong, so
a switch forwards only required multicast frames to the network
interfaces.
In the remainder of this document, the term "MAPOS" is used unless the
distinction between MAPOS version 1 [1] and MAPOS 16 [2] is required.
2. NSP+
2.1 Overview
Similar to NSP, NSP+ provides an automatic network-interface address
assignment function in MAPOS. It reduces the administrative burden of
network-interface address configuration and prevents trouble such as
address inconsistency and collision. When a MAPOS network interface
of a node is connected to a switch and receives a SONET signal
Ogura, et al. Expires September 2004 [Page 2]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
correctly, the node sends an address request frame from the network
interface to the control processor in the switch; the destination
address of this frame is 0x01 (MAPOS version 1) [1] or 0x0001 (MAPOS
16) [2].
NSP+ differs from NSP in that an optional multicast field can be
included in the address request frame. The multicast field contains a
complete set of multicast MAPOS addresses derived from all the
addresses of the network-layer multicast groups to which the network
interface sending the address request frame belongs. (Device
controller or operating system software usually holds such a set of
link-layer multicast addresses on each network interface.)
When the switch receives the address request frame, it replies with
an address assignment frame. The address assignment frame is exactly
the same as that of NSP, i.e., it includes the assigned MAPOS
address, and its destination is the assigned address [3]. The address
to be assigned to the network interface is decided in the same way as
in NSP, i.e., the address consists of the switch number and the port
number of the switch to which the network interface is connected [3].
In addition, the switch configures its frame forwarding table so that
unicast MAPOS frames destined to the address that has just been
assigned to the network interface are transmitted to it, in the same
way as in NSP.
Differently from NSP, in NSP+ the switch also configures the frame
forwarding table so that in the case of multicasting, it forwards to
the network interface only multicast frames whose destination
addresses are the same as one of the multicast MAPOS addresses
included in the multicast field of the address request. This
eliminates unnecessary multicast-frame transmission between a switch
and its directly connected nodes.
NSP+ does not influence the transmission of broadcast frames or the
frame transmission between switches.
2.2 Frame format
The HDLC protocol field of an NSP+ frame contains 0xFE03
(hexadecimal) similar to NSP [5], and the HDLC information field
contains a 32-bit command field and a 32-bit address field shown in
Figure 1, which are the same as those of NSP [3].
Ogura, et al. Expires September 2004 [Page 3]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
+-------------+-------------+
| Command | Address |
+-------------+-------------+
|<- 32 bits ->|<- 32 bits ->|
Figure 1. Content of the HDLC information field of an NSP+ frame.
The details of the fields are as follows:
Command 1 - address request
2 - address assignment
3 - reject (error)
Address In address request frames, the address field should
be filled with zeros, although the switch ignores
it. In address assignment frames, in the case of
MAPOS version 1, the assigned 8-bit address is
placed in the least significant octet of the field
and the rest of the field is filled with zeros. In
the case of MAPOS 16, the assigned 16-bit address
is placed in the least significant octets of the
field and the rest of the field is filled with
zeros. if the switch cannot assign the address for
some reason, the switch replies with a reject frame
(the value of the command field is 3). The value of
its address field is undefined.
In NSP+, differently from NSP, when the value of the command field is
1 (address request) and the address field is filled with zeros, an
optional multicast field can be added as shown in Figure 2.
+-------------+-------------+------------------------+
| Command | Address | Multicast |
+-------------+-------------+------------------------+
|<- 32 bits ->|<- 32 bits ->|
Figure 2. Content of the HDLC information field of an NSP+ frame with
a multicast field.
The multicast field contains multicast MAPOS addresses derived from
all the addresses of the network-layer multicast groups to which the
MAPOS network interface sending this address request frame belongs.
The length of this field is variable, and only one multicast field
can be added regardless of the number of included multicast MAPOS
addresses. This field is optional; an address request frame that has
Ogura, et al. Expires September 2004 [Page 4]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
no multicast field can also be used (see (b.3) in section 2.3).
Figure 3 shows the details of the multicast field. The address
fields store multicast MAPOS addresses derived from addresses of the
network-layer multicast groups to which the network interface
belongs.
+----------+----------+-----------+-----------+-----------+---
| Code | Form | Length | Address | Address |...
+----------+----------+-----------+-----------+-----------+---
|<-8 bits->|<-8 bits->|<-16 bits->|<-32 bits->|<-32 bits->|
Figure 3. Multicast field format.
The details of the fields are as follows:
Code 1 - reserved for future use
2 - multicast
(Indicates that the multicast field includes
multicast MAPOS addresses.)
Other values are not used.
Form 1 - MAPOS version 1
2 - MAPOS 16
Length The length of the multicast field in octets.
Address Includes a multicast MAPOS address. In MAPOS version
1, an 8-bit multicast MAPOS address is placed in the
least significant octet of the 32-bit address field
and the rest of the field is filled with zeros. In
MAPOS 16, a 16-bit multicast MAPOS address is placed
in the least significant octets of the 32-bit
address field and the rest of the field is filled
with zeros.
There is no limit on the number of address fields in a multicast
field, as long as the length of the content shown in Figure 2 does
not exceed the size of the maximum transmission unit (MTU) of the
network (see (b.2) in section 2.3). In addition, the number of
address fields can be zero (see (b.4) in section 2.3).
2.3 Behavior of nodes
A node must configure multicast fields and send address request
frames as described below.
Ogura, et al. Expires September 2004 [Page 5]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
(a) Generating multicast MAPOS addresses
Each multicast MAPOS address included in a multicast field is
generated from a network-layer multicast group address in the way
that each "<network layer> over MAPOS" specification describes. For
example, in the case of IPv4 over MAPOS version 1 [4], the MSB and
LSB of the MAPOS address are set to 1, and the remaining six bits of
the MAPOS address must contain the lowest-order six bits of the IP
multicast group address [8]. (Here, the term "multicast" does not
include broadcast. A multicast field must not include the broadcast
MAPOS address.)
As in the case of IP, multicast group addresses can be of two types.
The first is addresses corresponding to IP multicast groups to which
all the network interfaces of nodes have belonged since the time of
system initialization, such as 224.0.0.1 (all hosts) or 224.0.0.2
(all routers) in IPv4. The other is group addresses which a network
interface joins or leaves at the request of application software.
Regardless of that, in order for the nodes to receive network-layer
datagrams destined to these addresses, corresponding multicast MAPOS
addresses must be included in the multicast field.
(b) Configuring a multicast field
(b.1) The set of destination addresses of multicast MAPOS frames
that a node can receive through a MAPOS network interface is
exactly the same as the set of multicast MAPOS addresses
included in the multicast field of the latest address request
frame sent from the network interface. (If the latest address
request frame does not have a multicast field, the node can
receive all multicast frames regardless of their destination
addresses through the network interface. See (b.3).)
Therefore, whenever a network interface sends an address
request frame that has a multicast field, the multicast field
must contain a complete set of multicast MAPOS addresses
derived from all the addresses of the network-layer multicast
groups to which the network interface belongs. The network
interface can start or stop receiving multicast MAPOS frames
having certain multicast MAPOS addresses by sending a new
address request frame that has a new complete set of multicast
MAPOS addresses in its multicast field.
(b.2) There is no limit on the number of multicast MAPOS
addresses included in a multicast field. In other words, all
the multicast MAPOS addresses in the MAPOS address space can be
included in a single multicast field. This implies that the
largest possible multicast field contains 64 (the sixth power
Ogura, et al. Expires September 2004 [Page 6]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
of two) addresses in the case of MAPOS version 1 and 8192 (the
thirteenth power of two) addresses in the case of MAPOS 16.
In the latter case, the address fields of the multicast field
amounts to 32,768 octets in total because each multicast MAPOS
address is stored in a 32-bit-wide field, as described in
section 2.2. Even in this case, the content shown in Figure 2
can be accommodated by an address request frame, because the
maximum length of the information field of a MAPOS frame is
65,280 octets [1][2].
However, in a MAPOS implementation where the size of the
maximum transmission unit (MTU), i.e., the maximum length of
the information field of a MAPOS frame, is smaller than the
length of the content shown in Figure 2 with its largest
possible multicast field, it is possible for the length of the
content to exceed the size of the MTU. Such content cannot be
transmitted because NSP+ does not have a function for dividing
it into multiple address request frames.
In such cases, a node must send an address request frame that
has no multicast field through the network interface in order
to make the directly connected switch forward all multicast
frames to it regardless of their destination addresses
(see (b.3)). Even though this causes some unnecessary multicast
frame transmission, the node can receive all the multicast
frames it really needs to receive through the network
interface.
(b.3) When a node needs to receive all multicast frames regardless of
their destination addresses through a network interface, it
must send an address request frame that has no multicast field
through the network interface, i.e., an address request frame
that only contains the fields shown in Figure 1.
For example, this rule defines the outcome of cases where a
node that supports only conventional NSP is connected to a
switch that supports NSP+. According to this rule, the node
receives all multicast frames regardless of their destination
addresses.
(b.4) When a node does not need to receive any multicast frames
through a network interface, it must send an address request
frame including a multicast field that has no address fields
through the network interface, i.e., a multicast field
consisting of code, form, and length field. In this case, the
value of the length field is 4.
Ogura, et al. Expires September 2004 [Page 7]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
In the case of IPv4, this is an exceptional case because a
node's network interface which supports IP multicasting
usually belongs to multicast group 224.0.0.1 (all hosts) or
224.0.0.2 (all routers).
(c) When to send an address request frame
In NSP+, address request frames are sent basically at the same events
as those for NSP. These are described in [3] as follows.
(c.1) When a network interface of a node is connected to a switch
and receives a SONET signal, it sends an address request frame
to the switch. When the switch receives the frame, it replies
with an address assignment frame.
(c.2) If the network interface has not yet been assigned a MAPOS
address and it does not receive the address assignment frame
within 5 seconds, it continues to send address request frames
until it receives the address assignment frame.
(c.3) Whenever a network interface of a node detects a transmission
error such as carrier loss or out-of-synchronization, it should
send an address request frame to the switch and verify its
current address.
(c.4) In addition to (c.3), a network interface must verify its
address by sending address request frames every 30 seconds. The
switch regards these as keep-alive frames and utilizes them to
detect the interface's status. If the switch does not receive
an address request frame for more than 90 seconds, it assumes
that the network interface went down.
Moreover, in NSP+, different from NSP, an address request frame
should be sent under the following condition.
(c.5) When a network interface joins or leaves network-layer
multicast groups at the request of application software running
on a node, an address request frame should be sent from the
network interface. Here, its multicast field must contain the
new complete set of multicast MAPOS addresses derived from all
the addresses of the new network-layer multicast groups to
which the network interface belongs.
2.4 Behavior of switches
A switch compliant with NSP+ must obey the following when it
receives an address request frame from a network interface of a
directly connected node:
Ogura, et al. Expires September 2004 [Page 8]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
1) A switch decides a MAPOS address to be assigned to the network
interface in the same way as in NSP, then replies with an
address assignment frame. This address assignment frame is
exactly the same as that of NSP. If the switch cannot assign
the address for some reason, it replies with a reject frame.
2) A switch must configure its frame forwarding table so that
unicast MAPOS frames destined to the address that has just been
assigned to the network interface are transmitted to it and
so that multicast MAPOS frames are transmitted to the network
interface as described in (b.1), (b.3), and (b.4) in section
2.3.
The configuration of the frame forwarding table relevant to the
transmission of broadcast frames or to the frame transmission
between switches is not controlled by NSP+.
The order of the above actions is not specified. Furthermore, for a
switch that supports only NSP, its behavior upon receiving an address
request frame that includes a multicast field is not defined.
2.5 Consideration for special cases
There are two special cases to consider as described in [3]. The
first is point-to-point connection of two nodes without a switch. The
other is loop-back, that is, direct connection between the input and
the output of the same port of a network interface of a node.
In these cases, each network interface is assigned an address 0x03
(MAPOS version 1) or 0x0003 (MAPOS 16) in the same way as in NSP. The
multicast field of an address request frame is ignored.
3. Example
Figure 4 shows an example. In Figure 4, IPv4 over MAPOS version 1 is
assumed and the switch numbers are assumed to be two bits long. Node
N1 is connected to port 0x3 of switch S1 and node N2 is connected to
port 0x5 of the same switch. The switch is numbered 0x1 (01 in
binary).
Ogura, et al. Expires September 2004 [Page 9]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
---------+
|
AddrReq with |
m_field (G1',G2') |
---------------> |0x9
+------+ +---+----+ +--------+
| node +--------------------+ switch +----------+ switch |
| N1 | <------------ 0x3 | S1 |0x7 | S2 |
+------+ AddrAssign | 0x1 | | |
00100011 (0x23) +---+----+ +--------+
| 0x5
|
AddrReq with |
m_field (G1',G3') |
---------------> |
+------+ |
| node +------------------------+
| N2 | <---------------
+------+ AddrAssign
00100101 (0x25)
Figure 4. An example of NSP+.
The network interface of node N1 is a member of IPv4 multicast groups
G1 and G2, and that of N2 is a member of IPv4 multicast groups G1 and
G3. Here, G1 stands for an IPv4 multicast group address and G1'
stands for a multicast MAPOS address derived from G1; the same
applies to the others. In addition, the notation "m_field (G1', G2')"
stands for a multicast field which includes multicast MAPOS addresses
G1' and G2'.
After joining their multicast groups, N1 and N2 send address request
frames (AddrReq) with multicast fields to the control processor in S1
through their network interfaces. Specifically, N1 and N2 send
address request frames with m_field (G1', G2') and
m_field (G1', G3'), respectively, and the destination of the address
request frames is 0x01 (the control processor in the local switch).
On receiving the address request frames, S1 decides the MAPOS
addresses to be assigned to the network interfaces and sends back
address assignment frames (AddrAssign) in the same way as NSP does.
The assigned addresses are of the form "0 <switch number>
<port number> 1" [3]. In this example, the address assigned to N1 is
0 + 01 + 00011, that is, 00100011 (0x23), and the address assigned to
N2 is 00100101 (0x25). The address assignment frames include these
addresses, and their destinations are 0x23 and 0x25, respectively.
Ogura, et al. Expires September 2004 [Page 10]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
In addition, S1 configures its frame forwarding table so that it
forwards incoming unicast frames with destination address 0x23 to N1
and frames with destination address 0x25 to N2 respectively, and so
that it forwards incoming multicast frames with destination address
G1' to N1 and N2, frames with destination address G2' only to N1, and
frames with destination address G3' only to N2. It also ensures that
any multicast frames with destination addresses other than G1', G2',
and G3' are not forwarded to N1 or N2.
Care should be taken that NSP+ does not influence frame transmission
between switches. Usually in MAPOS, all multicast frames are
transmitted between S1 and S2.
4. Security Considerations
This section describes security factors related to NSP [3] and NSP+.
Common factors of NSP and NSP+ are discussed in section 4.1, and an
NSP+ specific factor is discussed in section 4.2.
4.1 Common factors of NSP and NSP+
4.1.1 Correspondence of an interface's MAPOS address to its location
In a multi-switch environment, a MAPOS address of a network interface
of a node assigned via NSP or NSP+ consists of the switch number and
the port number of the switch to which the network interface is
connected. This brings the following advantages.
1. The value of the MAPOS address of a network interface of a node
indicates the location of the interface in the MAPOS network. In
other words, the destination address of a unicast MAPOS frame
defines the actual location to which the frame should finally be
delivered. Therefore, as long as MAPOS addresses of network
interfaces of nodes that have been connected to the network
through proper administrative process are held, and as long as it
is ensured that in the case of unicasting only frames destined to
those addresses are delivered (e.g., by using destination address
filtering), other nodes cannot receive frames unless their network
interfaces are connected to the same ports of switches as those to
which network interfaces of properly administered nodes are
connected. This makes fraudulent reception of unicast traffic
difficult.
2. In the case where MAPOS addresses are not administered as
mentioned above, a malicious node could hijack traffic by spoofing
its layer-3 address in a response to a link-layer address
resolution. Even in this case, the node must advertise the true
MAPOS address of its network interface in the response so that it
Ogura, et al. Expires September 2004 [Page 11]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
can receive successive frames. This makes it easy to pinpoint the
location of the node.
4.1.2 A flood of address requests
An address request frame should be sent from nodes only when one of
the events described in section 2.3(c) occurs. However, a malicious
or malfunctioning node could send a large number of address request
frames in a very short time to the control processor of its directly
connected switch. In this case, if the receiving switch has only
straightforward functions to support NSP or NSP+, the load on its
control processor for processing these address request frames would
become high and this might lead to system failure.
In order to prevent the above, a switch should have a function to
monitor the arrival frequency of address request frames from each
port to its control processor, and to disconnect a line if a node
connected to it has sent too many address request frames.
4.2 An NSP+ specific factor
4.2.1 Insertion of unicast addresses in a multicast field
In each address field of a multicast field of an address request
frame, a multicast MAPOS address must be inserted, but a malicious or
malfunctioning node could insert a unicast MAPOS address in it. In
this case, if the receiving switch has only a straightforward
function to configure its frame forwarding table so that it forwards
MAPOS frames destined to the unicast address to the port from which
the address request frame arrived, the unicast MAPOS frames will
consequently be sent to the port, which is not necessarily their real
destination port. This leads to inappropriate or fraudulent reception
of unicast traffic.
In order to prevent the above, a switch should have a function to
remove or ignore MAPOS addresses which are not multicast addresses
included in a multicast field of an address request.
5. Normative References
[1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol
over SONET/SDH, Version 1," RFC-2171, June 1997.
[2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access
Protocol over SONET/SDH with 16 Bit Addressing," RFC2175,
June 1997.
[3] Maruyama, M. and K. Murakami, "A MAPOS Version 1 Extension -
Ogura, et al. Expires September 2004 [Page 12]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
Node Switch Protocol," RFC-2173, June 1997.
[4] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1,"
RFC-2176, June 1997.
[5] Murakami, K. and M. Maruyama, "MAPOS Version 1 Assigned
Numbers," RFC-2172, June 1997.
6. Informative References
[6] American National Standards Institute, "Synchronous Optical
Network (SONET) - Basic Description Including Multiplex
Structure, Rates and Formats," ANSI T1.105-1995.
[7] ITU-T Recommendation G.707, "Network Node Interface for the
Synchronous Digital Hierarchy (SDH)," October 2000.
[8] Deering, S., "Host Extensions for IP Multicasting," RFC-1112,
August 1989.
7. Authors' Addresses
Tsuyoshi Ogura
NTT Network Innovation Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180-8585, Japan
E-mail: ogura@core.ecl.net
Mitsuru Maruyama
NTT Network Innovation Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180-8585, Japan
E-mail: mitsuru@core.ecl.net
Toshiaki Yoshida
Werk Mikro Systems
250-1, Mikajiri
Kumagaya
Saitama 360-0843, Japan
E-mail: yoshida@peta.arch.ecl.net
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
Ogura, et al. Expires September 2004 [Page 13]
INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-03.txt March 2004
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ogura, et al. Expires September 2004 [Page 14]