From stiemerling at netlab.nec.de  Mon Feb  2 14:19:15 2004
From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Mon, 2 Feb 2004 15:19:15 +0100 (CET)
Subject: Seoul
In-Reply-To: <40044DFC.9090400@erg.abdn.ac.uk>
References:     <2BF0AD29BC31FE46B7887732114404310357E83F@trebe003.europe.nokia.com>
    <40042954.E7D60601@hns.com> <40044DFC.9090400@erg.abdn.ac.uk>
Message-ID: <4860.10.1.1.83.1075731555.squirrel@yamato.ccrle.nec.de>

Hi Gorry,

it would be great to have a WG session or at least some face-to-face
discussions
at the next IETF meeting in Seoul.

I have some comments on the requirement documents and will post them
within the next days (currently busy).

Regards,

  Martin

> John,
>
> We are still not an IETF working group, but there has been progress
> behind the scenes.
>
> A proposed charter for this WG was circulated by the IESG to the IETF
> and Internet Area Chairs before the last Minneapolis IETF meeting.
> There was some feedback that we have been working to address resulting
> in the latest version of our proposed charter text below.  We're still
> working to tune the milestones, etc. but I  am  expecting that this
> charter will be submited to the IESG for consideration at their next
> meeting on 22-Jan.
>
> We've had BoFs at the previous two IETFs. I am undecided about the need
> to call a meeting in Seoul (so if *anyone* has views, please do tell the
> list). It seems we are making progress with the ULE Spec, and that the
> requirements document is now in a position where the WG could offer
> comments and suggestions.
>
> If there is a need to meet, I'd be very willing to ask for a meeting
> slot, but obviously not all groups can meet at every IETF (there simply
> wouldn't be space), so the question is I guess, are there issues that
> need to be discussed, agenda items, or new inputs that we can expect in
> the next month?
>
> Gorry
>
> -------
>
>
> IP over MPEG-2/DVB (ipdvb)
>
> Chair(s):
> Gorry Fairhurst <gorry at erg.abdn.ac.uk>
>
> Responsible Area Director:
> Margaret Wasserman <margaret at thingmagic.com>
>
> Mailing Lists:
> General Discussion:  ip-dvb at erg.abdn.ac.uk
> To subscribe:        subscribe ip-dvb at majordomo at erg.abdn.ac.uk
> Archive:             http://www.erg.abdn.ac.uk/ip-dvb/archive/
>
> Description of Working Group:
> The WG will develop new protocols and architectures to enable better
> deployment of IP over MPEG-2 transport and provide easier interworking
> with IP networks. Specific properties of this subnetwork technology
> include link-layer support for unicast and multicast, large numbers
> of down-stream receivers, and efficiency of transmission. These
> properties resemble those in some other wireless networks. The specific
> ndards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in
>  protocols on the existing generation of networks.
>
> The WG will endeavour to reuse existing open standard technologies,
> giving guidance on usage in IP networks, whenever they are able to
> fulfil requirements. For instance, it acknowledges the existing
> Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that
> this will continue to be deployed in the future to develop new markets.
> Any alternative encapsulation would need to co-exist with MPE.
>
> Appropriate standards will be defined to support transmission of IPv4
> and IPv6 datagrams between IP networks connected using MPEG-2 transport
> subnetworks. This includes options for encapsulation, dynamic unicast
> address resolution for IPv4/IPv6, and the mechanisms needed to map
> routed IP multicast traffic to the MPEG-2 transport subnetwork. The
> standards will be appropriate to both MPE and any alternative
> encapsulation method developed. The developed protocols may also be
> applicable to other multicast enabled subnetwork technologies supporting
> large numbers of directly connected systems.
>
> The current list of work items is:
> Specify the requirements and architecture for supporting IPv4/IPv6 via
> MPEG-2 transmission networks. Such requirements should consider the range
> of platforms currently (or anticipated to be) in use. This draft will be
> an Informational RFC.
>
> Define a standards-track RFC defining an efficient encapsulation method.
> The design will consider the need for MAC addresses, the potential need
> for synchronisation between streams, support for a wide range of IPv4/IPv6
> and multicast traffic.
>
> Provide an Informational RFC describing a framework for unicast and
> multicast address resolution over MPEG-2 transmission networks. The
> document will describe options for the address resolution process,
> relating these to appropriate usage scenarios and suggesting appropriate
> protocol mechanisms for both the existing Multi-Protocol Encapsulation
> (MPE) and the efficient encapsulation (2). Consideration will be paid to
> existing standards, and the cases for IPv6 and IPv4 will be described.
>
> Define standards-track RFC(s) to specify procedures for dynamic address
> resolution for IPv4/IPv6. This will describe the protocol and syntax of
> the information exchanged to bind unicast and multicast flows to the
> MPEG-2
> TS Logical Channels. This will include specific optimisations
> appropriate for
> networks reaching large numbers of down-stream systems.
>
> Goals and Milestones:
>
> JAN 04    Draft of a WG Architecture ID describing usage of MPEG-2
>           transport for IP transmission.
> MAR 04    Draft of a WG ID on the new Encapsulation.
> JUL 04    Draft of a WG ID on the AR Framework, specifying mechanisms
>           to perform address resolution.
> JUL 04    Submit Architecture to IESG
> OCT 04    Draft of a WG ID or the AR Protocol, defining a protocol to
>           perform IP address resolution.
> OCT 04    Submit Encapsulation to IESG
> APR 05    Submit AR Framework to IESG
> AUG 05    Submit AR Protocol to IESG
> AUG 05    Progress the Encapsulation RFC along the IETF standards track.
>
>
>>
>>
>
>


From gorry at erg.abdn.ac.uk  Mon Feb  2 18:24:55 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 02 Feb 2004 18:24:55 +0000
Subject: comment on ULE draft (bridging mode)
In-Reply-To: <OF81FD1B9A.5C2F1E3E-ONC1256E2B.0053FA00@netfr.alcatel.fr>
References: <OF81FD1B9A.5C2F1E3E-ONC1256E2B.0053FA00@netfr.alcatel.fr>
Message-ID: <401E95F7.70100@erg.abdn.ac.uk>



Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>This concerns ?4.7.5 : bridged frame SNDU encapsulation ( fiugres 8 and 9)
>:
>The type field value in the figures is set to 0x0001.
>
Yes

> This indicates that
>the payload is an ethernet frame 
>
Yes

>with preserved FCS
>
The Ethernet frame should be sent using ULE *without* an Ethernet-level 
FCS as described in:

      "The Encapsulator MUST check the
        LAN-FCS value of all frames received, prior to further processing. 
        Frames received with an invalid LAN FCS MUST be discarded. After
        checking, the LAN FCS is then removed (i.e., it is NOT forwarded in
        the bridged SNDU)."

http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-02.txt

Is this the sort of behaviour that you desire?

>This leads to a redundant CRC : that of the Ethernet frame and that of the
>SNDU
>
>In Eth/AAL5, it is useual to remove the FCS field from the Eth frame before
>encapsulating it in AAL5 PDU since AAL5 makes its own checksum
>This may also be a good thing for ULE.
>
>The coding for the type field when the FCS is not preserved is 0x0007
>(instead of 0x0001)
>
What do you mean?

>regards
>
>
>ALCATEL SPACE
>DRT/RST  --  Ing?nieur Syst?mes
>Tel : 0534356918  /  Fax : 0534355560
>Porte : W.220
>
>  
>
Best wishes,

Gorry Fairhurst.




From gorry at erg.abdn.ac.uk  Tue Feb  3 12:30:23 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Tue, 03 Feb 2004 12:30:23 +0000
Subject: IETF Working Group Status for ipdvb (Feb 2004)
Message-ID: <401F945F.6010908@erg.abdn.ac.uk>


Welcome everyone!

You may have noted the (triple!) posting from the IESG, announcing that 
this is now an official IETF mailing list in the Internet Area:
http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00509.html


This announcement has several implications, including:

(i) You ARE ALREADY subscribed to this mailing list, and we are pleased 
to have you on-board. If you do wish to be a member of the IETF ipdvb 
WG, you must now  UNSUBSCRIBE from the list by sending an email to 
major-domo at erg.abdn.ac.uk with the following in the body of the message: 
unsubscribe ip-dvb.


(ii) I am obliged to remind you that you MUST comply with the IETF 
note-well governing disclosure and IPR, as stated at:
http://www.ietf.org/overview.html


(iii This WG is now permitted to request a meeting slot at an IETF 
meeting, although of course the IETF primarily functions through its 
mailing lists, and (unlike many other organisations) meetings are NOT 
required to approve documents.


(iv) We have NOT requested a meeting for ipdvb at the Seoul IETF (later 
this month). There are several reasons for this: - I am also keen to 
avoid calling a meeting with the same Agenda as the last two BoF 
meetings (several authors were also unable to make it) - I believe we 
can make significant progress for the following IETF (August 1-6, San 
Diego) and I do recommend you put this date in your diary straight away!!
http://www.ietf.org/meetings/0mtg-sites.txt


(v) We need to revive the work on our charter items:
    - In the first place this will mean consideration of the ULE 
Internet Draft for adoption as a working group item, for those 
unfamiliar, I will explain this process later in the week.
    - We also have a number of implementations of ULE, we shall be 
opening a new part of the web site to document the progress of these 
implementations.
    - We need to review/update/modify the requirements document to 
reflect the needs of this WG.

Best wishes,


Gorry Fairhurst
(ipdvb chair)


P.S. Some people may have noted that the IETF web page for the ipdvb WG 
displays a shortened form of the original proposed WG name (that simply 
expands the acronym). I am checking with the AD to see if the original 
name is still allowed, and will tell you progress.
http://www.ietf.org/html.charters/wg-dir.html




From Tarif.Zein-Alabedeen at space.alcatel.fr  Tue Feb  3 13:22:48 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Tue, 3 Feb 2004 14:22:48 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_comment_on_ULE_draft_=28bridging_mode?=
 =?us-ascii?Q?=29?=
Message-ID: <OFE8EC23EB.003F9AEB-ONC1256E2F.0047A518@netfr.alcatel.fr>



Hi Gorry,

Sorry if I have not been clear enough....
What I wanted to say is that I think the value for the TYPE field when the
FCS of the Ethernet frame is removed before it is encapsulated within the
SNDU (which is the case in the draft) should be 0x0007 and not 0x0001 (you
can check this in RFC 2684)
In fact both values indicate that the transported PDU is Ethernet. However
0x0001 indicates that the FCS is preserved and 0x0007 indicates that it is
removed.
This is the case for each bridged protocol and not only Ethernet.

What is needed is just to correct the type field in the indicated figures
of the draft

Best regards
Tarif ZEIN







Gorry Fairhurst <gorry at erg.abdn.ac.uk>@erg.abdn.ac.uk on 02/02/2004
19:24:55

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : ip-dvb at erg.abdn.ac.uk
cc :
Objet :     Re: comment on ULE draft (bridging mode)




Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>This concerns ?4.7.5 : bridged frame SNDU encapsulation ( fiugres 8 and 9)
>:
>The type field value in the figures is set to 0x0001.
>
Yes

> This indicates that
>the payload is an ethernet frame
>
Yes

>with preserved FCS
>
The Ethernet frame should be sent using ULE *without* an Ethernet-level
FCS as described in:

      "The Encapsulator MUST check the
        LAN-FCS value of all frames received, prior to further processing.
        Frames received with an invalid LAN FCS MUST be discarded. After
        checking, the LAN FCS is then removed (i.e., it is NOT forwarded in
        the bridged SNDU)."

http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-02.txt

Is this the sort of behaviour that you desire?

>This leads to a redundant CRC : that of the Ethernet frame and that of the
>SNDU
>
>In Eth/AAL5, it is useual to remove the FCS field from the Eth frame
before
>encapsulating it in AAL5 PDU since AAL5 makes its own checksum
>This may also be a good thing for ULE.
>
>The coding for the type field when the FCS is not preserved is 0x0007
>(instead of 0x0001)
>
What do you mean?

>regards
>
>
>ALCATEL SPACE
>DRT/RST  --  Ing?nieur Syst?mes
>Tel : 0534356918  /  Fax : 0534355560
>Porte : W.220
>
>
>
Best wishes,

Gorry Fairhurst.









ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From Tarif.Zein-Alabedeen at space.alcatel.fr  Tue Feb  3 13:22:48 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Tue, 3 Feb 2004 14:22:48 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_comment_on_ULE_draft_=28bridging_mode?=
 =?us-ascii?Q?=29?=
Message-ID: <OFE8EC23EB.003F9AEB-ONC1256E2F.0047A518@netfr.alcatel.fr>



Hi Gorry,

Sorry if I have not been clear enough....
What I wanted to say is that I think the value for the TYPE field when the
FCS of the Ethernet frame is removed before it is encapsulated within the
SNDU (which is the case in the draft) should be 0x0007 and not 0x0001 (you
can check this in RFC 2684)
In fact both values indicate that the transported PDU is Ethernet. However
0x0001 indicates that the FCS is preserved and 0x0007 indicates that it is
removed.
This is the case for each bridged protocol and not only Ethernet.

What is needed is just to correct the type field in the indicated figures
of the draft

Best regards
Tarif ZEIN







Gorry Fairhurst <gorry at erg.abdn.ac.uk>@erg.abdn.ac.uk on 02/02/2004
19:24:55

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : ip-dvb at erg.abdn.ac.uk
cc :
Objet :     Re: comment on ULE draft (bridging mode)




Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>This concerns ?4.7.5 : bridged frame SNDU encapsulation ( fiugres 8 and 9)
>:
>The type field value in the figures is set to 0x0001.
>
Yes

> This indicates that
>the payload is an ethernet frame
>
Yes

>with preserved FCS
>
The Ethernet frame should be sent using ULE *without* an Ethernet-level
FCS as described in:

      "The Encapsulator MUST check the
        LAN-FCS value of all frames received, prior to further processing.
        Frames received with an invalid LAN FCS MUST be discarded. After
        checking, the LAN FCS is then removed (i.e., it is NOT forwarded in
        the bridged SNDU)."

http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-02.txt

Is this the sort of behaviour that you desire?

>This leads to a redundant CRC : that of the Ethernet frame and that of the
>SNDU
>
>In Eth/AAL5, it is useual to remove the FCS field from the Eth frame
before
>encapsulating it in AAL5 PDU since AAL5 makes its own checksum
>This may also be a good thing for ULE.
>
>The coding for the type field when the FCS is not preserved is 0x0007
>(instead of 0x0001)
>
What do you mean?

>regards
>
>
>ALCATEL SPACE
>DRT/RST  --  Ing?nieur Syst?mes
>Tel : 0534356918  /  Fax : 0534355560
>Porte : W.220
>
>
>
Best wishes,

Gorry Fairhurst.









ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220







From alain.ritoux at 6wind.com  Mon Feb  9 12:19:30 2004
From: alain.ritoux at 6wind.com (Alain RITOUX)
Date: Mon, 09 Feb 2004 13:19:30 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <402767AE.3020709@erg.abdn.ac.uk>
References: <402767AE.3020709@erg.abdn.ac.uk>
Message-ID: <40277AD2.9010101@6wind.com>



Gorry Fairhurst wrote:

> As WG chair, I request the ipdvb list to consider whether the WG is
> ready to ...
> 

>        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

I DO support the adoption of this draft as a WG item.

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com





From border at hns.com  Mon Feb  9 14:18:22 2004
From: border at hns.com (John Border)
Date: Mon, 09 Feb 2004 09:18:22 -0500
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
References: <402767AE.3020709@erg.abdn.ac.uk>
Message-ID: <402796AE.E43C83B4@hns.com>


I support adopting the document as a WG document...


John


Gorry Fairhurst wrote:
> 
> 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) ???




From pulitano at ing.unirc.it  Mon Feb  9 14:59:25 2004
From: pulitano at ing.unirc.it (pulitano at ing.unirc.it)
Date: Mon,  9 Feb 2004 15:59:25 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <402796AE.E43C83B4@hns.com>
References: <402767AE.3020709@erg.abdn.ac.uk> <402796AE.E43C83B4@hns.com>
Message-ID: <1076338765.4027a04d44c13@mailer.ing.unirc.it>

I think that such a draft can be adopted as a WG draft.


From Fritsche at iabg.de  Mon Feb  9 15:19:30 2004
From: Fritsche at iabg.de (Fritsche Wolfgang)
Date: Mon, 9 Feb 2004 16:19:30 +0100
Subject: AW: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
Message-ID: <69A5E767EC979846826F566C7932A3F2074DAC@exchange03.iabg.de>

I do support the adoption of the ULE draft as a WG draft.

Cheers,

Wolfgang

> -----Urspr?ngliche Nachricht-----
> Von: owner-ip-dvb at erg.abdn.ac.uk
> [mailto:owner-ip-dvb at erg.abdn.ac.uk] Im Auftrag von Gorry Fairhurst
> Gesendet: Montag, 9. Februar 2004 11:58
> An: ipdvb at erg.abdn.ac.uk
> Betreff: 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) ???
> 
> 
> 




From mayer at iabg.de  Mon Feb  9 15:26:04 2004
From: mayer at iabg.de (Mayer Karl)
Date: Mon, 9 Feb 2004 16:26:04 +0100
Subject: AW: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
Message-ID: <BBDE6D332D319548BAAAC70344517B6218A0A8@exchange03.iabg.de>

I support the adoption of the ULE draft as WG ID.

Karl

> -----Urspr?ngliche Nachricht-----
> Von: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk] 
> Im Auftrag von Gorry Fairhurst
> Gesendet: Montag, 9. Februar 2004 11:58
> An: ipdvb at erg.abdn.ac.uk
> Betreff: 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) ???
> 






From Gessler at iabg.de  Mon Feb  9 16:10:16 2004
From: Gessler at iabg.de (Gessler Gerhard)
Date: Mon, 9 Feb 2004 17:10:16 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
Message-ID: <69A5E767EC979846826F566C7932A3F213566D@exchange03.iabg.de>


I do support the adoption of this draft as a WG item.

--------------------------------------------
Gerhard Ge?ler

Communication Networks, IABG mbH
Einsteinstr. 20
85521 Ottobrunn, Germany

Telefon: +49 89 6088 - 2021
Fax: +49 89 6088 - 2845

E-Mail: gessler at iabg.de 

  > -----Original Message-----
  > From: owner-ip-dvb at erg.abdn.ac.uk 
  > [mailto:owner-ip-dvb at erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
  > Sent: Monday, February 09, 2004 11:58 AM
  > To: ipdvb at 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) ???
  > 
  > 
  > 


From watson at cytanet.com.cy  Mon Feb  9 17:32:39 2004
From: watson at cytanet.com.cy (Pete, Bec and Ethan)
Date: Mon, 9 Feb 2004 19:32:39 +0200
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <402767AE.3020709@erg.abdn.ac.uk>
Message-ID: <20040209173238.E1AC68B3C2@demokritos1.cytanet.com.cy>

I support the adoption of the ULE draft as a WG item.

Pete


-----Original Message-----
From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
Sent: Monday, February 09, 2004 12:58 PM
To: ipdvb at 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
 

From anaf at prism.uvsq.fr  Mon Feb  9 17:55:33 2004
From: anaf at prism.uvsq.fr (Abdelhamid Nafaa)
Date: Mon, 9 Feb 2004 18:55:33 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <20040209173238.E1AC68B3C2@demokritos1.cytanet.com.cy>
Message-ID: <200402091752.i19HqQp23717@guillotin.prism.uvsq.fr>

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 at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst
Sent: Monday, February 09, 2004 12:58 PM
To: ipdvb at 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
 


From mariejose.montpetit at verizon.net  Mon Feb  9 18:36:30 2004
From: mariejose.montpetit at verizon.net (Marie-Jose Montpetit)
Date: Mon, 9 Feb 2004 13:36:30 -0500
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
References: <402767AE.3020709@erg.abdn.ac.uk>
Message-ID: <015e01c3ef3b$f70cdc70$b402a8c0@copernicus>

I support the adoption of the ID as WG document. I also suggest for point 5) extension headers in ULE for future services.

Marie-Jose
----- Original Message ----- 
From: "Gorry Fairhurst" <gorry at erg.abdn.ac.uk>
To: <ipdvb at erg.abdn.ac.uk>
Sent: Monday, February 09, 2004 5:57 AM
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) ???
>
>
>


From Frank.Zeppenfeldt at esa.int  Tue Feb 10 06:18:49 2004
From: Frank.Zeppenfeldt at esa.int (Frank.Zeppenfeldt at esa.int)
Date: Tue, 10 Feb 2004 07:18:49 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
Message-ID: <OF9C387CE8.F41F6FC6-ON41256E36.00227EAE@estec.esa.int>



I support the adoption of the ID draft-fair-ipdvb-ule-02.txt as a WG ID.

Frank.Zeppenfeldt at esa.int
http://telecom.esa.int/
ESA/ESTEC (European Space & Technology Centre)
Keplerlaan 1
Postbus 299
2200 AG Noordwijk (The Netherlands)



From alain.ritoux at 6wind.com  Tue Feb 10 08:25:33 2004
From: alain.ritoux at 6wind.com (alain.ritoux at 6wind.com)
Date: Tue, 10 Feb 2004 09:25:33 +0100
Subject: ULE extension headers
In-Reply-To: <c08lj6$1vvc$1@intranet.6wind.com>
References: <c08lj6$1vvc$1@intranet.6wind.com>
Message-ID: <4028957D.803@6wind.com>



Marie-Jose Montpetit wrote:

> I support the adoption of the ID as WG document. I also suggest for 
> point 5) extension headers in ULE for future services.
> 

I agree with an extension header for future services.

I would propose to do it in an IPv6-style, using some values in the 1-1500 part of next header, to signal the extention header(s). Such headers could then have a fixed and well known begining :
    +---+---+---+--//  ..... // ----+
    |   NH  | L |  extension value  |
    +---+---+---+--//  ..... // ----+

  NH : 2 bytes, defines the type of next field which could then be,
       a classical ULE payload (0x800 for IPv4 ...) or even another
       extension header.
  L  : length in bytes of the header.

Even some values range could be reseved for that purpose, that would allow implementation to be compatible with still not known extensions. And even that would indicate the behaviour if extension is not known.

exemple :
1280 <= type field < 1304  :  optional extension, if not known,
                               just skip  and process next
1304 <= type field < 1408  :  critical extension, if not known, stop
                               processing, drop ULE SNDU, and possibly
                               report an error to emitter
                              (if possible, but how ??, usefull ??,  ..)

I chose those values as exemple because
   - they are in the 1-500 range
   - they have a nice bit pattern and can be checked with a single AND


Still about the type field :
I think it would be good to reseve a certain range of these values, for experimental uses, which would garanty  that (if respected ;-))) there would be no conflict with due reserved values. 1408 <= type field < 1472  :  reseved for experimental purpose, In
                               operational use, such SNDU MUST be
                               silently dropped.

All this is very little implementation and keeps the door opened for any future services.

Your thoughts about this ?

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From alain.ritoux at 6wind.com  Tue Feb 10 10:29:11 2004
From: alain.ritoux at 6wind.com (alain.ritoux at 6wind.com)
Date: Tue, 10 Feb 2004 11:29:11 +0100
Subject: ULE : SNDU Packing/Padding examples
In-Reply-To: <c07r8s$2uk9$1@intranet.6wind.com>
References: <c07r8s$2uk9$1@intranet.6wind.com>
Message-ID: <4028B277.80407@6wind.com>



Gorry Fairhurst wrote:

> As WG chair, I request the ipdvb list to consider whether the WG is
>  ...
> 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?
I do ;-)

In all examples, we assume the SNDU size includes the whole SNDU
(header, body, trailer), hence, the field length is this size
minus 4

Exemple A.1, first TS cell
============================
Error in length:
    actually   0x00 0xC8
    should be  0x00 0xC4

Exemple A.1, second TS cell
============================
Error in length:
    actually   0x00 0xC0
    should be  0x00 0xC4
Error in Payload Pointer value
    actually   0x10 / PP=16
    should be  0x11 / PP=17

Exemple A.3, 5th TS cell
==========================
Error in last byte numbering
    actually   B186
    should be  B185

Exemple A.3, 6th TS cell
==========================
Error in first byte numbering
    actually   B187
    should be  B186

The others examples/TS-cells seem fine for me.
Cheers.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com





From mariejose.montpetit at verizon.net  Tue Feb 10 11:03:21 2004
From: mariejose.montpetit at verizon.net (Marie-Jose Montpetit)
Date: Tue, 10 Feb 2004 06:03:21 -0500
Subject: ULE extension headers
References: <c08lj6$1vvc$1@intranet.6wind.com> <4028957D.803@6wind.com>
Message-ID: <003301c3efc5$80edf4e0$b402a8c0@copernicus>

I also had thought of IPv6 type extensions and I believe have something written somewhere about it. I think the experimental values are fine as I would like to use some of this to "try" things out for address resolution and QoS support and control services related to onboard processing satellites and broadband wireless networks.

Marie-Jose
----- Original Message ----- 
From: <alain.ritoux at 6wind.com>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Tuesday, February 10, 2004 3:25 AM
Subject: ULE extension headers


