One document matched: draft-jang-16ng-llm-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:12:42 |