Differences between revisions 2 and 3
- No differences found!

Describe Network Model here.

The following text appears in http://tools.ietf.org/html/draft-chakrabarti-6lowpan-ipv6-nd-03.

This is the generic network model of 6lowpan the working group discussed before and captured in the ND draft as we needed some topological assumptions to begin with. -Samita Chakrabarti

Assumptions about Topology and Address Mapping

  • In order to minimize the multicast packets we need to make some assumptions that tie together the L2 functional elements and the L3 functional elements. We also state our understanding of how IPv6

    would map to a LowPan network: o One PAN-ID defines one LowPan Network. o Each LowPan corresponds to one IPv6 subnet as PAN-ID may be used

    • to determine a subnet.

    o There is one PAN co-ordinator or PAN group leader per one LowPan. o The IPv6 router which sits in the boundary of the LowPan is a PAN

    • co-ordinator.

    o There can be multiple co-ordinators in the LowPan. o When a device connects to the LowPan at layer 2, it finds out a

    • (unicast) layer 2 address for its co-ordinator.
    o By recursive construction, the previous item implies that a co-
    • ordinator knows its co-ordinator from when it connected to the

      LowPan, hence there is distributed knowledge of unicast addresses that lead all the way to the PAN co-ordinator.

    o The IPv6 router assigns addresses through prefix advertisement. o The other FFDs in the network do not act as a IPv6 router, but
    • they generally route data packet in the L2 layer (Mesh layer routing).
    o Star topology assumes that each node is one hop away from the PAN
    • co-ordinator.
    o This document defines a mesh topology (see diagram below). In
    • mesh topology, each node is capable of forwarding. Thus it can be assumed as a network of full functional devices (FFDs) with one PAN co-ordinator and multiple co-ordinators.

Chakrabarti & Nordmark Expires September 8, 2007 [Page 6]

Internet-Draft LowPan Neighbor Discovery Extensions March 2007

  • o FFDs may or may not be more than one hop away from the PAN co-
    • ordinator.
    o We assume that the 64-bit EUI-64 addresses are used as link-layer
    • address in the lowpan, since these addresses never change for a given node. Appendix A discusses some additional considerations should we apply this to the 16-bit addresses.
    This document currently supports the following topologies:
    • 1) Star Topology
      • PAN-C
        • O
        / | \
      • o o o <


RFDs or FFDs

  • 2) Mesh Topology
    • Example-1 Example-2
      • O PAN-C O <-- PAN-C

      • / | \ o / | \
      • / | \ / / | \

      FFD


FFD


FFD FFD--FFD


FFD

  • \ |\ / \ \ | \ /|
    • \ | \ /| o \ | \ / |
      • \ | \ / | \ | \/ |
        • \ | \ / | \ | /\ |
          • \ | \ | \| / \ |
            • \| / \ | |/ \|
              • FFD \ | FFD FFD
          / | \ FFD
        o 0 o / \
        • o o <--RFDs

  • Each FFD may act as simple co-ordinators but there is only one PAN

    co-ordinator in the mesh LowPan topology.

  • [ PLEASE SEE THE DIAGRAMS in EDIT mode or refer to the section 4 of the ND draft ]

Network Model (last edited 2008-02-20 14:57:22 by localhost)