>
>
> Marie-Jose Montpetit wrote:
>
> > I support the adoption of the ID as WG document. I also suggest for
point 5)
> > extension headers in ULE for future services.
> >
>
> I agree with an extension header for future services.
>
> I would propose to do it in an IPv6-style, using some values in the 
> 1-1500 part of next header, to signal the extention header(s). Such 
> headers could then have a fixed and well known begining :
>     +---+---+---+--//  ..... // ----+
>     |   NH  | L |  extension value  |
>     +---+---+---+--//  ..... // ----+
>
>   NH : 2 bytes, defines the type of next field which could then be,
>        a classical ULE payload (0x800 for IPv4 ...) or even another
>        extension header.
>   L  : length in bytes of the header.
>
> Even some values range could be reseved for that purpose, that would 
> allow implementation to be compatible with still not known extensions. 
> And even that would indicate the behaviour if extension is not known.
>
> exemple :
> 1280 <= type field < 1304  :  optional extension, if not known,
>                                just skip  and process next 1304 <= 
> type field < 1408  :  critical extension, if not known, stop
>                                processing, drop ULE SNDU, and possibly
>                                report an error to emitter
>                               (if possible, but how ??, usefull ??,  
> ..)
>
> I chose those values as exemple because
>    - they are in the 1-500 range
>    - they have a nice bit pattern and can be checked with a single AND
>
>
> Still about the type field :
> I think it would be good to reseve a certain range of these values, 
> for experimental uses, which would garanty  that (if respected ;-))) 
> there would be no conflict with due reserved values. 1408 <= type 
> field < 1472  :  reseved for experimental purpose, In
>                                operational use, such SNDU MUST be
>                                silently dropped.
>
> All this is very little implementation and keeps the door opened for 
> any future services.
>
> Your thoughts about this ?
>
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
>
>







From stiemerling at netlab.nec.de  Wed Feb 11 08:52:45 2004
From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 11 Feb 2004 09:52:45 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <402767AE.3020709@erg.abdn.ac.uk>
References: <402767AE.3020709@erg.abdn.ac.uk>
Message-ID: <2147483647.1076493165@[10.1.1.109]>

Hi,

I support to accept ULE as WG document.

  Martin

--On Montag, 9. Februar 2004 10:57 Uhr +0000 Gorry Fairhurst 
<gorry at erg.abdn.ac.uk> wrote:

| 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) ???
|
|







From benoit.oger at thales-bm.com  Wed Feb 11 09:24:17 2004
From: benoit.oger at thales-bm.com (Benoit Oger)
Date: Wed, 11 Feb 2004 10:24:17 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <2147483647.1076493165@[10.1.1.109]>
Message-ID: <NEBBIIDJEALBIGLMBGPFOEEHCNAA.benoit.oger@thales-bm.com>

Hello,

I support the adoption of the ULE draft as a WG draft.

Benoit

> --On Montag, 9. Februar 2004 10:57 Uhr +0000 Gorry Fairhurst 
> <gorry at erg.abdn.ac.uk> wrote:
>
> | 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) ???
> |
> |
>
>


From Rod.Walsh at nokia.com  Thu Feb 12 08:16:03 2004
From: Rod.Walsh at nokia.com (Rod.Walsh at nokia.com)
Date: Thu, 12 Feb 2004 10:16:03 +0200
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
Message-ID: <D0299AFF29E01E478321564030AD69090BE558@trebe003.europe.nokia.com>

Hi Gorry & WG

I also support ULE adoption as a WG draft.

Please spell out the proposed timeframe as this has a big effect on the quality of the final document developed.

BTW, the "option (2)" is rather confusing "That there is (or could be) alternative approaches to the problem, and that the current draft is not sufficiently developed", since there is an existing solution (MPE) and there certainly are alternatives (even ipdvb started with 2 :). Also, the point of chartering into a WG is to develop the work-in-progress draft with the aim of publishing as an RFC - not just rubber stamp the individual draft with an RFC number. Is this just imprecise wording, or have I misunderstood? - please clarify.

(I'll be in Korea, so would be happy to share a couple of round with anyone interested in a bar-WG - not a bar-bof anymore :)

Cheers, Rod.


-----Original Message-----
From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
Behalf Of ext Gorry Fairhurst
Sent: Monday, February 09, 2004 12:58 PM
To: ipdvb at 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) ???






From richard.lhermitte at thales-bm.com  Thu Feb 12 14:16:57 2004
From: richard.lhermitte at thales-bm.com (Richard Lhermitte)
Date: Thu, 12 Feb 2004 15:16:57 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
References: <402767AE.3020709@erg.abdn.ac.uk>
Message-ID: <402B8AD9.840AB752@thales-bm.com>

I support the adoption of the ULE draft as a WG item.

Richard



Gorry Fairhurst a ?crit :

> 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) ???







From Tarif.Zein-Alabedeen at space.alcatel.fr  Fri Feb 13 14:04:30 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Fri, 13 Feb 2004 15:04:30 +0100
Subject: Question on Continuity Counter field
Message-ID: <OFC07841F8.6E916A84-ONC1256E39.004B2527@netfr.alcatel.fr>



Hi,
I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1

Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled?

(oups, this makes 3 questions already)

thank's and best regards


T. Zein
ALCATEL SPACE
DRT/RST







From Frank.Zeppenfeldt at esa.int  Fri Feb 13 20:58:02 2004
From: Frank.Zeppenfeldt at esa.int (Frank.Zeppenfeldt at esa.int)
Date: Fri, 13 Feb 2004 21:58:02 +0100
Subject: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at
 ESTEC
Message-ID: <OF25E31BD8.BD1AC4DB-ON41256E39.00732B98-41256E39.00732D73@estec.esa.int>

A non-text attachment was scrubbed...
Name: not available
Type: multipart/mixed
Size: 1189 bytes
Desc: not available
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040213/c0c0186a/attachment.bin>

From margaret at thingmagic.com  Fri Feb 13 21:13:38 2004
From: margaret at thingmagic.com (Margaret Wasserman)
Date: Fri, 13 Feb 2004 16:13:38 -0500
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <D0299AFF29E01E478321564030AD69090BE558@trebe003.europe.nok
 ia.com>
Message-ID: <5.1.0.14.2.20040213161153.0447bb70@ms101.mail1.com>


Hi Rod,

>(I'll be in Korea, so would be happy to share a couple of round with
>anyone interested in a bar-WG - not a bar-bof anymore :)

If you don't mind, I'll take you up on this!  I don't want to distract the WG from its chartered work, but I would like to better understand the current state of standardization in the field and how our work in IPDVB will fit in.

It would be great if Gorry can join us, and anyone else who wants to come, of course.

Margaret







From Jens.Krause at ses-astra.com  Mon Feb 16 13:23:07 2004
From: Jens.Krause at ses-astra.com (Jens.Krause at ses-astra.com)
Date: Mon, 16 Feb 2004 14:23:07 +0100
Subject: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at
 ESTEC
Message-ID: <OF06F40C5C.AE499BB1-ONC1256E3C.00496367-C1256E3C.00498714@gen.btz.aia.lu>


I would like to attend the IP over DVB presentation on March 5th. As requested in the invitation, I herewith confirm my attendance. I will also participate in the ETSI BSM meeting the days before this presentation.

---------------------------------------------------------------------------
Dr. Jens Krause
Sr Mgr, Communications Systems Engineering
Technical Department
SES ASTRA

Address:
L-6815 Chateau de Betzdorf
Luxembourg
Tel.: +352-710 725 447
Fax: +352-710 725 482
E-mail: Jens.Krause at ses-astra.com
Our web site: http://www.ses-astra.com
---------------------------------------------------------------------------



--
DISCLAIMER:
This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.







From Jens.Krause at ses-astra.com  Mon Feb 16 14:55:41 2004
From: Jens.Krause at ses-astra.com (Jens.Krause at ses-astra.com)
Date: Mon, 16 Feb 2004 15:55:41 +0100
Subject: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at
 ESTEC
Message-ID: <OF00EA7D76.F3C68443-ONC1256E3C.00518BF9-C1256E3C.00520090@gen.btz.aia.lu>

Please disregard the e-mail below.
I wanted to send it to Frank Zeppenfeld from ESA, but sent it to this reflector by mistake. Sorry for the inconvenience and confusion.

----- Forwarded by Jens Krause/BTZ on 16/02/2004 15:50 -----
                                                                                                                                       
                      Jens Krause                                                                                                      
                                               To:      ip-dvb at erg.abdn.ac.uk                                                          
                      16/02/2004 14:23         cc:                                                                                     
                                               Subject: Re: Final Presentation of ESA study on ip-over-dvb: 5 March 2004 10.00h at     
                                               ESTEC(Document link: Jens Krause)                                                       
                                                                                                                                       



I would like to attend the IP over DVB presentation on March 5th. As requested in the invitation, I herewith confirm my attendance. I will also participate in the ETSI BSM meeting the days before this presentation.

---------------------------------------------------------------------------
Dr. Jens Krause
Sr Mgr, Communications Systems Engineering
Technical Department
SES ASTRA

Address:
L-6815 Chateau de Betzdorf
Luxembourg
Tel.: +352-710 725 447
Fax: +352-710 725 482
E-mail: Jens.Krause at ses-astra.com
Our web site: http://www.ses-astra.com
---------------------------------------------------------------------------




--
DISCLAIMER:
This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.






From AAllison at nab.org  Tue Feb 17 19:45:38 2004
From: AAllison at nab.org (Allison, Art)
Date: Tue, 17 Feb 2004 14:45:38 -0500
Subject: Question on Continuity Counter field
Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEDB@mail.NAB.ORG>

IMHO, if a MPEG-2 TS parser was presented with out of order packets identified by the same PID, a receiver failure is to be expected as the stream would be non-conformant. 

However, the continuity_counter can be the same in sequential packets (which are then required to be the same except for the PCR).  Also, this count may be discontinuous when that is indicated by the discontinuity_indicator.  So it is not always a monotonically incrementing field.  Given the rules for this 4-bit continuity_counter, it is not apparent that it is possible to use it to reorder packets at the MPEG-2 level.

