[16NG] question about rfc4840

"Wei Gengyu" <weigengyu@vip.sina.com> Tue, 17 April 2007 12:23 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdmiT-0000XW-VG; Tue, 17 Apr 2007 08:23:25 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1HdmiR-0000Wv-VH for 16ng-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 08:23:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdmiR-0000Wb-Kv for 16ng@ietf.org; Tue, 17 Apr 2007 08:23:23 -0400
Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdmiL-00027f-Uv for 16ng@ietf.org; Tue, 17 Apr 2007 08:23:23 -0400
Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id D164E44A414 for <16ng@ietf.org>; Tue, 17 Apr 2007 20:23:08 +0800 (CST)
Message-ID: <001701c780eb$21d3ff80$a507740a@DELLWEI>
From: "Wei Gengyu" <weigengyu@vip.sina.com>
To: <16ng@ietf.org>
Date: Tue, 17 Apr 2007 20:22:52 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Subject: [16NG] question about rfc4840
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1006547274=="
Errors-To: 16ng-bounces@ietf.org

Another question.

In 3.1 Generality

   Even if a single encapsulation method is used, problems can still
   occur if demultiplexing of ARP, IPv4, IPv6, and any other protocols
   in use, is not supported at the link layer.  While it is possible to
   demultiplex such packets based on the Version field (first four bits
   on the packet), this assumes that IPv4-only implementations will be
   able to properly handle IPv6 packets.  As a result, a more robust
   design is to demultiplex protocols in the link layer, such as by
   assigning a different protocol type, as is done in IEEE 802 media
   where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6.

   Recommendations: Link-layer protocols should enable network packets
   (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer.

Demultipex is required at link layer as you recommended. 
But the problem is how to demultiplex.

In IEEE802 media, as you said above, it use a Type field.
This is link layer identification.

And you also said to demultiplex packets based on the Version field. 
This is network layer identification.

To demultiplex in link layer, I think the basic method should use differen link id,
which may be the SAPI as LAPD, rather then the Type only.

By considering the address and multiplex and demultiplex requirements, 
it should define a field of link id, which is an unique identifier of the logical link,
in the header of link layer protocol. 
The link id can be an integer, the value is assigned when setup.
In this way there are multiple logic links beween a pair of ajointing nodes. 
Each logic link can be unicast or multicast identified as usual. 

So, multiplex and demultiplex are accomplished at link layer, 
but what each link conveys is identified by the upper layer, 
i.e. in the header of network layer protocol, version or any other fields. 

I wonder wether it is the meaning of the recommendations.

Regards,

Gengyu
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng