Internet Engineering Task Force Sander van Valkenburg INTERNET-DRAFT Nokia draft-valkenburg-fleming-bluetooth-pan-00.txt Kris D. Fleming July 13 2001 Intel Expires: December 13, 2001 Bluetooth SIG PAN Profile and BNEP protocol design considerations Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 0 of RFC2026 except that the right to produce derivative works is not granted. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 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 memo provides an overview of the Bluetooth Personal Area Networking Profile and the Bluetooth Network Encapsulation Protocol specification as developed by the Bluetooth SIG Personal Area Networking working group, and describes design considerations of the Bluetooth SIG PAN Working Group in developing these specifications. S. Valkenburg, K. Fleming [Page 1] Internet Draft PAN Profile design consideration July 13, 2001 Table of Contents 1. Introduction 2 2. Structure of the Bluetooth networking protocol stack 3 3. Bluetooth SIG Personal Area Networking Working Group 4 3.1 Charter 4 3.2 Timeline 5 4. BNEP architecture design considerations 5 4.1 Design criteria 5 4.2 Considered alternatives 5 4.3 Design considerations 5 5. Bluetooth PAN Specifications, phase 1 6 5.1 Bluetooth Network Encapsulation Protocol (BNEP) 7 5.2 Bluetooth PAN Profile 8 5.2.1 Required IP functionality 10 5.2.3 Different roles in the Bluetooth PAN Profile 10 6. Conclusions 10 7. Glossary of terms 11 8. References 11 1. INTRODUCTION This memo provides an overview of the Personal Area Networking specifications, phase 1, including design considerations that have led the Bluetooth SIG PAN Working Group to specify the PAN Profile [1] and the Bluetooth Networking Encapsulation Protocol [2] in its current form. The structure of this document is as follows: first the Bluetooth networking stack will be explained (Section 2), after which an overview of the PAN Working Group will be given (Section 3). Then the specifications of the PAN Profile will be discussed (Section 4), and architectural design choices that led to these specifications (Section 5). Finally some concluding remarks will be given (Section 6). The Bluetooth Special Interest Group (SIG) has been formed to specify a global standard for short-range low-power wireless communications in the license-free 2.4GHz ISM band. The Bluetooth SIG includes promoter companies, 3COM, Ericsson, IBM, Intel, Lucent, Microsoft, Motorola, Nokia and Toshiba, and more than 2000 Adopter/Associate member companies. The Bluetooth specifications target a small- form factor, low-cost radio solution providing links between mobile computers, mobile phones and other portable handheld devices, and connectivity to the Internet. The usage models that the specifications attempt to solve mainly relate to cable replacement, and networking to a limited extent. The goal of the Bluetooth SIG is the development of interoperable products. To achieve this, license free specifications (under conditions defined by membership agreement) are created for its members for developing and manufacturing products and software using the Bluetooth specification. In order to adopt the Bluetooth specifications for products, the SIG membership agreement has to be signed. This agreement includes a license free Intellectual Property policy, strict qualification requirements for Bluetooth-compliant products, and a confidentiality rule. The Bluetooth specifications consist of three parts: the Core specification, the Profile specifications, and Test specifications. The Core part specifies S. Valkenburg, K. Fleming [Page 2] Internet Draft PAN Profile design consideration July 13, 2001 components such as the radio, Baseband, link manager, service discovery protocol, transport layer, and interoperability with different communication protocols. The Profiles part specifies the protocols and procedures required for different types of Bluetooth applications. Section 2 will discuss the specifications in more detail. 2. STRUCTURE OF THE BLUETOOTH NETWORKING PROTOCOL STACK When mapping the generic OSI networking reference model to the Bluetooth specification, the OSI physical layer is represented by the Bluetooth Radio. The part of the data link layer (MAC) is represented by the Baseband, and the upper part by L2CAP, and the Link Manager Protocol as link setup and management entity. The PAN Profile defined the Bluetooth Networking Encapsulation Protocol as network adaptation layer between the Bluetooth data link layer and the IP layer. The complete networking reference stack for the PAN Profile is shown in Figure 1. +-------------------------+ | Networking applications | +-------------------------+ | TCP/UDP | +-------------------------+ | IP | +-------------------------+ +-------+ | BNEP | | SDP | +-------------------------+----+-------+ | L2CAP | LMP | +------------------------------+-------+ | Bluetooth Baseband | +--------------------------------------+ | Bluetooth Radio | +--------------------------------------+ Figure 1. Bluetooth PAN reference model The Bluetooth Radio follows a hopping sequence, which is dictated by the master of the piconet, and followed by all the active slaves (up to seven in total). Channel access by the slaves is permitted in the timeslot following the reception of a packet from the master. The Bluetooth Baseband layer provides mixed links within a piconet i.e. circuit- switched and packet-switched links. Synchronous Connection-Oriented (SCO) links are used for symmetric, synchronous services; such links have a slot reservation at fixed intervals and can be used for services such as voice. Asynchronous Connection-Less (ACL) links are provided for packet-switched, asynchronous services, which may be asymmetric as well. L2CAP mandates the use of ACL links. Also packets of different slot lengths are provided by the Baseband layer (one- slot, three-slot and five-slot packets). Neither a protocol identifier nor a length field is present in Baseband packets. Also segmentation and reassembly is not provided by the Baseband protocol layer. Both are provided by the Logical Link Control and Adaptation Protocol (L2CAP). S. Valkenburg, K. Fleming [Page 3] Internet Draft PAN Profile design consideration July 13, 2001 L2CAP defines a channel for each higher layer protocol connection with each slave to serve both protocol multiplexing and segmentation and reassembly, resulting in a four-byte packet header. Additionally, QoS parameters may be negotiated between two L2CAP peer entities. Every Bluetooth device has a 'Bluetooth Device Address' (BD_ADDR), which is a 48-bit globally unique IEEE address. The Bluetooth Network Encapsulation Protocol (BNEP) uses these addresses in an Ethernet-like header, for the source and destination address of hosts in the same logical subnet. This hides the star-topology, inherent to the master-slave relationship that exists at Baseband level, and the non-symmetric availability of broadcast and multicast. On top of BNEP, the Internet Protocol operates similar to the way it operates on top of Ethernet, as all protocols that operate on top of Ethernet will work on top of BNEP. The same applies to TCP and UDP at the transport layer, and session and application layer protocols, here referred to as 'networking applications'. 3. BLUETOOTH SIG PERSONAL AREA NETWORKING WORKING GROUP After the Bluetooth core specifications and a number of key application profiles were specified and released to the public in July 1999, the Bluetooth SIG started up several new working groups, chartered to develop more application profiles (as well as a working group chartered to develop both new (high-rate) and improved radio specifications). These groups were started in January 2000. The Personal Area Networking (PAN) working group was one of the newly formed working groups; its mission is to "Define/reference dynamic ad-hoc IP-based personal networking." The charter of PAN working group is described in Section 3.1 and its timeline (goals and milestones) are presented in Section 3.2. 3.1 Charter Upon creation of the working group, the following was given as basis for the charter [3]: "PAN networking enables multi-user collaboration by creating ad-hoc IP-based personal area networks." The working group scope is limited to the IP protocol suite, meaning IPv4 and IPv6. The solution must also be backward compatibility to Bluetooth v1.1 specifications for Baseband and L2CAP. The existence of any special purpose products or infrastructure is not required for operation, but it will inter- operate with such devices if they exist, to (a) facilitate the ad-hoc network or (b) provide LAN access to a separate wired (or wireless) network. Also, the focus must be on reuse of (preferably) royalty-free specifications. The working assumptions as defined by the working group restrict participation in a PAN to IP capable devices (or devices represented to the network by an IP capable proxy device). The current PPP solution is recognized to not scale to operate efficiently in an ad-hoc network. Finally, a phased approach is taken, as the working group recognizes that the final solution for IP based ad-hoc networking may take many years to develop. Therefore, the working group expects to develop a series of solutions, each solution providing more and more features. S. Valkenburg, K. Fleming [Page 4] Internet Draft PAN Profile design consideration July 13, 2001 3.2 Timeline After its first meeting in January 2000, the PAN working group delivered phase 1 of the specifications by August 2001. The working group decided to take a phased approach for the development of a solution for IP-based ad-hoc networking, as it was recognized that proprietary solutions could be emerging before a complete solution would be developed, impairing interoperability. 4. BNEP ARCHITECTURE DESIGN CONSIDERATIONS The PAN specifications were designed with the charter (see also chapter 3) and a set of identified reference usage models as starting point. This section gives insight into the design considerations that were made. 4.1 Design criteria The PAN specifications have to meet general design criteria, and some criteria that specifically apply to phase 1 of the PAN specifications (phase 1 for single piconet personal area networking, phase 2 for scatternets). The criteria are discussed below in this order. First of all, the solution has to support IP. Support for other networking protocols is optional. Supporting IP means support for both IPv4 and IPv6. The solution has to support Bluetooth specifications v1.1 for Baseband and L2CAP. In order to align with the general objectives of Bluetooth, the solution has to support both resource-constraint devices such as mobile phones and PDAs, as well as devices with less constraint with respect to power, memory and computational capabilities such as laptop computers. Since a phased approach was taken, the initial specification provides a solution for IP-based ad-hoc networking for a single Bluetooth Piconet. This solution must be extensible towards the second phase (inter-piconet routing), and towards enabling support for mobility. Additionally, stand-alone ad-hoc networking as well as improved network access (as compared to the LAN Access Profile) must be possible with the same solution. Finally, the solution must contain provisions for security, in such a way that it does not decrease the level of security provided by the Bluetooth Core specifications. 4.2 Considered alternatives The main discussion for solving IP-based ad-hoc networking over Bluetooth concentrated on the protocol layer to perform the routing/forwarding at. Routing/forwarding at layer 3 (IP Layer), as well as forwarding/'smart bridging' at layer 2 (sub-IP layer or Data Link Layer) were considered. The considered alternative solutions are briefly described. The main alternative for a complete IP-based solution was MANET-style IP routing, which basically would be the application of a MANET routing protocol at the Piconet master for all incoming IP traffic. An alternative solution inherited from the work on the LAN Access Profile, PPP (without HDLC framing) directly on the Bluetooth link layer, was not considered a strong contender. S. Valkenburg, K. Fleming [Page 5] Internet Draft PAN Profile design consideration July 13, 2001 A complete link layer based solution was the counter-proposal to the IP-based solution, where a MANET routing protocol would be applied on the link layer, routing packets based on their MAC address (which is an IEEE-EUI 48-bit address in the case of Bluetooth). Finally, the alternative that received most appreciation proposed link layer forwarding within a single piconet. Inter-piconet routing would not be considered and solved until phase 2, where the freedom of performing that routing at layer 2 or at layer 3 would still be present. 4.3 Design considerations The selection process of the most favorable alternative, as presented in section 4.2, was made on a qualitative basis, where the advantages and disadvantages of the different alternatives were compared. This prevailed over quantitative analysis, since all solutions are expected to perform well within the scope of a single piconet. The presentation of Bluetooth as networking interface to the IP stack was a primary consideration. Bluetooth should not be anything more than 'another' interface, meaning one could plug in a Bluetooth interface in a device with a networking stack, install the appropriate driver, and be able to communicate. >From this point of view, changes to the IP stack are undesirable implications. The same applies to the level of support for both IPv4 and IPv6 i.e. separate solutions need to be developed for both IPv4 and IPv6. Support for other, non-IP protocols is an additional advantage. Emulating a known and widely used medium below IP (Ethernet) provides support for any networking protocol. Requirements from the IP layer and above are the support for broadcast and multicast at the link layer. Experiences with other communication technologies shows that IP works far better on media that naturally support such point-to- multipoint capabilities, than on media that have to create such support artificially. Bluetooth does not have this point-to-multipoint support naturally either. However, every Bluetooth device has an IEEE-administered hardware address. This address space also supports multicast and broadcast addresses, in a way that naturally fits IP. The only thing lacking is mapping these point-to- multipoint capabilities to the Bluetooth Piconet topology, which can easily be done by the piconet master, since it is in control of the piconet. Zeroconfiguration of IP addresses and other IP interface parameters, using mechanisms such as those defined by the Zeroconf working group, need to be supported in order to provide a user-friendly way of stand-alone ad-hoc networking and infrastructure access, as well as migration between these two scenarios. Added to this consideration, flexible dynamic access to external (non-Bluetooth) networks also has to be supported in order to meet the design criteria (see section 4.1). For this, the emulation of a single Ethernet segment as provided by BNEP provides a degree of freedom for a Network Access Point, to either be a router or a bridge, as well as flexible support for the above mentioned design considerations. 5. BLUETOOTH PAN SPECIFICATIONS, PHASE 1 The PAN Profile specifications, phase 1, consists of two parts. The Bluetooth Network Encapsulation Protocol is the adaptation layer hiding the Bluetooth specifics, and described in Section 5.1). The PAN Profile specifies how to use S. Valkenburg, K. Fleming [Page 6] Internet Draft PAN Profile design consideration July 13, 2001 the different building blocks of the Bluetooth Core specifications [4] and other protocol layers, such that interoperability is ensured. The main features are described in Section 4.2. 5.1 Bluetooth Network Encapsulation Protocol (BNEP) The design considerations described in Section 4 led to the development of the Bluetooth Network Encapsulation Protocol (BNEP). BNEP hides Bluetooth specifics, including the piconet topology, and emulates a broadcast network segment. This is based on the format of a widely used local area networking technology, Ethernet. Extensions are added to this to increase efficiency of operation, to suit general demands by wireless communication and battery operated devices. Also the concept of extension headers is added to provide support for adding additional capabilities and for support in phases 2. BNEP encapsulates IP packets in BNEP packets, which in turn are encapsulated in L2CAP packets. The header format is shown in Figure 2. BNEP encapsulated packets are used to transport packets between two link-layer end-points on an IP segment. The IP segment can extend beyond the Bluetooth network, if connected to another (wired or wireless) network by a bridge. An L2CAP packet containing a BNEP packet is carried over an L2CAP channel for BNEP, established using the PSM value assigned to BNEP [5]. 0 1 2 3 4 5 6 7 15 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............ | BNEP Type |E| BNEP packet based on BNEP Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............ Figure 2. BNEP header format. The basic BNEP type for data transmissions consists of the BNEP Type field and the Ethernet header (as defined in [6]), see Figure 3. 0 1 2 3 4 5 6 7 15 23 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BNEP Type |E| Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Networking Protocol Type | EH/Payload ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Basic BNEP header format for data transmissions. BNEP fields: BNEP Type 7-bit BNEP header type = 0x01 Extension Flag (E) 1-bit extension flag that indicates if one or more extension headers follow the BNEP header before the data payload. S. Valkenburg, K. Fleming [Page 7] Internet Draft PAN Profile design consideration July 13, 2001 Destination Address 48-bit Bluetooth device address/IEEE address of the destination of the BNEP packet/Ethernet frame contained in the payload. IEEE broadcast and addresses are used for broadcast and multicast packets. Source Address 48-bit Bluetooth device address/IEEE address of the source of the BNEP packet/Ethernet frame contained in the payload. Networking Protocol Type 6-bit type field identifies the type of networking protocol contained in the payload. The values for this field are the same as defined for Ethernet types [6]. EH/Payload BNEP extension header(s) and/or BNEP payload. During setup of each Bluetooth connection between two devices, the BD_ADDR of the peer devices is learned during Baseband setup procedure. This address is subsequently associated with the L2CAP channel for BNEP (see [4] for details). The source and/or destination address can therefore be left out in some cases, as a means to reduce the amount of overhead introduced by BNEP. Three header formats have been defined for this purpose. For direct communication between a piconet master and slave, both the source and destination addresses may be left out. In other situations, either the source or destination address may be left out. Additionally, BNEP connection control messages have been defined. Before completion of the BNEP connection setup, the initiator has to indicate the roles of both end-points. For bandwidth saving purposes, protocol and multicast filter commands have been defined to indicate which protocol types and multicast addresses a PANU wants to receive. All these control messages have to be confirmed before the new configuration applies. For future extension of BNEP, extension headers have been defined. These extension headers follow the BNEP header. The format of these extension headers is similar to the IPv6 extension headers, with a type-length-value encoding. 5.2 Bluetooth PAN Profile A Bluetooth "Profile" specifies the protocols and procedures required for different kind of applications. In the case of the PAN Profile, the protocols and procedures that enable IP networking over Bluetooth are specified. This includes the behavior reflecting the role of a device in a Bluetooth PAN, as well as how to use certain protocols at certain levels. The minimal set of IP functionality is described in Section 5.2.1, other supported functionality is described in Section 5.2.2.The different roles of devices participating in a PAN are described in Section 5.2.3. 5.2.1 Required IP functionality As the PAN Profile defines IP networking over Bluetooth, a minimal set of IP protocols is required. The PAN Profile mandates that IPv4 and/or IPv6 is S. Valkenburg, K. Fleming [Page 8] Internet Draft PAN Profile design consideration July 13, 2001 supported. IP operates on top of BNEP (see Section 5.1). The minimal set of RFCs identified to support IP in an interoperable way is listed in Table 1 for IPv4 and in Table 2 for IPv6. Additionally, some functionality is strongly recommended. The corresponding RFCs are also listed for each version. Inclusion of additional RFCs is optional for PAN-capable devices. Mandatory RFCs: RFC Number Description 0791 Internet Protocol 0792 Internet Control Message Protocol 0826 An Ethernet Address Resolution Protocol 0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks 0919 Broadcasting Internet Datagrams 0922 Broadcasting Internet Datagrams In The Presence Of Subnets 0950 Internet Standard Subnetting Procedure 1112 Host Extensions for IP Multicasting 1122 Requirements for Internet Hosts -- Communication Layers 1123 Requirements for Internet Hosts -- Application and Support Recommended RFCs: RFC Number Description 1034 Domain Names - Concepts And Facilities 1035 Domain Names - Implementation And Specification 1256 ICMP Router Discovery Messages 2131 Dynamic Host Configuration Protocol 2132 DHCP Options and BOOTP Vendor Extensions Table 1: IPv4 RFCs RFC Number Description 1981 Path MTU Discovery for IP version 6 2373 IP Version 6 Addressing Architecture 2374 An IPv6 Aggregatable Global Unicast Address Format 2460 Internet Protocol, Version 6 (IPv6) Specification 2461 Neighbor Discovery for IP Version 6 (IPv6) 2462 IPv6 Stateless Address Autoconfiguration 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification 2464 Transmission of IPv6 Packets over Ethernet Networks 2526 Reserved IPv6 Subnet Anycast Addresses Recommended RFCs: RFC Number Description 1034 Domain Names - Concepts And Facilities 1035 Domain Names - Implementation And Specification 1886 DNS Extensions to support IP version 6 Table 2. IPv6 RFCs S. Valkenburg, K. Fleming [Page 9] Internet Draft PAN Profile design consideration July 13, 2001 The set of recommended RFCs is recognized to be part of the minimal IP functionality. However, certain resource-constraint devices may never use this functionality. E.g. devices that do not have a user interface will not invoke name-to-address resolution, or devices that only communicate on their local IP subnet will not need stateful address autoconfiguration. 5.2.2 Other supported functionality In addition to the IP functionality descibed in Section 5.2.1, other protocols are enabled by the PAN Profile. The IEEE 802.1p standard for packet priority and 802.1x for link layer authentication and key exchange and supported by the PAN Profile as optional mechanisms. 5.2.2 Different roles in the Bluetooth PAN Profile The Bluetooth PAN Profile defines three roles and two configurations. Their functionality is discussed in this section. The PAN Profile identifies two configurations of a Bluetooth PAN, one where the PAN is connected to an external network via a Network Access Point (NAP), and one where the PAN operates completely stand-alone. The latter is controlled by the Group Ad-hoc Node (GN). In both cases, the Bluetooth device that uses the respective services of these devices (NAP service and GN service) is the PAN User (PANU). The support of different roles is discovered using the Bluetooth Service Discovery Protocol [4]. A Bluetooth device that supports the NAP service is a device that provides some of the features of an Ethernet bridge to support network services. The device with the NAP service forwards BNEP packets between each of the connected Bluetooth devices (PANUs). The device with the NAP service has an additional network connection to a different network media in which the Ethernet packets are either exchanged via Layer 2 bridging or Layer 3 routing mechanism. These devices may require additional functionality when bridging to additional networks, (e.g. GPRS). A Bluetooth device that supports the GN service is able to forward Ethernet packets to each of the connected PANUs. GNs do not provide access to any additional networks. Instead, GNs are intended to allow a group of devices to form temporary networks and exchange information. A PANU is the Bluetooth device that uses either the NAP or the GN service. PANU supports the client role for both the NAP and GN roles. The PANU has a BNEP connection with the NAP or GN. A PANU must become a piconet slave if the NAP or GN is configured in multi-user mode. The NAP and GN forward BNEP packets between PANUs according to the IEEE 802.1D standard [7], where each BNEP connection is regarded as a valid Bridge Port. Depending on the protocol and multicast filters, this may apply to the forwarding of broadcast and multicast packets, even though it is recognized that this is wasteful of the piconet bandwidth in case more than one PANU is connected. S. Valkenburg, K. Fleming [Page 10] Internet Draft PAN Profile design consideration July 13, 2001 6. CONCLUSIONS This memo provided an overview of the Bluetooth PAN Profile and the BNEP specification as developed by the Bluetooth SIG Personal Area Networking working group, and describes some of the design decisions. PAN Profile and BNEP present an Ethernet-like interface on top of Bluetooth, which supports the various networking protocols, including IPv4 and IPv6. Often the additional overhead of BNEP is only 3 bytes, but the benefit of BNEP outweighs this additional overhead by providing a broadcast medium towards the networking layer, support for IEEE 802.1p (Packet Priority), IEEE 802.1x (link layer authentication and key exchange), and support for a wide array of networking protocols. 7. GLOSSARY OF TERMS BNEP Bluetooth Network Encapsulation Protocol GN Group Ad-hoc Network GPRS General Packet Radio Service NAP Network Access Point IP Internet Protocol L2CAP Logical Link Control and Adaptation Protocol LAN Local Area Network LMP Link Manager Protocol PAN Personal Area Network PANU Personal Area Network User 8. REFERENCES [1] Bluetooth Special Interest Group, "Bluetooth PAN Profile", Specification of the Bluetooth System, Version 0.95, May 6, 2001 [2] Bluetooth Special Interest Group, "Bluetooth Network Encapsulation Protocol (BNEP) Specification", Specification of the Bluetooth System, Version 0.95, May 6, 2001 [3] Bluetooth Special Interest Group, "Bluetooth Personal Area Networking (PAN) Charter, http://www.bluetooth.org/member/pan-charter.htm, [4] Bluetooth Special Interest Group, "Bluetooth Core", Specification of the Bluetooth System, Version 1.1, February 22, 2001 [5] Bluetooth Special Interest Group, "Bluetooth Assigned Number", Specification of the Bluetooth System, Version 1.1, December 1, 2000 [6] http://www.iana.org/assignments/ethernet-numbers [7] ISO/IEC 10038:1998 [ANSI/IEEE Std 802.1D-1998], Information technology- Telecommunications and information exchange between systems-Local area networks-Media Access Control (MAC) bridges. 9. ACKNOWLEDGEMENTS The authors would like to thank the members of Bluetooth SIG Personal Area Networking working group for their comments and input. S. Valkenburg, K. Fleming [Page 11] Internet Draft PAN Profile design consideration July 13, 2001 10. AUTHORS' ADDRESSES Sander van Valkenburg Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI FINLAND Phone: +358 7180 37360 E-mail: sander.van-valkenburg@nokia.com Kris Fleming Intel Corporation 5000 W. Chandler Blvd. Chandler, AZ USA Phone: +1 480 554-1371 E-mail: Kris.D.Fleming@Intel.com S. Valkenburg, K. Fleming [Page 12]