Therefore, IMHO, any lower level communication protocol must not reorder MPEG-2 transport stream packets that are identified by the same PID. If it has a potential to do so, then either constraints or an explicit method for restoring the order must be defined. 

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Tarif.Zein-Alabedeen at space.alcatel.fr
[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
Sent: Friday, February 13, 2004 9:05 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: Question on Continuity Counter field
Importance: Low




Hi,
I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1

Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled?

(oups, this makes 3 questions already)

thank's and best regards


T. Zein
ALCATEL SPACE
DRT/RST





From williams77 at rediffmail.com  Wed Feb 18 05:04:38 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 18 Feb 2004 05:04:38 -0000
Subject: Question on Continuity Counter field
Message-ID: <20040218050438.16049.qmail@mailweb33.rediffmail.com>

A non-text attachment was scrubbed...
Name: not available
Type: multipart/alternative
Size: 2310 bytes
Desc: not available
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040218/01fb4c47/attachment.bin>

From Rod.Walsh at nokia.com  Wed Feb 18 12:24:53 2004
From: Rod.Walsh at nokia.com (Rod.Walsh at nokia.com)
Date: Wed, 18 Feb 2004 14:24:53 +0200
Subject: Question on Continuity Counter field
Message-ID: <D0299AFF29E01E478321564030AD6909539415@trebe003.europe.nokia.com>

Hi

It is implementation dependent. Most likely a receiver would assume it has missed some packet(s). The spec doesn't specify the behaviour of a receiver. The spec only specifies how required parameters (incl. the continuity_counter) are coded.

Cheers, Rod.

-----Original Message-----
From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
Behalf Of ext Tarif.Zein-Alabedeen at space.alcatel.fr
Sent: Friday, February 13, 2004 4:05 PM
To: ip-dvb at erg.abdn.ac.uk
Subject: Question on Continuity Counter field
Importance: Low




Hi,
I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1

Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled?

(oups, this makes 3 questions already)

thank's and best regards


T. Zein
ALCATEL SPACE
DRT/RST



From Tarif.Zein-Alabedeen at space.alcatel.fr  Wed Feb 18 12:48:51 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Wed, 18 Feb 2004 13:48:51 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_Question_on_Continuity_Counter_field?=
Message-ID: <OF8AFE91E9.BE8A8DBD-ONC1256E3E.003F2741@netfr.alcatel.fr>



Thank you Art and william for your answers...

William says that consider or mask CC check for a given PID is implementation dependent.. is someone aware of the general rule for current IP/MPE/MPEG implementations?

Considering our ULE encapsulation, I think it would be wise to provision an option allowing to disactivate CC check for specified PIDs in the receiver. This may be helpful if, at some point in the future, we need ULE/MPEG to operate correctly in a mesh or multi star scenarios (PID shared among several transmiters). what is your opinion about that?

best regards
Traif ZEIN








"Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
cc :
Objet :     RE: Question on Continuity Counter field


IMHO, if a MPEG-2 TS parser was presented with out of order packets identified by the same PID, a receiver failure is to be expected as the stream would be non-conformant.

However, the continuity_counter can be the same in sequential packets (which are then required to be the same except for the PCR).  Also, this count may be discontinuous when that is indicated by the discontinuity_indicator.  So it is not always a monotonically incrementing field.  Given the rules for this 4-bit continuity_counter, it is not apparent that it is possible to use it to reorder packets at the MPEG-2 level.

Therefore, IMHO, any lower level communication protocol must not reorder MPEG-2 transport stream packets that are identified by the same PID. If it has a potential to do so, then either constraints or an explicit method for restoring the order must be defined.

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Tarif.Zein-Alabedeen at space.alcatel.fr
[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
Sent: Friday, February 13, 2004 9:05 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: Question on Continuity Counter field
Importance: Low




Hi,
I have a question about the continuity counter field in the TS packet header. May be someone in this group has the right answer : what heppens if an MPEG receiver receives an out of order TS packet? that is, for the same PID, the CC field value of a received packet not equal to CC field value of precedent TS packet + 1

Is there one standard behavior or is it implmenetation dependent? can CC check as the receiver be disabled?

(oups, this makes 3 questions already)

thank's and best regards











From gorry at erg.abdn.ac.uk  Wed Feb 18 13:38:13 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Wed, 18 Feb 2004 13:38:13 +0000
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <D0299AFF29E01E478321564030AD69090BE558@trebe003.europe.nokia.com>
Message-ID: <BC591B46.241%gorry@erg.abdn.ac.uk>

On 12/2/04 8:16 am, "Rod.Walsh at nokia.com" <Rod.Walsh at nokia.com> wrote:

> Hi Gorry & WG
> 
> I also support ULE adoption as a WG draft.
> 
> Please spell out the proposed timeframe as this has a big effect on 
> the quality of the final document developed.

There are now several early implementations being developed, so I'm keen to progress this, in parallel with this.

The milestones for ULE are on the ipdvb Charter page at: http://ietf.org/

> BTW, the "option (2)" is rather confusing

Sorry, it was just a general form of words for adopting a WG item. The aim is to allow people to tell the WG, if there is another (competing) ID on the way, or some alternative approach that also would address the charter, and hence they have concerns about adopting the WG item.

> "That there is (or could be)
> alternative approaches to the problem, and that the current draft is 
> not sufficiently developed", since there is an existing solution (MPE) 
> and there certainly are alternatives (even ipdvb started with 2 :).

Indeed MPE exists - and is acknowledged in the WG Charter.

The UNISAL encapsulation is not (as far as I am aware) being resubmitted to this WG as a competitor to ULE.

> Also, the point of
> chartering into a WG is to develop the work-in-progress draft with the 
> aim of publishing as an RFC - not just rubber stamp the individual 
> draft with an RFC number.

Exactly, the WG is now looking for any inputs and/or potential concerns.

> Is this just imprecise wording, or have I misunderstood? - please 
> clarify.

The wording of (2) was loose, to allow scope to respond - thanks for asking.

> 
> (I'll be in Korea, so would be happy to share a couple of round with 
> anyone interested in a bar-WG - not a bar-bof anymore :)
> 
> Cheers, Rod.
> 
> 
> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk 
> [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> Behalf Of ext Gorry Fairhurst
> Sent: Monday, February 09, 2004 12:58 PM
> To: ipdvb at 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) ???
> 
> 
5= Consideration of the proposed ULE Extension Header
> 




From alain.ritoux at 6wind.com  Wed Feb 18 13:52:57 2004
From: alain.ritoux at 6wind.com (alain.ritoux at 6wind.com)
Date: Wed, 18 Feb 2004 14:52:57 +0100
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_RE=3A_Question_on_Cont?=
 =?ISO-8859-1?Q?inuity_Counter_field?=
In-Reply-To: <c0vosn$2idf$1@intranet.6wind.com>
References: <c0vosn$2idf$1@intranet.6wind.com>
Message-ID: <40336E39.3050203@6wind.com>



Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
> 
> Thank you Art and william for your answers...
> 
> William says that consider or mask CC check for a given PID is 
> implementation dependent.. is someone aware of the general rule for 
> current IP/MPE/MPEG implementations?
> 
> Considering our ULE encapsulation, I think it would be wise to 
> provision an option allowing to disactivate CC check for specified 
> PIDs in the receiver.
I'm not that sure, because the countinuity counter shows some TS cells loss, which can be meesy wrt ULE re-assembly, so ignoring it may lead to strange packets (unless detetected by sizes issues). Of course such packets have very little chance to pass the CRC32 test, but an earlier drop prevents CPU usage for nothing.


> This may be helpful if, at some point in the future, we need ULE/MPEG 
> to operate correctly in a mesh or multi star scenarios (PID shared 
> among several transmiters).
The way ULE is designed doesn't seem to work with several independant transmitters, because reassembly of ULE SNDU is led only by PID, and if 2 SNDU ares sent by 2 transmitters, each splitting over many TS cells, the reciever, won't be able to tell whose fragment belongs to who, and hence won't be able to reconstruct any of the SNDUs.

my 2 cents.

Cheers.
Alain
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com




From bnocker at cosy.sbg.ac.at  Wed Feb 18 14:31:41 2004
From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker)
Date: Wed, 18 Feb 2004 15:31:41 +0100
Subject: =?iso-8859-1?Q?RE:_R=E9f._:_RE:_Question_on_Continuity_Counter_field?=
In-Reply-To: <OF8AFE91E9.BE8A8DBD-ONC1256E3E.003F2741@netfr.alcatel.fr>
Message-ID: <HOEPKOKAJBEOAIPGLHOCCEIDEMAA.bnocker@cosy.sbg.ac.at>

Dear all,

I do not agree with the conclusion that considering or masking CC check for a given PID is implementation dependent. According to ISO/IEC 13818-1 the CC is a 4 bit field incrementing with each Transport Stream packet with the same PID. It wraps around to 0 after its maxmimum value. Only in case when the adaptation_filed_control bits indicate "reserved" or "no payload" the CC shall not be incremented. For the receiver the CC is the only means (despite of a CRC/checksum of the reassembled payload) to check for TS packets belonging to the same "payload" on the same PID. When the CC of a subsequent packet is not incremented by one (or wrapped) then the receiver must assume that it has lost one or more TS packets and must wait for the next PUSI to resynchronize. It must flush its buffer if an end of a payload has not been reached yet. Disabling CC check on the receiver probably makes only sense if each payload fits into one TS packet, hence, all TS packets carry a PUSI and discontinuity does not introduce problems.

Finally PID sharing among different transmitters must follow the same rules. If there is no onboard functionality that resolves discontinuties in buffering complete payloads (sections or elementary stream packets or even ULE protocol data units) and playout with incremental CCs per payload receivers would screw up completely.

Kind regards,
Bernhard

Dr. Bernhard Collini-Nocker
Institute for Computer Sciences
Salzburg University
J. Haringerstr. 2
A-5020 Salzburg
Tel: +43 662 8044 6316
Fax: +43 662 8044 611



> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk 
> [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> Behalf Of Tarif.Zein-Alabedeen at space.alcatel.fr
> Sent: Mittwoch, 18. Februar 2004 13:49
> To: ip-dvb at erg.abdn.ac.uk
> Subject: R?f. : RE: Question on Continuity Counter field
> Importance: Low
>
>
>
>
> Thank you Art and william for your answers...
>
> William says that consider or mask CC check for a given PID is 
> implementation dependent.. is someone aware of the general rule for 
> current IP/MPE/MPEG implementations?
>
> Considering our ULE encapsulation, I think it would be wise to 
> provision an option allowing to disactivate CC check for specified 
> PIDs in the receiver.
> This may be helpful if, at some point in the future, we need ULE/MPEG to
> operate correctly in a mesh or multi star scenarios (PID shared among
> several transmiters).
> what is your opinion about that?
>
> best regards
> Traif ZEIN
>
>
>
>
>
>
>
>
> "Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 
> 20:45:38
>
> Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>
> Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>
>
> Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
> cc :
> Objet :     RE: Question on Continuity Counter field
>
>
> IMHO, if a MPEG-2 TS parser was presented with out of order packets 
> identified by the same PID, a receiver failure is to be expected as 
> the stream would be non-conformant.
>
> However, the continuity_counter can be the same in sequential packets 
> (which are then required to be the same except for the PCR).  Also, 
> this count may
> be discontinuous when that is indicated by the
> discontinuity_indicator.  So
> it is not always a monotonically incrementing field.  Given the rules for
> this 4-bit continuity_counter, it is not apparent that it is possible to
> use
> it to reorder packets at the MPEG-2 level.
>
> Therefore, IMHO, any lower level communication protocol must not 
> reorder MPEG-2 transport stream packets that are identified by the 
> same PID. If it has a potential to do so, then either constraints or 
> an explicit method for restoring the order must be defined.
>
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
>
>
> -----Original Message-----
> From: Tarif.Zein-Alabedeen at space.alcatel.fr
> [mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
> Sent: Friday, February 13, 2004 9:05 AM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Question on Continuity Counter field
> Importance: Low
>
>
>
>
> Hi,
> I have a question about the continuity counter field in the TS packet 
> header. May be someone in this group has the right answer : what 
> heppens if an MPEG receiver receives an out of order TS packet? that 
> is, for the same PID, the CC field value of a received packet not 
> equal to CC field value of precedent TS packet + 1
>
> Is there one standard behavior or is it implmenetation dependent? can 
> CC check as the receiver be disabled?
>
> (oups, this makes 3 questions already)
>
> thank's and best regards
>
>
>
>
>



From williams77 at rediffmail.com  Wed Feb 18 16:00:05 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 18 Feb 2004 16:00:05 -0000
Subject: =?iso-8859-1?Q?Re:_RE:_R=E9f=2E_:_RE:_Question_on_Continuity_Counter_fie?=
 =?iso-8859-1?Q?ld?=
Message-ID: <20040218160005.26069.qmail@mailweb34.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040218/dc45d7f5/attachment.html>
-------------- next part --------------
Dear all,
   I fully agree on Bernhard's comment, CC is the only means of validating any payload belonging to same TS packets for that PID. In case if any intermediate TS packets are lost, RX state moves to out of sync and flushes the buffer.
   But masking of CC is used on propriety PIDs and Real Time protocol PIDs,  where loss of TS packets are merely eliminated, mostly single ip packet is filled in one TS packet and  which is taken care by higher layer protocol.

Best Regards,
William.


On Wed, 18 Feb 2004 Bernhard Collini-Nocker wrote :
>Dear all,
>
>I do not agree with the conclusion that considering or masking CC check for
>a given PID is implementation dependent. According to ISO/IEC 13818-1 the CC
>is a 4 bit field incrementing with each Transport Stream packet with the
>same PID. It wraps around to 0 after its maxmimum value. Only in case when
>the adaptation_filed_control bits indicate "reserved" or "no payload" the CC
>shall not be incremented.
>For the receiver the CC is the only means (despite of a CRC/checksum of the
>reassembled payload) to check for TS packets belonging to the same "payload"
>on the same PID. When the CC of a subsequent packet is not incremented by
>one (or wrapped) then the receiver must assume that it has lost one or more
>TS packets and must wait for the next PUSI to resynchronize. It must flush
>its buffer if an end of a payload has not been reached yet.
>Disabling CC check on the receiver probably makes only sense if each payload
>fits into one TS packet, hence, all TS packets carry a PUSI and
>discontinuity does not introduce problems.
>
>Finally PID sharing among different transmitters must follow the same rules.
>If there is no onboard functionality that resolves discontinuties in
>buffering complete payloads (sections or elementary stream packets or even
>ULE protocol data units) and playout with incremental CCs per payload
>receivers would screw up completely.
>
>Kind regards,
>Bernhard
>
>Dr. Bernhard Collini-Nocker
>Institute for Computer Sciences
>Salzburg University
>J. Haringerstr. 2
>A-5020 Salzburg
>Tel: +43 662 8044 6316
>Fax: +43 662 8044 611
>
>
>
> > -----Original Message-----
> > From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> > Behalf Of Tarif.Zein-Alabedeen at space.alcatel.fr
> > Sent: Mittwoch, 18. Februar 2004 13:49
> > To: ip-dvb at erg.abdn.ac.uk
> > Subject: R?f. : RE: Question on Continuity Counter field
> > Importance: Low
> >
> >
> >
> >
> > Thank you Art and william for your answers...
> >
> > William says that consider or mask CC check for a given PID is
> > implementation dependent..
> > is someone aware of the general rule for current IP/MPE/MPEG
> > implementations?
> >
> > Considering our ULE encapsulation, I think it would be wise to
> > provision an
> > option allowing to disactivate CC check for specified PIDs in the
> > receiver.
> > This may be helpful if, at some point in the future, we need ULE/MPEG to
> > operate correctly in a mesh or multi star scenarios (PID shared among
> > several transmiters).
> > what is your opinion about that?
> >
> > best regards
> > Traif ZEIN
> >
> >
> >
> >
> >
> >
> >
> >
> > "Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
> >
> > Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
> >
> > Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
> >
> >
> > Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
> > cc :
> > Objet :     RE: Question on Continuity Counter field
> >
> >
> > IMHO, if a MPEG-2 TS parser was presented with out of order packets
> > identified by the same PID, a receiver failure is to be expected as the
> > stream would be non-conformant.
> >
> > However, the continuity_counter can be the same in sequential packets
> > (which
> > are then required to be the same except for the PCR).  Also, this
> > count may
> > be discontinuous when that is indicated by the
> > discontinuity_indicator.  So
> > it is not always a monotonically incrementing field.  Given the rules for
> > this 4-bit continuity_counter, it is not apparent that it is possible to
> > use
> > it to reorder packets at the MPEG-2 level.
> >
> > Therefore, IMHO, any lower level communication protocol must not reorder
> > MPEG-2 transport stream packets that are identified by the same PID. If it
> > has a potential to do so, then either constraints or an explicit
> > method for
> > restoring the order must be defined.
> >
> > Art
> > ::{)>
> > Art Allison
> > Director Advanced Engineering
> > NAB
> > 1771 N St NW
> > Washington DC 20036
> > 202 429 5418
> >
> >
> > -----Original Message-----
> > From: Tarif.Zein-Alabedeen at space.alcatel.fr
> > [mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
> > Sent: Friday, February 13, 2004 9:05 AM
> > To: ip-dvb at erg.abdn.ac.uk
> > Subject: Question on Continuity Counter field
> > Importance: Low
> >
> >
> >
> >
> > Hi,
> > I have a question about the continuity counter field in the TS packet
> > header. May be someone in this group has the right answer :
> > what heppens if an MPEG receiver receives an out of order TS packet?
> > that is, for the same PID, the CC field value of a received packet not
> > equal to CC field value of precedent TS packet + 1
> >
> > Is there one standard behavior or is it implmenetation dependent?
> > can CC check as the receiver be disabled?
> >
> > (oups, this makes 3 questions already)
> >
> > thank's and best regards
> >
> >
> >
> >
> >
>

From AAllison at nab.org  Wed Feb 18 17:58:11 2004
From: AAllison at nab.org (Allison, Art)
Date: Wed, 18 Feb 2004 12:58:11 -0500
Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_RE=3A_Question_on_Continuity?=
	=?iso-8859-1?Q?_Counter_field?=
Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEE9@mail.NAB.ORG>

Please note that the Continuity Counter need not increment in the special
case where the TS packet contents are duplicated, see same ref as below (and
my previous post). (So I take this small exception to Bernhard's post
below). But I agree with the thrust of his post.

Stated simply, if TS packets get out of order then one does not have a valid
MPEG-2 stream any longer and a receiver cannot be expected to work. The
question is about how to handle this failure mode seems a futile and
non-productive exercise. Don't enable it.

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Bernhard Collini-Nocker [mailto:bnocker at cosy.sbg.ac.at]
Sent: Wednesday, February 18, 2004 9:32 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: RE: R?f. : RE: Question on Continuity Counter field


Dear all,

I do not agree with the conclusion that considering or masking CC check for
a given PID is implementation dependent. According to ISO/IEC 13818-1 the CC
is a 4 bit field incrementing with each Transport Stream packet with the
same PID. It wraps around to 0 after its maxmimum value. Only in case when
the adaptation_filed_control bits indicate "reserved" or "no payload" the CC
shall not be incremented.
For the receiver the CC is the only means (despite of a CRC/checksum of the
reassembled payload) to check for TS packets belonging to the same "payload"
on the same PID. When the CC of a subsequent packet is not incremented by
one (or wrapped) then the receiver must assume that it has lost one or more
TS packets and must wait for the next PUSI to resynchronize. It must flush
its buffer if an end of a payload has not been reached yet.
Disabling CC check on the receiver probably makes only sense if each payload
fits into one TS packet, hence, all TS packets carry a PUSI and
discontinuity does not introduce problems.

Finally PID sharing among different transmitters must follow the same rules.
If there is no onboard functionality that resolves discontinuties in
buffering complete payloads (sections or elementary stream packets or even
ULE protocol data units) and playout with incremental CCs per payload
receivers would screw up completely.

Kind regards,
Bernhard

Dr. Bernhard Collini-Nocker
Institute for Computer Sciences
Salzburg University
J. Haringerstr. 2
A-5020 Salzburg
Tel: +43 662 8044 6316
Fax: +43 662 8044 611



> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> Behalf Of Tarif.Zein-Alabedeen at space.alcatel.fr
> Sent: Mittwoch, 18. Februar 2004 13:49
> To: ip-dvb at erg.abdn.ac.uk
> Subject: R?f. : RE: Question on Continuity Counter field
> Importance: Low
>
>
>
>
> Thank you Art and william for your answers...
>
> William says that consider or mask CC check for a given PID is
> implementation dependent..
> is someone aware of the general rule for current IP/MPE/MPEG
> implementations?
>
> Considering our ULE encapsulation, I think it would be wise to
> provision an
> option allowing to disactivate CC check for specified PIDs in the
> receiver.
> This may be helpful if, at some point in the future, we need ULE/MPEG to
> operate correctly in a mesh or multi star scenarios (PID shared among
> several transmiters).
> what is your opinion about that?
>
> best regards
> Traif ZEIN
>
>
>
>
>
>
>
>
> "Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
>
> Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>
> Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>
>
> Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
> cc :
> Objet :     RE: Question on Continuity Counter field
>
>
> IMHO, if a MPEG-2 TS parser was presented with out of order packets
> identified by the same PID, a receiver failure is to be expected as the
> stream would be non-conformant.
>
> However, the continuity_counter can be the same in sequential packets
> (which
> are then required to be the same except for the PCR).  Also, this
> count may
> be discontinuous when that is indicated by the
> discontinuity_indicator.  So
> it is not always a monotonically incrementing field.  Given the rules for
> this 4-bit continuity_counter, it is not apparent that it is possible to
> use
> it to reorder packets at the MPEG-2 level.
>
> Therefore, IMHO, any lower level communication protocol must not reorder
> MPEG-2 transport stream packets that are identified by the same PID. If it
> has a potential to do so, then either constraints or an explicit
> method for
> restoring the order must be defined.
>
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
>
>
> -----Original Message-----
> From: Tarif.Zein-Alabedeen at space.alcatel.fr
> [mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
> Sent: Friday, February 13, 2004 9:05 AM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Question on Continuity Counter field
> Importance: Low
>
>
>
>
> Hi,
> I have a question about the continuity counter field in the TS packet
> header. May be someone in this group has the right answer :
> what heppens if an MPEG receiver receives an out of order TS packet?
> that is, for the same PID, the CC field value of a received packet not
> equal to CC field value of precedent TS packet + 1
>
> Is there one standard behavior or is it implmenetation dependent?
> can CC check as the receiver be disabled?
>
> (oups, this makes 3 questions already)
>
> thank's and best regards
>
>
>
>
>



From gorry at erg.abdn.ac.uk  Wed Feb 18 13:55:21 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Wed, 18 Feb 2004 13:55:21 +0000
Subject: R=?ISO-8859-1?B?6Q==?=f. : RE: Question on Continuity Counter
	field
In-Reply-To: <OF8AFE91E9.BE8A8DBD-ONC1256E3E.003F2741@netfr.alcatel.fr>
Message-ID: <BC591F49.25C%gorry@erg.abdn.ac.uk>

So....

On transmission ULE  currently says:
       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
        Continuity Counter carried in the TS Packet header.  This value MUST
        be incremented by one (using modulo arithmetic) for each TS Packet
        sent using a TS Logical Channel [ISO-MPEG]."

This simply says the encapsulator must be compliant for what it sends.

At the receiver:
       "The Receiver MAY also check the MPEG-2 Continuity Counter carried in
        the TS Packet header. If the Receiver does perform Continuity
        Counter checking and the received value does not increment by one
        for successive TS Packets (modulo 16), the Receiver has detected a
        continuity error. Any partially received SNDU MUST be discarded. A
        continuity counter error event SHOULD be recorded. The Receiver then
        enters the Idle State."


The case for ULE reception seems much less clear, and I'd be interested to
re-assess the correct behaviour.

I wonder what is the implication of simply ignoring the CC field?
- This has no impact as far as I can see on ULE payload data integrity OR
framing, since in ULE these are primarily protected by the CRC-32.

Does anyone think we should change the recommendation to "SHOULD NOT" check
or "MUST" ignore the CC field?

Gorry


On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen at space.alcatel.fr"
<Tarif.Zein-Alabedeen at space.alcatel.fr> wrote:

> 
> 
> Thank you Art and william for your answers...
> 
> William says that consider or mask CC check for a given PID is
> implementation dependent..
> is someone aware of the general rule for current IP/MPE/MPEG
> implementations?
> 
> Considering our ULE encapsulation, I think it would be wise to provision an
> option allowing to disactivate CC check for specified PIDs in the receiver.
> This may be helpful if, at some point in the future, we need ULE/MPEG to
> operate correctly in a mesh or multi star scenarios (PID shared among
> several transmiters).
> what is your opinion about that?
> 
> best regards
> Traif ZEIN
> 
> 
> 
> 
> 
> 
> 
> 
> "Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
> 
> Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
> 
> Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
> 
> 
> Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
> cc :
> Objet :     RE: Question on Continuity Counter field
> 
> 
> IMHO, if a MPEG-2 TS parser was presented with out of order packets
> identified by the same PID, a receiver failure is to be expected as the
> stream would be non-conformant.
> 
> However, the continuity_counter can be the same in sequential packets
> (which
> are then required to be the same except for the PCR).  Also, this count may
> be discontinuous when that is indicated by the discontinuity_indicator.  So
> it is not always a monotonically incrementing field.  Given the rules for
> this 4-bit continuity_counter, it is not apparent that it is possible to
> use
> it to reorder packets at the MPEG-2 level.
> 
> Therefore, IMHO, any lower level communication protocol must not reorder
> MPEG-2 transport stream packets that are identified by the same PID. If it
> has a potential to do so, then either constraints or an explicit method for
> restoring the order must be defined.
> 
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
> 
> 
> -----Original Message-----
> From: Tarif.Zein-Alabedeen at space.alcatel.fr
> [mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
> Sent: Friday, February 13, 2004 9:05 AM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Question on Continuity Counter field
> Importance: Low
> 
> 
> 
> 
> Hi,
> I have a question about the continuity counter field in the TS packet
> header. May be someone in this group has the right answer :
> what heppens if an MPEG receiver receives an out of order TS packet?
> that is, for the same PID, the CC field value of a received packet not
> equal to CC field value of precedent TS packet + 1
> 
> Is there one standard behavior or is it implmenetation dependent?
> can CC check as the receiver be disabled?
> 
> (oups, this makes 3 questions already)
> 
> thank's and best regards
> 
> 
> 
> 
> 




From AAllison at nab.org  Wed Feb 18 22:52:08 2004
From: AAllison at nab.org (Allison, Art)
Date: Wed, 18 Feb 2004 17:52:08 -0500
Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_RE=3A_Question_on_Continuity?=
	=?iso-8859-1?Q?_Counter_field?=
Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEEB@mail.NAB.ORG>

So... what if the source MPEG-2 Transport stream has two packets that are
identified by the same PID which do not increment the CC (because the
content did not change)? 

This language would seem to require the CC to be incremented, which would
result in the duplicated data being presented to the parser as if it is the
next data in sequence. The resulting stream would no longer meet
13818-1:2000 and receiver behavior is unpredictable. Note that the packet
could be a table section, where error concealment is not an option. 

Also see my earlier post for other conditions where this payload counter
should not be incremented..

Further, requiring the ULE layer to touch this payload value seems like a
cross between layers and therefore a questionable design...  

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
Sent: Wednesday, February 18, 2004 8:55 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: Re: R?f. : RE: Question on Continuity Counter field


So....

On transmission ULE  currently says:
       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
        Continuity Counter carried in the TS Packet header.  This value MUST
        be incremented by one (using modulo arithmetic) for each TS Packet
        sent using a TS Logical Channel [ISO-MPEG]."

This simply says the encapsulator must be compliant for what it sends.

At the receiver:
       "The Receiver MAY also check the MPEG-2 Continuity Counter carried in
        the TS Packet header. If the Receiver does perform Continuity
        Counter checking and the received value does not increment by one
        for successive TS Packets (modulo 16), the Receiver has detected a
        continuity error. Any partially received SNDU MUST be discarded. A
        continuity counter error event SHOULD be recorded. The Receiver then
        enters the Idle State."


The case for ULE reception seems much less clear, and I'd be interested to
re-assess the correct behaviour.

I wonder what is the implication of simply ignoring the CC field?
- This has no impact as far as I can see on ULE payload data integrity OR
framing, since in ULE these are primarily protected by the CRC-32.

Does anyone think we should change the recommendation to "SHOULD NOT" check
or "MUST" ignore the CC field?

Gorry


On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen at space.alcatel.fr"
<Tarif.Zein-Alabedeen at space.alcatel.fr> wrote:

> 
> 
> Thank you Art and william for your answers...
> 
> William says that consider or mask CC check for a given PID is
> implementation dependent..
> is someone aware of the general rule for current IP/MPE/MPEG
> implementations?
> 
> Considering our ULE encapsulation, I think it would be wise to provision
an
> option allowing to disactivate CC check for specified PIDs in the
receiver.
> This may be helpful if, at some point in the future, we need ULE/MPEG to
> operate correctly in a mesh or multi star scenarios (PID shared among
> several transmiters).
> what is your opinion about that?
> 
> best regards
> Traif ZEIN
> 
> 
> 
> 
> 
> 
> 
> 
> "Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
> 
> Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
> 
> Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
> 
> 
> Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
> cc :
> Objet :     RE: Question on Continuity Counter field
> 
> 
> IMHO, if a MPEG-2 TS parser was presented with out of order packets
> identified by the same PID, a receiver failure is to be expected as the
> stream would be non-conformant.
> 
> However, the continuity_counter can be the same in sequential packets
> (which
> are then required to be the same except for the PCR).  Also, this count
may
> be discontinuous when that is indicated by the discontinuity_indicator.
So
> it is not always a monotonically incrementing field.  Given the rules for
> this 4-bit continuity_counter, it is not apparent that it is possible to
> use
> it to reorder packets at the MPEG-2 level.
> 
> Therefore, IMHO, any lower level communication protocol must not reorder
> MPEG-2 transport stream packets that are identified by the same PID. If it
> has a potential to do so, then either constraints or an explicit method
for
> restoring the order must be defined.
> 
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
> 
> 
> -----Original Message-----
> From: Tarif.Zein-Alabedeen at space.alcatel.fr
> [mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
> Sent: Friday, February 13, 2004 9:05 AM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Question on Continuity Counter field
> Importance: Low
> 
> 
> 
> 
> Hi,
> I have a question about the continuity counter field in the TS packet
> header. May be someone in this group has the right answer :
> what heppens if an MPEG receiver receives an out of order TS packet?
> that is, for the same PID, the CC field value of a received packet not
> equal to CC field value of precedent TS packet + 1
> 
> Is there one standard behavior or is it implmenetation dependent?
> can CC check as the receiver be disabled?
> 
> (oups, this makes 3 questions already)
> 
> thank's and best regards
> 
> 
> 
> 
> 




From gorry at erg.abdn.ac.uk  Thu Feb 19 15:09:32 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Thu, 19 Feb 2004 15:09:32 +0000
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_RE=3A_Question_on_Cont?=
 =?ISO-8859-1?Q?inuity_Counter_field?=
In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEEB@mail.NAB.ORG>
References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEEB@mail.NAB.ORG>
Message-ID: <4034D1AC.8030807@erg.abdn.ac.uk>

Before we look at any new ideas for potentially easing use of ULE over 
regenerative satellites, I'd like to clearly understand the points 
raised below, specifically the correct sender/receiver behaviour as 
required by MPEG-2:

Allison, Art wrote:

>So... what if the source MPEG-2 Transport stream has two packets that are
>identified by the same PID which do not increment the CC (because the
>content did not change)? 
>
So is this where the sender (encapsulator)  intentionaly replicates 
exactly the last TS-Packet?

>This language would seem to require the CC to be incremented, which would
>result in the duplicated data being presented to the parser as if it is the
>next data in sequence. The resulting stream would no longer meet
>13818-1:2000 and receiver behavior is unpredictable. Note that the packet
>could be a table section, where error concealment is not an option. 
>
If you're saying duplication is a valid technique to conceal loss, then 
the appropriate response should be to discard any duplicates (with 
identical CC). This is not what the current ID text says.

~If at all possible, ULE should be designed to fully conform to ISO 
MPEG-2 TS,  that is a stated goal.

Some new text is now definitely required.

>
>Also see my earlier post for other conditions where this payload counter
>should not be incremented..
>
>Further, requiring the ULE layer to touch this payload value seems like a
>cross between layers and therefore a questionable design...  
>
The current text did NOT require acceess to the CC field.  The actual 
text, only permitted this: "The Receiver MAY also check"...  There are 
alos other ways of verifying framing and integrity in ULE.

Best wishes,

Gorry

>
>Art
>::{)>
>Art Allison
>Director Advanced Engineering
>NAB
>1771 N St NW
>Washington DC 20036
>202 429 5418
>
>
>-----Original Message-----
>From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
>Sent: Wednesday, February 18, 2004 8:55 AM
>To: ip-dvb at erg.abdn.ac.uk
>Subject: Re: R?f. : RE: Question on Continuity Counter field
>
>
>So....
>
>On transmission ULE  currently says:
>       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
>        Continuity Counter carried in the TS Packet header.  This value MUST
>        be incremented by one (using modulo arithmetic) for each TS Packet
>        sent using a TS Logical Channel [ISO-MPEG]."
>
>This simply says the encapsulator must be compliant for what it sends.
>
>At the receiver:
>       "The Receiver MAY also check the MPEG-2 Continuity Counter carried in
>        the TS Packet header. If the Receiver does perform Continuity
>        Counter checking and the received value does not increment by one
>        for successive TS Packets (modulo 16), the Receiver has detected a
>        continuity error. Any partially received SNDU MUST be discarded. A
>        continuity counter error event SHOULD be recorded. The Receiver then
>        enters the Idle State."
>
>
>The case for ULE reception seems much less clear, and I'd be interested to
>re-assess the correct behaviour.
>
>I wonder what is the implication of simply ignoring the CC field?
>- This has no impact as far as I can see on ULE payload data integrity OR
>framing, since in ULE these are primarily protected by the CRC-32.
>
>Does anyone think we should change the recommendation to "SHOULD NOT" check
>or "MUST" ignore the CC field?
>
>Gorry
>
>
>On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen at space.alcatel.fr"
><Tarif.Zein-Alabedeen at space.alcatel.fr> wrote:
>
>  
>
>>Thank you Art and william for your answers...
>>
>>William says that consider or mask CC check for a given PID is
>>implementation dependent..
>>is someone aware of the general rule for current IP/MPE/MPEG
>>implementations?
>>
>>Considering our ULE encapsulation, I think it would be wise to provision
>>    
>>
>an
>  
>
>>option allowing to disactivate CC check for specified PIDs in the
>>    
>>
>receiver.
>  
>
>>This may be helpful if, at some point in the future, we need ULE/MPEG to
>>operate correctly in a mesh or multi star scenarios (PID shared among
>>several transmiters).
>>what is your opinion about that?
>>
>>best regards
>>Traif ZEIN
>>
>>
>>
>>
>>
>>
>>
>>
>>"Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
>>
>>Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>>
>>Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>>
>>
>>Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
>>cc :
>>Objet :     RE: Question on Continuity Counter field
>>
>>
>>IMHO, if a MPEG-2 TS parser was presented with out of order packets
>>identified by the same PID, a receiver failure is to be expected as the
>>stream would be non-conformant.
>>
>>However, the continuity_counter can be the same in sequential packets
>>(which
>>are then required to be the same except for the PCR).  Also, this count
>>    
>>
>may
>  
>
>>be discontinuous when that is indicated by the discontinuity_indicator.
>>    
>>
>So
>  
>
>>it is not always a monotonically incrementing field.  Given the rules for
>>this 4-bit continuity_counter, it is not apparent that it is possible to
>>use
>>it to reorder packets at the MPEG-2 level.
>>
>>Therefore, IMHO, any lower level communication protocol must not reorder
>>MPEG-2 transport stream packets that are identified by the same PID. If it
>>has a potential to do so, then either constraints or an explicit method
>>    
>>
>for
>  
>
>>restoring the order must be defined.
>>
>>Art
>>::{)>
>>Art Allison
>>Director Advanced Engineering
>>NAB
>>1771 N St NW
>>Washington DC 20036
>>202 429 5418
>>
>>
>>-----Original Message-----
>>From: Tarif.Zein-Alabedeen at space.alcatel.fr
>>[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
>>Sent: Friday, February 13, 2004 9:05 AM
>>To: ip-dvb at erg.abdn.ac.uk
>>Subject: Question on Continuity Counter field
>>Importance: Low
>>
>>
>>
>>
>>Hi,
>>I have a question about the continuity counter field in the TS packet
>>header. May be someone in this group has the right answer :
>>what heppens if an MPEG receiver receives an out of order TS packet?
>>that is, for the same PID, the CC field value of a received packet not
>>equal to CC field value of precedent TS packet + 1
>>
>>Is there one standard behavior or is it implmenetation dependent?
>>can CC check as the receiver be disabled?
>>
>>(oups, this makes 3 questions already)
>>
>>thank's and best regards
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>  
>



From Tarif.Zein-Alabedeen at space.alcatel.fr  Thu Feb 19 16:41:18 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Thu, 19 Feb 2004 17:41:18 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_RE=3A_Question_on?=
 Continuity Counter field
Message-ID: <OF64C322CC.3BFD7E32-ONC1256E3F.00578548@netfr.alcatel.fr>



About your first question, yes, it seems that a sender can intentionaly
replicates TS packets (only one replicate is allowed I think). This is to
conceal packet losses
It does not seem however that replication is obligatory.  It is up to the
sender to decide this (is that correct Allison?)....

So, the question now is (and before rewriting the ID) : do we need
replication in our ULE/MPEG mode?

My first feeling is that we don't (but this is still a feeling).
For this, let me bring the following argumentation :
The only reason I see for a packet bieng lost (at least on transparent
satellite channel) is that an error occured in its PID field (PIDx became
PIDy).
Is that correct?!
(another reason would be buffer overflow at the sender but in that case
replication is not applicable..)

Packet duplications is surely efficient for these losses. However, for a
given bit error ratio, the probability of erros occuring within the 184
bytes payload should be much higher than the probability of errors occuring
in the 13 bits PID field. In other terms, packet loss probability should be
much smaller than packet error probability which leads anyway to SNDU being
droped after CRC check... So, resolving packet loss would not improve
significantly the SNDU loss/drop ratio and finally the PDU delivery
robustness.

May be someone is aware of studies or simulations having been done on this
issue and quantifying the improvment of replication on the SNDU loss/drop
ratio

regards





Gorry Fairhurst <gorry at erg.abdn.ac.uk>@erg.abdn.ac.uk on 19/02/2004
16:09:32

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : ip-dvb at erg.abdn.ac.uk
cc :
Objet :     Re: R?f. : RE: Question on Continuity Counter field


Before we look at any new ideas for potentially easing use of ULE over
regenerative satellites, I'd like to clearly understand the points
raised below, specifically the correct sender/receiver behaviour as
required by MPEG-2:

Allison, Art wrote:

>So... what if the source MPEG-2 Transport stream has two packets that are
>identified by the same PID which do not increment the CC (because the
>content did not change)?
>
So is this where the sender (encapsulator)  intentionaly replicates
exactly the last TS-Packet?

>This language would seem to require the CC to be incremented, which would
>result in the duplicated data being presented to the parser as if it is
the
>next data in sequence. The resulting stream would no longer meet
>13818-1:2000 and receiver behavior is unpredictable. Note that the packet
>could be a table section, where error concealment is not an option.
>
If you're saying duplication is a valid technique to conceal loss, then
the appropriate response should be to discard any duplicates (with
identical CC). This is not what the current ID text says.

~If at all possible, ULE should be designed to fully conform to ISO
MPEG-2 TS,  that is a stated goal.

Some new text is now definitely required.

>
>Also see my earlier post for other conditions where this payload counter
>should not be incremented..
>
>Further, requiring the ULE layer to touch this payload value seems like a
>cross between layers and therefore a questionable design...
>
The current text did NOT require acceess to the CC field.  The actual
text, only permitted this: "The Receiver MAY also check"...  There are
alos other ways of verifying framing and integrity in ULE.

Best wishes,

Gorry

>
>Art
>::{)>
>Art Allison
>Director Advanced Engineering
>NAB
>1771 N St NW
>Washington DC 20036
>202 429 5418
>
>
>-----Original Message-----
>From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
>Sent: Wednesday, February 18, 2004 8:55 AM
>To: ip-dvb at erg.abdn.ac.uk
>Subject: Re: R?f. : RE: Question on Continuity Counter field
>
>
>So....
>
>On transmission ULE  currently says:
>       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
>        Continuity Counter carried in the TS Packet header.  This value
MUST
>        be incremented by one (using modulo arithmetic) for each TS Packet
>        sent using a TS Logical Channel [ISO-MPEG]."
>
>This simply says the encapsulator must be compliant for what it sends.
>
>At the receiver:
>       "The Receiver MAY also check the MPEG-2 Continuity Counter carried
in
>        the TS Packet header. If the Receiver does perform Continuity
>        Counter checking and the received value does not increment by one
>        for successive TS Packets (modulo 16), the Receiver has detected a
>        continuity error. Any partially received SNDU MUST be discarded. A
>        continuity counter error event SHOULD be recorded. The Receiver
then
>        enters the Idle State."
>
>
>The case for ULE reception seems much less clear, and I'd be interested to
>re-assess the correct behaviour.
>
>I wonder what is the implication of simply ignoring the CC field?
>- This has no impact as far as I can see on ULE payload data integrity OR
>framing, since in ULE these are primarily protected by the CRC-32.
>
>Does anyone think we should change the recommendation to "SHOULD NOT"
check
>or "MUST" ignore the CC field?
>
>Gorry
>
>
>On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen at space.alcatel.fr"
><Tarif.Zein-Alabedeen at space.alcatel.fr> wrote:
>
>
>
>>Thank you Art and william for your answers...
>>
>>William says that consider or mask CC check for a given PID is
>>implementation dependent..
>>is someone aware of the general rule for current IP/MPE/MPEG
>>implementations?
>>
>>Considering our ULE encapsulation, I think it would be wise to provision
>>
>>
>an
>
>
>>option allowing to disactivate CC check for specified PIDs in the
>>
>>
>receiver.
>
>
>>This may be helpful if, at some point in the future, we need ULE/MPEG to
>>operate correctly in a mesh or multi star scenarios (PID shared among
>>several transmiters).
>>what is your opinion about that?
>>
>>best regards
>>Traif ZEIN
>>
>>
>>
>>
>>
>>
>>
>>
>>"Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
>>
>>Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>>
>>Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>>
>>
>>Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
>>cc :
>>Objet :     RE: Question on Continuity Counter field
>>
>>
>>IMHO, if a MPEG-2 TS parser was presented with out of order packets
>>identified by the same PID, a receiver failure is to be expected as the
>>stream would be non-conformant.
>>
>>However, the continuity_counter can be the same in sequential packets
>>(which
>>are then required to be the same except for the PCR).  Also, this count
>>
>>
>may
>
>
>>be discontinuous when that is indicated by the discontinuity_indicator.
>>
>>
>So
>
>
>>it is not always a monotonically incrementing field.  Given the rules for
>>this 4-bit continuity_counter, it is not apparent that it is possible to
>>use
>>it to reorder packets at the MPEG-2 level.
>>
>>Therefore, IMHO, any lower level communication protocol must not reorder
>>MPEG-2 transport stream packets that are identified by the same PID. If
it
>>has a potential to do so, then either constraints or an explicit method
>>
>>
>for
>
>
>>restoring the order must be defined.
>>
>>Art
>>::{)>
>>Art Allison
>>Director Advanced Engineering
>>NAB
>>1771 N St NW
>>Washington DC 20036
>>202 429 5418
>>
>>
>>-----Original Message-----
>>From: Tarif.Zein-Alabedeen at space.alcatel.fr
>>[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
>>Sent: Friday, February 13, 2004 9:05 AM
>>To: ip-dvb at erg.abdn.ac.uk
>>Subject: Question on Continuity Counter field
>>Importance: Low
>>
>>
>>
>>
>>Hi,
>>I have a question about the continuity counter field in the TS packet
>>header. May be someone in this group has the right answer :
>>what heppens if an MPEG receiver receives an out of order TS packet?
>>that is, for the same PID, the CC field value of a received packet not
>>equal to CC field value of precedent TS packet + 1
>>
>>Is there one standard behavior or is it implmenetation dependent?
>>can CC check as the receiver be disabled?
>>
>>(oups, this makes 3 questions already)
>>
>>thank's and best regards
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>






T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From AAllison at nab.org  Thu Feb 19 23:32:31 2004
From: AAllison at nab.org (Allison, Art)
Date: Thu, 19 Feb 2004 18:32:31 -0500
Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_RE=3A_Que?=
	=?iso-8859-1?Q?stion_onContinuity_Counter_field?=
Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBEF2@mail.NAB.ORG>

See embedded.. sorry, but in meetings all day today and tomorrow..
I responded to this response and to the note before it in this one
message...as the day is gone.
Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Tarif.Zein-Alabedeen at space.alcatel.fr
[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
Sent: Thursday, February 19, 2004 11:41 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: R?f. : Re: R?f. : RE: Question onContinuity Counter field
Importance: Low




About your first question, yes, it seems that a sender can intentionaly
replicates TS packets (only one replicate is allowed I think). This is to
conceal packet losses
It does not seem however that replication is obligatory.  It is up to the
sender to decide this (is that correct Allison?)....
AA> Correct, it is a sender option.  

So, the question now is (and before rewriting the ID) : do we need
replication in our ULE/MPEG mode?

My first feeling is that we don't (but this is still a feeling).
AA> I don't see the need for replication. 

For this, let me bring the following argumentation :
The only reason I see for a packet bieng lost (at least on transparent
satellite channel) is that an error occured in its PID field (PIDx became
PIDy).
Is that correct?!
AA>I don't know the OFDM error detection/protection coding and its
relationship to MPEG-2 packets. For QAM per SCTE and 8VSB per ATSC, a
defective packet is considered a lost packet.  If <any> physical layer error
processing coding/method is not enough for proper reconstruction of bits
damaged in a packet, then determining which bit is bad may not be possible.
Even if the system can determine which bit is not correct, there is only one
bit for signaling at the Transport Stream layer. Therefore which bit(s)
is(are) bad is not available at the MPEG-2 transport stream layer. 

(another reason would be buffer overflow at the sender but in that case
replication is not applicable..)
AA> Yes, if buffer overflow the TS is broken already and not this RFC's job
to try to fix.

Packet duplications is surely efficient for these losses. However, for a
given bit error ratio, the probability of erros occuring within the 184
bytes payload should be much higher than the probability of errors occuring
in the 13 bits PID field. In other terms, packet loss probability should be
much smaller than packet error probability which leads anyway to SNDU being
droped after CRC check... So, resolving packet loss would not improve
significantly the SNDU loss/drop ratio and finally the PDU delivery
robustness.
AA>Is it possible you are mixing PES layer with MPEG2 transport stream
layer? While a table can be in a packet (and therefore have a CRC in that
packet), they and PES packets cross packet boundaries.
AA> For some transports the entire packet is coded with Reed Solomon for
error detection and recovery, and if this fails the entire packet is usually
tossed.. The hit chance a function of bit count would only apply to <just>
the transport error indicator bit being hit, a very remote chance.

May be someone is aware of studies or simulations having been done on this
issue and quantifying the improvment of replication on the SNDU loss/drop
ratio

regards





Gorry Fairhurst <gorry at erg.abdn.ac.uk>@erg.abdn.ac.uk on 19/02/2004
16:09:32

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : ip-dvb at erg.abdn.ac.uk
cc :
Objet :     Re: R?f. : RE: Question on Continuity Counter field


Before we look at any new ideas for potentially easing use of ULE over
regenerative satellites, I'd like to clearly understand the points
raised below, specifically the correct sender/receiver behaviour as
required by MPEG-2:

Allison, Art wrote:

>So... what if the source MPEG-2 Transport stream has two packets that are
>identified by the same PID which do not increment the CC (because the
>content did not change)?
>
So is this where the sender (encapsulator)  intentionaly replicates
exactly the last TS-Packet?

AA> Yes.

>This language would seem to require the CC to be incremented, which would
>result in the duplicated data being presented to the parser as if it is
the
>next data in sequence. The resulting stream would no longer meet
>13818-1:2000 and receiver behavior is unpredictable. Note that the packet
>could be a table section, where error concealment is not an option.
>
If you're saying duplication is a valid technique to conceal loss, then
the appropriate response should be to discard any duplicates (with
identical CC). This is not what the current ID text says.
AA> Discarding of duplicates seems like an alternative.  However, if this
ULE were used as part of a distribution chain perhaps thinking if forces a
re-generation and insertion of duplicate packets.  Also the rules are more
complex than discard duplicates as they involve the state of the
discontinuity_indicator.

~If at all possible, ULE should be designed to fully conform to ISO
MPEG-2 TS,  that is a stated goal.

Some new text is now definitely required.

>
>Also see my earlier post for other conditions where this payload counter
>should not be incremented..
>
>Further, requiring the ULE layer to touch this payload value seems like a
>cross between layers and therefore a questionable design...
>
The current text did NOT require acceess to the CC field.  The actual
text, only permitted this: "The Receiver MAY also check"...  There are
alos other ways of verifying framing and integrity in ULE.
AA> I read an encapsulator MUST requirement (and cross over) not a receiver
requirement..

Best wishes,

Gorry

>
>Art
>::{)>
>Art Allison
>Director Advanced Engineering
>NAB
>1771 N St NW
>Washington DC 20036
>202 429 5418
>
>
>-----Original Message-----
>From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
>Sent: Wednesday, February 18, 2004 8:55 AM
>To: ip-dvb at erg.abdn.ac.uk
>Subject: Re: R?f. : RE: Question on Continuity Counter field
>
>
>So....
>
>On transmission ULE  currently says:
>       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
>        Continuity Counter carried in the TS Packet header.  This value
MUST
>        be incremented by one (using modulo arithmetic) for each TS Packet
>        sent using a TS Logical Channel [ISO-MPEG]."
>
>This simply says the encapsulator must be compliant for what it sends.
>
>At the receiver:
>       "The Receiver MAY also check the MPEG-2 Continuity Counter carried
in
>        the TS Packet header. If the Receiver does perform Continuity
>        Counter checking and the received value does not increment by one
>        for successive TS Packets (modulo 16), the Receiver has detected a
>        continuity error. Any partially received SNDU MUST be discarded. A
>        continuity counter error event SHOULD be recorded. The Receiver
then
>        enters the Idle State."
>
>
>The case for ULE reception seems much less clear, and I'd be interested to
>re-assess the correct behaviour.
>
>I wonder what is the implication of simply ignoring the CC field?
>- This has no impact as far as I can see on ULE payload data integrity OR
>framing, since in ULE these are primarily protected by the CRC-32.
>
>Does anyone think we should change the recommendation to "SHOULD NOT"
check
>or "MUST" ignore the CC field?
>
>Gorry
>
>
>On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen at space.alcatel.fr"
><Tarif.Zein-Alabedeen at space.alcatel.fr> wrote:
>
>
>
>>Thank you Art and william for your answers...
>>
>>William says that consider or mask CC check for a given PID is
>>implementation dependent..
>>is someone aware of the general rule for current IP/MPE/MPEG
>>implementations?
>>
>>Considering our ULE encapsulation, I think it would be wise to provision
>>
>>
>an
>
>
>>option allowing to disactivate CC check for specified PIDs in the
>>
>>
>receiver.
>
>
>>This may be helpful if, at some point in the future, we need ULE/MPEG to
>>operate correctly in a mesh or multi star scenarios (PID shared among
>>several transmiters).
>>what is your opinion about that?
>>
>>best regards
>>Traif ZEIN
>>
>>
>>
>>
>>
>>
>>
>>
>>"Allison, Art" <AAllison at nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
>>
>>Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>>
>>Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>>
>>
>>Pour : "'ip-dvb at erg.abdn.ac.uk'" <ip-dvb at erg.abdn.ac.uk>
>>cc :
>>Objet :     RE: Question on Continuity Counter field
>>
>>
>>IMHO, if a MPEG-2 TS parser was presented with out of order packets
>>identified by the same PID, a receiver failure is to be expected as the
>>stream would be non-conformant.
>>
>>However, the continuity_counter can be the same in sequential packets
>>(which
>>are then required to be the same except for the PCR).  Also, this count
>>
>>
>may
>
>
>>be discontinuous when that is indicated by the discontinuity_indicator.
>>
>>
>So
>
>
>>it is not always a monotonically incrementing field.  Given the rules for
>>this 4-bit continuity_counter, it is not apparent that it is possible to
>>use
>>it to reorder packets at the MPEG-2 level.
>>
>>Therefore, IMHO, any lower level communication protocol must not reorder
>>MPEG-2 transport stream packets that are identified by the same PID. If
it
>>has a potential to do so, then either constraints or an explicit method
>>
>>
>for
>
>
>>restoring the order must be defined.
>>
>>Art
>>::{)>
>>Art Allison
>>Director Advanced Engineering
>>NAB
>>1771 N St NW
>>Washington DC 20036
>>202 429 5418
>>
>>
>>-----Original Message-----
>>From: Tarif.Zein-Alabedeen at space.alcatel.fr
>>[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
>>Sent: Friday, February 13, 2004 9:05 AM
>>To: ip-dvb at erg.abdn.ac.uk
>>Subject: Question on Continuity Counter field
>>Importance: Low
>>
>>
>>
>>
>>Hi,
>>I have a question about the continuity counter field in the TS packet
>>header. May be someone in this group has the right answer :
>>what heppens if an MPEG receiver receives an out of order TS packet?
>>that is, for the same PID, the CC field value of a received packet not
>>equal to CC field value of precedent TS packet + 1
>>
>>Is there one standard behavior or is it implmenetation dependent?
>>can CC check as the receiver be disabled?
>>
>>(oups, this makes 3 questions already)
>>
>>thank's and best regards
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>






T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From williams77 at rediffmail.com  Mon Feb 23 12:08:30 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 23 Feb 2004 12:08:30 -0000
Subject: UnderStanding ULE
Message-ID: <20040223120830.30076.qmail@webmail26.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040223/eee847a8/attachment.html>
-------------- next part --------------
Dear all,

Might be I?m a bit late on ULE discussion, though I have few quick questions hit my mind, hope anyone can help me

1)	Is there any document available already to differentiate DSMCC and ULE, advantages and disadvantages, why we use ULE instead of DSMCC. If not already available, I?ll volunteer to prepare one from my understanding of both the MPE types.

Doubts on ULE Draft
-------------------------------
1.	Section 4.2 Maximum size of SNDU should be defined, according to draft it says 15 bits, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence please define Max Size for SNDU used for any payload.
2.	Destination Address field: Section 4.5, Well to provide MAC level filtering as similar to DSMCC, we have this support. But nowhere it is mentioned as MAC Destination Address. Might be misleading to IP addressing since Ipv6 is 6 byte addressing.
3.	Scenarios for Bridged SNDU Encapsulation. For example, we have DVB-RCS terminal with one Ethernet Interface and one DVB interface(TX and RX). When a packet has to be routed from Ethernet Interface to DVB interface, here in Bridged SNDU Encapsulation comes into picture when the DVB-RCS terminal is configured as L2 SWITCH. Did we mean that in this case, or when we are using GRE and receive an L2 payload for GRE, which decapsulates the IP & GRE  header and forwards the payload directly into DVB interface with ULE encapsulation.

Thanks and Best Regards,
William

From williams77 at rediffmail.com  Mon Feb 23 12:10:16 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 23 Feb 2004 12:10:16 -0000
Subject: UnderStanding ULE
Message-ID: <20040223121016.30792.qmail@mailweb34.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040223/f2da7fb1/attachment.html>
-------------- next part --------------
Dear all,

Might be I?m a bit late on ULE discussion, though I have few quick questions hit my mind, hope anyone can help me

1)	Is there any document available already to differentiate DSMCC and ULE, advantages and disadvantages, why we use ULE instead of DSMCC. If not already available, I?ll volunteer to prepare one from my understanding of both the MPE types.

Doubts on ULE Draft
-------------------------------
1.	Section 4.2 Maximum size of SNDU should be defined, according to draft it says 15 bits, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence please define Max Size for SNDU used for any payload.
2.	Destination Address field: Section 4.5, Well to provide MAC level filtering as similar to DSMCC, we have this support. But nowhere it is mentioned as MAC Destination Address. Might be misleading to IP addressing since Ipv6 is 6 byte addressing.
3.	Scenarios for Bridged SNDU Encapsulation. For example, we have DVB-RCS terminal with one Ethernet Interface and one DVB interface(TX and RX). When a packet has to be routed from Ethernet Interface to DVB interface, here in Bridged SNDU Encapsulation comes into picture when the DVB-RCS terminal is configured as L2 SWITCH. Did we mean that in this case, or when we are using GRE and receive an L2 payload for GRE, which decapsulates the IP & GRE  header and forwards the payload directly into DVB interface with ULE encapsulation.

Thanks and Best Regards,
William

From mariejose.montpetit at verizon.net  Mon Feb 23 12:34:00 2004
From: mariejose.montpetit at verizon.net (Marie-Jose Montpetit)
Date: Mon, 23 Feb 2004 07:34:00 -0500
Subject: UnderStanding ULE
References: <20040223121016.30792.qmail@mailweb34.rediffmail.com>
Message-ID: <05e501c3fa09$5280faa0$b402a8c0@copernicus>

Actually part of the study we did with ESTEC was to look at those differences/advantages; the FP for the study is end of next week so we're busy writing those differences. We will have both hardware advantage/disadvantages and protocol level differences. I'm ready to help also write the document if that is considered helpful by the group.

Marie-Jose
  ----- Original Message ----- 
  From: William StanisLaus 
  To: 'ip-dvb at erg.abdn.ac.uk' 
  Sent: Monday, February 23, 2004 7:10 AM
  Subject: UnderStanding ULE


  Dear all,

  Might be I'm a bit late on ULE discussion, though I have few quick questions hit my mind, hope anyone can help me

  1)     Is there any document available already to differentiate DSMCC and ULE, advantages and disadvantages, why we use ULE instead of DSMCC. If not already available, I'll volunteer to prepare one from my understanding of both the MPE types.

  Doubts on ULE Draft
  -------------------------------
  1.     Section 4.2 Maximum size of SNDU should be defined, according to draft it says 15 bits, means 32K. If it has to be 0x7FFF it is an End Indicator. Hence please define Max Size for SNDU used for any payload.
  2.     Destination Address field: Section 4.5, Well to provide MAC level filtering as similar to DSMCC, we have this support. But nowhere it is mentioned as MAC Destination Address. Might be misleading to IP addressing since Ipv6 is 6 byte addressing.
  3.     Scenarios for Bridged SNDU Encapsulation. For example, we have DVB-RCS terminal with one Ethernet Interface and one DVB interface(TX and RX). When a packet has to be routed from Ethernet Interface to DVB interface, here in Bridged SNDU Encapsulation comes into picture when the DVB-RCS terminal is configured as L2 SWITCH. Did we mean that in this case, or when we are using GRE and receive an L2 payload for GRE, which decapsulates the IP & GRE  header and forwards the payload directly into DVB interface with ULE encapsulation.

  Thanks and Best Regards,
  William 



   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040223/9b1decf8/attachment.html>

From Rod.Walsh at nokia.com  Mon Feb 23 13:42:46 2004
From: Rod.Walsh at nokia.com (Rod.Walsh at nokia.com)
Date: Mon, 23 Feb 2004 15:42:46 +0200
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
Message-ID: <D0299AFF29E01E478321564030AD6909539460@trebe003.europe.nokia.com>

Hi Margaret et al.

(Sorry about the dekay - just waiting to see if anyone else flagged interest in a "bar-WG" in Korea - none yet)

I'd be happy to make time for this. Anyone else interested? (If there's only the two of us the drinks are on me, otherwise we'll see :)

How about Tuesday 1130-1500 or 1515-1545?

Cheers, Rod.


-----Original Message-----
From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
Behalf Of ext Margaret Wasserman
Sent: Friday, February 13, 2004 11:14 PM
To: ip-dvb at erg.abdn.ac.uk
Cc: Gorry Fairhurst
Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.



Hi Rod,

>(I'll be in Korea, so would be happy to share a couple of round with 
>anyone interested in a bar-WG - not a bar-bof anymore :)

If you don't mind, I'll take you up on this!  I don't want to distract
the WG from its chartered work, but I would like to better understand
the current state of standardization in the field and how our work in
IPDVB will fit in.

It would be great if Gorry can join us, and anyone else who wants to
come, of course.

Margaret





From Joel.Grotz at ses-astra.com  Tue Feb 24 00:01:14 2004
From: Joel.Grotz at ses-astra.com (Joel.Grotz at ses-astra.com)
Date: Tue, 24 Feb 2004 01:01:14 +0100
Subject: Joel Grotz is out of office.
Message-ID: <OFE6D924D9.E9B70935-ONC1256E44.00001CE7-C1256E44.00001CE7@gen.btz.aia.lu>

I will be out of the office starting  02/23/2004 and will not return until
02/25/2004.

If required, I will respond to your message when I return to office.
Best Regards,
Joel Grotz

PS: Use joel.grotz at gmx.net for urgent matters.




--
DISCLAIMER:
This e-mail contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an addressing
or transmission error has misdirected this e-mail, please notify the author
by replying to this e-mail. If you are not the intended recipient you must
not use, disclose, distribute, copy, print, or rely on this e-mail.




From Tarif.Zein-Alabedeen at space.alcatel.fr  Tue Feb 24 17:27:28 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Tue, 24 Feb 2004 18:27:28 +0100
Subject: Encryption control of SNDU
Message-ID: <OFD24760E0.280D12A1-ONC1256E44.005BEC6E@netfr.alcatel.fr>



Hi every body

The current ULE draft does not address the issue of SNDU encryption which
we think is important.
In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
implement this capability (e.g. Alcatel 9780)
Encryption is controlled using the 'payload scrambling control' field (2
bits) in the MPE header.

Consequently, it would be necessary to provision an "encryption-control"
field (2 bits) in the SNDU header.
This could also facilitate the transition from MPE to ULE
Here is a proposal for its definition :
   bit 1 : indicates if the SNDU is encrypted or not
   bit 2 : indicating the type of encryption (when active) odd/even (to
   allow key shift on the fly)

Adding 2 bits would require to add a complete byte to the SNDU header in
order that the header still an integer number of bytes. If this is not
acceptable from a performance point of view, we can envisage to shorten the
'length' field from 15 bits down to 13 bits (note that in MPE, the length
field is 12 bits).

waiting for your feedback
regards

T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220





From bnocker at cosy.sbg.ac.at  Tue Feb 24 20:25:15 2004
From: bnocker at cosy.sbg.ac.at (Bernhard Nocker)
Date: Tue, 24 Feb 2004 21:25:15 +0100 (MET)
Subject: Encryption control of SNDU
In-Reply-To: <OFD24760E0.280D12A1-ONC1256E44.005BEC6E@netfr.alcatel.fr>
Message-ID: <Pine.GSO.4.33.0402242114120.7287-100000@lama.cosy.sbg.ac.at>

Hi,

if it is really required to notify a receiver about scrambled SNDUs I
would prefer to use another type field value for that purpose instead of
adding new header fields. But it might be as appropriate to start a S-ULE
(secure ULE) draft just for that purpose?! Another alternative would be to
announce the scrambled ULE in the PSI/SI instead of the encapsulation
header fields.

Kind regards,
Bernhard

On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>
>
> Hi every body
>
> The current ULE draft does not address the issue of SNDU encryption which
> we think is important.
> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
> implement this capability (e.g. Alcatel 9780)
> Encryption is controlled using the 'payload scrambling control' field (2
> bits) in the MPE header.
>
> Consequently, it would be necessary to provision an "encryption-control"
> field (2 bits) in the SNDU header.
> This could also facilitate the transition from MPE to ULE
> Here is a proposal for its definition :
>    bit 1 : indicates if the SNDU is encrypted or not
>    bit 2 : indicating the type of encryption (when active) odd/even (to
>    allow key shift on the fly)
>
> Adding 2 bits would require to add a complete byte to the SNDU header in
> order that the header still an integer number of bytes. If this is not
> acceptable from a performance point of view, we can envisage to shorten the
> 'length' field from 15 bits down to 13 bits (note that in MPE, the length
> field is 12 bits).
>
> waiting for your feedback
> regards
>
> T. Zein
>
> ALCATEL SPACE
> DRT/RST  --  Ing?nieur Syst?mes
> Tel : 0534356918  /  Fax : 0534355560
> Porte : W.220
>
>
>



From alain.ritoux at 6wind.com  Wed Feb 25 09:36:33 2004
From: alain.ritoux at 6wind.com (alain.ritoux at 6wind.com)
Date: Wed, 25 Feb 2004 10:36:33 +0100
Subject: Encryption control of SNDU
In-Reply-To: <c1g4cd$rkg$1@intranet.6wind.com>
References: <c1g4cd$rkg$1@intranet.6wind.com>
Message-ID: <403C6CA1.6050708@6wind.com>



Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

> 
> Hi every body
> 
> The current ULE draft does not address the issue of SNDU encryption which
> we think is important.
> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
> implement this capability (e.g. Alcatel 9780)
> Encryption is controlled using the 'payload scrambling control' field (2
> bits) in the MPE header.

I fail to see why we would need an L2 encryption to carry IP/IPv6
traffic, when IPsec/IKE is already defined including encryption,
authentication, key distribution and all that kind of stuff.
Would it not be re-inventing the (rather complex) wheel ?

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From benoit.oger at thales-bm.com  Wed Feb 25 09:38:09 2004
From: benoit.oger at thales-bm.com (Benoit Oger)
Date: Wed, 25 Feb 2004 10:38:09 +0100
Subject: ULE and FEC
In-Reply-To: <Pine.GSO.4.33.0402242114120.7287-100000@lama.cosy.sbg.ac.at>
Message-ID: <NEBBIIDJEALBIGLMBGPFMEHKCNAA.benoit.oger@thales-bm.com>

Hello,

as new subjects are raised, like encryption, I was thinking it could be
interessant for ULE to propose a FEC system (Forward Error Correction). ULE
is aimed for a wide range of physical media, more or less exposed to noise
and error; therefore an error correction ability could be useful. Actually,
we could be inspired by the DVB-H draft that provide MPE with such a system,
called MPE-FEC. DVB-H derive from DVB-T standard, it deals with optimisation
for wireless communication like the reduction of the average power
consumption for mobile or a better resistance to noise.

MPE-FEC simply combine datagrams interleaving and a Reed-Solomon code. It is
designed in such a way that it will be transparent for a receiver not
supporting MPE-FEC. Datagrams are encapsulated and sent as usual.
Reed-Solomon parity bytes are transmitted on the same Pid but with a
different section type , for ULE it migth be a different type.

Your thoughts about that.


Benoit Oger
Thales Broadcast & Multimedia




From gorry at erg.abdn.ac.uk  Wed Feb 25 10:02:54 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Wed, 25 Feb 2004 10:02:54 +0000
Subject: ipdvb: draft-fair-ipdvb-ule-02.txt progression to WG draft
Message-ID: <BC62234E.2E5%gorry@erg.abdn.ac.uk>


I am pleased to announce the adoption of the following draft as a Working
Group work item. This draft will be re-issued as draft-ietf-ipdvb-ule-00,
following re-opening of the Internet Draft Archives after the Seoul meeting.
A list of known issues will be posted soon by the authors and inputs will be
appreciated to address as many of these issues as possible in the next
revision.


       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


Gorry Fairhurst
Ipdvb WG chair



From bnocker at cosy.sbg.ac.at  Wed Feb 25 10:46:57 2004
From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker)
Date: Wed, 25 Feb 2004 11:46:57 +0100
Subject: Encryption control of SNDU
In-Reply-To: <403C6CA1.6050708@6wind.com>
Message-ID: <HOEPKOKAJBEOAIPGLHOCAENHENAA.bnocker@cosy.sbg.ac.at>

Hello,

I do see reasons for scrambling e.g. for the case to prevent from traffic
analysis. Whether this or other reasons are taking into account is in my
view a question of community demand.
But again, I am not in favour of new header fields/flags. Scrambling has
too little to do with encapsulation.

One other issue, which has not been discussed yet, is how to announce ULE
streams in PSI/SI at all. Does someone have a preferred strategy on how to
proceed with this issue? It is certainly a side-issue, but without having
a god-idea (in advance or by stream analysis) what stream type
(encapsulation)
is used on a specific PID receivers are somehow left in the dark.

Best regards,
Bernhard

> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> Behalf Of alain.ritoux at 6wind.com
> Sent: Mittwoch, 25. Februar 2004 10:37
> To: IPDVB
> Subject: Re: Encryption control of SNDU
>
>
>
>
> Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
>
> >
> > Hi every body
> >
> > The current ULE draft does not address the issue of SNDU
> encryption which
> > we think is important.
> > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> > necessary, data encryption at MPE level. Some IP/MPE/MPEG
> products already
> > implement this capability (e.g. Alcatel 9780)
> > Encryption is controlled using the 'payload scrambling control' field (2
> > bits) in the MPE header.
>
> I fail to see why we would need an L2 encryption to carry IP/IPv6
> traffic, when IPsec/IKE is already defined including encryption,
> authentication, key distribution and all that kind of stuff.
> Would it not be re-inventing the (rather complex) wheel ?
>
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
>



From alain.ritoux at 6wind.com  Wed Feb 25 10:49:58 2004
From: alain.ritoux at 6wind.com (Alain RITOUX)
Date: Wed, 25 Feb 2004 11:49:58 +0100
Subject: ULE and FEC
In-Reply-To: <NEBBIIDJEALBIGLMBGPFMEHKCNAA.benoit.oger@thales-bm.com>
References: <NEBBIIDJEALBIGLMBGPFMEHKCNAA.benoit.oger@thales-bm.com>
Message-ID: <403C7DD6.2080402@6wind.com>



Benoit Oger wrote:

> Hello,
> 
> as new subjects are raised, like encryption, I was thinking it could be
> interessant for ULE to propose a FEC system (Forward Error Correction). ULE
> is aimed for a wide range of physical media, more or less exposed to noise
> and error; therefore an error correction ability could be useful. Actually,
> we could be inspired by the DVB-H draft that provide MPE with such a system,
> called MPE-FEC. DVB-H derive from DVB-T standard, it deals with optimisation
> for wireless communication like the reduction of the average power
> consumption for mobile or a better resistance to noise.
> 
> MPE-FEC simply combine datagrams interleaving and a Reed-Solomon code. It is
> designed in such a way that it will be transparent for a receiver not
> supporting MPE-FEC. Datagrams are encapsulated and sent as usual.
> Reed-Solomon parity bytes are transmitted on the same Pid but with a
> different section type , for ULE it migth be a different type.

I don't have precise opinion about the usefullness of such FEC. But
indeed, if it was needed, the FEC itself could be inserted in an
"extension header", associated to the SNDU itself, as I proposed some
time ago (http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00527.html)
Such an extension would then be of type : optional extension, if not 
known, just skip  and process next.

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From Tarif.Zein-Alabedeen at space.alcatel.fr  Wed Feb 25 10:44:48 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Wed, 25 Feb 2004 11:44:48 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <OF641D0E4D.CC71909F-ONC1256E45.00367B4E@netfr.alcatel.fr>



Thanks bernhard for your answer,

In fact, even if we use a secure ULE session mechanism, rekeying is
required during a session.
PSI/SI is not real time and could not allow synchronized rekeying on the
fly without SNDU (or MPE section) loss.
The receiver still needs a flag indicating from which SNDU the new key
applies.

The requirement for such a control field is specified in the dvb-rcs
standard (EN 301790) and in EN 301192.
In EN 301790 section 6.4.6.3, the exact wording for this is as follows :

DVB Multiprotocol Encapsulation sections, according to EN 301 192 [5], the 2-bit
payload_scrambling_control field in the section header is used:
- 00: not encrypted;
- 01: reserved;
- 10: encrypted using session key 0;
- 11: encrypted using session key 1.

Regards







Bernhard Nocker <bnocker at cosy.sbg.ac.at>@erg.abdn.ac.uk on 24/02/2004
21:25:15

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : <ip-dvb at erg.abdn.ac.uk>
cc :
Objet :     Re: Encryption control of SNDU


Hi,

if it is really required to notify a receiver about scrambled SNDUs I
would prefer to use another type field value for that purpose instead of
adding new header fields. But it might be as appropriate to start a S-ULE
(secure ULE) draft just for that purpose?! Another alternative would be to
announce the scrambled ULE in the PSI/SI instead of the encapsulation
header fields.

Kind regards,
Bernhard

On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>
>
> Hi every body
>
> The current ULE draft does not address the issue of SNDU encryption which
> we think is important.
> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> necessary, data encryption at MPE level. Some IP/MPE/MPEG products
already
> implement this capability (e.g. Alcatel 9780)
> Encryption is controlled using the 'payload scrambling control' field (2
> bits) in the MPE header.
>
> Consequently, it would be necessary to provision an "encryption-control"
> field (2 bits) in the SNDU header.
> This could also facilitate the transition from MPE to ULE
> Here is a proposal for its definition :
>    bit 1 : indicates if the SNDU is encrypted or not
>    bit 2 : indicating the type of encryption (when active) odd/even (to
>    allow key shift on the fly)
>
> Adding 2 bits would require to add a complete byte to the SNDU header in
> order that the header still an integer number of bytes. If this is not
> acceptable from a performance point of view, we can envisage to shorten
the
> 'length' field from 15 bits down to 13 bits (note that in MPE, the length
> field is 12 bits).
>
> waiting for your feedback
> regards
>
> T. Zein
>
> ALCATEL SPACE
> DRT/RST  --  Ing?nieur Syst?mes
> Tel : 0534356918  /  Fax : 0534355560
> Porte : W.220
>
>
>






T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From bnocker at cosy.sbg.ac.at  Wed Feb 25 10:58:28 2004
From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker)
Date: Wed, 25 Feb 2004 11:58:28 +0100
Subject: ULE and FEC
In-Reply-To: <NEBBIIDJEALBIGLMBGPFMEHKCNAA.benoit.oger@thales-bm.com>
Message-ID: <HOEPKOKAJBEOAIPGLHOCGENJENAA.bnocker@cosy.sbg.ac.at>

Hello,

since I am on holidays :-) I take the chance to be more active in this
discussion group.

Well, FEC is a very good point, and the need for it in DVB-T is certainly
existing. My question, apart from whether or not to add a FEC type, at
this point is, what error patterns are being considered. We also have a
DVB-T set-up running in our lab and the probability that packets (SNDUs)
can be corrected with FEC and interleaving alone is from my experiences
rather low, given that outages (link losses during station movements)
are typically affecting quite many TS cells corresponding to many SNDUs
and, hence, retransmissions are needed to maintain reliability.

Best regards,
Bernhard

> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> Behalf Of Benoit Oger
> Sent: Mittwoch, 25. Februar 2004 10:38
> To: ip-dvb at erg.abdn.ac.uk
> Subject: ULE and FEC
>
>
> Hello,
>
> as new subjects are raised, like encryption, I was thinking it could be
> interessant for ULE to propose a FEC system (Forward Error
> Correction). ULE
> is aimed for a wide range of physical media, more or less exposed to noise
> and error; therefore an error correction ability could be useful.
> Actually,
> we could be inspired by the DVB-H draft that provide MPE with
> such a system,
> called MPE-FEC. DVB-H derive from DVB-T standard, it deals with
> optimisation
> for wireless communication like the reduction of the average power
> consumption for mobile or a better resistance to noise.
>
> MPE-FEC simply combine datagrams interleaving and a Reed-Solomon
> code. It is
> designed in such a way that it will be transparent for a receiver not
> supporting MPE-FEC. Datagrams are encapsulated and sent as usual.
> Reed-Solomon parity bytes are transmitted on the same Pid but with a
> different section type , for ULE it migth be a different type.
>
> Your thoughts about that.
>
>
> Benoit Oger
> Thales Broadcast & Multimedia
>
>



From williams77 at rediffmail.com  Wed Feb 25 11:30:26 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 25 Feb 2004 11:30:26 -0000
Subject: Encryption control of SNDU
Message-ID: <20040225113026.8257.qmail@webmail25.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040225/17ba059b/attachment.html>
-------------- next part --------------
Hi,
     L2 scrambling is used only for Conditional Access System, i.e. settop boxes.. correct me if i'm wrong.
MPEG IP payload can be well protected by any standard L3 encryption algorithms as said by alain.

Best Regards,
William.


On Wed, 25 Feb 2004 alain.ritoux at 6wind.com wrote :
>
>
>Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
>
>>
>>Hi every body
>>
>>The current ULE draft does not address the issue of SNDU encryption which
>>we think is important.
>>In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
>>necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
>>implement this capability (e.g. Alcatel 9780)
>>Encryption is controlled using the 'payload scrambling control' field (2
>>bits) in the MPE header.
>
>I fail to see why we would need an L2 encryption to carry IP/IPv6
>traffic, when IPsec/IKE is already defined including encryption,
>authentication, key distribution and all that kind of stuff.
>Would it not be re-inventing the (rather complex) wheel ?
>
>Regards.
>Alain.
>-- Alain RITOUX
>Tel +33-1-39-30-92-32
>Fax +33-1-39-30-92-11
>visit our web http://www.6wind.com
>

From Tarif.Zein-Alabedeen at space.alcatel.fr  Wed Feb 25 11:41:12 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Wed, 25 Feb 2004 12:41:12 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <OFDA51B459.0E6A7B28-ONC1256E45.003D6441@netfr.alcatel.fr>



Well, L3 IPsec vs L2 encryption is rather an old debate.
Any way, L2 encryption is almost always asked for by satellite providers to
allow intrinsic securtiy within the system
independantly of L3 security. IPsec is an option which is not always
applied.
How many poeple do have their DSL link secured with IPsec?
if this is not dramatic in a wired system since it is rather difficult to
snif your DSL line, a wireless system is rather vulnerable.

That is why such L2 securtiy has been provisioned for dvb-rcs systems.
Encryption at MPEG layer as suggested in the requirements ID
(draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying

If such a solution is not put into ULE, it may simply turn to be
inapplicable to dvb-rcs systems :(

cheers
tarif




alain.ritoux at 6wind.com@erg.abdn.ac.uk on 25/02/2004 10:36:33

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
cc :
Objet :     Re: Encryption control of SNDU




Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>
> Hi every body
>
> The current ULE draft does not address the issue of SNDU encryption which
> we think is important.
> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> necessary, data encryption at MPE level. Some IP/MPE/MPEG products
already
> implement this capability (e.g. Alcatel 9780)
> Encryption is controlled using the 'payload scrambling control' field (2
> bits) in the MPE header.

I fail to see why we would need an L2 encryption to carry IP/IPv6
traffic, when IPsec/IKE is already defined including encryption,
authentication, key distribution and all that kind of stuff.
Would it not be re-inventing the (rather complex) wheel ?

Regards.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com






T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From bnocker at cosy.sbg.ac.at  Wed Feb 25 12:39:12 2004
From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker)
Date: Wed, 25 Feb 2004 13:39:12 +0100
Subject: =?iso-8859-1?Q?RE:_R=E9f._:_Re:_Encryption_control_of_SNDU?=
In-Reply-To: <OF641D0E4D.CC71909F-ONC1256E45.00367B4E@netfr.alcatel.fr>
Message-ID: <HOEPKOKAJBEOAIPGLHOCEENPENAA.bnocker@cosy.sbg.ac.at>

Dear Tarif,

since I am not an expert on scrambling could you please elaborate a
little bit on how the receivers do obtain the two keys. Is there a
key distribution mechanism or are those keys permanently set in the
receiver hardware?
Still my personal opinion is that scrambling control should be in a
separate standard track. Where to put the 2 necessary bits is a good
question, adding another header byte seems too much overhead to me.
An potential alternative, provided the MTU of the SNDUs is small
enough, which might be the case for DVB-RCS anyhow, could be to limit
the Length field and insert those 2 bits after the D bit. That would
lead to a 8 K maximum size of SNDUs.

Any other ideas and arguments?

Regards,
Bernhard

> Thanks bernhard for your answer,
>
> In fact, even if we use a secure ULE session mechanism, rekeying is
> required during a session.
> PSI/SI is not real time and could not allow synchronized rekeying on the
> fly without SNDU (or MPE section) loss.
> The receiver still needs a flag indicating from which SNDU the new key
> applies.
>
> The requirement for such a control field is specified in the dvb-rcs
> standard (EN 301790) and in EN 301192.
> In EN 301790 section 6.4.6.3, the exact wording for this is as follows :
>
> DVB Multiprotocol Encapsulation sections, according to EN 301 192
> [5], the 2-bit
> payload_scrambling_control field in the section header is used:
> - 00: not encrypted;
> - 01: reserved;
> - 10: encrypted using session key 0;
> - 11: encrypted using session key 1.
>
> Regards
>
>
>
>
>
>
>
> Bernhard Nocker <bnocker at cosy.sbg.ac.at>@erg.abdn.ac.uk on 24/02/2004
> 21:25:15
>
> Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>
> Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>
>
> Pour : <ip-dvb at erg.abdn.ac.uk>
> cc :
> Objet :     Re: Encryption control of SNDU
>
>
> Hi,
>
> if it is really required to notify a receiver about scrambled SNDUs I
> would prefer to use another type field value for that purpose instead of
> adding new header fields. But it might be as appropriate to start a S-ULE
> (secure ULE) draft just for that purpose?! Another alternative would be to
> announce the scrambled ULE in the PSI/SI instead of the encapsulation
> header fields.
>
> Kind regards,
> Bernhard
>
> On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
>
> >
> >
> > Hi every body
> >
> > The current ULE draft does not address the issue of SNDU
> encryption which
> > we think is important.
> > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> > necessary, data encryption at MPE level. Some IP/MPE/MPEG products
> already
> > implement this capability (e.g. Alcatel 9780)
> > Encryption is controlled using the 'payload scrambling control' field (2
> > bits) in the MPE header.
> >
> > Consequently, it would be necessary to provision an "encryption-control"
> > field (2 bits) in the SNDU header.
> > This could also facilitate the transition from MPE to ULE
> > Here is a proposal for its definition :
> >    bit 1 : indicates if the SNDU is encrypted or not
> >    bit 2 : indicating the type of encryption (when active) odd/even (to
> >    allow key shift on the fly)
> >
> > Adding 2 bits would require to add a complete byte to the SNDU header in
> > order that the header still an integer number of bytes. If this is not
> > acceptable from a performance point of view, we can envisage to shorten
> the
> > 'length' field from 15 bits down to 13 bits (note that in MPE,
> the length
> > field is 12 bits).
> >
> > waiting for your feedback
> > regards
> >
> > T. Zein
> >
> > ALCATEL SPACE
> > DRT/RST  --  Ing?nieur Syst?mes
> > Tel : 0534356918  /  Fax : 0534355560
> > Porte : W.220
> >
> >
> >
>
>
>
>
>
>
> T. Zein
>
> ALCATEL SPACE
> DRT/RST  --  Ing?nieur Syst?mes
> Tel : 0534356918  /  Fax : 0534355560
> Porte : W.220
>
>
>
>



From alain.ritoux at 6wind.com  Wed Feb 25 13:05:34 2004
From: alain.ritoux at 6wind.com (Alain RITOUX)
Date: Wed, 25 Feb 2004 14:05:34 +0100
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control?=
 =?ISO-8859-1?Q?_of_SNDU?=
In-Reply-To: <OFDA51B459.0E6A7B28-ONC1256E45.003D6441@netfr.alcatel.fr>
References: <OFDA51B459.0E6A7B28-ONC1256E45.003D6441@netfr.alcatel.fr>
Message-ID: <403C9D9E.2020909@6wind.com>



Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

> 
> Well, L3 IPsec vs L2 encryption is rather an old debate.
Yes, and far from me the will to initiate a flame war ;-)

> Any way, L2 encryption is almost always asked for by satellite providers to
> allow intrinsic securtiy within the system
> independantly of L3 security. IPsec is an option which is not always
> applied.
> How many poeple do have their DSL link secured with IPsec?
> if this is not dramatic in a wired system since it is rather difficult to
> snif your DSL line, a wireless system is rather vulnerable.
I don't really buy those arguments, but I think this debate is out of
scope of this WG ;-) but I'm ready to have a discussion with you
off-list.

> That is why such L2 securtiy has been provisioned for dvb-rcs systems.
> Encryption at MPEG layer as suggested in the requirements ID
> (draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying
> 
> If such a solution is not put into ULE, it may simply turn to be
> inapplicable to dvb-rcs systems :(
If such L2 encryption is unavoidable, can it be managed (including
keying etc ...) at pure MPEG-2 level ? i.e. there's an encryption
done for all traffic using a (some) PID(s), which leaves ULE quite
un-concerned ?

Cheers.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From Tarif.Zein-Alabedeen at space.alcatel.fr  Wed Feb 25 14:37:16 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Wed, 25 Feb 2004 15:37:16 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_Re=3A_Encryption_control?=
 of SNDU
Message-ID: <OFDD1FEEC5.1745251B-ONC1256E45.004D7BE5@netfr.alcatel.fr>



As I said, encryption at MPEG level does not allow a per receiver
encryption key.
A PID is "multi receiver" which means that if encryption is applied to TS
packets, all receivers tuned to a given PID should have the same key
and hence each receiver can deencrypte traffic destined to other receivers.
This is no issue if all receivers associated to the same PID are in a
closed group (VPN)
But if not, the question of privacy rises....

I agree that encryption, session securtiy, key exchange can be handled in
another ID.
However, ULE  is still concerned in the way to control and synchronise
this. That is to provide tags allwoing the receiver to know :
- if a received SNDU is encrypted or not
- if yes, which key is used (this is to allow rekeying..)

regards





Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 25/02/2004 14:05:34

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : ip-dvb at erg.abdn.ac.uk
cc :
Objet :     Re: R?f. : Re: Encryption control of SNDU




Tarif.Zein-Alabedeen at space.alcatel.fr wrote:

>
> Well, L3 IPsec vs L2 encryption is rather an old debate.
Yes, and far from me the will to initiate a flame war ;-)

> Any way, L2 encryption is almost always asked for by satellite providers
to
> allow intrinsic securtiy within the system
> independantly of L3 security. IPsec is an option which is not always
> applied.
> How many poeple do have their DSL link secured with IPsec?
> if this is not dramatic in a wired system since it is rather difficult to
> snif your DSL line, a wireless system is rather vulnerable.
I don't really buy those arguments, but I think this debate is out of
scope of this WG ;-) but I'm ready to have a discussion with you
off-list.

> That is why such L2 securtiy has been provisioned for dvb-rcs systems.
> Encryption at MPEG layer as suggested in the requirements ID
> (draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying
>
> If such a solution is not put into ULE, it may simply turn to be
> inapplicable to dvb-rcs systems :(
can it be managed (including
keying etc ...) at pure MPEG-2 level ? i.e. there's an encryption
done for all traffic using a (some) PID(s), which leaves ULE quite
un-concerned ?

Cheers.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com






T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From williams77 at rediffmail.com  Wed Feb 25 15:18:58 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 25 Feb 2004 15:18:58 -0000
Subject: ULE and FEC
Message-ID: <20040225151858.12665.qmail@webmail25.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040225/2376472b/attachment.html>
-------------- next part --------------
Hi,
   I don't quite understand FEC in MPE level, can anyone please elaborate or refer some specifications regarding it.

Thanks and Best Regards,
William.

On Wed, 25 Feb 2004 Bernhard Collini-Nocker wrote :
>Hello,
>
>since I am on holidays :-) I take the chance to be more active in this
>discussion group.
>
>Well, FEC is a very good point, and the need for it in DVB-T is certainly
>existing. My question, apart from whether or not to add a FEC type, at
>this point is, what error patterns are being considered. We also have a
>DVB-T set-up running in our lab and the probability that packets (SNDUs)
>can be corrected with FEC and interleaving alone is from my experiences
>rather low, given that outages (link losses during station movements)
>are typically affecting quite many TS cells corresponding to many SNDUs
>and, hence, retransmissions are needed to maintain reliability.
>
>Best regards,
>Bernhard
>
> > -----Original Message-----
> > From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
> > Behalf Of Benoit Oger
> > Sent: Mittwoch, 25. Februar 2004 10:38
> > To: ip-dvb at erg.abdn.ac.uk
> > Subject: ULE and FEC
> >
> >
> > Hello,
> >
> > as new subjects are raised, like encryption, I was thinking it could be
> > interessant for ULE to propose a FEC system (Forward Error
> > Correction). ULE
> > is aimed for a wide range of physical media, more or less exposed to noise
> > and error; therefore an error correction ability could be useful.
> > Actually,
> > we could be inspired by the DVB-H draft that provide MPE with
> > such a system,
> > called MPE-FEC. DVB-H derive from DVB-T standard, it deals with
> > optimisation
> > for wireless communication like the reduction of the average power
> > consumption for mobile or a better resistance to noise.
> >
> > MPE-FEC simply combine datagrams interleaving and a Reed-Solomon
> > code. It is
> > designed in such a way that it will be transparent for a receiver not
> > supporting MPE-FEC. Datagrams are encapsulated and sent as usual.
> > Reed-Solomon parity bytes are transmitted on the same Pid but with a
> > different section type , for ULE it migth be a different type.
> >
> > Your thoughts about that.
> >
> >
> > Benoit Oger
> > Thales Broadcast & Multimedia
> >
> >
>

From benoit.oger at thales-bm.com  Wed Feb 25 16:17:38 2004
From: benoit.oger at thales-bm.com (Benoit Oger)
Date: Wed, 25 Feb 2004 17:17:38 +0100
Subject: ULE and FEC
In-Reply-To: <20040225151858.12665.qmail@webmail25.rediffmail.com>
Message-ID: <NEBBIIDJEALBIGLMBGPFCEHOCNAA.benoit.oger@thales-bm.com>

You can have a look at DVB-H draft, TM 2939.

Regards

Benoit Oger
Thales Broadcast & Multimedia


 -----Message d'origine-----
De : owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]De la
part de William StanisLaus
Envoy? : mercredi 25 f?vrier 2004 16:19
? : ip-dvb at erg.abdn.ac.uk
Cc : Bernhard Collini-Nocker
Objet : Re: RE: ULE and FEC


  Hi,
    I don't quite understand FEC in MPE level, can anyone please elaborate
or refer some specifications regarding it.

  Thanks and Best Regards,
  William.

  On Wed, 25 Feb 2004 Bernhard Collini-Nocker wrote :
  >Hello,
  >
  >since I am on holidays :-) I take the chance to be more active in this
  >discussion group.
  >
  >Well, FEC is a very good point, and the need for it in DVB-T is certainly
  >existing. My question, apart from whether or not to add a FEC type, at
  >this point is, what error patterns are being considered. We also have a
  >DVB-T set-up running in our lab and the probability that packets (SNDUs)
  >can be corrected with FEC and interleaving alone is from my experiences
  >rather low, given that outages (link losses during station movements)
  >are typically affecting quite many TS cells corresponding to many SNDUs
  >and, hence, retransmissions are needed to maintain reliability.
  >
  >Best regards,
  >Bernhard
  >
  > > -----Original Message-----
  > > From: owner-ip-dvb at erg.abdn.ac.uk
[mailto:owner-ip-dvb at erg.abdn.ac.uk]On
  > > Behalf Of Benoit Oger
  > > Sent: Mittwoch, 25. Februar 2004 10:38
  > > To: ip-dvb at erg.abdn.ac.uk
  > > Subject: ULE and FEC
  > >
  > >
  > > Hello,
  > >
  > > as new subjects are raised, like encryption, I was thinking it could
be
  > > interessant for ULE to propose a FEC system (Forward Error
  > > Correction). ULE
  > > is aimed for a wide range of physical media, more or less exposed to
noise
  > > and error; therefore an error correction ability could be useful.
  > > Actually,
  > > we could be inspired by the DVB-H draft that provide MPE with
  > > such a system,
  > > called MPE-FEC. DVB-H derive from DVB-T standard, it deals with
  > > optimisation
  > > for wireless communication like the reduction of the average power
  > > consumption for mobile or a better resistance to noise.
  > >
  > > MPE-FEC simply combine datagrams interleaving and a Reed-Solomon
  > > code. It is
  > > designed in such a way that it will be transparent for a receiver not
  > > supporting MPE-FEC. Datagrams are encapsulated and sent as usual.
  > > Reed-Solomon parity bytes are transmitted on the same Pid but with a
  > > different section type , for ULE it migth be a different type.
  > >
  > > Your thoughts about that.
  > >
  > >
  > > Benoit Oger
  > > Thales Broadcast & Multimedia
  > >
  > >
  >





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040225/6eeab263/attachment.html>

From Fritsche at iabg.de  Wed Feb 25 17:13:55 2004
From: Fritsche at iabg.de (Fritsche Wolfgang)
Date: Wed, 25 Feb 2004 18:13:55 +0100
Subject: =?iso-8859-1?Q?AW=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <69A5E767EC979846826F566C7932A3F2074E27@exchange03.iabg.de>

Scrambling and FEC are first examples for possible future extensions of ULE, which have not been foreseen during the original design. Certainly these will not be the last ones. 

Therefore I don't think using space from the length field is a good way to serve these future needs, and would agree with Alains proposal that a cleaner, more flexible and more efficient way to allow extensibility of ULE is the specification of an optional extension header. Like for IPv6 this keeps the basic header slim for efficient processing and allows the introduction of new functionality while keeping backward compatibility (older ULE versions simply can skip new functionality).

Cheers,

Wolfgang


> -----Urspr?ngliche Nachricht-----
> Von: owner-ip-dvb at erg.abdn.ac.uk 
> [mailto:owner-ip-dvb at erg.abdn.ac.uk] Im Auftrag von Bernhard 
> Collini-Nocker
> Gesendet: Mittwoch, 25. Februar 2004 13:39
> An: ip-dvb at erg.abdn.ac.uk
> Betreff: RE: R?f. : Re: Encryption control of SNDU
> 
> 
> Dear Tarif,
> 
> since I am not an expert on scrambling could you please 
> elaborate a little bit on how the receivers do obtain the two 
> keys. Is there a key distribution mechanism or are those keys 
> permanently set in the receiver hardware? Still my personal 
> opinion is that scrambling control should be in a separate 
> standard track. Where to put the 2 necessary bits is a good 
> question, adding another header byte seems too much overhead 
> to me. An potential alternative, provided the MTU of the 
> SNDUs is small enough, which might be the case for DVB-RCS 
> anyhow, could be to limit the Length field and insert those 2 
> bits after the D bit. That would lead to a 8 K maximum size of SNDUs.
> 
> Any other ideas and arguments?
> 
> Regards,
> Bernhard
> 
> > Thanks bernhard for your answer,
> >
> > In fact, even if we use a secure ULE session mechanism, rekeying is 
> > required during a session. PSI/SI is not real time and 
> could not allow 
> > synchronized rekeying on the fly without SNDU (or MPE section) loss.
> > The receiver still needs a flag indicating from which SNDU 
> the new key
> > applies.
> >
> > The requirement for such a control field is specified in 
> the dvb-rcs 
> > standard (EN 301790) and in EN 301192. In EN 301790 section 
> 6.4.6.3, 
> > the exact wording for this is as follows :
> >
> > DVB Multiprotocol Encapsulation sections, according to EN 
> 301 192 [5], 
> > the 2-bit payload_scrambling_control field in the section header is 
> > used:
> > - 00: not encrypted;
> > - 01: reserved;
> > - 10: encrypted using session key 0;
> > - 11: encrypted using session key 1.
> >
> > Regards
> >
> >
> >
> >
> >
> >
> >
> > Bernhard Nocker <bnocker at cosy.sbg.ac.at>@erg.abdn.ac.uk on 
> 24/02/2004 
> > 21:25:15
> >
> > Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
> >
> > Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
> >
> >
> > Pour : <ip-dvb at erg.abdn.ac.uk>
> > cc :
> > Objet :     Re: Encryption control of SNDU
> >
> >
> > Hi,
> >
> > if it is really required to notify a receiver about 
> scrambled SNDUs I 
> > would prefer to use another type field value for that 
> purpose instead 
> > of adding new header fields. But it might be as appropriate 
> to start a 
> > S-ULE (secure ULE) draft just for that purpose?! Another 
> alternative 
> > would be to announce the scrambled ULE in the PSI/SI instead of the 
> > encapsulation header fields.
> >
> > Kind regards,
> > Bernhard
> >
> > On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
> >
> > >
> > >
> > > Hi every body
> > >
> > > The current ULE draft does not address the issue of SNDU
> > encryption which
> > > we think is important.
> > > In fact, a requirement has been identified in IP/MPE/MPEG 
> to allow, 
> > > when necessary, data encryption at MPE level. Some IP/MPE/MPEG 
> > > products
> > already
> > > implement this capability (e.g. Alcatel 9780)
> > > Encryption is controlled using the 'payload scrambling control' 
> > > field (2
> > > bits) in the MPE header.
> > >
> > > Consequently, it would be necessary to provision an 
> > > "encryption-control" field (2 bits) in the SNDU header. 
> This could 
> > > also facilitate the transition from MPE to ULE Here is a proposal 
> > > for its definition :
> > >    bit 1 : indicates if the SNDU is encrypted or not
> > >    bit 2 : indicating the type of encryption (when 
> active) odd/even (to
> > >    allow key shift on the fly)
> > >
> > > Adding 2 bits would require to add a complete byte to the SNDU 
> > > header in order that the header still an integer number 
> of bytes. If 
> > > this is not acceptable from a performance point of view, we can 
> > > envisage to shorten
> > the
> > > 'length' field from 15 bits down to 13 bits (note that in MPE,
> > the length
> > > field is 12 bits).
> > >
> > > waiting for your feedback
> > > regards
> > >
> > > T. Zein
> > >
> > > ALCATEL SPACE
> > > DRT/RST  --  Ing?nieur Syst?mes
> > > Tel : 0534356918  /  Fax : 0534355560
> > > Porte : W.220
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> > T. Zein
> >
> > ALCATEL SPACE
> > DRT/RST  --  Ing?nieur Syst?mes
> > Tel : 0534356918  /  Fax : 0534355560
> > Porte : W.220
> >
> >
> >
> >
> 
> 



From stiemerling at netlab.nec.de  Thu Feb 26 07:57:20 2004
From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Thu, 26 Feb 2004 08:57:20 +0100
Subject: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
In-Reply-To: <D0299AFF29E01E478321564030AD6909539460@trebe003.europe.nokia.com>
References: <D0299AFF29E01E478321564030AD6909539460@trebe003.europe.nokia.co
 m>
Message-ID: <2147483647.1077785840@[139.100.140.135]>

Hi all bar-WG interested,

I'll be in Korea, but I'm not sure whether I can make it to the bar. So if 
there is any please post time and location to the list.

Thanks,

 Martin

--On Montag, 23. Februar 2004 15:42 Uhr +0200 Rod.Walsh at nokia.com wrote:

| Hi Margaret et al.
|
| (Sorry about the dekay - just waiting to see if anyone else flagged
| interest in a "bar-WG" in Korea - none yet)
|
| I'd be happy to make time for this. Anyone else interested? (If there's
| only the two of us the drinks are on me, otherwise we'll see :)
|
| How about Tuesday 1130-1500 or 1515-1545?
|
| Cheers, Rod.
|
|
| -----Original Message-----
| From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]On
| Behalf Of ext Margaret Wasserman
| Sent: Friday, February 13, 2004 11:14 PM
| To: ip-dvb at erg.abdn.ac.uk
| Cc: Gorry Fairhurst
| Subject: RE: Call for the ipdvb WG to adopt: draft-fair-ipdvb-ule-02.
|
|
|
| Hi Rod,
|
|> (I'll be in Korea, so would be happy to share a couple of round with
|> anyone interested in a bar-WG - not a bar-bof anymore :)
|
| If you don't mind, I'll take you up on this!  I don't want to distract
| the WG from its chartered work, but I would like to better understand
| the current state of standardization in the field and how our work in
| IPDVB will fit in.
|
| It would be great if Gorry can join us, and anyone else who wants to
| come, of course.
|
| Margaret
|
|
|




From H.Cruickshank at eim.surrey.ac.uk  Thu Feb 26 10:32:18 2004
From: H.Cruickshank at eim.surrey.ac.uk (Haitham Cruickshank)
Date: Thu, 26 Feb 2004 10:32:18 +0000
Subject: Encryption control of SNDU
References: <c1g4cd$rkg$1@intranet.6wind.com> <403C6CA1.6050708@6wind.com>
Message-ID: <403DCB32.30AE6F12@surrey.ac.uk>

Hi Alain and All,

I like to add my voice to Alain's, regarding keeping ULE simple and free from
security complications.  Also using IPSEC mean closer integration with
terrestrial IP networks.

However, Bernhard mentioned a good point: "I do see reasons for scrambling e.g.
for the case to prevent from traffic analysis".  I think this problem can be
solved using IPSEC between satellite nodes (before ULE encapsulation) in two
ways:

1. Using IPSEC ESP in transparent mode.  This means the IP header is sent in the
clear and IP payload is encrypted.  This solution is efficient but might not
prevent traffic analysis using IP addresses.
2. Using IPSEC ESP in tunnel mode.  This means IP header and payload are
encrypted.  This solution is better against traffic analysis, but there is the
extra overhead of IPSEC tunnelling.

Regards.
Haitham

alain.ritoux at 6wind.com wrote:

> Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
>
> >
> > Hi every body
> >
> > The current ULE draft does not address the issue of SNDU encryption which
> > we think is important.
> > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> > necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
> > implement this capability (e.g. Alcatel 9780)
> > Encryption is controlled using the 'payload scrambling control' field (2
> > bits) in the MPE header.
>
> I fail to see why we would need an L2 encryption to carry IP/IPv6
> traffic, when IPsec/IKE is already defined including encryption,
> authentication, key distribution and all that kind of stuff.
> Would it not be re-inventing the (rather complex) wheel ?
>
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com

--
Dr. Haitham S. Cruickshank

Senior Research Fellow
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank at surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/




From gorry at erg.abdn.ac.uk  Thu Feb 26 12:29:39 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Thu, 26 Feb 2004 12:29:39 +0000
Subject: Encryption control of SNDU
In-Reply-To: <403DCB32.30AE6F12@surrey.ac.uk>
Message-ID: <BC639733.358%gorry@erg.abdn.ac.uk>


So, I'm trying to build a list of "issues for ULE" and the questions I have
are:

(i) Does the proposed ULE base header format (4/12B of header) need to be
changed to support any required encryption/scrambling?

Possible answers include:

* Yes - because the ULE header must not be increased when
    link encryption is used.

* No - because the ULE header can specify a TYPE that could
    indicate an encrypted payload, and hence this issue
    could be solved by using an extension header of some form.

If it is YES, then this has design implications for the ULE Spec.

If it is NO, then some text on how to implement the encryption header would
be a useful input - perhaps this should be a short separate ID?
- We can discuss this more easily if we have a proposal and a short example,
I'd also be keen to get expert security advice, we don't wish to repeat any
of the mistakes made by others.  If we can find a solution that is accepted
and widely applicable, we could then either add this to the ULE Spec or as a
separate document.


(b) Whatever the result of the above question, it would be MOST beneficial
to have some security inputs to the REQUIREMENTS ID.  This document needs to
evolve to clearly express the motivations of the ipdvb protocol framework.
This is the next draft on the table for discussion....

Can anyone offer 2 or 3 paragraphs on why we need to do/not to do
encryption/scrambling at the ULE layer, and what the relationship is to
MPEG-2 scrambling and IPSEC?

Gorry Fairhurst


On 26/2/04 10:32 am, "Haitham Cruickshank" <H.Cruickshank at eim.surrey.ac.uk>
wrote:

> Hi Alain and All,
> 
> I like to add my voice to Alain's, regarding keeping ULE simple and free from
> security complications.  Also using IPSEC mean closer integration with
> terrestrial IP networks.
> 
> However, Bernhard mentioned a good point: "I do see reasons for scrambling
> e.g.
> for the case to prevent from traffic analysis".  I think this problem can be
> solved using IPSEC between satellite nodes (before ULE encapsulation) in two
> ways:
> 
> 1. Using IPSEC ESP in transparent mode.  This means the IP header is sent in
> the
> clear and IP payload is encrypted.  This solution is efficient but might not
> prevent traffic analysis using IP addresses.
> 2. Using IPSEC ESP in tunnel mode.  This means IP header and payload are
> encrypted.  This solution is better against traffic analysis, but there is the
> extra overhead of IPSEC tunnelling.
> 
> Regards.
> Haitham
> 
> alain.ritoux at 6wind.com wrote:
> 
>> Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
>> 
>>> 
>>> Hi every body
>>> 
>>> The current ULE draft does not address the issue of SNDU encryption which
>>> we think is important.
>>> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
>>> necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
>>> implement this capability (e.g. Alcatel 9780)
>>> Encryption is controlled using the 'payload scrambling control' field (2
>>> bits) in the MPE header.
>> 
>> I fail to see why we would need an L2 encryption to carry IP/IPv6
>> traffic, when IPsec/IKE is already defined including encryption,
>> authentication, key distribution and all that kind of stuff.
>> Would it not be re-inventing the (rather complex) wheel ?
>> 
>> Regards.
>> Alain.
>> --
>> Alain RITOUX
>> Tel +33-1-39-30-92-32
>> Fax +33-1-39-30-92-11
>> visit our web http://www.6wind.com
> 
> --
> Dr. Haitham S. Cruickshank
> 
> Senior Research Fellow
> Communications Centre for Communication Systems Research (CCSR)
> School of Electronics, Computing and Mathematics
> University of Surrey, Guildford, Surrey GU2 7XH, UK
> 
> Tel: +44 1483 686007 (indirect 689844)
> Fax: +44 1483 686011
> e-mail: H.Cruickshank at surrey.ac.uk
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
> 
> 



From AAllison at nab.org  Thu Feb 26 13:56:43 2004
From: AAllison at nab.org (Allison, Art)
Date: Thu, 26 Feb 2004 08:56:43 -0500
Subject: Encryption control of SNDU
Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEBF32@mail.NAB.ORG>

I add my voice to those saying keep this ULE recommendation free from
security complications.

It seems to me that whatever security that anyone feels is needed can happen
above (or below) this transport recommendations place in the stack of
protocols.

The entire payload of all packets identified by a PID can be scrambled at
the MPEG-2 layer, with what ever CA standard is appropriate.  At the IP
layer (and/or higher) there are tools available, such as IPSEC.

With respect to traffic analysis protection, that too does not seem to need
definition at this layer. However, my difficulty in understanding what
traffic analysis means or could yield to an attacker in a one-way broadcast
environment may be affecting this assessment.  

Regards,
Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Haitham Cruickshank [mailto:H.Cruickshank at eim.surrey.ac.uk]
Sent: Thursday, February 26, 2004 5:32 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: Re: Encryption control of SNDU


Hi Alain and All,

I like to add my voice to Alain's, regarding keeping ULE simple and free
from
security complications.  Also using IPSEC mean closer integration with
terrestrial IP networks.

However, Bernhard mentioned a good point: "I do see reasons for scrambling
e.g.
for the case to prevent from traffic analysis".  I think this problem can be
solved using IPSEC between satellite nodes (before ULE encapsulation) in two
ways:

1. Using IPSEC ESP in transparent mode.  This means the IP header is sent in
the
clear and IP payload is encrypted.  This solution is efficient but might not
prevent traffic analysis using IP addresses.
2. Using IPSEC ESP in tunnel mode.  This means IP header and payload are
encrypted.  This solution is better against traffic analysis, but there is
the
extra overhead of IPSEC tunnelling.

Regards.
Haitham

alain.ritoux at 6wind.com wrote:

> Tarif.Zein-Alabedeen at space.alcatel.fr wrote:
>
> >
> > Hi every body
> >
> > The current ULE draft does not address the issue of SNDU encryption
which
> > we think is important.
> > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> > necessary, data encryption at MPE level. Some IP/MPE/MPEG products
already
> > implement this capability (e.g. Alcatel 9780)
> > Encryption is controlled using the 'payload scrambling control' field (2
> > bits) in the MPE header.
>
> I fail to see why we would need an L2 encryption to carry IP/IPv6
> traffic, when IPsec/IKE is already defined including encryption,
> authentication, key distribution and all that kind of stuff.
> Would it not be re-inventing the (rather complex) wheel ?
>
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com

--
Dr. Haitham S. Cruickshank

Senior Research Fellow
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank at surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/



From alain.ritoux at 6wind.com  Thu Feb 26 14:25:15 2004
From: alain.ritoux at 6wind.com (Alain RITOUX)
Date: Thu, 26 Feb 2004 15:25:15 +0100
Subject: Encryption control of SNDU
In-Reply-To: <BC639733.358%gorry@erg.abdn.ac.uk>
References: <BC639733.358%gorry@erg.abdn.ac.uk>
Message-ID: <403E01CB.3000301@6wind.com>



Gorry Fairhurst wrote:

> So, I'm trying to build a list of "issues for ULE" and the questions I have
> are:
> 
> (i) Does the proposed ULE base header format (4/12B of header) need to be
> changed to support any required encryption/scrambling?
> 
> Possible answers include:
> 
> * Yes - because the ULE header must not be increased when
>     link encryption is used.
> 
> * No - because the ULE header can specify a TYPE that could
>     indicate an encrypted payload, and hence this issue
>     could be solved by using an extension header of some form.
> 
> If it is YES, then this has design implications for the ULE Spec.

I would say No, because :
   - I don't really understand the need for ULE level encryption
     see point I)
   - If needed, it can be separated from ULE base specs. see point II)

