Subject: [16ng] FW:Impending publication: draft-iab-link-encaps-02.txt

From: "Soohong Daniel Park" <[email-masked]>
Date: Wed, 13 Sep 2006 09:37:51 +0200

We should go through 16 relevant text in this document carefully prior
to submitting it. Due is September 27. Please speak up your comments
if any.

=================================

The IAB is ready to ask the RFC-Editor to publish

     Multiple Encapsulation Methods Considered Harmful
                draft-iab-link-encaps-02.txt

as an Informational RFC. While typically a link layer protocol
supports only a single Internet Protocol (IP) encapsulation
method, this is not always the case. Recently new link types
have been defined that support multiple encapsulation methods.
This document describes architectural and operational issues
arising from use of multiple ways of encapsulating IP packets
on the same link.  Multiple encapsulation methods are not,
themselves, new -- previous considerations of the approach
are considered, as well as a review of potential issues related
to the current proposals.

The IAB solicits comments by September 27, 2006. Please send
comments to the IAB ([email-masked]), or to [email-masked].

The document can be found at

http://www.ietf.org/internet-drafts/draft-iab-link-encaps-02.txt

 From the Abstract:

   This document describes architectural and operational issues that
   arise from link layer protocols supporting multiple Internet Protocol
   encapsulation methods.

Leslie Daigle,
      For the IAB.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Wed, 27 Sep 2006 15:17:31 +0200

Dear IAB,

While agreeing in general with the statements of the I-D
draft-iab-link-encaps-02.txt, especially the portions dealing with
Ethernet, I have a couple of concerns on the statements given on
IEEE802.16:

1. IEEE802.16 does not provide multiple encapsulation methods for the
same kind of payload. IEEE802.16 defines exactly one way of
encapsulation for one kind of payload. I.e. there is one way to
encapsulate a plain IPv4 packet into an IEEE802.16 MAC frame, there is
one way for IPv6 packets and one way for ROHC packets, and there is one
way of _encapsulation_ of Ethernet frames into IEEE802.16 MAC frames,
even when there are different possibilities of classification of an
Ethernet frame for forwarding it on the appropriate connection over the
air.

2. Unfortunately the I-D makes no distinction between encapsulation and
classification. IEEE802.16 provides unique ways of encapsulation for IP
and Ethernet but multiple ways of classification. Not making this
distinction leads to the impression of multiple encapsulation methods.

IEEE802.16 is not perfect in its definition of classification. A number
of fields in the TCP-/UDP-, IP- as well as the Ethernet-header are
foreseen to be used for classification, i.e. Src-Port, Dest-Port,
Protocol, DSCP, Src-IP, Dest-IP, Src-ETH, Dest-ETH, Ethertype/SAP,
Eth-Prio, VLAN-ID and ContextID in the case of ROHC or ECRTP. A
particular convergence sublayer is defined by its subset of header
fields to be applied for classification.

3. The difficulty with IEEE802.16 arises by its capability to
encapsulate layer 2 frames as well as layer 3 packets in IEEE802.16 MAC
frames. This leads to the cumbersome situation that IP packets may be
directly encapsulated in IEEE802.16 MAC frames as well as framed with
Ethernet headers in IEEE802.16 MAC frames. The I-D does not address
sufficiently this Layer 2 payload and Layer 3 payload (and Layer 3 in
Layer 2 payload) over the same link issue, which occurs also over other
link types, e.g. PPP.

4. IEEE802.16e added four new Convergence Sublayers (not eight, as
stated in '1. Introduction').

I would recommend not to publish the I-D draft-iab-link-encaps-02.txt as
RFC but to extend the text with considerations on concurrent
transmission of L2 and L3 over the same link and to refine the sections
on IEEE802.16.

Bye
Max