[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
I support the adoption of the ULE draft as a WG item and starting point for a proposed IETF standard. Abdelhamid
----------------
Abdelhamid NAFAA | Tel: +33 1 39 25 40 59
PRiSM-CNRS Lab. | Web: http://www.prism.uvsq.fr/~anaf/
University of Versailles
45, Av. Des Etats Unis, 78035 - Versailles, France.
-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
Sent: Monday, February 09, 2004 12:58 PM
To: ipdvb@erg.abdn.ac.uk
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
As WG chair, I request the ipdvb list to consider whether the WG is ready to support adoption of the following individual Internet Draft (ID) as a WG ID.
By adopting an individual ID as a working group ID, this WG indicates that
it intends to be develop this into an RFC, according to the WG charter.
WG documents should no longer be regarded as the property of the
individuals who originally authored them - the working group as a whole
must decide how they are shaped, and to see the document to
a successful conclusion. If adopted, the Internet Draft will be renamed to start with the filename draft-ietf-ipdvb..., and will be listed on the IETF web page for this WG.
---
Title : Ultra Lightweight Encapsulation (ULE) for
transmission of IP datagrams over
MPEG-2/DVB networks
Author(s) : G. Fairhurst, B. Collini-Nocker
Filename : draft-fair-ipdvb-ule-02.txt
Pages : 32
Date : 2003-11-24
The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data.
---
You are encouraged to send email to this WG, to help make the decision for adoption. Possible recommendations are:
1) Support for adoption as a working group draft under our Charter -
i.e. Recommend this Internet Draft SHOULD be used as the basis for
developing an RFC by the ipdvb WG.
2) Request for non-adoption
i.e. That there is (or could be) alternative approaches to
the problem, and that the current draft is not sufficiently
developed / or correctly designed ipdvb WG
3) Out of scope
i.e. you believe the document to be beyond the scope of the
approved ipdvb WG charter.
Emails on this topic should be sent to the ipdvb mailing list before 23rd February 2004.
Note that an ID does not need to be complete to be adopted. It would also be most useful to collect as many comments/criticisms as possible from those reading this ID. Looking through the archived mailing list, a first list of issues to be addressed is included at the end of this email.
Please do help to identify any more known (or potential) issues that should be addressed/discussed.
Best wishes,
Gorry Fairhurst
(ipdvb WG Chair)
---
Known issues with draft-fair-ipdvb-ule-02.txt =============================================
1) Refinement of the text on CRC generation to be unambiguous
(explicitly talk about the polynomial as a forward CRC-32
and THEN explicitly about the computation process)
- Text to be rewritten.
2) Query about the code point value for an Ethernet Bridging SNDU - should the ULE type-field be 0x0001 ; 0x0007 as in ATM/AAL5 (as in RFC2684);
or should the IEEE Ethertype for bridging (0x6558) be used instead?
- Discuss on list.
3) Need to check the SNDU Packing/Padding examples in the informative appendix of the ID for correctness (including the length of the last
packet of example A.4)
--- any volunteers?
4) Suggestion to add an appendix to the next rev of the ID, with a hexadecimal example of an SNDU, to assist implementors in validating the operation of the CRC. The following example has been proposed:
>> Ping6
>> from 2001:660:3008:1789::5 to 2001:660:3008:1789::6, with the
>> associated DVB MAC addr being 01:02:03:04:05:06. It gives the
>> following SNDU :
>>
>> 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d
>> .?........`.....
>> 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 :@ ..`0.........
>> 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 .. ..`0.........
>> 0030: 00 06 80 00 9c 58 07 70 00 00 00 00 00 00 00 02 .....X.p........
>> 0040: 72 c9 c2 r..
>>
- The exact decode of this needs to be done and verified
5) ???
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003