I) Why ULE level encryption ?
=============================
I still don't sse the need for an ULE-level encryption, because
I see 3 possibilities of encryption
1) At MPEG-2 level, i.e. same encryption for whole content of a PID
2) At ULE level, i.e. encryption on a per SNDU basis for the case as
  Tarif said, where PID is mutli-receiver (belonging to different groups)
3) At IP level

but what can distinguish 2 SNDU ?
   - IP addresses ?
   - DVB Mac addr ?
But the DVB Mac addr is itself the result of IP address/prefix
resolution (which can use destination and/or sources)
So I think it can all be expresed in term of either destination and/or
source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
seem to me to offer the same granularity and 3) is already defined and
working.

This is my current understanding,  and a counter-example where 2) would
solve a use-case and not 3) would be very helpfull.
Anyway, I may have missed something, so :

II) Etxension Header for Encryption
====================================
*IF* an ULE encryption is needed, then some extension header can be
defined to provide it, so the SNDU would be like :

-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
         |
         +--> Type = sec_header
    (*) if MAC addres bit is '0'


-  The SEC_Header would be
    +---+---+---+--//  ..... // ----+
    |   NH  | L |  security params  |
    +---+---+---+--//  ..... // ----+

    with NH = Type of SNDU payload (IP, IPv6, ...)
         L  = Length of SEC_Header

    security params will define key material, type of security
    (encryption, authentication, ....), algo, whatever ...

    In the extension headers I proposed, the SEC_Header would be one
    of the "drop packets if unknown"  type.

  - The SNDU payload woul be clear/encrypt/padded accordingly to what
    params will be found in SEC_Header.

