One document matched: draft-kahng-6lowpan-global-connectivity-01.txt
Differences from draft-kahng-6lowpan-global-connectivity-00.txt
6LowPAN Network Working Group Hyun K. Kahng
Internet Draft Dae-In, Choi
Expires: September 30, 2011 Korea University
Suyeon, Kim
Mobilab
March 12, 2011
Global connectivity in 6LoWPAN
draft-kahng-6lowpan-global-connectivity-01.txt
Abstract
This document specifies the translation mechanism mapping IPv6
address with 128 bits to the Adaptation Identifier (AID) with 16 bits.
When a device in IEEE 802.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 node will
send packets using these AIDs to the gateway, and then the gateway
will translate them to normal IPv6 addresses using the mapping table
already associated.
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) 2011 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
Hyun-Kook Kahng Expires: September 30, 2011 [Page 1]
Internet-Draft Global-connectivity March 2011
Simplified BSD License text as described in Section 4.e of the Trust
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............................... 4
3.1. AID for outbound traffic................................ 4
3.2. AID for inbound traffic................................. 5
3.3. AID Assignment in the Gateway........................... 5
3.4. AID deletion in the Gateway............................. 5
4. Mapping Table Global Connectivity in 6LoWPAN ................. 6
5. Frame Format for AID Assignment.............................. 6
5.1. AID REQUEST frame....................................... 8
5.2. AID REPLY frame......................................... 8
5.3. AID DELETE frame........................................ 9
5.4. LOWPAN_GCHC frame....................................... 9
6. Formal Syntax ............................................... 9
7. Security Considerations...................................... 9
8. IANA Considerations ........................................ 10
9. References ................................................. 10
9.1. Normative References................................... 10
9.2. Informative References................................. 10
Authors' Addresses ............................................ 11
1. Introduction
IETF 6LoWPAN Working Group 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. 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.
Hyun-Kook Kahng Expires: September 30, 2011 [Page 2]
Internet-Draft Global-connectivity March 2011
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
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 also to map unique IPv6 address to AID
with short length. The encoding of AID utilizes 2 bytes; 1 byte is
used for identifying each node in IEEE 802.15.4. The other 1 byte is
used for identifying the external IPV6 node connected with the node
of IEEE 802.15.4. How the value of AID is determined in the gateway
is out of scope.
As a result, this document defines an encoding format, LOWPAN_GCHC,
for effective compression of Global IPv6 address based on shared
state with AID. In addition, this document also introduces additional
frame format over the header compression format defined in [RFC 4944]
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].
The term "byte" is used in its now customary sense as a synonym for
"octet".
AID : Adaptation Identifier
GCHC : Global Connectivity Header Compression
Hyun-Kook Kahng Expires: September 30, 2011 [Page 3]
Internet-Draft Global-connectivity March 2011
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. The gateway performs new AID assignment
operation to be mapped with IPV6 address by the request of IEEE
802.16 node and executes translation operation which maps IPv6
address encoded with 16 bytes to AID with 2 bytes to compress packet
header and vice versa.
---+------------------------------------
| Global IPv6 network |
| |
+-----+ +-----+
| | Gateway(AID translation) | | Outer Node
| | | |
+-----+ +-----+
|
+--------------+
| 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.
Hyun-Kook Kahng Expires: September 30, 2011 [Page 4]
Internet-Draft Global-connectivity March 2011
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.
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 2 bytes.
1. If the Gateway receives the AID request frame 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.
Hyun-Kook Kahng Expires: September 30, 2011 [Page 5]
Internet-Draft Global-connectivity March 2011
1. If the Gateway receives the AID delete frame 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 frame.
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
16 bits.
+--------------------------------------+
|Global IPv6 address| AID |
+--------------------------------------+
Figure 2: Address Mapping Table
5. Frame Format for AID Assignment
The format shown in Figure 3 and Figure 4 are the payload in the
IEEE 802.15.4 MAC protocol data unit (PDU). The Frame format was
used in communications to assign AID between internal nodes and
gateway. Each AID will represent its corresponding global IP address.
The Frame format is defined in Figure 3.
+-----------------------------------------------+
| AID Message Dispatch | AID Message Parameters |
+-----------------------------------------------+
Figure 3: A LoWPAN encapsulated AID Assignment Frame
The details of AID Message Parameters are defined below in Section 6.
The encapsulation format defined in Figure 4 defines LOWPAN_GCHC
encoding format for compressing the IPv6 header. To enable effective
compression LOWPAN_GCHC relies on AID information pertaining to AID
Assignment Frame.
Hyun-Kook Kahng Expires: September 30, 2011 [Page 6]
Internet-Draft Global-connectivity March 2011
+-------------------------------------------------------------------+
|LOWPAN_GCHC Dispatch | LOWPAN_GCHC(4)| In-line IPv6 Header Fields |
+-------------------------------------------------------------------+
Figure 4: LOWPAN_GCHC Frame
We defined three kinds of frames related to AID assignment as shown
Figure 5: AID REQUEST frame, AID REPLY frame and AID DELETE frame.
The document allocates the following 3 dispatch type field values for
these frame types and 1 dispatch type field value for LOWPAN_GCHC.
Figure 5 shows new dispatch value bit pattern as updating Figure 2 in
[RFC 4944].
+-----------------------------------------+
| Pattern | Header Type |
+-----------------------------------------+
| 00 xxxxxx | NALP |
| 01 000001 | IPv6 |
| 01 000010 | LOWPAN_HC1 |
| 01 000011 | Reserved |
| ... | Reserved |
| 01 001111 | Reserved |
| 01 010000 | LOWPAN_BC0 |
| 01 010001 | AID REQUEST |
| 01 010010 | AID REPLY |
| 01 010011 | AID DELETE |
| 01 010100 | LoWPAN_GCHC |
| ... | Reserved |
| 01 111110 | Reserved |
| 01 111111 | ESC |
| 10 xxxxxx | MESH |
| 11 000xxx | FRAG1 |
| 11 001000 | Reserved |
| ... | Reserved |
| 11 011111 | Reserved |
| 11 100xxx | FRAGN |
| 11 101000 | Reserved |
| ... | Reserved |
| 11 111111 | Reserved |
+-----------------------------------------+
Figure 5: Dispatch Value Bit Pattern
AID REQUEST : Specifies that the frame is an AID request frame.
Hyun-Kook Kahng Expires: September 30, 2011 [Page 7]
Internet-Draft Global-connectivity March 2011
AID RESPONSE : Specifies that the frame is an AID response frame.
AID DELETE : Specifies that frame is an AID delete frame.
LOWPAN_GCHC : Specifies that following header is a LOWPAN_GCHC
compressed IPV6 header.
5.1. AID REQUEST frame
In case that the node in 6LowPAN needs a new IPV6 connection with the
external node in IPV6 network, the node must send AID REQUEST frame
to the gateway. The source address and destination address must set
to its source address and the destination address of the external
node respectively. To get new source AID and destination AID, both
AID must be set to zero. The format of AID REQUEST frame is in Figure
6.
+-------------------------------------------------------------------+
| 01010001 | Src.address | Src.AID(2) | Dst.Address | Dst. AID(2) |
| | (16) | 0x0000 | (16) | 0x0000 |
+-------------------------------------------------------------------+
Figure 6: AID REQUEST frame format
5.2. AID REPLY frame
As the response of AID REPLY frame, the gateway must reply to the
node in 6LowPAN by sending AID REPLY frame. In case of AID REPLY
frame, the frame must be sent to the node in 6LowPAN from the gateway.
The gateway must assign unique values as the values of source AID and
destination AID. How to calculate and decide the values of the source
AID and the destination AID is out of scope except that 1 byte is
used for identifying each node in IEEE 802.15.4 and the other 1 byte
is used for identifying the external IPV6 node connected with the
node of IEEE 802.15.4. AID REPLY frame format is in the Figure 7.
+-------------------------------------------------------------------+
|01010000| Src.address | Src.AID | Dst.Address | Dst. AID |
| | (16) | (2) | (16) | (2) |
+-------------------------------------------------------------------+
Figure 7: AID REPLY frame format
Hyun-Kook Kahng Expires: September 30, 2011 [Page 8]
Internet-Draft Global-connectivity March 2011
5.3. AID DELETE frame
The node in 6LowPAN must send AID DELETE frame to the gateway. After
the node in 6LowPAN disconnected to the Global IPV6 node, it must
send AID DELETE frame to the gateway to inform not to use the values
any longer. The format of AID DELETE frame is in the Figure 8.
+------------------------------------------------------------------+
|01010011|Src. Address(16)|Src. ADI(2)|Dst. Address(16)|Dst. AID(2)|
+------------------------------------------------------------------+
Figure 8: AID DELETE frame format
5.4. LOWPAN_GCHC frame
After AID assignment, LOWPAN_GCHC frame indicates that the following
header is encoded using AID values. The LOWPAN_GCHC encoding utilizes
4 octets, 2 of which is source AID and 2 of which is Destination AID.
Any information from the uncompressed IPv6 header fields is carried
in-line following the LOWPAN_GCHC encoding. The format of LOWPAN_GCHC
is in the Figure 9.
+------------------------------------------------------------------+
|01010100|Src. AID(2)|Dst. ADI(2)| In-line IPv6 Header Fields |
+------------------------------------------------------------------+
Figure 9: LOWPAN_GCHC frame format
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [RFC2234].
7. Security Considerations
TBD
Hyun-Kook Kahng Expires: September 30, 2011 [Page 9]
Internet-Draft Global-connectivity March 2011
8. IANA Considerations
TBD
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.
Hyun-Kook Kahng Expires: September 30, 2011 [Page 10]
Internet-Draft Global-connectivity March 2011
[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
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: September 30, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 23:52:24 |