One document matched: draft-kahng-6lowpan-global-connectivity-00.txt
6LowPAN Network Working Group Hyun K. Kahng
Internet Draft Dae-In, Choi
Expires: March 31, 2011 Korea University
Suyeon, Kim
Mobilab
October 14, 2010
Global connectivity in 6LoWPAN
draft-kahng-6lowpan-global-connectivity-00.txt
Abstract
This document specifies the translation mechanism mapping IPv6
address with 128 bits to the Adaptation Identifier (AID) with shorter
length. When a device in IEEE802.15.4 domain needs to communicate
with other nodes in IPv6 domain, it should acquire source AID and
destination AID corresponding to source IPv6 address and destination
IPv6 address, respectively from an IPv6 translation-capable gateway.
The device will send packets using those AIDs to the gateway, and
then the gateway will translate them to normal IPv6 addresses.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF). Note that
other groups may also distribute working documents as Internet-Drafts.
The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current.
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."
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Hyun-Kook Kahng Expires: March 31, 2011 [Page 1]
Internet-Draft Global-connectivity October 2010
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Global Connectivity in 6LoWPAN .............................. 3
3.1. AID for outbound traffic ............................... 4
3.2. AID for inbound traffic ................................ 4
3.3. AID Assignment in the Gateway .......................... 5
3.4. AID deletion in the Gateway ............................ 5
4. Mapping Table Global Connectivity in 6LoWPAN ................ 5
5. Messages for AID Assignment ................................. 6
6. Formal Syntax ............................................... 6
7. Security Considerations ..................................... 6
8. IANA Considerations ......................................... 6
9. References .................................................. 7
9.1. Normative References ................................... 7
9.2. Informative References ................................. 7
Authors' Addresses ............................................. 8
1. Introduction
IETF 6LoWPAN is an IPv6 based low-power wireless area network and has
been working for IPv6 packets to be sent to and received from over
IEEE 802.15.4 based networks for applications which require wireless
internet connectivity at lower data rates for devices.
However it is well known that the management of addresses for devices
that communicate across the two dissimilar domains of IPv6 and
IEEE802.15.4 is complicated. Routing itself is another problem
especially between the IPv6 domain and the IEEE802.15.4 domain.
IEEE802.15.4 standard packet size is 127 bytes, among which IEEE 64
bit extended addresses may be used. After an association, 16 bits are
used as a unique ID in a PAN L2, Still only 102 bytes are available
for payload at MAC layer. Now considering the devices need to
communicate with other nodes via IPv6 domain, 256 bits of the source
and destination addresses seem to be cumbersome in a limited MAC
payload fields.
It is obvious that the IP connectivity between 6LowPANs and the
global IPv6 networks is necessary. For this connectivity, [I-
D.6lowpan-interoperability] proposes the mapping of 16 bits short
Hyun-Kook Kahng Expires: March 31, 2011 [Page 2]
Internet-Draft Global-connectivity October 2010
address and the interoperability between 6LowPAN devices and the
external IPV6 networks. However this document does not specify
multiple network prefix address but does single network prefix
address to use 16 bit short addresses. In the case of the network
configuration for the connectivity between 6LowPANs and the external
IPv6 networks, multiple network prefix address must be considered for
several connections between them. So this document describes the AID
assignment mechanism in the gateway not only to support multiple
network prefix address but to map unique IPv6 address to AID with
short length.
This document is based on [Interoperability of 6LoWPAN] for the
adaptation layer of fragmentation and reassembly, the stateless
address auto-configuration based on EUI-64[EUI64].
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 [RFC2119].
Readers are expected to be familiar with all the terms and concepts
that are discussed in "IPv6 over Low-Power Wireless Personal Area
Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
Goals" [RFC4919], and "Transmission of IPv6 Packets over IEEE
802.15.4 Networks" [RFC4944].
AID : Adaptation IDentifier
3. Global Connectivity in 6LoWPAN
This section defines the gateway architecture for the Global
Connectivity between the global IPv6 nodes and 6LowPANs. Figure 1
shows the example of the IPv6 connection between the gateway and the
external IPv6 nodes.
---+------------------------------------
| Global IPv6 network |
| |
+-----+ +-----+
| | Gateway | | Outer Node
| | | |
+-----+ +-----+
Hyun-Kook Kahng Expires: March 31, 2011 [Page 3]
Internet-Draft Global-connectivity October 2010
|
+--------------+
| o |
| o o o o |
| o o o o o | Inner Node (IEEE 802.15.4)
| o o o o |
| o o o |
+--------------+
Figure 1: Gateway and node
3.1. AID for outbound traffic
Outbound traffic means the traffic from the inner node to the outer
nodes.
1. Each node in 6LowPAN checks if it has an AID identifying its own
global IPv6 address.
2. Each node can use the AID if it has. Unless, it should request the
new AID to the gateway.
3. Each node in 6LowPAN checks if it has an AID identifying its
corresponding global IPv6 address.
4. Each node can use the AID if it has. Unless, it should request to
new AID to the gateway.
5. Each node should request to the gateway to delete both AIDs if
they didn't use during a certain time.
3.2. AID for inbound traffic
Inbound traffic means the traffic from the outer node to the inner
nodes.
1. The Gateway checks if it has an AID identifying Source IPv6
address of the received inbound traffic.
2. The Gateway can use the AID if it has. Unless, it should assign
the new AID for Source IPv6 address in the inbound traffic.
Hyun-Kook Kahng Expires: March 31, 2011 [Page 4]
Internet-Draft Global-connectivity October 2010
3. The Gateway checks if it has an AID identifying Destination IPv6
address of the received inbound traffic.
4. The Gateway can use the AID if it has. Unless, it should assign
the new AID for Destination IPv6 address in the inbound traffic.
5. Each node should request to the gateway to delete both AIDs if
they didn't use during a certain time.
3.3. AID Assignment in the Gateway
An AID must be assigned by the Gateway according to the following
assignment method. The length of an AID being assigned is not defined
in this document.
1. If the Gateway receives the AID request message for the specific
IPv6 address, it looks up its own address mapping table for the
specific IPv6 address.
2. If the Gateway finds the AID matched with the specific IPv6
address, it will return the AID. Otherwise, it will generate and
return the new AID not to be duplicated.
3.4. AID deletion in the Gateway
An AID must be deleted by the Gateway according to the following
deletion method.
1. If the Gateway receives the AID delete message for the specific
AID, it looks up its own address mapping table for the AID.
2. If the Gateway finds the AID, it will delete the AID. Otherwise,
it neglects the messages.
4. Mapping Table Global Connectivity in 6LoWPAN
Gateway has the address mapping table as shown in Figure 2. The
length of Global IPv6 address field is 128 bits. The length of AID is
TBD.
+--------------------------------------+
|Global IPv6 address| AID |
+--------------------------------------+
Figure 2: Address Mapping Table
Hyun-Kook Kahng Expires: March 31, 2011 [Page 5]
Internet-Draft Global-connectivity October 2010
5. Messages for AID Assignment
The format shown in Fig 3 was used in communications to assign AID
between internal nodes and gateway. We defined three kinds of
messages related to AID assignment: AID REQUEST message, AID REPLY
message and AID DELETE message. Each AID will represent its
corresponding global IP address. The packets will be defined as
follows:
Message Types IPv6 dispatch value
AID REQUEST 01010001
AID REPLY 01010010
AID DELETE 01010011
Figure 3: Message Types for AID Assignment
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [RFC2234].
7. Security Considerations
TBD
8. IANA Considerations
TBD
Hyun-Kook Kahng Expires: March 31, 2011 [Page 6]
Internet-Draft Global-connectivity October 2010
9. References
9.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version6
(IPv6) Specification", RFC 2460, December 1998.
[ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003",
October 2003.
[RFC4919] N. Kushalnagar, G. Montenegro, C. Schumacher, "IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs): Overview,
Assumptions, Problem Statement, and Goals", RFC4919, August 2007.
[RFC4944] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
RFC4944, September 2007.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
9.2. Informative References
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY", IEEE,
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC4862, September 2007.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology
Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684,
February 2004.
[I-D.6lowpan-interoperability] Ki-Hyung Kim, Seung Wha Yoo, Hee Jung
Kim, Soohong Daniel Park, Jae Ho Lee, "Interoperability of 6LoWPAN",
draft-daniel-6lowpan-interoperability-01, July 2005
[I-D. 6lowpan-backbone-router] Pascal Thubert, "6LoWPAN Backbone
Router", draft-thubert-6lowpan-backbone-router-02, June 2010
Hyun-Kook Kahng Expires: March 31, 2011 [Page 7]
Internet-Draft Global-connectivity October 2010
Authors' Addresses
Hyun K. Kahng
Korea University
Electronic Information Engineering
Seoul, Korea
Email: kahng@korea.ac.kr
Dae-In Choi
Korea University
Electronic Information Engineering
Seoul, Korea
Email: nbear@korea.ac.kr
Suyeon, Kim
Mobilab
Daegu, Korea
Email: sykim@mobilab.co.kr
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Telecommunication Technology Association (TTA)
Hyun-Kook Kahng Expires: March 31, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 17:26:11 |