With that approach, the only thing needed is to include the Extension
Headers mechanism definition in the ULE base specs. Then ALL that
SEC_Header stuff can be described in a separate doc, and good luck with
the (re)keying framework/protocols, security analysis ...

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From Tarif.Zein-Alabedeen at space.alcatel.fr  Thu Feb 26 16:23:07 2004
From: Tarif.Zein-Alabedeen at space.alcatel.fr (Tarif.Zein-Alabedeen at space.alcatel.fr)
Date: Thu, 26 Feb 2004 17:23:07 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <OFC599E85A.63081B50-ONC1256E46.0053462A@netfr.alcatel.fr>



Hi alain and every body
Concerning point I, let me go back to dvb-rcs : encryption at the
encapsulation layer
(which is now MPE but may become ULE in the future) has been provisioned
and the way it is
controlled by the 2 bits field in the MPE header has been clearly specified
(see my precedent mail)

I am not aware of the exact reasons which led poeple who contributed to the
dvb-rcs definition to do this
may be they did something wrong or expected a functionnality that will
never be used....!!!!
But it is more probable that they had real reasons to do this (so we can
avoid to reinvent the wheel as you said)
Any one has an idea?

I see an example which could make case 3 difficult to apply. It concerns
bridging
When forwarding (in the Gateway for example) is performed by bridging (as
in Ethernet switches) and not by routing (as routers),
IPsec can not apply because the GW handles frames and not datagrams (am I
wrong?). Such case may happen with e.g a PPPOE access scheme.
So if IPsec is not applied end-to-end (but this can not be controlled by
the satellite segment), traffic will be transmitted clear on the
sat interface

