16ng BoF Heejin Jang Internet-Draft Samsung-AIT Expires: August 27, 2006 Sangjin Jeong ETRI Syam Madanapalli Samsung-ISO February 23, 2006 Link-local Multicast Packet Transmission in 802.16 Networks draft-jang-16ng-llm-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes how the IPv6 Neighbor Discovery messages with link-local scope could be delivered with multicast CIDs in the 802.16 networks. Jang, et al. Expires August 27, 2006 [Page 1] Internet-Draft LLMulticast support in 802.16 networks February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Approach to link-local multicast packet transmission in 802.16 networks . . . . . . . . . . . . . . . . . . . . . . . 6 4. The creation and sharing mechanism of multicast link-local CIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. A distributed approach . . . . . . . . . . . . . . . . . . 7 4.2. A centralized approach . . . . . . . . . . . . . . . . . . 8 5. Link-local multicast packet transmission in 802.16 networks . 9 5.1. Link-local multicast packet transmission on a SS . . . . . 9 5.2. Link-local multicast packet forwarding on a BS . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Jang, et al. Expires August 27, 2006 [Page 2] Internet-Draft LLMulticast support in 802.16 networks February 2006 1. Introduction When a multicast-capable interface becomes enabled, the IPv6 node generates a few link-local addresses as well as a global address. It MUST join the all-nodes multicast address and solicited-node multicast address on that interface according to [RFC 2461]. If the node functions as a router, it also MUST join all-routers multicast address on that interface. The conventional IPv6 was designed based on assumption that lower layer will use 48 bit H/W address for the packet transmission. For a node to capture such link-local multicast packets in Ethernet and Wireless LAN, it generates a set of corresponding Ethernet addresses which are mapped one-to-one to link-local IPv6 address. That could be done by affixing well-known MAC prefix for IPv6 link-local multicast, 3333 (hexadecimal), to the last four octets of the IPv6 multicast address [RFC 2464]. So same multicast group members can share same MAC address as well as same IPv6 link-local multicast address and capture the packets of the multicast groups it belongs to. Therefore multicast MAC address sharing and the transmission of IPv6 packets with link-local scope are done in a distributed manner. On the other hand, the 802.16 [802.16] uses Connection ID (CID) for packet transmissions instead of 48-bit H/W address. Whether IEEE 802.16 Convergence Sublayer (CS) supports IPv6 over Ethernet or native IPv6, the IPv6 address finally should be mapped to CID for transmission, which necessitates a mechanism to share multicast CIDs among multicast group members. In this draft, we propose two approaches for creating and sharing multicast CIDs for IPv6 link- local multicast packet (llm-packet) transmission. Jang, et al. Expires August 27, 2006 [Page 3] Internet-Draft LLMulticast support in 802.16 networks February 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. BS (Base Station) A generalized equipment set providing connectivity, management, and control of the subscriber station (SS). SS (Subscriber Station) A generalized equipment set providing connectivity between subscriber equipment and a base station. Link-local multicast packet The IPv6 multicast packets with the link local scope such as Neighbor Solicitation, Neighbor Advertisement, Router Solicitation and Router Advertisement. CID (Connection Identifier) A16-bit value that identifies a connection to equivalent peers in the MAC of the base station and subscriber station. llm-CID (Link-local muticast CID) A CID shared among the member nodes of link-local multicast group. There are three llm-CIDs on a link, CIDs for all-nodes multicast, all-routers multicast, solicited-node multicast groups. llm-packet (Link-local muticast CID) Mulitcast packet with link-local scope among Neighbor Discovery messages. Currently NA, RA and unsolicited NS and RS. PDU (Protocol Data Unit) The data unit exchanged between peer entities of the same protocol layer. Packet CS (Packet Convergence Sublayer) Jang, et al. Expires August 27, 2006 [Page 4] Internet-Draft LLMulticast support in 802.16 networks February 2006 The sublay residing on top of the IEEE Std 802.16 MAC CPS (Common Part Sublayer). The CS utilizes the services of the MAC, performing classification, header suppression, transmission/receipt CS PDU to/from the peer MAC SAP etc. MBS (Multicast and Broadcast Service) Some globally defined service flows which may carry broadcast or multicast information that should be delivered to a plurality of SS or MS. MBS Contents Identifier TLV 16 bit vendor-specific or application-specific value which indicates the MBS services contents. Jang, et al. Expires August 27, 2006 [Page 5] Internet-Draft LLMulticast support in 802.16 networks February 2006 3. Approach to link-local multicast packet transmission in 802.16 networks To enable the transmission of llm-packets in 802.16 networks, [NDPCPA] suggests two approaches; by using common CID (CCID) for multicast and by emulating multicast with unicast transmission. With the later approach, the BS needs to copy and send original packets as many times as the number of multicast group members, requiring more processing in BS and network resource. Therefore, the proposed scheme is based on multicast CID sharing approach. To transmit llm-packets over the link with multicast CID, each CID should be shared per link-local group members prior to packet transmission. We classify multicast CID concept to three Link-local multicast CID (llm-CID) each of which is shared among the multicast group SSs. Currently there are three llm-CIDs on a link; for all- nodes multicast group, all-routers multicast group, solicited-node multicast group. In the next section, we suggest mechanisms for llm-CIDs sharing , and describes how to support llm-packet transmissions with such llm-CIDs. Jang, et al. Expires August 27, 2006 [Page 6] Internet-Draft LLMulticast support in 802.16 networks February 2006 4. The creation and sharing mechanism of multicast link-local CIDs We propose two approaches for sharing the llm-CIDs; one is a distributed approach without the intervention of BS and the other is a centralized approach controlled by BS. 4.1. A distributed approach As mentioned in Section 1, in Ethernet networks and Wireless LAN, all IPv6 nodes generate the 48-bit H/W addresses for all-nodes and solicited-node multicast according to [RFC 2464]. Routers additionally create it for all-routers multicast. In other words, IPv6 nodes generate several H/W addresses by themselves, and recognize llm-packets destined to each link-local multicast group. Therefore creation and sharing of common MAC address are done in a distributed manner without the intervention of centralized network entity like an access router or access point. This approach is efficient because it requires neither additional message exchanges nor additional BS processing for assigning and sharing llm-CIDs. The proposed distributed mechanism takes a similar approach and assumes all SSs agree to perform same operation as [RFC 2464] does. When the 802.16 network interface is initialized, a SS generates a set of corresponding llm-CIDs by affixing well-known prefix n bit for IPv6 link-local multicast, to the 16-n bit of the IPv6 multicast address. The well-known prefix will be allocated by IANA later and 'n' will be decided with much consideration in later version. The followings show simple example. If the SS's H/W address is 00: 04:75:AA:19:A7, the IPv6 link-local multicast addresses are generated according to [RFC 2373]. 1) FF02::1 (IPv6 all-nodes multicast address) 2) FF02::2 (IPv6 all-routers multicast address) 3) FF02::1:FFAA:19A7 (IPv6 solicited-node multicast address) For instance, if four bits are assigned for the llm-CID prefix, or n=4, and the value is 1100, then the corresponding CIDs are generated as follows. 1) 1100:0000:0000:0001 (All-nodes multicast CID) 2) 1100:0000:0000:0002 (All-routers multicast CID) 3) 1100:1001:1010:0111 (Solicited-node multicast CID) Jang, et al. Expires August 27, 2006 [Page 7] Internet-Draft LLMulticast support in 802.16 networks February 2006 4.2. A centralized approach While a distributed approach does not depends on BS, llm-CIDs are allocated by BS in a centralized approach. In this scheme llm-CIDs are not generated by each SSs but assigned by BS, and shared among SSs via some MAC messages for MBS (Multicast Broadcast Service). To create a connection for service flow in 802.16 networks, BS and SS exchange DSA-REQ & DSA-RSP messages prior to the packet transmission. A BS utilizes these messages to share llm-CIDs with SSs. When a SS has a initiating llm-packet, it exchanges DSA-REQ & DSA-RSP messages with BS for the flow. At this time the SS can send a DSA-REQ including MBS Contents Identifier TLV to request a llm-CID. MBS Contents Identifier is the 16 bit vendor-specific or application- specific value which indicates the MBS service contents. For example, for unsolicited NA and RA flow, MBS Contents CID TLV is set to the constants which indicate all-nodes multicast. In this approach, the constants for all-nodes, all-routers and solicited-node multicast service need to be assigned by IANA and should be well- known to SSs and BS in advance. As a response to a DSA-REQ, the BS responds with DSA-RSP including MBS Contents CID and corresponding llm-CID together. Note that when a BS is co-located with an access router, llm-CIDs can be decided among any available transport CIDs at BS's discretion (Single-BS access case in 802.16). However, if an access router is connected to more than one BS and llm-packets are multicasted synchronously across multiple BSs on the same channel(Multi-BS access case), the multicast CID should be selected among multicast CID ranges defined [802.16e]. A SS or BS may send a DSA-REQ including multiple MBS Contents TLVs at one time. For example, a SS can request llm-CIDs for all-nodes and solicited-node multicast together by putting MBS Contents TLVs and llm-CIDs in same order within each TLV field. Jang, et al. Expires August 27, 2006 [Page 8] Internet-Draft LLMulticast support in 802.16 networks February 2006 5. Link-local multicast packet transmission in 802.16 networks 5.1. Link-local multicast packet transmission on a SS When a SS has llm-packets to send, it encapsulates a native IPv6 packet or IPv6 within Ethernet packet with IEEE 802.16 header whose CID field is set to the corresponding llm-CID. In previous example, if a SS sends an RS, it attaches 802.16 header with CID set to 1100: 0000:0000:0002. 5.2. Link-local multicast packet forwarding on a BS There are two cases when a BS forwards llm-packets to SSs; one is the packets from an access router and another is the packets from the SSs on the link. When a BS receives a packets from an access router, the BS's CS performs the classification to match the service flows to the corresponding 802.16 connections. During the classification, BS maps the flows to CIDs based on IP address, port number, flow label, etc. If the packet is a llm-packet, BS fills the final 802.16 PDU's CID with llm-CID made according to Section 4. When a BS receives a packet from the SSs, it looks into the received packet's 802.16 header and checks whether the packet is llm-packet or not. In a distributed approach, this can be done simply by checking the CID's prefix n bit. If the packet is proved to a llm-packet, then the BS keeps the CID when it forwards to SSs finally. The packet also needs to be deliverd to the access router and neighboring BSs under same subnet. How to deliver the llm-packets depends on the kinds of CS and the deployed architectures, and for more detailed information refer to [IPTX80216]. Jang, et al. Expires August 27, 2006 [Page 9] Internet-Draft LLMulticast support in 802.16 networks February 2006 6. Security Considerations Further security considerations will be carefully studied along with this document. 7. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [802.16e] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 802.16e/D12, October 2005. [NDPCPA] Jeon, H. and J. Jee, "IPv6 NDP for Common Prefix Allocation in IEEE 802.16", draft-jeon-ipv6-ndp- ieee802.16-00 (work in progress), October 2005. [IPTX80216] Shin, M. and J. Hee, "Transmission of IPv6 Packets over IEEE 802.16", draft-shin-16ng-ipv6-transmission-00, February 2005. Jang, et al. Expires August 27, 2006 [Page 10] Internet-Draft LLMulticast support in 802.16 networks February 2006 Authors' Addresses Heejin Jang Samsung Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea Email: heejin.jang@samsung.com Sangjin Jeong ETRI 161 Gajeong-dong, Yusung-gu Daejeon 305-350 Korea Email: sjjeong@gmail.com Syam Madanapalli Samsung India Software Operations 66/1 Bagmane Tech Park Bangalore 560-093 India Email: syam@samsung.com Jang, et al. Expires August 27, 2006 [Page 11] Internet-Draft LLMulticast support in 802.16 networks February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jang, et al. Expires August 27, 2006 [Page 12]