Network Working Group T. Kuwahara Internet Draft J. Murayama Expires: December 2001 N. Yoshida M. Tanikawa NTT Corporation June 19, 2001 Scalable Connectionless Tunneling Architecture and Protocols for VPNs Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a connectionless tunneling architecture that is applicable to provider provisioned virtual private networks (PPVPNs) and specifies protocols for implementing it. This architecture is designed to facilitate scalable operation, load balancing, and high reliability. A prominent feature of it is to provide VPN tunnels over a connectionless network. Since a connectionless network can provide full mesh connectivity without a connection establishing procedure, the architecture enables scalable operation of a VPN more efficiently than connection-oriented tunneling technologies. Kuwahara et al. Expires December 2001 [Page 1] Internet Draft CL Tunneling for VPNs June, 2001 Table of Contents 1. Introduction ................................................. 3 2. Connectionless Tunneling Architecture ........................ 4 3. Protocol Suite ............................................... 6 3.1 Overview .................................................. 6 3.2 Connectionless Tunneling Control Protocol ................. 7 3.2.1 Message Format ........................................ 7 3.2.2 Procedures ............................................ 9 4. Security Considerations ...................................... 11 5. Acknowledgements ............................................. 11 6. References ................................................... 11 7. Authors' Addresses ........................................... 12 Appendix A: Example Configuration Scheme for Core Network Address ........ 13 Appendix B: ATM-based Protocol Suite ..................................... 14 Full Copyright Statement ........................................ 27 Kuwahara et al. Expires December 2001 [Page 2] Internet Draft CL Tunneling for VPNs June, 2001 1. Introduction This document defines a connectionless (CL) tunneling architecture that is applicable to provider provisioned virtual private networks (PPVPNs) [PPVPN-FR]. It also specifies protocols for implementing the CL tunneling architecture. A prominent feature of this architecture is establishing VPN tunnels [PPVPN-FR] using connectivity provided by a connectionless Service Provider (SP) network (e.g., an IP routing network). Here, such a VPN tunnel and a CL SP network [PPVPN-FR] are called a CL tunnel and a core network, respectively. This architecture is designed to satisfy the following objectives: - scalable operation, - load balancing, and - high reliability. This architecture is based on the reference model for the layer 3 network-based VPN (NBVPN) defined in [PPVPN-FR]. It assumes that an SP network consists of Provider Edge (PE) routers, which accommodate Customer Edge (CE) devices, and Provider (P) routers, which interconnect PEs but do not provide VPN-specific functionalities. A PE router can support more than one VPN. A VPN is supported by a VPN Forwarding Instance (VFI), which is implemented within a PE. One of the major issues of PPVPNs using a connection-oriented tunneling technology is the large number of connections, each of which provides an associated VPN tunnel, when the number of PEs and/or VPNs is increased. To solve this issue and achieve scalable operation, this architecture deploys a core network in which full mesh connectivity is achieved without a connection establishment procedure, although appropriate updating of routing information is needed to maintain the connectivity of the core network. By applying the hierarchical addressing configuration described in Appendix A to the core network, we further reduce the processing load needed to maintain the connectivity. For efficient use of network resources and reliable operation, load balancing and support for multiple routes between PEs are necessary. To satisfy these requirements, CL tunnels between VFIs need to be mapped to appropriate routes between PEs. Thus, this architecture specifies a VFI addressing scheme that enables explicit routing in order to support these features. Note that the CL tunneling technology specified in this architecture also supports DiffServ [RFC2474], which is supported by other tunneling technologies. In this document, Section 2 defines the CL tunneling architecture, Kuwahara et al. Expires December 2001 [Page 3] Internet Draft CL Tunneling for VPNs June, 2001 and section 3 specifies protocols applied to this architecture based on IPv6 [RFC2460]. In addition, Appendix A describes an example configuration for addressing used in CL networks enabling efficient operation of VPNs. Appendix B specifies an ATM-based protocol suite that makes use of cell-based encapsulation to improve forwarding performance. 2. Connectionless Tunneling Architecture This section specifies a CL tunneling architecture that is applicable to PPVPNs. In this architecture, the same names are used for those entities already defined in [PPVPN-FR]. A network model is shown in Figure 2.1. In this model, an access network connects a CE with a PE. Note that this document does not specify any details of the access network. Access SP Network Access Network (Core Network) Network |<--------->|<-------------------------->|<--------->| PE P PE +----------+ +-----+ +----------+ | |IP VPN| | | | +-------------------------------------------------------------+ | +--+ | +---+ | | | | +---+ | +--+ | | |CE|-------|VFI|<=======================>| |-------|CE| | | +--+ | +---+ | CL | | | | | | +--+ | | | |Tunnel| | | |VFI| | | +-------------------------------------+ | | | | +--+ | | | | | | | | |-------|CE| | +-----------------------+ | | | | +---+ | +--+ | | +--+ | +---+ | | | | +-----------------------+ | |CE|-------| | | | | | | | | +--+ | | | | +-------------------------------------+ | | |VFI| | | | CL | | | | +--+ | | | | | |Tunnel| +---+ | +--+ | | |CE|-------| |<=======================>|VFI|-------|CE| | | +--+ | +---+ | | | | +---+ | +--+ | +-------------------------------------------------------------+ | | | |IP VPN| | +----------+ +-----+ +----------+ Figure 2.1 Network Model A VFI is created for each VPN in a PE to support VPN functionality specific to the associated VPN. An access network provides point- to-point access connections between CEs and VFIs belonging to the Kuwahara et al. Expires December 2001 [Page 4] Internet Draft CL Tunneling for VPNs June, 2001 same VPN. A core network provides connectivity among VFIs belonging to a VPN. An IP packet sent from a CE is received by a VFI and forwarded to an appropriate VFI via the core network, and then sent to a destination CE. Each VFI searches its IP forwarding table using the destination IP address in the received IP packet as a key when it forwards an IP packet to the next hop PE/CE. Here, an IP packet forwarded between CEs over a core network is called a tunneled IP packet. A protocol that supports the connectivity of core networks is called a core network protocol. An address used by the core network protocol is called a core network address. This core network address is assigned to a VFI in a PE. CL tunnels over a core network are implemented by associating each entry in the IP forwarding table with the core network address of an appropriate egress VFI. Since the core network provides full mesh connectivity with no preceding connection establishing procedure, a tunneled IP packet (encapsulated in the core network protocol PDU) can be forwarded to the VFI by simply setting the core network address of an egress VFI in the core network protocol PDU. In this architecture, a CL tunnel between a pair of PEs is supported either by directly forwarding the core network protocol PDUs or by forwarding them through one or more P routers as intermediate nodes. Here, a PE (as well as a P router) searches its core forwarding table using the destination core network address as a key to find a P/PE router as the next hop. In this model, PEs process IP packets as follows: (1) Ingress PE When an IP packet is sent from a CE to a PE, the IP packet is delivered to the VFI that is associated with the access connection (and thus, associated with a specific VPN). The VFI searches its IP forwarding table using the destination IP address as a key and resolves the core network address identifying the destination VFI. Then, the VFI searches its core forwarding table to determine the P or PE as the next hop by using the destination core network address as a key. Then, the ingress PE encapsulates the IP packet into a core network protocol PDU, and forwards it toward the next hop (P/PE). (2) Egress PE When receiving a core network protocol PDU from a P router or an ingress PE, the VFI in an egress PE decapsulates the IP packet from the PDU, and determines the appropriate access connection by searching the IP forwarding table using the destination IP address as Kuwahara et al. Expires December 2001 [Page 5] Internet Draft CL Tunneling for VPNs June, 2001 a key. Then, the egress PE forwards the IP packet toward the destination CE via the access connection. This architecture enables the use of both "full mesh" and "hub and spoke" (Figure 2.2) CL tunnel topologies. In the latter, the PE used as the hub is called a Default Forwarder (DF) and the route from a PE to a DF is called the default route. When a direct route between PEs is lightly loaded, it is possible to use the default route to support the traffic between these PEs and thus reduce the number of entries in the IP forwarding table within a VFI. To reduce the load on a DF, this architecture also supports dynamic creation of a cut-through CL tunnel (bypassing a DF) between two PEs. This feature is enabled by Connectionless Tunneling Control Protocol (CTCP) defined in Section 3.2. <=====>: CL tunnel for default route forwarding <----->: CL tunnel for cut through route forwarding +------------+ +----+ | P | +----+ | PE |<======================================>| DF | | |<------------------+ | | | +----+ | | | | | | | | | | +----+ | | | | | | PE |<------------------+ | | | | |<======================================>| | +----+ | | | | | | | | +----+ | | | | | PE |<======================================>| | +----+ | | +----+ +------------+ Figure 2.2 Hub and Spoke Topology 3. Protocol Suite This section specifies the protocol suite to be applied to the architecture specified in Section 2. 3.1 Overview Figure 3.1 shows the protocol suite to be applied to the CL tunneling architecture. IPv6 [RFC2460] and ICMPv6 [RFC2463] are used for the core network Kuwahara et al. Expires December 2001 [Page 6] Internet Draft CL Tunneling for VPNs June, 2001 protocol. Here, a core network protocol PDU is constructed by encapsulating an IP packet received from a CE into an IPv6 packet format as specified in [RFC2473]. Quality-of-service (QoS) control in core networks conforms to Diffserv specifications for IPv6 [RFC2474]. The Connectionless Tunneling Control Protocol (CTCP) specified in Section 3.2 is used for controlling the cut-through packet forwarding. This protocol is specified over UDP, while the port number of UDP for identifying CTCP is TBD. {RFC 2463} | V +----------+----------+----------+ {Section 3.2}---> | CTCP | ICMPv6 | IP | +----------+ | | | UDP | | | +----------+----------+----------+ <---{RFC 2473} | IPv6 | <---{RFC 2460} +--------------------------------+ Figure 3.1 IPv6-based Protocol Suite for the CL Tunneling Architecture 3.2 Connectionless Tunneling Control Protocol The Connectionless Tunneling Control Protocol (CTCP) is a protocol for controlling cut-through packet forwarding of tunneled IP packets within a VPN supported by core networks. 3.2.1 Message Format Every CTCP message is preceded by a UDP header. CTCP messages have the following general format: Kuwahara et al. Expires December 2001 [Page 7] Internet Draft CL Tunneling for VPNs June, 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation ID | Address Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Target Address + | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Resolved IPv6 Address + | (128 bits) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation ID | Address Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Target Address + | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Resolved IPv6 Address + | (128 bits) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8-bit unsigned integer. The type field indicates the type of message. Its value determines the format of the remaining data. Code: 8-bit unsigned integer. The code field depends on the message type. It is used to create an additional level of message granularity. The following sets of TYPE/CODE are defined 1/1 Tunnel Redirection Notification 1/2 Tunnel Purge Notification Kuwahara et al. Expires December 2001 [Page 8] Internet Draft CL Tunneling for VPNs June, 2001 Operation ID: Identifies operations in the message. 16-bit unsigned integer. Address Type: Protocol number in [RFC1700], which indicates the type of the target address. 8-bit unsigned integer. Prefix Length: Length of the target address prefix. 8-bit unsigned integer. Target Address: Destination IP address for the cut-through tunnel to be used/cancelled. Resolved IPv6 Address: IPv6 address of the egress VFI to which the cut-through tunnel shall be used/cancelled. 128-bit unsigned integer. Descriptions: A Tunnel Redirection Notification message (Type=1, Code=1) is used by a VFI to request an ingress VFI that tunneled IP packets with the indicated address prefix be forwarded via a new cut-through tunnel indicated in the message. A Tunnel Purge Notification message (Type=1, Code=2) is used by a VFI to request the ingress VFI to discontinue the forwarding of tunneled IP packets through the cut-through tunnel indicated in the message. 3.2.2 Procedures This section specifies the Tunnel Redirection and Tunnel Purge procedures. These are unconfirmed procedures, so their protocol instances can be implemented as stateless processes, because they do not create any response messages. In a core network with "hub and spoke" topology, a tunneled IP packet is forwarded from an ingress PE to a DF. Then the DF forwards the received tunneled IP packet to the egress PE identified by the destination address of the tunneled IP packet. At the same time, the DF asks the ingress PE for redirection via a cut-through CL tunnel by sending a Tunnel Redirection Notification message (Type=1, Code=1). In this message, the Target Address field contains the destination IP address of the tunneled IP packet that has triggered the redirection control. Prefix Length fields and Resolved IPv6 Address fields contain prefix length of the taget address and the PE address obtained by table searching, respectively. When an ingress VFI receives a Tunnel Redirection Notification message, it adds the notified entry information in its IP forwarding table as a tunnel redirection entry. This is because tunnel redirection entries may be removed by the tunnel purge procedure. As a result, succeeding tunneled IP packets to the same destination are Kuwahara et al. Expires December 2001 [Page 9] Internet Draft CL Tunneling for VPNs June, 2001 forwarded through the cut-through CL tunnel. (2) Tunnel Redirection Notification +------------+ +------------------|Intermediate| | +------------->| DF (VFI) |------------+ | | (1) Default +------------+(1) Default | | | Forwarding Forwarding | | | | V | V +-----------+ +-----------+ | Ingress | (3) Cut-Through Forwarding | Egress | | PE (VFI) |----------------------------->| PE (VFI) | +-----------+ +-----------+ Figure 3.2 Tunnel Redirection Control by the Intermediate Default Forwarder (DF) When a VFI in a PE receives a tunneled IP packet from a cut-through CL tunnel, it searches the IP forwarding table. If the destination address does not match any entry in the table, the VFI discards the IP packet and sends the ingress VFI a Tunnel Purge Notification message (Type=1, Code=2) to stop the redirection using the cut- through CL tunnel. This message contains the Target IP Address and Resolved IPv6 Address but no Prefix Length. When an ingress VFI receives a Tunnel Purge Notification message, it searches the IP forwarding table using the notified IP address as a key. And if the IP address matches a tunnel redirection entry, the VFI removes the entry. Thus, IP packets toward the same destination are forwarded to the default route to a DF. +------------+ |Intermediate| +------------->| DF (VFI) |--------------------------+ | (3) Default +------------+ (3) Default Forwarding | | Forwarding | | | | | | V +---------+ (1) Cut-Through Forwarding +-------------+ +-----------+ | |---------------------------->|Inappropriate| |Appropriate| | Ingress | | Egress | | Egress | | PE (VFI)|<----------------------------| PE (VFI) | | PE (VFI) | +---------+(2) Tunnel Purge Notification+-------------+ +-----------+ Figure 3.3 Tunnel Purge Control by the Egress Edge Node Kuwahara et al. Expires December 2001 [Page 10] Internet Draft CL Tunneling for VPNs June, 2001 4. Security Considerations The level of security provided by this CL tunneling architecture is identical to that provided by the tunneling technologies using layer 3 connectivity, since the core network providing these tunnels is operated not by users but by an SP in a manner invisible to users. 5. Acknowledgements This architecture and protocol specifications are outputs of GMN-CL (Global Megamedia Networks based on Connectionless Technologies) project in NTT. The authors would like to acknowledge - O. Tabata and T. Iwase (NEC Corporation), - M. Inami and E. Takahashi (Fujitsu Limited), - H. Takenoshita and Y. Araki (Oki Electric Industry Company), - K. Kitami (NTT Corporation) for discussions and comments on the specification and implementations. 6. References [PPVPN-FR] Callon, R., Suzuki, M., et al., "A Framework for Provider Provisioned Virtual Private Networks," Internet-draft , February 2001. [RFC2474] Nichols, K., Blake, S., Baker, F., and Black, D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, December 1988. [RFC2460] Deering, S., and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998. [RFC2463] Conta, A., and Deering, S., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification," RFC 2463, December 1988. [RFC2473] Conta, A., et al., "Generic Packet Tunneling in IPv6 Specification," RFC 2473, December 1988. [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [RFC2373] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture," RFC 2373, July 1998. Kuwahara et al. Expires December 2001 [Page 11] Internet Draft CL Tunneling for VPNs June, 2001 [I.361] "B-ISDN ATM Layer Specification," I.361 ITU-T Recommendation, February 1999. [I.363.5] "B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification," I.363.5 ITU-T Recommendation, August 1996. [RFC2684] Grossman, D., and Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5," RFC 2684, September 1999. [E.164] "The International Public Telecommunication Numbering Plan," E.164 ITU-T Recommendation, May 1997. 7. Authors' Addresses Takeshi Kuwahara NTT Corporation, 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: kuwahara.takeshi@lab.ntt.co.jp Junichi Murayama NTT Corporation, 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: murayama.junichi@lab.ntt.co.jp Norishige Yoshida NTT Corporation, 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: yoshida.norishige@lab.ntt.co.jp Masaki Tanikawa NTT Corporation, 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: tanikawa.masaki@lab.ntt.co.jp Kuwahara et al. Expires December 2001 [Page 12] Internet Draft CL Tunneling for VPNs June, 2001 Appendix A: Example Configuration Scheme for Core Network Address This appendix shows an example configuration scheme for the core network address to achieve efficient operation of the core network protocol specified in Section 3 of this document. In a core network, an IPv6 address is assigned to a VFI as a core network address. As multiple VFIs are generally created in a PE/DF, load balancing among VPNs is possible in core networks. If SLA ID and INTERFACE ID in the Aggregatable Global Unicast Addresses [RFC2373] are configured hierarchically, the following information can be directly extracted from the IPv6 Addresses used in a core network. - Area identification (identifies an area accommodating the addressed VFI within a core network identified by TLA and NLA of the IPv6 address), - PE/DF identification (identifies a PE/DE supporting the addressed VFI in the indicated area), and - VPN identification (identifies the VPN to which the addressed VFI is associated). The address configuration scheme described above enables: - route aggregation by using AREA IDs for each area, - load balancing among routes toward a certain AREA, by assigning multiple AREA IDs to the AREA, - load balancing among routes toward a certain PE/DF, by assigning multiple PE/DF IDs to the PE/DF supporting the addressed VFI, - efficient VPN operation by using core addresses including explicit VPN identification as well as explicit Area and PE/DF identifications. The same hierarchical address configuration scheme can also be defined to achieve efficient operation when the Site-Local Address of Local-Use Unicast Address [RFC2373] is used for VFI addresses in the core network. Kuwahara et al. Expires December 2001 [Page 13] Internet Draft CL Tunneling for VPNs June, 2001 Appendix B: ATM-based Protocol Suite B.1 Introduction This appendix specifies an ATM-based protocol suite applicable to the CL tunneling architecture defined in this document. The core network protocol specified here (called the ATM-based core network protocol) is an essential part of the protocol suite. The ATM-based core network protocol is designed to satisfy the addressing requirements described in Appendix A and is also designed to achieve efficient encapsulation/decapsulation of core network protocol PDUs in PEs when both access networks and the core network are constructed on the basis of ATM. B.2 Overview Figure B.1 shows the protocol suite designed for efficient operation in the ATM environment applicable to the CL tunneling architecture as specified in this document. Section B.3 shows protocol stacks of the ATM-based protocol suite described in this appendix. Section B.4 describes the usage of the ATM protocol in the protocol suite. Section B.5 specifies the structure of an AAL5-CPCS PDU encapsulating a core network protocol PDU. The ATM-based core protocol is specified in section B.6 and used for CL tunneling without a tunneling establishment procedure over ATM networks. Section B.7 describes scheme for encapsulating/decapsulating an IP packet from a user as a core network protocol PDU defined in Section B.5. To control the core network applying the ATM-based core protocol, the Core Control Message Protocol (CCMP) is used; it is specified in section B.8. CCMP is also used to control the tunnel configuration. {Section B.8} | | V V +-------------+-------------+-------------+ |CCMP for |CCMP for | IP | |tunnel |core network | | |configuration|control | | +-------------+-------------+-------------|<--{Section B.7} | ATM-based core network protocol |<--{Section B.6} +-----------------------------------------+<--{Section B.5} | ATM |<--{Section B.4} +-----------------------------------------+ Figure B.1 ATM-based Protocol Suite for the CL Tunneling Architecture Kuwahara et al. Expires December 2001 [Page 14] Internet Draft CL Tunneling for VPNs June, 2001 B.3 Protocol Stacks B.3.1 Overview This section shows the protocol stacks of the ATM-based core network protocol described in this appendix. Here, the forwarding plane corresponds to core network protocol PDU forwarding functions between PEs/DFs via P routers. The core network control plane and the tunnel configuration plane correspond to the functions of CCMP described in Section B.8. B.3.2 Forwarding Plane +---------+ +---------+ | IP | | IP | +----+----+ +----+----+ |SNAP|SNAP| |SNAP|SNAP| +----+----+ +----+----+ |LLC |LLC | |LLC |LLC | +----+----+ +---------+ +----+----+ | |CORE|<--------------->| CORE |<--------------->|CORE| | + +----+ +----+----+ +----+ + | |SNAP|<--------------->|SNAP|SNAP|<--------------->|SNAP| | +AAL5+----+ +----+----+ +----+AAL5+ | |LLC |<--------------->|LLC |LLC |<--------------->|LLC | | + +----+ +----+----+ +----+ + | |AAL5|<--------------->|AAL5|AAL5|<--------------->|AAL5| | +----+----+ +---+---+ +----+----+ +---+---+ +----+----+ |ATM |ATM |<-->|ATM|ATM|<-->|ATM |ATM |<-->|ATM|ATM|<-->|ATM |ATM | +----+----+ +---+---+ +----+----+ +---+---+ +----+----+ |PHY |PHY |<-->|PHY|PHY|<-->|PHY |PHY |<-->|PHY|PHY|<-->|PHY |PHY | +----+----+ +---+---+ +----+----+ +---+---+ +----+----+ PE/DF ATM Node P router ATM Node PE/DF Figure B.2 Protocol Stack of the Forwarding Plane Kuwahara et al. Expires December 2001 [Page 15] Internet Draft CL Tunneling for VPNs June, 2001 B.3.3 Core Network Control Plane +----+ +----+ |CCMP|<--------------------------------------------------->|CCMP| +----+ +---------+ +----+ |CORE|<------------------->| CORE |<------------------->|CORE| +----+ +----+----+ +----+ |SNAP|<------------------->|SNAP|SNAP|<------------------->|SNAP| +----+ +----+----+ +----+ |LLC |<------------------->|LLC |LLC |<------------------->|LLC | +----+ +----+----+ +----+ |AAL5|<------------------->|AAL5|AAL5|<------------------->|AAL5| +----+ +----+----+ +----+----+ +----+----+ +----+ |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM | +----+ +----+----+ +----+----+ +----+----+ +----+ |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY | +----+ +----+----+ +----+----+ +----+----+ +----+ P or PE/DF ATM Node P Router ATM Node P or PE/DF Figure B.3 Protocol Stack of the Core Network Control Plane B.3.4 Tunneling Configuration Plane +----+ +----+ |CCMP| |CCMP| +----+ +---------+ +----+ |CORE|<------------------->| CORE |<------------------->|CORE| +----+ +----+----+ +----+ |SNAP|<------------------->|SNAP|SNAP|<------------------->|SNAP| +----+ +----+----+ +----+ |LLC |<------------------->|LLC |LLC |<------------------->|LLC | +----+ +----+----+ +----+ |AAL5|<------------------->|AAL5|AAL5|<------------------->|AAL5| +----+ +----+----+ +----+----+ +----+----+ +----+ |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM | +----+ +----+----+ +----+----+ +----+----+ +----+ |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY | +----+ +----+----+ +----+----+ +----+----+ +----+ PE/DF ATM Node P Router ATM Node PE/DF Figure B.4 Protocol Stack of the CL Tunneling Plane B.4 ATM Protocol The ATM layer complies with ITU-T recommendation [I.361]. A VP is used to interconnect nodes (i.e., PE, DF, P) in a core network. The AAL layer complies with ITU-T recommendation of AAL5 Kuwahara et al. Expires December 2001 [Page 16] Internet Draft CL Tunneling for VPNs June, 2001 specification [I.363.5]. The AAL5 message mode shall be used. B.5 AAL5-CPCS PDU for ATM-based Core Network Protocol PDU The ATM-based core network protocol PDU is encapsulated as an AAL5- CPCS PDU based on the "LLC Encapsulation for Routed Protocols" format defined in [RFC2684] using the LLC/SNAP header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSAP | SSAP | Ctrl | OUI (Upper) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI (Lower) | EtherType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | ~ Core Network Protocol PDU ~ | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ PAD ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UU | CPI | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DSAP: 0xAA (Destination Service Access Point defined in IEEE802.2 LLC header). SSAP: 0xAA (Source Service Access Point defined in IEEE802.2 LLC header). Ctrl: 0x03 (SNAP identifier). OUI: 0x00-00-00. EtherType: TBD. Core Network Protocol PDU: Up to (2^16)-9 octets, the maximum length of the Core Network Protocol PDU is 65527 octets. PAD: From 0 to 47 octets. UU: Should be 0x00. CPI: Should be 0x00. Length: This field shows the byte length of the AAL5-CPCS PDU payload. The value of 0x00 may be used as an abort signal. Kuwahara et al. Expires December 2001 [Page 17] Internet Draft CL Tunneling for VPNs June, 2001 CRC: A CRC 32 is calculated for the entire AAL5-CPCS PDU except for the CRC field itself. B.6 ATM-based Core Network Protocol B.6.1 ATM-based Core Network Protocol Header Format 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| Traffic Class | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | HLSI | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Core Network Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Core Network Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: 4-bit ATM-based core network protocol version number. The current version number is 1. Traffic Class: 8-bit unsigned integer. This field is divided as follows in the core network protocol: +--+--+--+--+--+--+--+--+ | Priority | Reserved | +--+--+--+--+--+--+--+--+ Priority: 4-bit unsigned integer. This indicates the priority of the core network protocol PDU. The values listed below are used for priority identification: 0(0000B) prio-0 PDU (lowest) 8(1000B) prio-8 PDU 10(1010B) prio-10 PDU 12(1100B) prio-12 PDU (highest) Others unassigned Kuwahara et al. Expires December 2001 [Page 18] Internet Draft CL Tunneling for VPNs June, 2001 Reserved: It must be encoded as all '0'. HLSI: 8-bit Higher Layer Service Identifier that identifies the higher-layer protocols and services carried by the core network protocol: 1 IPv4 service 16 CCMP core network control service 17 CCMP tunneling configuration service Other values are reserved for future use. Hop Limit: 8-bit unsigned integer. Source Core Network Address: 128 bits. See Section B.6.2 for the internal structure. Destination Core Network Address: 128 bits. See Section B.6.2 for the internal structure. Reserved: It must be encoded as all '0'. The maximum PDU length of the core network protocol is 65527 octets. B.6.2 Structure of Source/Destination Core Network Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PE/DF ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + VPN ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PE/DF ID: 64 bits, identifying source/destination PE/DF. See Section B.6.3 for the internal structure. VPN ID: 64 bits. See Section B.6.4 for the internal structure. Kuwahara et al. Expires December 2001 [Page 19] Internet Draft CL Tunneling for VPNs June, 2001 B.6.3 Structure of PE/DF ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FP | Reserved | PC | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Area | PE/DF Group ID | PE/DF ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FP: 3-bit unsigned integer. Format Prefix, encoded as 001B. Reserved Encoded as all '0'. PC: 8-bit unsigned integer. Provider Code - identifying the serving provider. CC: 10-bit unsigned integer. Country Code - identifying the country where the indicated area is located. Its value is as specified in [E.164] and encoded in binary. Area: 10-bit unsigned integer. Area number - identifying an area in the indicated country. PE/DF Group ID: 14-bit unsigned integer. Identifying a physical node supporting a group of PE/DF in the ATM-based core network. PE/DF ID: 6-bit unsigned integer. PE/DF identifier in an identified PE/DF group. Note that a "PE/DF group" represents a physical node that terminates ATM connections of a core network and access networks. It supports one or more PEs and DFs and the core network protocol based forwarding function to distribute core network protocol PDUs among accommodated PEs/DFs. B.6.4 Structure of VPN ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | VPN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VPN Number: 24-bit unsigned integer identifying the VPN. Reserved: It must be encoded as all '0'. Kuwahara et al. Expires December 2001 [Page 20] Internet Draft CL Tunneling for VPNs June, 2001 B.7 Encapsulation Scheme for IP Packet from User This section describes how to encapsulate/decapsulate an IP packet over AAL5 from a user as an ATM-based core network protocol PDU defined in Section B.5. The encapsulation/decapsulation scheme is designed to improve forwarding performance. The ingress PE can perform core network protocol PDU encapsulation on a cell-by-cell basis. For this, the first cell of the core network protocol PDU is used to hold the core network protocol header. The cell-divided IP packet received from an access connection conforms to the "LLC Encapsulation for Routed Protocols" format with the LLC/SNAP header defined in [RFC2684] and it is directly mapped to the following cells of the core network protocol PDU. Consequently, the IP PDU is still encapsulated with the LLC/SNAP header even in the core network protocol PDU as shown in Figure B.2. The core network protocol header is also encapsulated with the other LLC/SNAP header. The encapsulation scheme is shown in Figure B.5. Here, the payload of last cell is modified because the AAL5-PDU trailer part should be reconfigured for the core network protocol PDU. The egress PE decapsulates it by simply removing the first cell containing the core network protocol header and modifying the AAL5-PDU trailer part in the payload of the last cell. |<- AAL5-CPCS PDU received from access network ->| | | +-+-------+ +-+-------+ +-+-------+ +-+-------+ | | IPv4 | | | | | | | | | | +-+-------+ +-+-------+ +-+-------+ +-+-------+ |First cell | cell | | cell | |Last cell| | | | | | | | | | | | | | | | | +-+-------+ +-+-------+ +-+-------+ +-+-------+ +-+-------+ <--| | core | | | IPv4 | | | | | | | | | | +-+-------+ +-+-------+ +-+-------+ +-+-------+ +-+-------+ |Core cell cell cell cell Last cell| | | |<---------- AAL5-CPCS PDU sent to core network ------------->| Figure B.5 Core Encapsulation B.8 Core Control Message Protocol The Core Control Message Protocol (CCMP) specified here supports core network control and tunnel configuration. Kuwahara et al. Expires December 2001 [Page 21] Internet Draft CL Tunneling for VPNs June, 2001 B.8.1 Common Message Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Body + | | TYPE: CCMP message identifier. CODE: The value allocation method depends on the message type. It is used to create an additional level of message granularity. Reserved: It must be encoded as all '0' by the sender, and ignored by the receiver. Message Body: The main body of the message. The assigned values of TYPE and CODE are listed in Table B.1. Table B.1 CCMP Message Classes +---------------++----------------------------------+----+----+ | Message Class || Message Contents |TYPE|CODE| +===============++==================================+====+====+ | Core Network || ECHO Request | 0| 0| | Control || ECHO Reply | 1| 0| | || Hop Limit Exceeded | 16| 0| +---------------++----------------------------------+----+----+ | Tunneling || Tunnel Redirection Notification | 32| 0| | Configuration || Tunnel Purge Notification | 33| 0| +---------------++----------------------------------+----+----+ B.8.2 ECHO Request This message is transmitted to test the reachability to a destination and quality in the core layer. Every node must be able to send and receive an ECHO Request message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved |4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number |8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ...... |12 +-+-+-+-+-+-+-+-+-+- Kuwahara et al. Expires December 2001 [Page 22] Internet Draft CL Tunneling for VPNs June, 2001 TYPE: 8-bit unsigned integer The ECHO request message type. It must be set to 0. CODE: 8-bit unsigned integer. It must be set to 0. Identifier: 8-bit unsigned integer. An identifier to match the ECHO request with the ECHO reply. It may be used by higher-layer applications. Sequence Number: 16-bit unsigned integer. A sequence number may be used by higher-layer applications to match the ECHO request with the ECHO reply. Data: Zero or more bytes of arbitrary data. Reserved: It must be encoded as all '0' by the sender, and ignored by the receiver. B.8.3 ECHO Reply This message is transmitted to confirm the reachability to a destination and quality in the core layer. Every node must send an ECHO Reply message whenever it receives an ECHO Request message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved |4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number |8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ...... |12 +-+-+-+-+-+-+-+-+-+- TYPE: 8-bit unsigned integer. Echo reply message type. It must be set to 1. CODE: 8-bit unsigned integer It must be set to 0. Identifier: 16-bit unsigned integer. The identifier extracted from the invoking ECHO Request message. Sequence Number: 16-bit unsigned integer. The sequence number extracted from the invoking ECHO Request message. Data: The data extracted from the invoking ECHO Request message. Reserved: It must be encoded as all '0' by the sender, and ignored by the receiver. Kuwahara et al. Expires December 2001 [Page 23] Internet Draft CL Tunneling for VPNs June, 2001 B.8.4 Hop Limit Exceeded This message is sent to the ingress PE when Hop Limit is exceeded. The message format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved |4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ...... |12 +-+-+-+-+-+-+-+-+-+- TYPE: Time Exceeded message type. It must be set to 16. CODE: It must be set to 0. Data: As much of the invoking packet as will fit without the CCMP packet exceeding the minimum MTU of the core network protocol. Reserved: It must be encoded as all '0' by the sender, and ignored by the receiver. B.8.5 Tunnel Redirection Notification A DF sends a Tunnel Redirection Notification message to the ingress PE for redirection. The message format is as follows: Kuwahara et al. Expires December 2001 [Page 24] Internet Draft CL Tunneling for VPNs June, 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved |4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Prefix Length | Reserved |8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |12 + + | |16 + Target Address + | |20 + + | |24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |28 + + | Resolved Core Network Address |32 + + | |36 + + | |40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TYPE: 8-bit unsigned integer. The Tunnel Redirection Notification message type. It must be set to 32. See Table B.1 for the allocation of values. CODE: 8-bit unsigned integer. The Tunnel Redirection Notification message class. See Table B.1 for the allocation of values. Address Type: 8-bit unsigned integer. It identifies the address type of the target address: IPv4 2 Other values are reserved. Prefix Length: 8-bit unsigned integer. This part represents the length of the prefix in the target address in bits. Reserved: It must be encoded as all '0' by the sender, and ignored by the receiver. Target Address: 128-bit unsigned integer. The target address for which redirection is requested to be initiated. Resolved Core Network Address: 128-bit unsigned integer. The core network address of the appropriate egress VFI. B.8.6 Tunnel Purge Notification Kuwahara et al. Expires December 2001 [Page 25] Internet Draft CL Tunneling for VPNs June, 2001 The egress PE sends a Tunnel Purge Notification message to the ingress PE to cancel redirection. The message format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | CODE | Reserved |4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Prefix Length | Reserved |8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |12 + + | |16 + Target Address + | |20 + + | |24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |28 + + | Resolved Core Network Address |32 + + | |36 + + | |40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TYPE: 8-bit unsigned integer. The Tunnel Purge Notification message type. It must be set to 33. See Table B.1 for the allocation of values. CODE: 8-bit unsigned integer. The Tunnel Purge Notification message class. See Table B.1 for the allocation of values. Address Type: 8-bit unsigned integer. It identifies the address type of the target address: IPv4 2 Other values are reserved. Prefix Length: 8-bit unsigned integer. It must be encoded as all '0' by the sender, and ignored by the receiver. Reserved: It must be encoded as all '0' by the sender, and ignored by the receiver. Target Address: 128-bit unsigned integer. The target address for which redirection is requested to be cancelled . Resolved Core Network Address: 128-bit unsigned integer. The core network address of the egress VFI. Kuwahara et al. Expires December 2001 [Page 26] Internet Draft CL Tunneling for VPNs June, 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to 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. Kuwahara et al. Expires December 2001 [Page 27]