Concerning the use of the extension header, the main question is : when
encryption is applied at ULE level, do we need the encryption control field
in all SNDUs or not. If yes, the extension header solution may turn to be
inefficient since it would lead to about 5 bytes extra header (taking your
example below). I submitted this question to Alcatel's security experts but
would be great  if others in this groupe could also think about it and make
suggestions

regards





Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
cc :
Objet :     Re: Encryption control of SNDU




Gorry Fairhurst wrote:

> So, I'm trying to build a list of "issues for ULE" and the questions I
have
> are:
>
> (i) Does the proposed ULE base header format (4/12B of header) need to be
> changed to support any required encryption/scrambling?
>
> Possible answers include:
>
> * Yes - because the ULE header must not be increased when
>     link encryption is used.
>
> * No - because the ULE header can specify a TYPE that could
>     indicate an encrypted payload, and hence this issue
>     could be solved by using an extension header of some form.
>
> If it is YES, then this has design implications for the ULE Spec.

I would say No, because :
   - I don't really understand the need for ULE level encryption
     see point I)
   - If needed, it can be separated from ULE base specs. see point II)

I) Why ULE level encryption ?
=============================
I still don't sse the need for an ULE-level encryption, because
I see 3 possibilities of encryption
1) At MPEG-2 level, i.e. same encryption for whole content of a PID
2) At ULE level, i.e. encryption on a per SNDU basis for the case as
  Tarif said, where PID is mutli-receiver (belonging to different groups)
3) At IP level

but what can distinguish 2 SNDU ?
   - IP addresses ?
   - DVB Mac addr ?
But the DVB Mac addr is itself the result of IP address/prefix
resolution (which can use destination and/or sources)
So I think it can all be expresed in term of either destination and/or
source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
seem to me to offer the same granularity and 3) is already defined and
working.

This is my current understanding,  and a counter-example where 2) would
solve a use-case and not 3) would be very helpfull.
Anyway, I may have missed something, so :

II) Etxension Header for Encryption
====================================
*IF* an ULE encryption is needed, then some extension header can be
defined to provide it, so the SNDU would be like :

-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
         |
         +--> Type = sec_header
    (*) if MAC addres bit is '0'


-  The SEC_Header would be
    +---+---+---+--//  ..... // ----+
    |   NH  | L |  security params  |
    +---+---+---+--//  ..... // ----+

    with NH = Type of SNDU payload (IP, IPv6, ...)
         L  = Length of SEC_Header

    security params will define key material, type of security
    (encryption, authentication, ....), algo, whatever ...

    In the extension headers I proposed, the SEC_Header would be one
    of the "drop packets if unknown"  type.

  - The SNDU payload woul be clear/encrypt/padded accordingly to what
    params will be found in SEC_Header.

With that approach, the only thing needed is to include the Extension
Headers mechanism definition in the ULE base specs. Then ALL that
SEC_Header stuff can be described in a separate doc, and good luck with
the (re)keying framework/protocols, security analysis ...

Regards.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com






T. Zein

ALCATEL SPACE
DRT/RST  --  Ing?nieur Syst?mes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220






From Laurent.Claverotte at space.alcatel.fr  Thu Feb 26 17:11:07 2004
From: Laurent.Claverotte at space.alcatel.fr (Laurent.Claverotte at space.alcatel.fr)
Date: Thu, 26 Feb 2004 18:11:07 +0100
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <OF0DB0451C.7E2BA4C2-ONC1256E46.005A022F@netfr.alcatel.fr>



Dear All,

I am working on layer 2 security solution for broadband satellite systems
based on the DVB-RCS standard (part 9.4 of the EN301790) and I see several
advantages for an ULE-level encryption as explained below.

Why ULE level encryption ?
1. Role Model and security requirements
Satcom systems based on DVB-S/DVB-RCS are operated by Access Network
Operators that want to provide their customers (ISP) with security
services.
Common targeted security services are : terminal authentication and data
confidentiality (for the unicast and multicast streams) between the gateway
and the terminals (also limited to the satcom system).
The objective is to provide the same level of privacy as the terrestrial
links.
Moreover, in the same time, the ISP may want to provide end-to-end security
services to the end-users (based on the well known IPSec).
As a matter, I think this is really important to understand that both
security solutions ((ANO to ISP) and (ISP to End-users)) can co-exist and
are economically viable.

2. Solutions comparison
For the end-to-end security solution between the ISP and the end-users, it
is obvious that IPSec or an application security (TLS or SSL) are largely
deployed and accepted by the telecom world.
Regarding the satcom security (between the gateway and the terminals),
different solutions were envisaged by Alcatel Space :
- DVB-S Common Scrambling (security solution deployed for the digital
broadcast television) : this solution is not compliant to the granularity
security requirement (scrambling per PID and not per unicast user!).
Moreover, key distribution techniques are one way only and does not benefit
from the interactive return link.
- IPSec has lot of drawbacks :  it is not a L2 solution, it is an
end-to-end technology, it can interfere with the end-to-end security
solution, it can interfere with satellite techniques (PEP), it does not
provide encryption of  multicast flows and it generates many overheads and
number of signaling messages!!!!!! Lots of comparison studies and
simulations have been performed by Alcatel leading to reject this
solution!!
- Proprietary solutions close to the DVB-S CS : same conclusion as DVB-S CS
- DVB-RCS security solution : we believe that it is the most interesting
solution regarding the intrinsic satcom security as  it complies with the
ANO security requirements.
Indeed, it is a layer 2 solution (control plane defined in the DVB-RCS
standard and traffic plane below the IP layer) enabling to encrypt not only
IP streams but also Ethernet frames (PPPoE for example) or other
protocols... It can support unicast or multicast streams encryption.
Moreover, regarding the performances, It largely reduces the number of
signaling messages and overheads (main worry in satcom!).
It is currently based on the 2 bits payload_scrambling_control of the MPE
header providing the information if the packet is encrypted or not and with
which key (odd or even)...... and this essential information would be
canceled in the ULE definition.

3. Concurrent systems and standardization
As you know, the main concurrent to the european ETSI DVB-S/DVB-RCS
standards is the US DOCSIS standard that includes (in its baseline!!!) a
layer 2 security solution providing terminal authentication and
confidentiality (called BPI+).
Alcatel believes that it is really important to make the DVB-RCS standard
evolve (current Satlab contributions) to offer a complete DVB-RCS security
solution that can be compared to the US DOCSIS standard.
That would really be worrying if the ULE encapsulation could not include
this feature because it would not be compliant with the DVB-RCS security
solution.

I hope that you will understand my concern.
Regards.
Laurent Claverotte






Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
cc :
Objet :     Re: Encryption control of SNDU




Gorry Fairhurst wrote:

> So, I'm trying to build a list of "issues for ULE" and the questions I
have
> are:
>
> (i) Does the proposed ULE base header format (4/12B of header) need to be
> changed to support any required encryption/scrambling?
>
> Possible answers include:
>
> * Yes - because the ULE header must not be increased when
>     link encryption is used.
>
> * No - because the ULE header can specify a TYPE that could
>     indicate an encrypted payload, and hence this issue
>     could be solved by using an extension header of some form.
>
> If it is YES, then this has design implications for the ULE Spec.

I would say No, because :
   - I don't really understand the need for ULE level encryption
     see point I)
   - If needed, it can be separated from ULE base specs. see point II)

I) Why ULE level encryption ?
=============================
I still don't sse the need for an ULE-level encryption, because
I see 3 possibilities of encryption
1) At MPEG-2 level, i.e. same encryption for whole content of a PID
2) At ULE level, i.e. encryption on a per SNDU basis for the case as
  Tarif said, where PID is mutli-receiver (belonging to different groups)
3) At IP level

but what can distinguish 2 SNDU ?
   - IP addresses ?
   - DVB Mac addr ?
But the DVB Mac addr is itself the result of IP address/prefix
resolution (which can use destination and/or sources)
So I think it can all be expresed in term of either destination and/or
source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
seem to me to offer the same granularity and 3) is already defined and
working.

This is my current understanding,  and a counter-example where 2) would
solve a use-case and not 3) would be very helpfull.
Anyway, I may have missed something, so :

II) Etxension Header for Encryption
====================================
*IF* an ULE encryption is needed, then some extension header can be
defined to provide it, so the SNDU would be like :

-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
         |
         +--> Type = sec_header
    (*) if MAC addres bit is '0'


-  The SEC_Header would be
    +---+---+---+--//  ..... // ----+
    |   NH  | L |  security params  |
    +---+---+---+--//  ..... // ----+

    with NH = Type of SNDU payload (IP, IPv6, ...)
         L  = Length of SEC_Header

    security params will define key material, type of security
    (encryption, authentication, ....), algo, whatever ...

    In the extension headers I proposed, the SEC_Header would be one
    of the "drop packets if unknown"  type.

  - The SNDU payload woul be clear/encrypt/padded accordingly to what
    params will be found in SEC_Header.

With that approach, the only thing needed is to include the Extension
Headers mechanism definition in the ULE base specs. Then ALL that
SEC_Header stuff can be described in a separate doc, and good luck with
the (re)keying framework/protocols, security analysis ...

Regards.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com






Sinc?res Salutations / Best regards
Laurent Claverotte

ALCATEL SPACE
DSR/DRE
Tel : 33 (0)5.34.35.46.47  /  Fax : 33 (0)5.34.35.61.69
E-Mail : Laurent.Claverotte at space.alcatel.fr






From williams77 at rediffmail.com  Fri Feb 27 07:37:07 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 27 Feb 2004 07:37:07 -0000
Subject: =?iso-8859-1?Q?Re:_R=E9f=2E_:_Re:_Encryption_control_of_SNDU?=
Message-ID: <20040227073707.20125.qmail@webmail35.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040227/db263c5d/attachment.html>
-------------- next part --------------
Hi everyone,
	I like to support for the requirement of Encryption/security at L2 with in satellite network(Terminal and Gateway) for any confidential informations, both signaling and data packets.

Further to the extension header for ULE, 
it can be made option as we have for destination mac address, without effecting any implementation and design 

-  [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]

we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
with that bit we can define any extension header is present for any future updations to the ULE, 
the Ext. Header is defined as
   +---+--------+---//  ..... // ----+
   |EHT| NHB & L| Ext.Header params  |
   +---+--------+---//  ..... // ----+
   
   where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
          L   = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
          NHB = MSB 1 bit contains if there is any other extension header present.
	  Ext.Header params = variable length based on the ext. header parameter length.

Best Regards,
William.


On Thu, 26 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote :
>
>
>Hi alain and every body
>Concerning point I, let me go back to dvb-rcs : encryption at the
>encapsulation layer
>(which is now MPE but may become ULE in the future) has been provisioned
>and the way it is
>controlled by the 2 bits field in the MPE header has been clearly specified
>(see my precedent mail)
>
>I am not aware of the exact reasons which led poeple who contributed to the
>dvb-rcs definition to do this
>may be they did something wrong or expected a functionnality that will
>never be used....!!!!
>But it is more probable that they had real reasons to do this (so we can
>avoid to reinvent the wheel as you said)
>Any one has an idea?
>
>I see an example which could make case 3 difficult to apply. It concerns
>bridging
>When forwarding (in the Gateway for example) is performed by bridging (as
>in Ethernet switches) and not by routing (as routers),
>IPsec can not apply because the GW handles frames and not datagrams (am I
>wrong?). Such case may happen with e.g a PPPOE access scheme.
>So if IPsec is not applied end-to-end (but this can not be controlled by
>the satellite segment), traffic will be transmitted clear on the
>sat interface
>
>Concerning the use of the extension header, the main question is : when
>encryption is applied at ULE level, do we need the encryption control field
>in all SNDUs or not. If yes, the extension header solution may turn to be
>inefficient since it would lead to about 5 bytes extra header (taking your
>example below). I submitted this question to Alcatel's security experts but
>would be great  if others in this groupe could also think about it and make
>suggestions
>
>regards
>
>
>
>
>
>Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15
>
>Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>
>Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>
>
>Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
>cc :
>Objet :     Re: Encryption control of SNDU
>
>
>
>
>Gorry Fairhurst wrote:
>
> > So, I'm trying to build a list of "issues for ULE" and the questions I
>have
> > are:
> >
> > (i) Does the proposed ULE base header format (4/12B of header) need to be
> > changed to support any required encryption/scrambling?
> >
> > Possible answers include:
> >
> > * Yes - because the ULE header must not be increased when
> >     link encryption is used.
> >
> > * No - because the ULE header can specify a TYPE that could
> >     indicate an encrypted payload, and hence this issue
> >     could be solved by using an extension header of some form.
> >
> > If it is YES, then this has design implications for the ULE Spec.
>
>I would say No, because :
>    - I don't really understand the need for ULE level encryption
>      see point I)
>    - If needed, it can be separated from ULE base specs. see point II)
>
>I) Why ULE level encryption ?
>=============================
>I still don't sse the need for an ULE-level encryption, because
>I see 3 possibilities of encryption
>1) At MPEG-2 level, i.e. same encryption for whole content of a PID
>2) At ULE level, i.e. encryption on a per SNDU basis for the case as
>   Tarif said, where PID is mutli-receiver (belonging to different groups)
>3) At IP level
>
>but what can distinguish 2 SNDU ?
>    - IP addresses ?
>    - DVB Mac addr ?
>But the DVB Mac addr is itself the result of IP address/prefix
>resolution (which can use destination and/or sources)
>So I think it can all be expresed in term of either destination and/or
>source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
>seem to me to offer the same granularity and 3) is already defined and
>working.
>
>This is my current understanding,  and a counter-example where 2) would
>solve a use-case and not 3) would be very helpfull.
>Anyway, I may have missed something, so :
>
>II) Etxension Header for Encryption
>====================================
>*IF* an ULE encryption is needed, then some extension header can be
>defined to provide it, so the SNDU would be like :
>
>-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
>          |
>          +--> Type = sec_header
>     (*) if MAC addres bit is '0'
>
>
>-  The SEC_Header would be
>     +---+---+---+--//  ..... // ----+
>     |   NH  | L |  security params  |
>     +---+---+---+--//  ..... // ----+
>
>     with NH = Type of SNDU payload (IP, IPv6, ...)
>          L  = Length of SEC_Header
>
>     security params will define key material, type of security
>     (encryption, authentication, ....), algo, whatever ...
>
>     In the extension headers I proposed, the SEC_Header would be one
>     of the "drop packets if unknown"  type.
>
>   - The SNDU payload woul be clear/encrypt/padded accordingly to what
>     params will be found in SEC_Header.
>
>With that approach, the only thing needed is to include the Extension
>Headers mechanism definition in the ULE base specs. Then ALL that
>SEC_Header stuff can be described in a separate doc, and good luck with
>the (re)keying framework/protocols, security analysis ...
>
>Regards.
>Alain.
>--
>Alain RITOUX
>Tel +33-1-39-30-92-32
>Fax +33-1-39-30-92-11
>visit our web http://www.6wind.com
>
>
>
>
>
>
>T. Zein
>
>ALCATEL SPACE
>DRT/RST  --  Ing?nieur Syst?mes
>Tel : 0534356918  /  Fax : 0534355560
>Porte : W.220
>
>
>
>

From alain.ritoux at 6wind.com  Fri Feb 27 07:25:20 2004
From: alain.ritoux at 6wind.com (alain.ritoux at 6wind.com)
Date: Fri, 27 Feb 2004 08:25:20 +0100
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control?=
 =?ISO-8859-1?Q?_of_SNDU?=
In-Reply-To: <c1lbs7$kpd$1@intranet.6wind.com>
References: <c1lbs7$kpd$1@intranet.6wind.com>
Message-ID: <403EF0E0.6020506@6wind.com>


Dear Laurent and all,

Not being a satcom expert I cannot argue the L2 security details,
but I do understanf your concern. But some precision need to be done
about the IPsec "drawbacks" paragraph

Laurent.Claverotte at space.alcatel.fr wrote:

> ... snip 
> 
> 2. Solutions comparison
> 
> ... snip 
> - IPSec has lot of drawbacks :  it is not a L2 solution, it is an
> end-to-end technology, it can interfere with the end-to-end security
> solution, it can interfere with satellite techniques (PEP), it does not
> provide encryption of  multicast flows and it generates many overheads and
> number of signaling messages!!!!!! Lots of comparison studies and
> simulations have been performed by Alcatel leading to reject this
> solution!!

* It is not an L2 solution :
well, some might see it a a plus.  end of religious debate ;-)

* its is an end-to-end technology
No, It can support end-to-end security (I mean host-to-host), but
the tunnel mode is available for security gateways, hence allowing
securisation of part of the total path. for exemple between the DVB
sender, and the DVB receiver (even if it is a host and not a router
it can behave as a security gateway for himself).

* it can interfere with end-to-end security solution
??? I don't understand the argument :
It is a solution, that works at IP level, in both end-to-end
model or gateway-to-gateway model. Both models can be used
simultaneously, while working over a secure L2, for transporting
SSL ... I see no contradiction.

* it can interfere with satellite techniques (PEP)
Could you elaborate, because all it does it take an IP packet
and generate one other IP packet. How can satellite technique
interfere without messing into IP level?

* multicast :
Indeed it does not protect multicast yet, but work is in progress.
if there is an easy solution to key distribution, the msec IETF wg
should be informed

* it generates overhead :
Yes there is overhead, but I don't really see fields in AH/ESP that
are unncessary.

* many signalling messages :
I thnk you refer here to IKE. Of course some messages are exchanged
for key negociation, but I think it is the price for dynamic keying.
L2 securisation with dynamic keying will allso generate messages
exchanges.
Anyway, those exchanges are done for each IPsec tunnel, and once done
have generated key whose lifetime can be chosen (in term of duration
and/or tarfic volume), so the overhead relatively to the global volume
should be quite small.

Are those Alcatel comparison studies and/or simulations available
somewhere, could be interesting.

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From williams77 at rediffmail.com  Fri Feb 27 07:36:30 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 27 Feb 2004 07:36:30 -0000
Subject: =?iso-8859-1?Q?Re:_R=E9f=2E_:_Re:_Encryption_control_of_SNDU?=
Message-ID: <20040227073630.25988.qmail@webmail36.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040227/52df3db7/attachment.html>
-------------- next part --------------
Hi everyone,
	I like to support for the requirement of Encryption/security at L2 with in satellite network(Terminal and Gateway) for any confidential informations, both signaling and data packets.

Further to the extension header for ULE, 
it can be made option as we have for destination mac address, without effecting any implementation and design 

-  [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]

we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
with that bit we can define any extension header is present for any future updations to the ULE, 
the Ext. Header is defined as
   +---+--------+---//  ..... // ----+
   |EHT| NHB & L| Ext.Header params  |
   +---+--------+---//  ..... // ----+
   
   where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
          L   = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
          NHB = MSB 1 bit contains if there is any other extension header present.
	  Ext.Header params = variable length based on the ext. header parameter length.

Best Regards,
William.


On Thu, 26 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote :
>
>
>Hi alain and every body
>Concerning point I, let me go back to dvb-rcs : encryption at the
>encapsulation layer
>(which is now MPE but may become ULE in the future) has been provisioned
>and the way it is
>controlled by the 2 bits field in the MPE header has been clearly specified
>(see my precedent mail)
>
>I am not aware of the exact reasons which led poeple who contributed to the
>dvb-rcs definition to do this
>may be they did something wrong or expected a functionnality that will
>never be used....!!!!
>But it is more probable that they had real reasons to do this (so we can
>avoid to reinvent the wheel as you said)
>Any one has an idea?
>
>I see an example which could make case 3 difficult to apply. It concerns
>bridging
>When forwarding (in the Gateway for example) is performed by bridging (as
>in Ethernet switches) and not by routing (as routers),
>IPsec can not apply because the GW handles frames and not datagrams (am I
>wrong?). Such case may happen with e.g a PPPOE access scheme.
>So if IPsec is not applied end-to-end (but this can not be controlled by
>the satellite segment), traffic will be transmitted clear on the
>sat interface
>
>Concerning the use of the extension header, the main question is : when
>encryption is applied at ULE level, do we need the encryption control field
>in all SNDUs or not. If yes, the extension header solution may turn to be
>inefficient since it would lead to about 5 bytes extra header (taking your
>example below). I submitted this question to Alcatel's security experts but
>would be great  if others in this groupe could also think about it and make
>suggestions
>
>regards
>
>
>
>
>
>Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15
>
>Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>
>Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>
>
>Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
>cc :
>Objet :     Re: Encryption control of SNDU
>
>
>
>
>Gorry Fairhurst wrote:
>
> > So, I'm trying to build a list of "issues for ULE" and the questions I
>have
> > are:
> >
> > (i) Does the proposed ULE base header format (4/12B of header) need to be
> > changed to support any required encryption/scrambling?
> >
> > Possible answers include:
> >
> > * Yes - because the ULE header must not be increased when
> >     link encryption is used.
> >
> > * No - because the ULE header can specify a TYPE that could
> >     indicate an encrypted payload, and hence this issue
> >     could be solved by using an extension header of some form.
> >
> > If it is YES, then this has design implications for the ULE Spec.
>
>I would say No, because :
>    - I don't really understand the need for ULE level encryption
>      see point I)
>    - If needed, it can be separated from ULE base specs. see point II)
>
>I) Why ULE level encryption ?
>=============================
>I still don't sse the need for an ULE-level encryption, because
>I see 3 possibilities of encryption
>1) At MPEG-2 level, i.e. same encryption for whole content of a PID
>2) At ULE level, i.e. encryption on a per SNDU basis for the case as
>   Tarif said, where PID is mutli-receiver (belonging to different groups)
>3) At IP level
>
>but what can distinguish 2 SNDU ?
>    - IP addresses ?
>    - DVB Mac addr ?
>But the DVB Mac addr is itself the result of IP address/prefix
>resolution (which can use destination and/or sources)
>So I think it can all be expresed in term of either destination and/or
>source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
>seem to me to offer the same granularity and 3) is already defined and
>working.
>
>This is my current understanding,  and a counter-example where 2) would
>solve a use-case and not 3) would be very helpfull.
>Anyway, I may have missed something, so :
>
>II) Etxension Header for Encryption
>====================================
>*IF* an ULE encryption is needed, then some extension header can be
>defined to provide it, so the SNDU would be like :
>
>-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
>          |
>          +--> Type = sec_header
>     (*) if MAC addres bit is '0'
>
>
>-  The SEC_Header would be
>     +---+---+---+--//  ..... // ----+
>     |   NH  | L |  security params  |
>     +---+---+---+--//  ..... // ----+
>
>     with NH = Type of SNDU payload (IP, IPv6, ...)
>          L  = Length of SEC_Header
>
>     security params will define key material, type of security
>     (encryption, authentication, ....), algo, whatever ...
>
>     In the extension headers I proposed, the SEC_Header would be one
>     of the "drop packets if unknown"  type.
>
>   - The SNDU payload woul be clear/encrypt/padded accordingly to what
>     params will be found in SEC_Header.
>
>With that approach, the only thing needed is to include the Extension
>Headers mechanism definition in the ULE base specs. Then ALL that
>SEC_Header stuff can be described in a separate doc, and good luck with
>the (re)keying framework/protocols, security analysis ...
>
>Regards.
>Alain.
>--
>Alain RITOUX
>Tel +33-1-39-30-92-32
>Fax +33-1-39-30-92-11
>visit our web http://www.6wind.com
>
>
>
>
>
>
>T. Zein
>
>ALCATEL SPACE
>DRT/RST  --  Ing?nieur Syst?mes
>Tel : 0534356918  /  Fax : 0534355560
>Porte : W.220
>
>
>
>

From gorry at erg.abdn.ac.uk  Fri Feb 27 07:53:28 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 27 Feb 2004 07:53:28 +0000
Subject: Encryption control of SNDU
In-Reply-To: <403E01CB.3000301@6wind.com>
Message-ID: <BC64A7F8.39E%gorry@erg.abdn.ac.uk>



Thanks Alain for the example "extension format"

- I like the idea you put forward of extension headers for optional items,
the the Receiver *may* wish to use to enhance processing - this can be very
powerful, particularly with unidirectional and/or multipoint feeds, and
avoids explicit configuration for each Receiver.

- But I think the encryption information is mandatory to processing the
SNDU, so an alternate way to extend the header would be to assign one (or a
block of several contiguous) codepoints from the TYPE field. This could be
more efficient to implement, and would carry the same semantics as other
packet types - i.e. The type field indicates how to demultiplex the PDU. An
example could be:

< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | ENC |ETYPE |                PDU              | CRC-32 |
+-+-------------------------------------------------------+--------+
       
Where ENC = a predefined 2B TYPE  value, and ETYPE is the 2B type field
Corresponding to the PDU. Several ENC values could be specified.
Additional overhead = 2B.

If necessary, one or more bytes could be added between ENC and ETYPE,
It would be useful to think if these were desirable i.e. could assist
security decoding (or not).

So, I'm saying is:

(i) We now have two ways to extend ULE, we need to see which is most
appropriate, and for what.

(ii) The part of the text that I cut is equally important, we need inputs on
*WHY* and *HOW* the encryption should be done.

Gorry Fairhurst.


On 26/2/04 2:25 pm, "Alain RITOUX" <alain.ritoux at 6wind.com> wrote:

> 
> 
> Gorry Fairhurst wrote:
> 
>> So, I'm trying to build a list of "issues for ULE" and the questions I have
>> are:
>> 
>> (i) Does the proposed ULE base header format (4/12B of header) need to be
>> changed to support any required encryption/scrambling?
>> 
>> Possible answers include:
> Anyway, I may have missed something, so :
> 
> II) Etxension Header for Encryption
> ====================================
> *IF* an ULE encryption is needed, then some extension header can be
> defined to provide it, so the SNDU would be like :
> 
> -  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
>        |
>        +--> Type = sec_header
>   (*) if MAC addres bit is '0'
> 
> 
> -  The SEC_Header would be
>   +---+---+---+--//  ..... // ----+
>   |   NH  | L |  security params  |
>   +---+---+---+--//  ..... // ----+
> 
>   with NH = Type of SNDU payload (IP, IPv6, ...)
>        L  = Length of SEC_Header
> 
>   security params will define key material, type of security
>   (encryption, authentication, ....), algo, whatever ...
> 
>   In the extension headers I proposed, the SEC_Header would be one
>   of the "drop packets if unknown"  type.
> 
> - The SNDU payload woul be clear/encrypt/padded accordingly to what
>   params will be found in SEC_Header.
> 
> With that approach, the only thing needed is to include the Extension
> Headers mechanism definition in the ULE base specs. Then ALL that
> SEC_Header stuff can be described in a separate doc, and good luck with
> the (re)keying framework/protocols, security analysis ...
> 
> Regards.
> Alain.



From Bertrand.Wendling at nagra.fr  Fri Feb 27 08:30:38 2004
From: Bertrand.Wendling at nagra.fr (Wendling Bertrand)
Date: Fri, 27 Feb 2004 09:30:38 +0100
Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <BA5A8D05954E6D43872DAF8677AD78FA48AE77@servmgap04.mg.k.grp>

Dear Laurent,
In your mail you wrote :
Moreover, key distribution techniques are one way only and does not benefit from the interactive return link.
I cannot agree with you, CA systems for Broadcast TV take since years benefit from interactive return link for key distribution (individual addressing base). 
Regards
Bertrand
 
 

-----Original Message-----
From: owner-ip-dvb at erg.abdn.ac.uk [ mailto:owner-ip-dvb at erg.abdn.ac.uk]On
Behalf Of Laurent.Claverotte at space.alcatel.fr
Sent: Thursday, February 26, 2004 6:11 PM
To: ip-dvb at erg.abdn.ac.uk
Subject: R?f. : Re: Encryption control of SNDU
Importance: Low




Dear All,

I am working on layer 2 security solution for broadband satellite systems
based on the DVB-RCS standard (part 9.4 of the EN301790) and I see several
advantages for an ULE-level encryption as explained below.

Why ULE level encryption ?
1. Role Model and security requirements
Satcom systems based on DVB-S/DVB-RCS are operated by Access Network
Operators that want to provide their customers (ISP) with security
services.
Common targeted security services are : terminal authentication and data
confidentiality (for the unicast and multicast streams) between the gateway
and the terminals (also limited to the satcom system).
The objective is to provide the same level of privacy as the terrestrial
links.
Moreover, in the same time, the ISP may want to provide end-to-end security
services to the end-users (based on the well known IPSec).
As a matter, I think this is really important to understand that both
security solutions ((ANO to ISP) and (ISP to End-users)) can co-exist and
are economically viable.

2. Solutions comparison
For the end-to-end security solution between the ISP and the end-users, it
is obvious that IPSec or an application security (TLS or SSL) are largely
deployed and accepted by the telecom world.
Regarding the satcom security (between the gateway and the terminals),
different solutions were envisaged by Alcatel Space :
- DVB-S Common Scrambling (security solution deployed for the digital
broadcast television) : this solution is not compliant to the granularity
security requirement (scrambling per PID and not per unicast user!).
Moreover, key distribution techniques are one way only and does not benefit
from the interactive return link.
- IPSec has lot of drawbacks :  it is not a L2 solution, it is an
end-to-end technology, it can interfere with the end-to-end security
solution, it can interfere with satellite techniques (PEP), it does not
provide encryption of  multicast flows and it generates many overheads and
number of signaling messages!!!!!! Lots of comparison studies and
simulations have been performed by Alcatel leading to reject this
solution!!
- Proprietary solutions close to the DVB-S CS : same conclusion as DVB-S CS
- DVB-RCS security solution : we believe that it is the most interesting
solution regarding the intrinsic satcom security as  it complies with the
ANO security requirements.
Indeed, it is a layer 2 solution (control plane defined in the DVB-RCS
standard and traffic plane below the IP layer) enabling to encrypt not only
IP streams but also Ethernet frames (PPPoE for example) or other
protocols... It can support unicast or multicast streams encryption.
Moreover, regarding the performances, It largely reduces the number of
signaling messages and overheads (main worry in satcom!).
It is currently based on the 2 bits payload_scrambling_control of the MPE
header providing the information if the packet is encrypted or not and with
which key (odd or even)...... and this essential information would be
canceled in the ULE definition.

3. Concurrent systems and standardization
As you know, the main concurrent to the european ETSI DVB-S/DVB-RCS
standards is the US DOCSIS standard that includes (in its baseline!!!) a
layer 2 security solution providing terminal authentication and
confidentiality (called BPI+).
Alcatel believes that it is really important to make the DVB-RCS standard
evolve (current Satlab contributions) to offer a complete DVB-RCS security
solution that can be compared to the US DOCSIS standard.
That would really be worrying if the ULE encapsulation could not include
this feature because it would not be compliant with the DVB-RCS security
solution.

I hope that you will understand my concern.
Regards.
Laurent Claverotte






Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk


Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
cc :
Objet :     Re: Encryption control of SNDU




Gorry Fairhurst wrote:

> So, I'm trying to build a list of "issues for ULE" and the questions I
have
> are:
>
> (i) Does the proposed ULE base header format (4/12B of header) need to be
> changed to support any required encryption/scrambling?
>
> Possible answers include:
>
> * Yes - because the ULE header must not be increased when
>     link encryption is used.
>
> * No - because the ULE header can specify a TYPE that could
>     indicate an encrypted payload, and hence this issue
>     could be solved by using an extension header of some form.
>
> If it is YES, then this has design implications for the ULE Spec.

I would say No, because :
   - I don't really understand the need for ULE level encryption
     see point I)
   - If needed, it can be separated from ULE base specs. see point II)

I) Why ULE level encryption ?
=============================
I still don't sse the need for an ULE-level encryption, because
I see 3 possibilities of encryption
1) At MPEG-2 level, i.e. same encryption for whole content of a PID
2) At ULE level, i.e. encryption on a per SNDU basis for the case as
  Tarif said, where PID is mutli-receiver (belonging to different groups)
3) At IP level

but what can distinguish 2 SNDU ?
   - IP addresses ?
   - DVB Mac addr ?
But the DVB Mac addr is itself the result of IP address/prefix
resolution (which can use destination and/or sources)
So I think it can all be expresed in term of either destination and/or
source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
seem to me to offer the same granularity and 3) is already defined and
working.

This is my current understanding,  and a counter-example where 2) would
solve a use-case and not 3) would be very helpfull.
Anyway, I may have missed something, so :

II) Etxension Header for Encryption
====================================
*IF* an ULE encryption is needed, then some extension header can be
defined to provide it, so the SNDU would be like :

-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
         |
         +--> Type = sec_header
    (*) if MAC addres bit is '0'


-  The SEC_Header would be
    +---+---+---+--//  ..... // ----+
    |   NH  | L |  security params  |
    +---+---+---+--//  ..... // ----+

    with NH = Type of SNDU payload (IP, IPv6, ...)
         L  = Length of SEC_Header

    security params will define key material, type of security
    (encryption, authentication, ....), algo, whatever ...

    In the extension headers I proposed, the SEC_Header would be one
    of the "drop packets if unknown"  type.

  - The SNDU payload woul be clear/encrypt/padded accordingly to what
    params will be found in SEC_Header.

With that approach, the only thing needed is to include the Extension
Headers mechanism definition in the ULE base specs. Then ALL that
SEC_Header stuff can be described in a separate doc, and good luck with
the (re)keying framework/protocols, security analysis ...

Regards.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com






Sinc?res Salutations / Best regards
Laurent Claverotte

ALCATEL SPACE
DSR/DRE
Tel : 33 (0)5.34.35.46.47  /  Fax : 33 (0)5.34.35.61.69
E-Mail : Laurent.Claverotte at space.alcatel.fr





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040227/de41e5de/attachment.html>

From Fritsche at iabg.de  Fri Feb 27 10:34:10 2004
From: Fritsche at iabg.de (Fritsche Wolfgang)
Date: Fri, 27 Feb 2004 11:34:10 +0100
Subject: =?iso-8859-1?Q?AW=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <69A5E767EC979846826F566C7932A3F2074E2F@exchange03.iabg.de>



> -----Urspr?ngliche Nachricht-----
> Von: owner-ip-dvb at erg.abdn.ac.uk 
> [mailto:owner-ip-dvb at erg.abdn.ac.uk] Im Auftrag von 
> Tarif.Zein-Alabedeen at space.alcatel.fr
> Gesendet: Donnerstag, 26. Februar 2004 17:23
> An: ip-dvb at erg.abdn.ac.uk
> Betreff: R?f. : Re: Encryption control of SNDU
> Wichtigkeit: Niedrig
> 
> 
> 
> 
> Hi alain and every body
> Concerning point I, let me go back to dvb-rcs : encryption at 
> the encapsulation layer (which is now MPE but may become ULE 
> in the future) has been provisioned and the way it is 
> controlled by the 2 bits field in the MPE header has been 
> clearly specified (see my precedent mail)
> 
> I am not aware of the exact reasons which led poeple who 
> contributed to the dvb-rcs definition to do this may be they 
> did something wrong or expected a functionnality that will 
> never be used....!!!! But it is more probable that they had 
> real reasons to do this (so we can avoid to reinvent the 
> wheel as you said) Any one has an idea?

Before requiring the adoption of these 2bits we really should know and understand their reasons, and assess if they still exist for ULE.

> 
> I see an example which could make case 3 difficult to apply. 
> It concerns bridging When forwarding (in the Gateway for 
> example) is performed by bridging (as in Ethernet switches) 
> and not by routing (as routers), IPsec can not apply because 
> the GW handles frames and not datagrams (am I wrong?). Such 
> case may happen with e.g a PPPOE access scheme. So if IPsec 
> is not applied end-to-end (but this can not be controlled by 
> the satellite segment), traffic will be transmitted clear on 
> the sat interface

I don't think your example above necessarily means cleartext transmission.

Even when briding is used on the encapsulator, there is a node before, which performs routing functionality. Often this node is controlled by the same entity as the encapsulator in "bridging mode" (e.g. a Teleport operator), so the IPsec SA could start in this case on the router.

In case the encapsulator in "bridging mode" and its closest preceding router are controlled by different entities, you still could apply security on MPEG level.

Cheers,

Wolfgang

> 
> Concerning the use of the extension header, the main question 
> is : when encryption is applied at ULE level, do we need the 
> encryption control field in all SNDUs or not. If yes, the 
> extension header solution may turn to be inefficient since it 
> would lead to about 5 bytes extra header (taking your example 
> below). I submitted this question to Alcatel's security 
> experts but would be great  if others in this groupe could 
> also think about it and make suggestions
> 
> regards
> 
> 
> 
> 
> 
> Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 
> 26/02/2004 15:25:15
> 
> Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
> 
> Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
> 
> 
> Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
> cc :
> Objet :     Re: Encryption control of SNDU
> 
> 
> 
> 
> Gorry Fairhurst wrote:
> 
> > So, I'm trying to build a list of "issues for ULE" and the 
> questions I
> have
> > are:
> >
> > (i) Does the proposed ULE base header format (4/12B of 
> header) need to 
> > be changed to support any required encryption/scrambling?
> >
> > Possible answers include:
> >
> > * Yes - because the ULE header must not be increased when
> >     link encryption is used.
> >
> > * No - because the ULE header can specify a TYPE that could
> >     indicate an encrypted payload, and hence this issue
> >     could be solved by using an extension header of some form.
> >
> > If it is YES, then this has design implications for the ULE Spec.
> 
> I would say No, because :
>    - I don't really understand the need for ULE level encryption
>      see point I)
>    - If needed, it can be separated from ULE base specs. see point II)
> 
> I) Why ULE level encryption ?
> =============================
> I still don't sse the need for an ULE-level encryption, 
> because I see 3 possibilities of encryption
> 1) At MPEG-2 level, i.e. same encryption for whole content of a PID
> 2) At ULE level, i.e. encryption on a per SNDU basis for the case as
>   Tarif said, where PID is mutli-receiver (belonging to 
> different groups)
> 3) At IP level
> 
> but what can distinguish 2 SNDU ?
>    - IP addresses ?
>    - DVB Mac addr ?
> But the DVB Mac addr is itself the result of IP 
> address/prefix resolution (which can use destination and/or 
> sources) So I think it can all be expresed in term of either 
> destination and/or source Addresses, which can perfectly be 
> handled by IPsec. So 2) and 3) seem to me to offer the same 
> granularity and 3) is already defined and working.
> 
> This is my current understanding,  and a counter-example 
> where 2) would solve a use-case and not 3) would be very 
> helpfull. Anyway, I may have missed something, so :
> 
> II) Etxension Header for Encryption 
> ====================================
> *IF* an ULE encryption is needed, then some extension header 
> can be defined to provide it, so the SNDU would be like :
> 
> -  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
>          |
>          +--> Type = sec_header
>     (*) if MAC addres bit is '0'
> 
> 
> -  The SEC_Header would be
>     +---+---+---+--//  ..... // ----+
>     |   NH  | L |  security params  |
>     +---+---+---+--//  ..... // ----+
> 
>     with NH = Type of SNDU payload (IP, IPv6, ...)
>          L  = Length of SEC_Header
> 
>     security params will define key material, type of security
>     (encryption, authentication, ....), algo, whatever ...
> 
>     In the extension headers I proposed, the SEC_Header would be one
>     of the "drop packets if unknown"  type.
> 
>   - The SNDU payload woul be clear/encrypt/padded accordingly to what
>     params will be found in SEC_Header.
> 
> With that approach, the only thing needed is to include the 
> Extension Headers mechanism definition in the ULE base specs. 
> Then ALL that SEC_Header stuff can be described in a separate 
> doc, and good luck with the (re)keying framework/protocols, 
> security analysis ...
> 
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
> 
> 
> 
> 
> 
> 
> T. Zein
> 
> ALCATEL SPACE
> DRT/RST  --  Ing?nieur Syst?mes
> Tel : 0534356918  /  Fax : 0534355560
> Porte : W.220
> 
> 
> 
> 
> 



From Fritsche at iabg.de  Fri Feb 27 10:39:41 2004
From: Fritsche at iabg.de (Fritsche Wolfgang)
Date: Fri, 27 Feb 2004 11:39:41 +0100
Subject: =?iso-8859-1?Q?AW=3A_R=E9f=2E_=3A_Re=3A_Encryption_control_of_SNDU?=
Message-ID: <69A5E767EC979846826F566C7932A3F2074E30@exchange03.iabg.de>



> -----Urspr?ngliche Nachricht-----
> Von: owner-ip-dvb at erg.abdn.ac.uk 
> [mailto:owner-ip-dvb at erg.abdn.ac.uk] Im Auftrag von 
> alain.ritoux at 6wind.com
> Gesendet: Freitag, 27. Februar 2004 08:25
> Betreff: Re: R?f. : Re: Encryption control of SNDU
> 
> 
> 
> Dear Laurent and all,
> 
> Not being a satcom expert I cannot argue the L2 security 
> details, but I do understanf your concern. But some precision 
> need to be done about the IPsec "drawbacks" paragraph
> 
> Laurent.Claverotte at space.alcatel.fr wrote:
> 
> > ... snip
> > 
> > 2. Solutions comparison
> > 
> > ... snip
> > - IPSec has lot of drawbacks :  it is not a L2 solution, it is an
> > end-to-end technology, it can interfere with the end-to-end security
> > solution, it can interfere with satellite techniques (PEP), 
> it does not
> > provide encryption of  multicast flows and it generates 
> many overheads and
> > number of signaling messages!!!!!! Lots of comparison studies and
> > simulations have been performed by Alcatel leading to reject this
> > solution!!
> 
> * It is not an L2 solution :
> well, some might see it a a plus.  end of religious debate ;-)
> 
> * its is an end-to-end technology
> No, It can support end-to-end security (I mean host-to-host), 
> but the tunnel mode is available for security gateways, hence 
> allowing securisation of part of the total path. for exemple 
> between the DVB sender, and the DVB receiver (even if it is a 
> host and not a router it can behave as a security gateway for 
> himself).
> 
> * it can interfere with end-to-end security solution
> ??? I don't understand the argument :
> It is a solution, that works at IP level, in both end-to-end 
> model or gateway-to-gateway model. Both models can be used 
> simultaneously, while working over a secure L2, for 
> transporting SSL ... I see no contradiction.
> 
> * it can interfere with satellite techniques (PEP)
> Could you elaborate, because all it does it take an IP packet 
> and generate one other IP packet. How can satellite technique 
> interfere without messing into IP level?

If it interferes with PEPs depends on the architecture, that is the position of the IPsec functionality relatively to the PEPs.

> 
> * multicast :
> Indeed it does not protect multicast yet, but work is in 
> progress. if there is an easy solution to key distribution, 
> the msec IETF wg should be informed

Multicast security without key management should work already with most IPsec implementations (they should not differ between IP unicast and IP Multicast destination address of an SA, and the spec also doesn't exlude this).

Multicast key management is in the cycle of standardisation, and has already been demonstrated as prototype (Haitham and Logica have done this within an ESA project, making using GSAKMP light).

Cheers,

Wolfgang

> 
> * it generates overhead :
> Yes there is overhead, but I don't really see fields in 
> AH/ESP that are unncessary.
> 
> * many signalling messages :
> I thnk you refer here to IKE. Of course some messages are 
> exchanged for key negociation, but I think it is the price 
> for dynamic keying. L2 securisation with dynamic keying will 
> allso generate messages exchanges. Anyway, those exchanges 
> are done for each IPsec tunnel, and once done have generated 
> key whose lifetime can be chosen (in term of duration and/or 
> tarfic volume), so the overhead relatively to the global 
> volume should be quite small.
> 
> Are those Alcatel comparison studies and/or simulations 
> available somewhere, could be interesting.
> 
> Regards.
> Alain.
> -- 
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
> 
> 



From alain.ritoux at 6wind.com  Fri Feb 27 10:56:05 2004
From: alain.ritoux at 6wind.com (Alain RITOUX)
Date: Fri, 27 Feb 2004 11:56:05 +0100
Subject: ULE extensions
In-Reply-To: <20040227073707.20125.qmail@webmail35.rediffmail.com>
References: <20040227073707.20125.qmail@webmail35.rediffmail.com>
Message-ID: <403F2245.7020601@6wind.com>

Hello William and all,

(I changed the title to separate thread for ULE extension, from
thread about encryption)


> Further to the extension header for ULE, 
> it can be made option as we have for destination mac address, without effecting any implementation and design 
> 
> -  [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]
> 
> we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
> with that bit we can define any extension header is present for any future updations to the ULE, 
> the Ext. Header is defined as
>    +---+--------+---//  ..... // ----+
>    |EHT| NHB & L| Ext.Header params  |
>    +---+--------+---//  .... // ----+
>    
>    where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
>           L   = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
>           NHB = MSB 1 bit contains if there is any other extension header present.
> 	  Ext.Header params = variable length based on the ext. header parameter length.
> 

If I understand correctly, the type field in the ULE header remains
unchanged, and indicates the final payload. The EHT is from a different
namespace.

So the deal is
  (1 bit of ULE length) + (1 bit in ExtHdr length) dealed for
  (1 byte in each ExtHdr)

This seems VERY good to me.

If we also compare with Gorry's last proposal,

 > < ----------------------------- SNDU ----------------------------- >
 > +-+-------------------------------------------------------+--------+
 > |D| Length | ENC |ETYPE |                PDU              | CRC-32 |
 > +-+-------------------------------------------------------+--------+
 >
 > Where ENC = a predefined 2B TYPE  value, and ETYPE is the 2B type
 > field Corresponding to the PDU. Several ENC values could be specified.
 > Additional overhead = 2B.

it has the very same overhead, but keeps the possibility
   - to chain headers.
   - to make them blindly parsable.

Indeed if some extension are mandatory, we can still, with
this new extension model, split the naming space in 2 parts :

  <128  - Optional ExtHeader  : if unknown, skip and process next
 >=128  - Mandatory ExtHeader : if unknown, drop SNDU


So I'm in favour of this 3rd extention scheme (until of course somebody
finds a way to gain one more byte ;-))

[
  And just a word about encryption : if it is done by such an ExtHdr
  format, it just has to use a "Mandatory Ext Header", and the ULE
  specs just has to define this ext mechanism. The "how" and "why"
  use encryption will not be linked to ULE, but to ULE-security-extension
  and described in the separate I-D

  please any response to this part should start an other thread
]

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com



From gorry at erg.abdn.ac.uk  Fri Feb 27 13:00:20 2004
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 27 Feb 2004 13:00:20 +0000
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_Encryption_control?=
 =?ISO-8859-1?Q?_of_SNDU?=
In-Reply-To: <20040227073630.25988.qmail@webmail36.rediffmail.com>
References: <20040227073630.25988.qmail@webmail36.rediffmail.com>
Message-ID: <403F3F64.7040900@erg.abdn.ac.uk>


OK, so this is a third way to introduce an extension header,
that takes one bit form the Length field, but otherwise resembles
Alain's... approach.

gorry


William StanisLaus wrote:

<snip>

>Further to the extension header for ULE, 
>it can be made option as we have for destination mac address, without effecting any implementation and design 
>
>-  [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]
>
>we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
>with that bit we can define any extension header is present for any future updations to the ULE, 
>the Ext. Header is defined as
>   +---+--------+---//  ..... // ----+
>   |EHT| NHB & L| Ext.Header params  |
>   +---+--------+---//  ..... // ----+
>   
>   where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
>          L   = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
>          NHB = MSB 1 bit contains if there is any other extension header present.
>	  Ext.Header params = variable length based on the ext. header parameter length.
>
>Best Regards,
>William.
>
>
>On Thu, 26 Feb 2004 Tarif.Zein-Alabedeen at space.alcatel.fr wrote :
>  
>
>>Hi alain and every body
>>Concerning point I, let me go back to dvb-rcs : encryption at the
>>encapsulation layer
>>(which is now MPE but may become ULE in the future) has been provisioned
>>and the way it is
>>controlled by the 2 bits field in the MPE header has been clearly specified
>>(see my precedent mail)
>>
>>I am not aware of the exact reasons which led poeple who contributed to the
>>dvb-rcs definition to do this
>>may be they did something wrong or expected a functionnality that will
>>never be used....!!!!
>>But it is more probable that they had real reasons to do this (so we can
>>avoid to reinvent the wheel as you said)
>>Any one has an idea?
>>
>>I see an example which could make case 3 difficult to apply. It concerns
>>bridging
>>When forwarding (in the Gateway for example) is performed by bridging (as
>>in Ethernet switches) and not by routing (as routers),
>>IPsec can not apply because the GW handles frames and not datagrams (am I
>>wrong?). Such case may happen with e.g a PPPOE access scheme.
>>So if IPsec is not applied end-to-end (but this can not be controlled by
>>the satellite segment), traffic will be transmitted clear on the
>>sat interface
>>
>>Concerning the use of the extension header, the main question is : when
>>encryption is applied at ULE level, do we need the encryption control field
>>in all SNDUs or not. If yes, the extension header solution may turn to be
>>inefficient since it would lead to about 5 bytes extra header (taking your
>>example below). I submitted this question to Alcatel's security experts but
>>would be great  if others in this groupe could also think about it and make
>>suggestions
>>
>>regards
>>
>>
>>
>>
>>
>>Alain RITOUX <alain.ritoux at 6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15
>>
>>Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk
>>
>>Envoy? par :      owner-ip-dvb at erg.abdn.ac.uk
>>
>>
>>Pour : IPDVB <ip-dvb at erg.abdn.ac.uk>
>>cc :
>>Objet :     Re: Encryption control of SNDU
>>
>>
>>
>>
>>Gorry Fairhurst wrote:
>>
>>    
>>
>>>So, I'm trying to build a list of "issues for ULE" and the questions I
>>>      
>>>
>>have
>>    
>>
>>>are:
>>>
>>>(i) Does the proposed ULE base header format (4/12B of header) need to be
>>>changed to support any required encryption/scrambling?
>>>
>>>Possible answers include:
>>>
>>>* Yes - because the ULE header must not be increased when
>>>    link encryption is used.
>>>
>>>* No - because the ULE header can specify a TYPE that could
>>>    indicate an encrypted payload, and hence this issue
>>>    could be solved by using an extension header of some form.
>>>
>>>If it is YES, then this has design implications for the ULE Spec.
>>>      
>>>
>>I would say No, because :
>>   - I don't really understand the need for ULE level encryption
>>     see point I)
>>   - If needed, it can be separated from ULE base specs. see point II)
>>
>>I) Why ULE level encryption ?
>>=============================
>>I still don't sse the need for an ULE-level encryption, because
>>I see 3 possibilities of encryption
>>1) At MPEG-2 level, i.e. same encryption for whole content of a PID
>>2) At ULE level, i.e. encryption on a per SNDU basis for the case as
>>  Tarif said, where PID is mutli-receiver (belonging to different groups)
>>3) At IP level
>>
>>but what can distinguish 2 SNDU ?
>>   - IP addresses ?
>>   - DVB Mac addr ?
>>But the DVB Mac addr is itself the result of IP address/prefix
>>resolution (which can use destination and/or sources)
>>So I think it can all be expresed in term of either destination and/or
>>source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
>>seem to me to offer the same granularity and 3) is already defined and
>>working.
>>
>>This is my current understanding,  and a counter-example where 2) would
>>solve a use-case and not 3) would be very helpfull.
>>Anyway, I may have missed something, so :
>>
>>II) Etxension Header for Encryption
>>====================================
>>*IF* an ULE encryption is needed, then some extension header can be
>>defined to provide it, so the SNDU would be like :
>>
>>-  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
>>         |
>>         +--> Type = sec_header
>>    (*) if MAC addres bit is '0'
>>
>>
>>-  The SEC_Header would be
>>    +---+---+---+--//  ..... // ----+
>>    |   NH  | L |  security params  |
>>    +---+---+---+--//  ..... // ----+
>>
>>    with NH = Type of SNDU payload (IP, IPv6, ...)
>>         L  = Length of SEC_Header
>>
>>    security params will define key material, type of security
>>    (encryption, authentication, ....), algo, whatever ...
>>
>>    In the extension headers I proposed, the SEC_Header would be one
>>    of the "drop packets if unknown"  type.
>>
>>  - The SNDU payload woul be clear/encrypt/padded accordingly to what
>>    params will be found in SEC_Header.
>>
>>With that approach, the only thing needed is to include the Extension
>>Headers mechanism definition in the ULE base specs. Then ALL that
>>SEC_Header stuff can be described in a separate doc, and good luck with
>>the (re)keying framework/protocols, security analysis ...
>>
>>Regards.
>>Alain.
>>--
>>Alain RITOUX
>>Tel +33-1-39-30-92-32
>>Fax +33-1-39-30-92-11
>>visit our web http://www.6wind.com
>>
>>
>>
>>
>>
>>
>>T. Zein
>>
>>ALCATEL SPACE
>>DRT/RST  --  Ing?nieur Syst?mes
>>Tel : 0534356918  /  Fax : 0534355560
>>Porte : W.220
>>
>>
>>
>>
>>    
>>
>
>  
>



From williams77 at rediffmail.com  Sat Feb 28 06:37:00 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 28 Feb 2004 06:37:00 -0000
Subject: ULE extensions
Message-ID: <20040228063700.7223.qmail@webmail25.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040228/56a83fa8/attachment.html>
-------------- next part --------------
Hi Alain and all,

I have a small concern here on 

> > < ----------------------------- SNDU ----------------------------- >
> > +-+-------------------------------------------------------+--------+
> > |D| Length | ENC |ETYPE |                PDU              | CRC-32 |
> > +-+-------------------------------------------------------+--------+
here, always ENC which is 2 bytes wasted even if we don't support ULE encryption. Also there is no provision for future extension of any other informations which can be added to the ULE header, say for example LLC_SNAP support, Section number(in case if any one of the intermediate MPEG1-TS packet is lost for a particular SNDU, Receiver can request that particular SNDU from the sender with Section number in ULE.. this might be for error detection, packet loss etc).

In the other approach, based on the extension header bit, we can add extension headers, which can chain more than one extension headers as well.
If there is no extension is required and if we are going to follow the simple approach, then  extension header bit is set to ZERO and there is no modification to the present ULE draft.


Best Regards,
William.

On Fri, 27 Feb 2004 Alain RITOUX wrote :
>Hello William and all,
>
>(I changed the title to separate thread for ULE extension, from
>thread about encryption)
>
>
>>Further to the extension header for ULE, it can be made option as we have for destination mac address, without effecting any implementation and design 
>>-  [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]
>>
>>we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
>>with that bit we can define any extension header is present for any future updations to the ULE, the Ext. Header is defined as
>>    +---+--------+---//  ..... // ----+
>>    |EHT| NHB & L| Ext.Header params  |
>>    +---+--------+---//  .... // ----+
>>       where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
>>           L   = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
>>           NHB = MSB 1 bit contains if there is any other extension header present.
>> 	  Ext.Header params = variable length based on the ext. header parameter length.
>>
>
>If I understand correctly, the type field in the ULE header remains
>unchanged, and indicates the final payload. The EHT is from a different
>namespace.
>
>So the deal is
>  (1 bit of ULE length) + (1 bit in ExtHdr length) dealed for
>  (1 byte in each ExtHdr)
>
>This seems VERY good to me.
>
>If we also compare with Gorry's last proposal,
>
> > < ----------------------------- SNDU ----------------------------- >
> > +-+-------------------------------------------------------+--------+
> > |D| Length | ENC |ETYPE |                PDU              | CRC-32 |
> > +-+-------------------------------------------------------+--------+
> >
> > Where ENC = a predefined 2B TYPE  value, and ETYPE is the 2B type
> > field Corresponding to the PDU. Several ENC values could be specified.
> > Additional overhead = 2B.
>
>it has the very same overhead, but keeps the possibility
>   - to chain headers.
>   - to make them blindly parsable.
>
>Indeed if some extension are mandatory, we can still, with
>this new extension model, split the naming space in 2 parts :
>
>  <128  - Optional ExtHeader  : if unknown, skip and process next
> >=128  - Mandatory ExtHeader : if unknown, drop SNDU
>
>
>So I'm in favour of this 3rd extention scheme (until of course somebody
>finds a way to gain one more byte ;-))
>
>[
>  And just a word about encryption : if it is done by such an ExtHdr
>  format, it just has to use a "Mandatory Ext Header", and the ULE
>  specs just has to define this ext mechanism. The "how" and "why"
>  use encryption will not be linked to ULE, but to ULE-security-extension
>  and described in the separate I-D
>
>  please any response to this part should start an other thread
>]
>
>Regards.
>Alain.
>-- Alain RITOUX
>Tel +33-1-39-30-92-32
>Fax +33-1-39-30-92-11
>visit our web http://www.6wind.com
>

From williams77 at rediffmail.com  Sat Feb 28 17:04:32 2004
From: williams77 at rediffmail.com (William StanisLaus)
Date: 28 Feb 2004 17:04:32 -0000
Subject: ULE encryption Support.
Message-ID: <20040228170432.6819.qmail@mailweb33.rediffmail.com>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20040228/cf9beeb4/attachment.html>
-------------- next part --------------
Hi Alain,
    Its seems when are sure to have some ext. headers as mandatory.. we can well define in as part of the standarded ULE header itself as any other IE (Information Element) in ULE header. I can see the only exception as Optional Headers support to keep the ULE header minimal. Except MUST HAVE IE's in ULE we can push all other things into optional headers, and we can leave it to the implementation whether to support those optional headers are not.
Regarding Encryption, i personnely feel that it should be an optional header, since it is not all Satellite network operators interest to implement encryption in L2.

Best Regards,
William.

On Fri, 27 Feb 2004 Alain RITOUX wrote :

<snip>

>
>[
>  And just a word about encryption : if it is done by such an ExtHdr
>  format, it just has to use a "Mandatory Ext Header", and the ULE
>  specs just has to define this ext mechanism. The "how" and "why"
>  use encryption will not be linked to ULE, but to ULE-security-extension
>  and described in the separate I-D
>
>  please any response to this part should start an other thread
>]
>
>Regards.
>Alain.
>-- Alain RITOUX
>Tel +33-1-39-30-92-32
>Fax +33-1-39-30-92-11
>visit our web http://www.6wind.com
>

From Rod.Walsh at nokia.com  Sun Feb 29 17:18:55 2004
From: Rod.Walsh at nokia.com (Rod.Walsh at nokia.com)
Date: Sun, 29 Feb 2004 19:18:55 +0200
Subject: IPDVB bar-bof in Seoul
Message-ID: <D0299AFF29E01E478321564030AD69094528F8@trebe003.europe.nokia.com>

Hello everyone

Anyone interested in talking IPDVB, and maybe an early afternoon beverage, is welcome to join a few of us in Bobby London's pub on Tuesday 15:15 (3:15pm).

Cheers, Rod.