From owner-ipdvb@erg.abdn.ac.uk Thu Jul 1 06:47:52 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i615lE2N006104 for ; Thu, 1 Jul 2004 06:47:14 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i615lEon006103 for ipdvb-subscribed-users; Thu, 1 Jul 2004 06:47:14 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i615kT1N006073 for ; Thu, 1 Jul 2004 06:46:29 +0100 (BST) Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id B81D5F9021; Thu, 1 Jul 2004 07:46:29 +0200 (CEST) Received: from milbe (milbe.cosy.sbg.ac.at [141.201.2.21]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id 7F131F8C06 for ; Thu, 1 Jul 2004 07:46:28 +0200 (CEST) From: "Bernhard Collini-Nocker" To: Subject: AW: IPDVB Framework ID Date: Thu, 1 Jul 2004 07:46:19 +0200 Message-ID: <08f301c45f2e$bea56060$0100030a@milbe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08F4_01C45F3F.822E3060" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <016e01c45e06$f8df1240$b402a8c0@copernicus> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on dobermann.cosy.sbg.ac.at X-Spam-Level: X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_08F4_01C45F3F.822E3060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marie-Jose, =20 many thanks for the effort! =20 Found just a few typos: TC], Satellite TV [ETSI-DVBS; ATSC-S]and Cable Transmission [ETSI- # = missing space DSM-CC: "Digital Storage Management Command and Control" should read = "Digital Storage Media =96 Command and Control" # M stands for media PES: "Programme Elementary Stream" should be."Packetized Elementary = Stream"=20 "appropriate MPEG2 control information" # misiing - in MPEG2 "return link (if required)is provided by other means." # missing space = after ) multi-homing and mobility). This capability could be associated # no = associated (=20 CSMA/CD [LLC], although in this cased a SNAP (subnetwork access # "case" = instead of "cased" protocol) header is also required for IP packets). # no associated ( both addresses used, they must, be mapped either in a static or a # = "both addresses are used, they must be mapped..."? modified by a user to allow reception of specified (or all packets), # = modified by a user to allow reception of specified (or all) packets, Reception of The additional network # "the" instead of "The"=20 Kind regards, Bernhard -----Urspr=FCngliche Nachricht----- Von: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Im = Auftrag von Marie-Jose Montpetit Gesendet: Tuesday, June 29, 2004 20:29 An: ipdvb@erg.abdn.ac.uk Betreff: IPDVB Framework ID List: =20 I'd like to get final comments on: =20 A Framework for transmission of IP datagrams over MPEG-2 networks Document: draft-fair-ipdvb-req-05.txt http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-05.txt by Thursday 1st of July. =20 I will fix the document with the comment I have and any potential new = one and submit by Friday. =20 Thanks! =20 Marie-Jose Montpetit ------=_NextPart_000_08F4_01C45F3F.822E3060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Dear=20 Marie-Jose,
 
many=20 thanks for the effort!
 
Found=20 just a few typos:
TC], Satellite TV [ETSI-DVBS; = ATSC-S]and=20 Cable Transmission [ETSI-    # missing space
DSM-CC: "Digital Storage Management Command and Control" = should read "Digital Storage Media – Command and = Control" # M=20 stands for media
PES: "Programme Elementary Stream" should be."Packetized = Elementary Stream"
"appropriate MPEG2 control information" # misiing - in=20 MPEG2
"return link = (if required)is=20 provided by other means." # missing space after=20 )
multi-homing and mobility). This capability could = be=20 associated # no associated (
CSMA/CD [LLC], although in this cased a SNAP = (subnetwork=20 access # "case" instead of "cased"
protocol) header is also required = for IP=20 packets). # no associated (
both addresses used, they must, be = mapped=20 either in a static or a # "both addresses are used, they must be=20 mapped..."?
modified by a user to allow reception of specified (or = all=20 packets), # modified by a user to allow reception of specified (or all)=20 packets,
Reception of The additional network # "the" instead of=20 "The" 

Kind=20 regards,
Bernhard
-----Urspr=FCngliche Nachricht-----
Von:=20 owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] Im = Auftrag=20 von Marie-Jose Montpetit
Gesendet: Tuesday, June 29, = 2004=20 20:29
An: ipdvb@erg.abdn.ac.uk
Betreff: IPDVB = Framework=20 ID

List:
 
I'd like to get final comments = on:
 
A Framework for transmission of IP = datagrams over=20 MPEG-2 networks
Document: draft-fair-ipdvb-req-05.txt
= http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-05.txt<= /FONT>
by Thursday 1st of=20 July.
 
I will fix the document with the = comment I have and any potential new one and submit by=20 Friday.
 
Thanks!
 
Marie-Jose=20 Montpetit
------=_NextPart_000_08F4_01C45F3F.822E3060-- From owner-ipdvb@erg.abdn.ac.uk Wed Jul 7 10:11:34 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i679AR5m019635 for ; Wed, 7 Jul 2004 10:10:27 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i679ARdr019634 for ipdvb-subscribed-users; Wed, 7 Jul 2004 10:10:27 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6798jnU019540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Jul 2004 10:08:46 +0100 (BST) Message-ID: <40EBBD9E.7030301@erg.abdn.ac.uk> Date: Wed, 07 Jul 2004 10:08:46 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Cut-off dates for the upcoming 60th IETF meeting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Here are the cut-off dates for the upcoming 60th IETF meeting: Mon Jul 12, 0900 EDT: cutoff for initial (-00) I-D submissions Mon Jul 19, 0900 EDT: final cutoff for I-D submission In addition, please note that the I-D boilerplate was updated recently. In this context, the following recent announcement from the IESG is helpful: ---------------------------------------------------------------------- The IESG has emitted new versions of the following guideline documents: "Guidelines to authors of Internet-Drafts" http://www.ietf.org/ietf/1id-guidelines.txt which has been updated to reflect the new IPR policy RFCs (3667 and 3668): Note that in this process, we discovered a bug in one of the RFCs; the document contains a temporary fix, but the details of a permanent fix are still being worked out on the IPR WG list. "Checklist for Internet-Drafts submitted for RFC publication" http://www.ietf.org/ID-Checklist.html This has had a more thorough review/revision, and should be re-read by all participants. Note in particular the new language about IANA considerations. ---------------------------------------------------------------------- If you use the xml2rfc toolset from http://xml.resource.org/ , you basically have to upgrade to the most recent version of the tool, and use the right declarations to select the most suitable variant of boilerplate. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Thu Jul 8 09:40:43 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i688e7pJ013088 for ; Thu, 8 Jul 2004 09:40:07 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i688e6v7013087 for ipdvb-subscribed-users; Thu, 8 Jul 2004 09:40:06 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i688dJDT013031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Jul 2004 09:39:19 +0100 (BST) Message-ID: <40ED0835.4050108@erg.abdn.ac.uk> Date: Thu, 08 Jul 2004 09:39:17 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: DARFT AGENDA for WG Comment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Dear all, I propose a draft Agenda for the IETF-60 meeting in San Diego. http://www.ietf.org/meetings/IETF-60.html Items for the Agenda - or topics to be discussed should be sent to the WG Chair or to this list. A revised Agenda will be posted next week. Gorry Fairhurst (ipdvb WG Chair) -------- AGENDA (Draft) ====== ipdvb IP over digital video broadcast networks WG (Internet area) DURATION 2 hours. CHAIR: Gorry Fairhurst 1. Agenda Bashing (5 minutes) - Chair * Agenda changes * Election of scribes * Blue Sheets 2. Working Group Status and Plans (10 minutes) - Chair * Charter Active Drafts 3. Requirements/Framework (20 minutes) Marie-Jose Montpetit http://www.ietf.org/internet-drafts/draft-ipdvb-arch-00.txt * Document structure * Changes since last rev (draft-fair-ipdvb-req-05.txt). * Scenarios * Remaining issues to complete the ID for submission as RFC * Questions 4. Ultra Lightweight Encapsulation (15 minutes) - Bernhard Collini-Nocker http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-01.txt * Changes since rev -00. * Questions 5. ULE Extension Headers (10 minutes) - Bernhard Collini-Nocker http://www.ietf.org/internet-drafts/draft-collini-xule-00.txt * Questions 6. ULE Issues to progress WGLC (15 minutes) - Chair * Extension Headers * Encryption * Adaptation Field * Discussion of way to proceed 7. Address Resolution (15 minutes) - Marie-Jose Montpetit http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-??.txt (or replacement draft) 8. Other Issues * Update on status of known implementations (?any contributions?) 9. Review of Milestones (5 minutes) - Chair Archive: http://www.erg.abdn.ac.uk/ip-dvb/archive From owner-ipdvb@erg.abdn.ac.uk Thu Jul 8 11:24:10 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i68AMvHN017510 for ; Thu, 8 Jul 2004 11:22:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i68AMuET017508 for ipdvb-subscribed-users; Thu, 8 Jul 2004 11:22:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i68AL6xK017419 for ; Thu, 8 Jul 2004 11:21:06 +0100 (BST) Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id 3B1F3F8F21; Thu, 8 Jul 2004 12:21:07 +0200 (CEST) Received: from milbe (milbe.cosy.sbg.ac.at [141.201.2.21]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id E7216F8CE0 for ; Thu, 8 Jul 2004 12:21:05 +0200 (CEST) From: "Bernhard Collini-Nocker" To: Subject: AW: DARFT AGENDA for WG Comment Date: Thu, 8 Jul 2004 12:20:52 +0200 Message-ID: <00b701c464d5$42586f00$0100030a@milbe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <40ED0835.4050108@erg.abdn.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on dobermann.cosy.sbg.ac.at X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Dear Gorry and all, thanks for the agenda proposal, looks very reasonable! Are there any thoughts/ideas from the list members about issues Hilmar has raised wrt XULE in an e-mail a few weeks ago? Greeetings, Bernhard > Dear all, > > I propose a draft Agenda for the IETF-60 meeting in San Diego. > > http://www.ietf.org/meetings/IETF-60.html > > Items for the Agenda - or topics to be discussed should be > sent to the WG Chair or to this list. A revised Agenda will > be posted next week. > > Gorry Fairhurst > (ipdvb WG Chair) > > -------- > > AGENDA (Draft) > ====== > > ipdvb IP over digital video broadcast networks WG > (Internet area) > > DURATION 2 hours. > > CHAIR: Gorry Fairhurst > > 1. Agenda Bashing (5 minutes) - Chair > * Agenda changes > * Election of scribes > * Blue Sheets > > 2. Working Group Status and Plans (10 minutes) - Chair > * Charter > > Active Drafts > > 3. Requirements/Framework (20 minutes) Marie-Jose Montpetit > http://www.ietf.org/internet-drafts/draft-ipdvb-arch-00.txt > * Document structure > * Changes since last rev (draft-fair-ipdvb-req-05.txt). > * Scenarios > * Remaining issues to complete the ID for submission as RFC > * Questions > > 4. Ultra Lightweight Encapsulation (15 minutes) - Bernhard > Collini-Nocker > http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-01.txt > * Changes since rev -00. > * Questions > > 5. ULE Extension Headers (10 minutes) - Bernhard Collini-Nocker > http://www.ietf.org/internet-drafts/draft-collini-xule-00.txt > * Questions > > 6. ULE Issues to progress WGLC (15 minutes) - Chair > * Extension Headers > * Encryption > * Adaptation Field > * Discussion of way to proceed > > 7. Address Resolution (15 minutes) - Marie-Jose Montpetit > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-??.txt > (or replacement draft) > > 8. Other Issues > * Update on status of known implementations (?any contributions?) > > 9. Review of Milestones (5 minutes) - Chair > > > Archive: http://www.erg.abdn.ac.uk/ip-dvb/archive > > > > From owner-ipdvb@erg.abdn.ac.uk Thu Jul 8 17:27:48 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i68GPuta002698 for ; Thu, 8 Jul 2004 17:25:56 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i68GPu7H002697 for ipdvb-subscribed-users; Thu, 8 Jul 2004 17:25:56 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i68GONgV002595 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 8 Jul 2004 17:24:24 +0100 (BST) Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1Bibgw-0004zO-00; Thu, 08 Jul 2004 17:24:10 +0100 Message-ID: <40ED752A.BF815444@surrey.ac.uk> Date: Thu, 08 Jul 2004 17:24:10 +0100 From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gorry Fairhurst CC: ipdvb@erg.abdn.ac.uk, Sunil Iyengar Subject: Re: ULE Extension Header Thoughts - Security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-100.6 required=5.5 tests=REFERENCES,USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST, X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1Bibgw-0004zO-00*D8kcbs4z7fc* (SECM, UniS) X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Hi All, Further to Gorry's request about the security issue here is the reply from my colleague Sunil Iyengar (Sunny) re: http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00731.html >>> Hilmar Linder: >>> o) Does it make sense to define the header types 0x002 and 0x003 as >>> mandatory encryption header (section 2.1). As different encryptions >>> require different extension headers we should probably only >>> define that the next-layer-header types should be larger than >>> 0x001 and smaller than 0x0100. >> Gorry: >> Any chance I can get a quick security view on this query.... >> >> My thoughts were that the encryption algorithm, use of padding, >> etc were normally negotiated as a part of the key exchange process >> - therefore you don't need to define separate link formats for >> each encryption format. >> //Sunny: You are right that all the parameters for the encryption process are negotiated via key exchange mechanisms or policy mechanisms. There is always a tendency to separate key management (negotiation ) with link formats. >>> Hilmar Linder: >>> o) How many different encryption schemes do we expect to >>> support with the ULE extension headers? Is the type range >>> allocated sufficiently large? >>> Any other thoughts? >> Gorry: >> My take was: >> When a new encryption algorithm is introduced, the >> link still marks the packet as "encrypted", but negotiates >> a different type of encryption. This does not require an extra >> link frame type, only a new key exchange format. // Sunny: If a new encryption algorithm is used, then a key exchange is done prior to its usage. This does not require a different link type, only marking of the packet as "encrypted" is sufficient. When a packet is received it knows which algorithm is being used and the parameters and hence one does not have to include it in the link type only to indicate that it is encrypted. Moreover, it is necessary to have the Odd and Even type of encryption header fields because of the rekey. Hope that answers the question. Cheers Sunny -- 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@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ From owner-ipdvb@erg.abdn.ac.uk Fri Jul 9 06:05:49 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i69543Lq000980 for ; Fri, 9 Jul 2004 06:04:03 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i69543Kx000979 for ipdvb-subscribed-users; Fri, 9 Jul 2004 06:04:03 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6951mgx000869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 9 Jul 2004 06:01:51 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by hnse2.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i6951doW007808 for ; Fri, 9 Jul 2004 01:01:39 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i6950apT013687 for ; Fri, 9 Jul 2004 01:01:31 -0400 (EDT) Subject: Roderick Ragland/HNS is out of the office. From: Roderick Ragland To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Fri, 9 Jul 2004 01:01:13 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 6.5.1|January 21, 2004) at 07/09/2004 00:59:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Filtered: Sendmail Attachment Filter v2.6.0 hnse2.hns.com i6951doW007808 X-AntiVirus: Sendmail Anti-Virus Filter hnse2.hns.com 4.3.20 4374 i6951doW007808 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk I will be out of the office starting 07/08/2004 and will not return until 07/13/2004. I will respond to your message when I return. From owner-ipdvb@erg.abdn.ac.uk Fri Jul 9 14:17:15 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i69DFcs2019060 for ; Fri, 9 Jul 2004 14:15:38 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i69DFcVB019059 for ipdvb-subscribed-users; Fri, 9 Jul 2004 14:15:38 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i69DDphr018960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Jul 2004 14:13:52 +0100 (BST) Message-ID: <40EE9A11.1050209@erg.abdn.ac.uk> Date: Fri, 09 Jul 2004 14:13:53 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: An advance copy of the WG Architecture ID Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk A Framework for transmission of IP datagrams over MPEG-2 networks The above document has been uploaded several times to the Internet-Drafts server, but so far has been rejected each time because of changes in the IPR and Disclaimer rules that were recently made. Since currently there is no feedback from the ID Editor to indicate what specific issue relate to a particular draft, this is taking some time to sort out. I'm happy that the draft will soon be up-loaded. In the mean-time, I've uploaded the current rev to the ipdvb web site, so that you can offer any feedback to the list :-) Download from: http://www.erg.abdn.ac.uk/ip-dvb/ids/draft-ipdvb-arch-00.txt Best wishes, Gorry From owner-ipdvb@erg.abdn.ac.uk Fri Jul 9 23:16:06 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i69MErgD009278 for ; Fri, 9 Jul 2004 23:14:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i69MEqRP009277 for ipdvb-subscribed-users; Fri, 9 Jul 2004 23:14:52 +0100 (BST) Message-Id: <200407092214.i69MEqRP009277@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f From: Internet-Drafts@ietf.org Date: Fri, 09 Jul 2004 15:31:21 -0400 Subject: I-D ACTION:draft-ietf-ipdvb-arch-00.txt Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : A Framework for transmission of IP datagrams over MPEG-2 networks Author(s) : M. Montpetit, et al. Filename : draft-ietf-ipdvb-arch-00.txt Pages : 38 Date : 2004-7-9 This document describes a new architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). 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. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-9154917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipdvb-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipdvb-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-9154917.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipdvb@erg.abdn.ac.uk Sat Jul 10 10:48:44 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6A9lrh6004530 for ; Sat, 10 Jul 2004 10:47:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6A9lrRp004529 for ipdvb-subscribed-users; Sat, 10 Jul 2004 10:47:53 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.15] (maxp28.abdn.ac.uk [139.133.7.187]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6A9kwMR004493 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sat, 10 Jul 2004 10:47:00 +0100 (BST) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Sat, 10 Jul 2004 10:47:00 +0100 Subject: FW: I-D ACTION:draft-ietf-ipdvb-arch-00.txt From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" CC: Marie-Jose Montpetit Message-ID: In-Reply-To: <200407092214.i69MEqRP009277@mavis.erg.abdn.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : A Framework for transmission of IP datagrams over MPEG-2 networks Author(s) : M. Montpetit, et al. Filename : draft-ietf-ipdvb-arch-00.txt Pages : 38 Date : 2004-7-9 This document describes a new architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). 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. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipdvb@erg.abdn.ac.uk Wed Jul 14 15:27:01 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6EEPf9H015107 for ; Wed, 14 Jul 2004 15:25:41 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6EEPfwE015106 for ipdvb-subscribed-users; Wed, 14 Jul 2004 15:25:41 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from out007.verizon.net (out007pub.verizon.net [206.46.170.107]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6EEOS88015055; Wed, 14 Jul 2004 15:24:28 +0100 (BST) Received: from copernicus ([68.163.135.87]) by out007.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040714142425.JIDI28276.out007.verizon.net@copernicus>; Wed, 14 Jul 2004 09:24:25 -0500 Message-ID: <061401c469ae$463d6070$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: Cc: "Gorry Fairhurst" , , Date: Wed, 14 Jul 2004 10:24:13 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0605_01C4698C.B53E3F70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authentication-Info: Submitted using SMTP AUTH at out007.verizon.net from [68.163.135.87] at Wed, 14 Jul 2004 09:24:20 -0500 X-ERG-MailScanner: Found to be clean, Found to be clean Subject: draft-fair-ipdvb-ar-01.txt Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_0605_01C4698C.B53E3F70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0606_01C4698C.B53E3F70" ------=_NextPart_001_0606_01C4698C.B53E3F70 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please find attached the draft-fair-ipdvb-ar-01.txt as an individual = submission to be discussed further at the ipdvb WG meeting at IETF 60. Marie-Jose Montpetit ------=_NextPart_001_0606_01C4698C.B53E3F70 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Please find attached the draft-fair-ipdvb-ar-01.txt as=20 an individual submission to be discussed further at the ipdvb WG meeting = at IETF=20 60.
 
 
Marie-Jose=20 Montpetit
------=_NextPart_001_0606_01C4698C.B53E3F70-- ------=_NextPart_000_0605_01C4698C.B53E3F70 Content-Type: text/plain; name="draft-fair-ipdvb-ar-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-fair-ipdvb-ar-01.txt" Internet Engineering Task Force Gorry Fairhurst=20 Internet Draft University of Aberdeen, U.K.=20 Document: draft-fair-ipdvb-ar-01.txt Marie-Jose Montpetit=20 July 2004 MJMontpetit.com=20 = = =20 Category: Informational Expires November 2004 = =20 = =20 Address Resolution for IP datagrams over MPEG-2 networks=20 =20 Status of this Memo =20 By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we am aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-Draft, we accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2004), All Rights Reserved Expires November 2004 = [page 1] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks July 2004=20 =20 Abstract=20 =20 This document describes mechanisms to bind IPv4/IPv6 addresses=20 and flows to MPEG-2 Transport Streams (TS). While methods currently exist to perform these bindings, for MPEG-2 systems to=20 become true subnetworks of the general Internet, protocols are required to signal IPv4/v6 addresses to the link receivers and=20 transmitters. This is known as Address Resolution (AR), or Neighbour Discovery (ND). Although AR is often associated with Ethernet [RFC803], it is essential to the operation of any L2 network. MPEG-2 transmission networks often utilize broadcast media (e.g. satellite or cable) where the mapping may take into=20 account issues related to network operations and traffic engineering. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and specific transmission=20 multiplex. Address resolution complements the higher layer=20 resource discovery tools that are used to advertise IP sessions. In this document the different mechanisms used for address=20 resolution for MPEG-2 are reviewed and guidelines for future developments of efficient schemes are given.=20 Table of Contents=20 =20 Document History 1. Introduction 2. Convention used in the document 3. Address Resolution Requirement 4. MPEG-2 Address Resolution Operation 5. Conclusions and Recommendations 6. Security Considerations 7. Acknowledgements 8. References 9. Author's Addresses 10. IPR Notices 11. Copyright Statements 12. IANA Considerations =20 =20 Document History=20 =20 -00 This draft is intended as a study item for proposed future work by the IETF in this area. =20 -01 Review of initial content, major edit and refinement of concepts =20 =20 Expires November 2004 [page 2] =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004 =20 =20 1. Introduction=20 The MPEG-2 stream is defined in the specification ISO/IEC 138181.=20 It provides a time-division multiplexed (TDM) stream that may=20 contain audio, video and other information. Each frame, known as an MPEG-2 TS Packet, contains 4 bytes of header and 188 bytes of data. The standard also defines the PES packet (Packetized Elementary Stream) and the Section or Transport Stream (TS) packet. The PES packet can carry video, audio, private data and was originally used for some data streaming applications; this usage is now historical. Each MPEG-2 TS Packet is associated with one Transport Stream (TS) logical channel, which is identified by a 13 bit Packet ID (PID) carried in the MPEG-2 TS Packet header. =20 =20 The standard also defines a MPEG-2 control plane that may be used=20 to transmit control information. For example, using System=20 Information (SI) Tables (ETSI-SI, ETSI-SI1], or Program Specific=20 Information (PSI) Tables. The Tables can be used to carry PID=20 information about the transported stream. MPEG-2 address=20 resolution assigns IP addresses to particular transmission=20 multiplexes, and within a multiplex to a specific PID. =20 The protocol signals this mapping to the other communicating devices (Gateways and Receivers). In some address resolution=20 schemes, this address space is sub-divided into logical contexts known as Platforms or Sections. One use of this sub-division is=20 to associate a separate context with each IP service provider that=20 shares a common MPEG-2 TS (uses the same PID).=20 =20 MPEG-2 Receivers may optionally be assigned a Network Point of=20 Attachment (NPA) to uniquely identify the L2 node within the=20 MPEG-2 transmission network. An example of an NPA is the IEEE Medium Access Control (MAC) address. Where such addresses are=20 used, these must also be signalled by the address resolution procedure. Finally, address resolution may need to signal the format of the data being transmitted. For example, the encapsulation used or any compression scheme that was used at the sender [ID-IPDVB-ARCH].=20 =20 This document describes mechanisms to signal the TS Multiplex, the=20 PID, and (if used) the MAC address or platform ID associated with=20 each IP address or flow to the network layer at the sender and=20 receiver. As will be seen below this can, for example, be implemented via descriptors sent in MPEG-2 SI tables (using the MPEG-2 control plane), via one or more new SI tables, or in-band=20 by a protocol using a data channel similarly to the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbour Discovery (ND) =20 protocol.=20 Expires November 2004 [page 3] =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 2. Conventions used in this document=20 =20 AIT: Application Information Table specified by the Multimedia Home Platform (MHP) specifications [ETSI-MHP]. This table may carry IPv4/IPv6 to MPEG-2 TS address resolution information.=20 =20 ATSC: Advanced Television Systems Committee [ATSC]. A set of=20 framework and associated standards for the transmission of video,=20 audio, and data, using the ISO MPEG-2 standard.=20 =20 DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and=20 associated standards for the transmission of video, audio, and=20 data, using the ISO MPEG-2 standard.=20 =20 DVB-RCS: Digital Video Broadcast Return Channel via Satellite.=20 A bi-directional IPv4/IPv6 service employing low-cost Receivers. =20 INT: Internet/MAC Notification Table. A uni-directional=20 addressing resolution mechanism using SI and/or PSI Tables.=20 =20 MAC: Medium Access and Control of the Ethernet IEEE 802 standard of protocols (see also NPA).=20 =20 MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia=20 receiver, that may (in some cases) support IPv4/IPv6 services.=20 =20 MMT: Multicast Mapping Table (proprietary extension to DVB-RCS).=20 MPE: Multiprotocol Encapsulation [ETSI-DAT, ETSI-DAT1]. A scheme=20 that encapsulates Ethernet frames or IP Packets, creating a =20 DSM-CC Section. The Section will be sent in a series of TS Packets = over a TS Logical Channel.=20 =20 MPEG-2: A set of standards specified by the Motion Picture Experts=20 Group (MPEG), and standardized by the International Standards=20 Organisation (ISO) [ISO-MPEG].=20 NPA: Network Point of Attachment. Addresses primarily used for station (receiver) identification within a local network (e.g.=20 IEEE MAC address).=20 PES: Packetized Elementary Stream. A format of MPEG-2 TS packet=20 payload usually used for video or audio information in MPEG-2 [ISO-MPEG].=20 =20 Expires November 2004 [page 4]=20 =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks July 2004 =20 PID: Packet Identifier. A 13-bit field carried in the header of all MPEG-2 Transport Stream packets [ISO-MPEG]. This is used to identify the TS Logical Channel to which it belongs.=20 =20 PRIVATE SECTION: A syntactic structure used for mapping all service information (e.g. an SI table) into TS Packets. A table may be divided into a number of sections. All sections of a table=20 must be carried over a single TS Logical Channel.=20 =20 PSI: Programme Specific Information: In this document, the term is=20 used to describe any table used to convey information about a subset of services carried in a TS Multiplex (e.g. [ISO-MPEG]).=20 PSI tables are carried in MPEG-2 private sections. =20 =20 SI TABLE: Service Information Table. In this document, the term is=20 used to describe any table used to convey information about the=20 service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are=20 carried in MPEG-2 private sections. =20 =20 TS: Transport Stream [ISO-MPEG], a method of transmission at the=20 MPEG-2 level using TS Packets; it represents level 2 of the=20 ISO/OSI=20 reference model. See also TS Logical Channel and TS Multiplex.=20 =20 TS LOGICAL CHANNEL: A channel identified at the MPEG-2 level; it=20 represents level 2 of the ISO/OSI reference model. All packets=20 sent over a channel carry the same PID value.=20 =20 TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a=20 single common physical bearer (i.e. a link transmitting at a=20 specified symbol rate, FEC setting, and transmission frequency).=20 =20 TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2=20 multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM=20 networks, and is frequently also referred to as a TS_cell. =20 Each TS Packet carries a 4B header, plus optional overhead. Each TS packet carries a PID value to associate it with a single TS=20 Logical Channel.=20 =20 Expires November 2004 [page 5] = INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 3. Address Resolution Requirements=20 =20 The IP address resolution support should support both existing IP=20 over MPEG-2 encapsulations (e.g., MPE [ETSI-DAT, ETSI-DAT1]), and=20 also any IETF encapsulation that may be defined [ID-IPDVB-ARCH].=20 <<< more requirements to be added >>> =20 In some case, an MPEG-2 Transmission Network may support multiple IP networks. If this is the case, it is important to recognise=20 the context (scope) within which an address is resolved, to prevent packets from one addressed scope leaking into other=20 scopes.=20 =20 Examples of overlapping IP address assignments include: =20 (i) Private unicast addresses (e.g. in IPv4, 10/8 prefix;=20 172.16/12 prefix; 192.168/16 prefix) should be confined to=20 one addressed area.=20 (ii) Some multicast addresses, (e.g., the scoped multicast=20 addresses sometimes used in private networks). These are=20 only valid within an addressed area (examples for IPv4=20 include; 239/8; 224.0.0/24; 224.0.1/24). Similar cases=20 exist for some IPv6 multicast addresses.=20 (iii) Scoped multicast addresses. Forwarding of these addresses=20 is controlled by the scope associated with the address.=20 IP packets with these addresses must not be allowed to travel=20 outside their intended scope, and may cause unexpected behaviour=20 if allowed to do so.=20 =20 In addition, overlapping address assignments can arise when using=20 Level 2 Network Point of Attachment (NPA) addresses [ID-IPDVB- ARCH]: =20 (i) The NPA address must be unique within the addressed area.=20 IEEE MAC addresses used in Ethernet LANs are globally unique. If the NPA addresses are not globally unique,=20 the same NPA address may be re-used by receivers in=20 different addressed areas. =20 (ii) The NPA broadcast address (all 1=92s MAC address). Traffic with this address should be confined to one addressed area. = =20 (iii) Other non-IP protocols may also view sets of MAC multicast=20 addresses as link-local, and may produce unexpected results=20 if distributed across several private networks!=20 2.1 Unicast Support =20 Reception of unicast packets destined for another addressed area may lead to an increase in the rate of received packets by systems=20 connected via the network. IP end hosts normally filter received=20 unicast IP packets based on their assigned IP address.=20 Expires November 2004 [page 6] = INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 =20 Reception of the additional network traffic may contribute to Processing load but should not lead to unexpected protocol behaviour. It does however introduce a potential Denial of Service (DoS) opportunity.=20 =20 When the Receiver acts as an IP router, the receipt of such packet=20 may lead to unexpected protocol behaviour. This also provides a=20 security vulnerability since arbitrary packets may be passed to=20 the IP layer.=20 =20 2.2 Multicast Support=20 =20 There are specific issues concerning IPv4 and IPv6 multicast over MPEG-2 Transmission Networks. =20 =20 (i) Mapping IP multicast groups to the underlying MPEG-2 TS=20 Logical Channel (PID) and the MPEG-2 TS Multiplex.=20 (ii) Provide signalling information to allow a receiver to=20 locate an IP multicast flow within an MPEG-2 TS Multiplex.=20 (iii) Determining group membership (e.g. utilising IGMP/MLD). =20 =20 Appropriate procedures need to be specified to identify the=20 correct action when the same multicast group is available on=20 separate TS Logical Channels. This could arise when different end=20 hosts act as senders to contribute IP packets with the same IP=20 group destination address.=20 =20 Another different case arises when a receiver may potentially=20 receive more than one copy of the same packet. In some cases,=20 these may be sent in different TS Logical Channels, or even=20 different TS Multiplexes. In this case, at the IP level, the=20 host/router may be unaware of this duplication.=20 =20 The primary goal of multicast support will be efficient filtering=20 of IP-multicast packets by the receiver, and the mapping of IPv4=20 and IPv6 multicast addresses onto the associated PID value and TS=20 Multiplex. The design should permit a large number of active=20 multicast groups, and should minimise the processing load at the=20 receiver when filtering and forwarding IP multicast packets. For=20 example, schemes that may be easily implemented in hardware would be beneficial, since these may relieve the drivers and operating=20 systems from discarding unwanted multicast traffic.=20 =20 =20 Expires November 2004 [page 7] = INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 =20 4. MPEG-2 Address Resolution Operation=20 =20 In this section, the MPEG-2 address resolution mechanisms are=20 reviewed. In MPEG-2, the information about the set of MPEG-2 TS=20 Logical Channels carried over a TS Multiplex is usually=20 distributed via tables (service information, SI) sent using=20 channels assigned a specific (well-known) set of PIDs. This system was originally designed for audio/video distribution. The design=20 requires access to and processing of the SI table information=20 [ETSI-SI, ETSI-SI1]. This scheme is complex, and reflects the=20 complexity of delivering and co-ordinating the various TS Logical=20 Channels associated with a multimedia TV programme. Because of its historical usage, there is no direct support for IP mechanisms for=20 identification of the TS multiplex and PID in use for a particular=20 IP address. It is also important to highlight that a PID value is=20 associated with a unidirectional channel, also a result of its=20 initial usage.=20 =20 4.1 Static configuration.=20 =20 The static mapping option (IP addresses or flows statically mapped=20 to PIDs) is the equivalent to signalling "out-of-band". The=20 application programmer, installing engineer, or user receives the=20 mapping via some outside means (not in the MPEG-2 TS). This is=20 useful for testing, experimental networks, small subnetworks and=20 closed domains.=20 =20 A single "well-known" PID is a specialisation of this, but=20 requires all IP traffic to be placed into the specified TS logical=20 channel. Section filtering may be used to differentiate=20 subnetworks at the expense of added complexity and potential=20 performance penalties.=20 =20 4.2 Table-Based Address Resolution=20 =20 MPEG-2 associates multimedia MPEG information with PIDs, using MPEG-2 Tables. A TS multiplex may provide PID information for IP=20 services by integrating additional information into the existing=20 MPEG-2 tables, or to define additional tables specific to the IP=20 service. This has a dual advantage:=20 =20 (i) IP specific information can be obtained directly.=20 =20 (ii) The mechanism uses an already standardised mechanism.=20 =20 A large number of methods exist within the standards and current=20 implementations of systems for allowing a MPEG-2 receiver to=20 identify the appropriate PID and multiplex using to transmit traffic to a specific IP address.=20 Expires November 2004 [page 8]=20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks July 2004=20 =20 Examples include:=20 =20 (i) IP/MAC Notification Table (INT) in the DVB Data standard=20 [ETS_DAT]. This provides uni-directional address=20 resolution of IPv4/IPv6 multicast addresses to MPEG-2=20 TS.=20 =20 (ii) Application Information Table (AIT) in the Multimedia=20 Home Platform (MHP) specifications [ETSI-MHP].=20 =20 (iii) Multicast Mapping Table (MMT) an MPEG-2 Table employed=20 by some DVB-RCS systems to provide uni-directional=20 address resolution of IPv4 multicast addresses to MPEG-2=20 TS.=20 =20 (iv) >>> Author=92s Note: Please send details of experience=20 using the above schemes (and any others) to authors. <<<=20 =20 The MMT and AIT are used for specific applications. The INT is DVB standardised and more general purpose. It supports both IPv4=20 and IPv6 and can be used in combination with the other tables. It is the favoured choice of some members of the DVB community for=20 address management and is briefly described below.=20 =20 4.2.1 Description of the IP/MAC Notification Table (INT) and its=20 usage.=20 =20 The INT provides a mechanism for carrying information about the=20 location of IP/MAC flows within DVB networks. An IP/MAC Platform=20 represents a set of IP/MAC streams and/or receiver devices. Such a=20 Platform may span several transport streams within one or multiple=20 DVB networks and represents a single IP network with a harmonized=20 address space (i.e. one without address conflicts). The IP/MAC=20 Platform concept allows for the coexistence of several non- harmonized IP/MAC address spaces on the same DVB network.=20 =20 The INT allows "subnets" and fully specified single destination=20 addresses to make signalling bandwidth efficient and flexible as=20 required. The "subnet mask" (also for IPv6) can be given in full=20 form or in slash notation (e.g. /127), this supports IPv6 prefixes.=20 =20 Multicast addresses can be given with or without source (address or range), although if source address is given then only the slash=20 notation can be used for prefixes/subnets.=20 =20 =20 =20 Expires November 2004 [page 9] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 In addition to identification and security descriptors the=20 following descriptors are used for address binding in INT tables:=20 =20 (i) target_MAC_address_descriptor: The descriptor used to=20 describe a single or group of MAC addresses (and=20 their mask). =20 (ii) target_MAC_address_range_descriptor: May be used to=20 setup filters.=20 (iii) target_IP_address_descriptor: The descriptor=20 describing a single or group of IPv4 unicast or=20 multicast addresses (and their mask).=20 (iv) target_IP_slash_descriptor: Allows definition and=20 announcement of an IPv4 subnet.=20 (v) target_IP_source_slash_descriptor: Uses source and=20 destination addresses to target a single or group of=20 devices; could be used to define flows.=20 (vi) IP/MAC stream_location_descriptor: This descriptor=20 directly locates the IP/MAC stream in a DVB network.=20 The following descriptors provide corresponding functions for IPv6=20 addresses:=20 =20 target_IPv6_address_descriptor=20 target_IPv6_slash_descriptor=20 and target_IPv6_source_slash_descriptor=20 =20 In addition, the ISP_access_mode_descriptor allows definition if the access to the ISP is done via an alternative non-DVB network (hence another address is necessary).=20 =20 The INT provides a set of descriptors to manage addressing in a=20 DVB network. Its drawbacks are that while the IP/MAC concept is=20 general enough there is still a need to manage the addressing=20 (and the traffic) at the PID level. It currently is defined only for Multi-Protocol Encapsulation (MPE) and would need extension to=20 support other schemes. In addition the use of a centralized management prevents the implementation of a more dynamic=20 scheme.=20 =20 4.3 IP Address Resolution Protocol=20 =20 Another possible approach is to design a query/response protocol=20 (similar to, or based on the neighbour advertisements of the IPv6=20 ND protocol), which operates over an MPEG-2 TS Logical Channel=20 using a previously agreed PID (e.g. configured, or communicated using a SI table). =20 =20 Expires November 2004 [page 10]=20 =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 =20 While the Neighbour Advertisement Protocol [RFC2461] could be used=20 as a basis for such a design for IPv6 addresses, the extensive use=20 of broadcast messages to request and transmit layer 2 addresses=20 would prove inefficient for systems using a wireless physical=20 layer. =20 =20 Both ARP and ND allow unsolicited advertisements of bindings by a=20 sender that are broadcast/multicast to the network, without=20 requiring the overhead of a client request. However, both ND and=20 ARP are currently restricted to advertising a single association=20 per message. To achieve efficient transmission and receiver=20 processing over broadcast physical layer, a method needs to be=20 found that advertises several associations in a single message=20 (e.g., following the method used in MPEG-2 Tables).=20 =20 The development of IP_layer address resolution would have several=20 merits, particularly for IP-only services and two-way MPEG-2=20 transmission networks. Not only would may release a Receiver from=20 performing MPEG-2 table processing, it would also allow much more=20 dynamic association of PIDs to traffic. Examples of dynamic=20 associations include: association/freeing of PIDs in response to=20 join or prune actions taken by multicast routing protocols, or on=20 assignment of new IP addresses using DHCP/DHCPv6. Implementing=20 such protocols above the IP layer (e.g. using multicast IP=20 transport, as used by ND), would allow this protocol to be=20 implemented in a portable way not dependent on specific receiver=20 hardware/drivers and would allow future integration of the=20 functions within IP routers.=20 =20 The nature of an MPEG-2 transport network and the need to maintain=20 flexibility for the operator, means that a protocol would need to=20 use operator specifics for address resolution. Adding to this=20 complexity, 2-way MPEG-2 services (e.g. DVB-RCS) employ a pair of=20 logically separate unidirectional TS, requiring separate return and forward resolution. No address resolution protocol has yet been defined for MPEG-2 transmission networks. =20 =20 5. Conclusions and Recommendations=20 =20 In current MPEG-2 networks, the bindings between IP addresses and PIDs are usually either done statically (such as in the cable=20 networks) or carried in tables such at the standard AIT in MHP and=20 the IP Notification Tables (INT) of DVB. In addition, the DVB-RCS community has defined a Multicast Mapping Tables (MMT) to improve=20 the efficiency of multicast address mappings in DVB-RCS networks.=20 This brief document has reviewed the status of these current=20 address resolution mechanisms in MPEG-2 networks to clearly define their usage and identify what would be needed to improve their=20 conformity to standard IP practices. Expires November 2004 [page = 11] =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004 Current limitations of the current methods include the dynamics of=20 the table refresh support for IP scoping of addresses, and the lack of a universal and generic table access methodology. =20 =20 The authors recommend that standards track activity is needed in the IPDVB WG to define an IP-oriented alternative to allow link configuration of a ULE/MPE link above the IP layer. The=20 specification and definition of address resolution mechanisms=20 relating to MPEG-2 PID to/from IP address mapping function, QoS=20 association and other mapping functions (e.g. parameters=20 associated with a PID/Multiplex) could be supported using a table- based protocol to be extensible to ensure a wide applicability=20 to different types of MPEG-2 networks and intended applications. =20 It is expected to be possible to re-use existing protocol=20 machinery. For example, XML schemas could be defined and used to fetch the required information from the tables. Because XML=20 implements standard grammar and syntax this address resolution information would be common to all MPEG-2 networks. XML/SOAP=20 protocol exchanges may be a suitable method to transfer the=20 tables.=20 =20 6. Security Considerations=20 The normal security issues relating to the use of wireless links=20 for transport Internet traffic should be considered. Readers are=20 also referred to the known security issues associated with ARP=20 RFC826] and ND. Consideration will be given to those methods that will ensure that usage of MPEG-2 network resources will be restricted to IP addresses that are not a threat to those=20 resources or other resources in the Internet. =20 7. Acknowledgments=20 =20 The authors wish to thank Rod Walsh, Jun Takei, Alexander Adolf=20 and the ipdvb WG members for their inputs. The authors would also=20 like to acknowledge the support of the European Space Agency =20 Expires November 2004 [page 12] =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 =20 8. References=20 =20 8.1 Normative References [ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53C, 2004. =20 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000. =20 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC),Doc. A/91, 2001. =20 [ATSC-A92] A/92 "Delivery of IP Multicast Sessions over ATSC Data Broadcast", Advanced Television Systems Committee (ATSC),=20 Doc. A/92, 2002. =20 [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC),=20 Doc. A/54A, 2003. =20 [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems Committee (ATSC), Doc. A/65B, 2003.=20 [ETSI-DAT] EN 301 192, "Specifications for Data =20 Broadcasting", v1.3.1, European Telecommunications Standards=20 Institute (ETSI), May 2003. http://www.etsi/org/=20 =20 [ETSI-DAT1] EN 101 202, "Implementation Guide for Data", v1.2.1,=20 European Telecommunications Standards Institute (ETSI), May 2003.=20 http://www.etsi/org/ =20 [ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB);=20 Multimedia Home Platform (MHP) Specification", v1.2.1, European=20 Telecommunications Standards Institute (ETSI), June 2002.=20 http://www.etsi/org/=20 =20 [ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB);=20 Specification for Service Information (SI) in DVB systems".=20 =20 [ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB);=20 Allocation of Service Information (SI) codes for DVB systems". =20 =20 [ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,=20 Collini-Nocker, B., and H. Linder, "Architecture for IP transport=20 over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt, July 2004, Work in Progress, IPDVB WG.=20 Expires November 2004 [page 13] =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne, "Protocol Requirements for Internet Media Guides", nternet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work=20 in Progress,MMUSIC WG. =20 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic=20 coding of moving pictures and associated audio information -- Part=20 6: Extensions for DSM-CC is a full software implementation",=20 International Standards Organisation (ISO).=20 =20 [RFC826] Plummer, D. "An Ethernet Address Resolution Protocol",=20 RFC 826, IETF, November 1982.=20 [RFC1122] B. Braden, ed., "Requirements for Internet Hosts - Communication Layers", RFC 1122. =20 [RFC1112] Deering, S.E., "Host Extensions for IP Multicasting", =20 RFC1112, (STD05), IETF. August 1989.=20 =20 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor=20 Discovery for IP Version 6 (IPv6), RFC 2461, December 1998.=20 =20 [RFC2464] Crawford. M., "Transmission of IPv6 Packets over=20 Ethernet Networks", RFC2464, IETF December 1998.=20 =20 8.2 Informative References =20 [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting,=20 European Telecommunications Standards Institute (ETSI). =20 [ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV), European Telecommunications Standards Institute (ETSI). =20 [ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information technology =96=20 Generic coding of moving pictures and associated audio information: Systems", International Standards Organisation (ISO). =20 [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting,=20 European Telecommunications Standards Institute (ETSI). =20 http://www.atsc.org/standards/Code_Point_Registry.pdf Expires November 2004 [page 14] =20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004=20 =20 9. Authors' Addresses=20 =20 Godred Fairhurst=20 Department of Engineering=20 University of Aberdeen=20 Aberdeen, AB24 3UE=20 UK=20 Email: gorry@erg.abdn.ac.uk=20 Web: http://www.erg.abdn.ac.uk/users/gorry=20 =20 =20 Marie-Jose Montpetit=20 MJMontpetit.com Email: marie@mjmontpetit.com=20 10. IPR Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed=20 to pertain to the implementation or use of the technology=20 described in this document or the extent to which any license=20 under such rights might or might not be available; nor does it=20 represent that it has made any independent effort to identify any=20 such rights. Information on the procedures with respect to rights=20 in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. =20 The IETF invites any interested party to bring to its attention=20 any copyrights, patents or patent applications, or other=20 proprietary rights that may cover technology that may be required=20 to implement this standard. Please address the information to the=20 IETF at ietf-ipr@ietf.org. Expires November 2004 [page 15]=20 INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2=20 networks July 2004 =20 =20 =20 11. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTORS, THE ORGANIZATIONS THEY REPRESENT OR ARE SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY=20 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. IANA Considerations=20 =20 =20 NOT KNOWN AT THIS TIME. =20 =20 =20 Expires November 2004 [page 16]=20 =20 ------=_NextPart_000_0605_01C4698C.B53E3F70-- From owner-ipdvb@erg.abdn.ac.uk Wed Jul 14 20:00:25 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6EIx9Cp025667 for ; Wed, 14 Jul 2004 19:59:09 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6EIx9HQ025666 for ipdvb-subscribed-users; Wed, 14 Jul 2004 19:59:09 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6EIwF8k025622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jul 2004 19:58:17 +0100 (BST) Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP ; Wed, 14 Jul 2004 14:57:31 -0400 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jul 2004 14:57:31 -0400 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC409@mail.NAB.ORG> From: "Allison, Art" To: "'ipdvb@erg.abdn.ac.uk'" , internet-drafts@ietf.org Cc: Gorry Fairhurst Subject: draft-ipmulticast-ipdvb-awa-01.txt Date: Wed, 14 Jul 2004 14:57:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C469D4.69A598E0" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C469D4.69A598E0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469D4.69A598E0" ------_=_NextPart_001_01C469D4.69A598E0 Content-Type: text/plain; charset="iso-8859-1" Please find attached the draft-ipmulticast-ipdvb-awa-01.txt as an individual submission to be discussed further at the will of those participating in ipdvb WG meeting at IETF 60. Arthur W. Allison ------_=_NextPart_001_01C469D4.69A598E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Please find = attached the draft-ipmulticast-ipdvb-awa-01.txt as an individual submission to be = discussed=20 further at the will of those participating = in ipdvb WG=20 meeting at IETF 60.

Arthur W. Allison

 
 
------_=_NextPart_001_01C469D4.69A598E0-- ------_=_NextPart_000_01C469D4.69A598E0 Content-Type: text/plain; name="draft-ipmulticast-ipdvb-awa-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ipmulticast-ipdvb-awa-01.txt" Delivery of IP Multicast Sessions Using ISO/IEC 13818-1:2000 1. SCOPE This standard specifies the delivery of IP Multicast sessions, and the = delivery of data for describing the characteristics of a session for IP = Multicast. This document defines a Standard for the asynchronous transmission of = Internet Protocols (IP) specifically it is compatible with the ATSC = A/90 Data Broadcast Standard. This Standard assumes the use of Session = Description Protocol (SDP) as an integral part of the IP = Multicast-based Data Broadcast service. It is strongly suggested that = normative clauses that do not directly involve SDP be retained in the = case of IP Multicast-based Data Broadcast services that do not include = any SDP data, such as would be used for non-session-based IP Multicast. This document focuses solely on the carriage of all information using = the DSMCC_addressable_section. Synchronous and synchronized carriage of = IP Multicast datagrams are not addressed by this document. 1.1. Organization Entire normative sections of this document are identified as such with = the parenthetical "(Normative)". Other sections may contain normative = clauses that are identified by use of the preamble "Normative Clause" = and by distinctive formatting of the normative clause. All remaining = text is provided for informational purposes only. The document is organized as follows: Section 1-Provides this general introduction. Section 2-Lists references and applicable documents. Section 3-Provides a definition of terms, acronyms, abbreviations, = syntax formats, and code points for this document. Section 4-Specifies the IP Network model in an ATSC Transport Stream. Section 5-Specifies the rules for mapping IP Multicast sessions to ATSC = Virtual Channels. Section 6-Specifies usage of the Session Description Protocol. Section 7-Specifies the encapsulation for IP Multicast datagrams. Section 8-Specifies the schedule announcement of an IP Multicast data = service. Section 9-Specifies the receiver discovery and binding mechanisms for = an IP Multicast service. Section 10-Illustrates the application buffer model of an IP Multicast = service. Section 11-Describes options for the scrambling of IP Multicast = streams. Section 12-Provides an overview for how an IP Multicast service may be = acquired. Section 13-Describes the use of the Network Resources Table. Section 14-Describes the IP Multicast application buffer model. Section 15-Provides the syntax and semantics of the = MAC_Address_List_descriptor. 2. REFERENCES 2.1 Normative References (Normative) The following documents are normative for this Standard: 1) ATSC A/90, "ATSC Data Broadcast Standard," July 26, 2000. 2) ATSC A/65A, "Program and System Information Protocol for Terrestrial = Broadcast and Cable," May 31, 2000. 3) IETF RFC 2327, "SDP: Session Description Protocol," April 1998. 4) IETF RFC 1112, "Host Extensions for IP Multicasting," August 1989. 5) IETF RFC 1700, "Assigned Numbers," October 1994. 6) IETF RFC 2974, "Session Announcement Protocol," October 2000. 2.2 Informative References The following documents are informative for this Standard: 7) ATSC A/70, "Conditional Access System for Terrestrial Broadcast and = Amendment No. 1," July 17, 1999. 8) SMPTE 357M, "Declarative Data Essence, IP Multicast Encapsulation." 9) IETF RFC 2365, "Administratively Scoped IP Multicast," July 1998. 10) ISO/IEC 13818-6:1998/Amd.1:2000(E) - "Additions to support data = broadcasting." 11) SCTE DVS 311r6, "IP Multicast for Digital MPEG Networks," March = 2002. 3. DEFINITIONS AND STRUCTURES (NORMATIVE) 3.1 Compliance Notation As used in this document, "shall" denotes a mandatory provision of the = standard. "Should" denotes a provision that is recommended but not = mandatory. "May" denotes a feature whose presence does not preclude = compliance, that may or may not be present at the option of the = implementer. All sections of this document are informative, unless otherwise = specifically indicated with the heading "Normative Clause" or which = contain the word "Normative" in parenthesis in the section title. 3.2 Acronyms and Abbreviations The following acronyms and abbreviations are used within this = specification: ATSC Advanced Television Systems Committee bslbf bit serial, leftmost bit first CRC cyclic redundancy check DDE declarative data essence DEB data program element buffer DET data event table DSM-CC digital storage media command and control DST data service table EIT event information table ETM extended text message ETT extended text table FRAGnkj IP fragmentation buffer for fragment identifier j, multicast = address k, in program element n. IETF Internet Engineering Task Force IP Internet Protocol IPM IP Multicast IPGRMBnk IP datagram buffer for kth IP Multicast address in the nth = program element ITU International Telecommunication Union MAC media access control MPE multi-protocol encapsulation MPEG Moving Picture Experts Group MTU maximum transmission unit MS media stream NRT network resources table NTP network time protocol PAT program association table PDU protocol data unit PES packetized elementary stream PID packet identifier PMT program map table PSIP program and system information protocol RFC request for comments SAP session announcement protocol SBn smoothing buffer for the nth program element SCTE Society of Cable Telecommunications Engineers SDP session description protocol SDF service description framework SLD service location descriptor SMPTE Society of Motion Picture and Television Engineers TBn transport buffer for the nth program element TS transport stream TTL time to live uimsbf unsigned integer, most significant bit first nbomsbf network byte order, most significant bit first UDP user datagram protocol UDPnkji UDP buffer for port i, fragment identifier j, IP multicast = address k, in program element n. VCT virtual channel table 3.3 Global Terms The following terms are used throughout this document: ATSC Advanced Television Systems Committee. The committee responsible = for the coordination and development of voluntary technical standards = for advanced television systems. bit rate The rate at which the compressed bit stream is delivered from = the channel to the input of a decoder. bps bits per second. byte-aligned A bit in a coded bit stream is byte-aligned if its = position is a multiple of 8-bits from the first bit in the stream. CRC The cyclic redundancy check used to verify the correctness of the = data. data element A self-contained subset of a data Program Element. data receiver Any device capable of receiving and consuming data = carried on an MPEG-2 transport stream. data service A collection of scheduled applications and associated data = Program Elements as signaled in one Data Services Table. A data service = is characterized by a profile and level. datagram A datagram is the fundamental protocol data unit in a = packet-oriented data delivery protocol. Typically, a datagram is = divided into header and data areas, where the header contains full = addressing information (source and destination IP addresses) with each = data unit. Datagrams are most often associated with connectionless = network and transport layer services. data source The provider of data that is being inserted into the MPEG-2 = transport stream. decoded stream The decoded reconstruction of a compressed bit stream. decoder An embodiment of a decoding process. decoding (process) The process defined in the Digital Television = Standard that reads an input coded bit stream and outputs decoded = pictures, audio samples, or data objects. elementary stream (ES) A generic term for one of the coded video or = coded audio bit streams. One elementary stream is carried in a sequence = of PES packets with one and only one stream_id. encoding (process) A process that reads a stream of input pictures or = audio samples and produces a valid coded bit stream as defined in the = Digital Television Standard. event A collection of elementary streams with a common time base, an = associated start time, and an associated end time. An event is = equivalent to the common industry usage of "TV program." forbidden This term, when used in clauses defining the coded bit = stream, indicates that the value shall never be used. This is usually = to avoid emulation of start codes. IP multicast application buffer The buffer following the Smoothing = Buffer of an MPEG-2 Program Element of stream_type 0x0D as defined in = [1]. The purpose of this buffer is to collect only the IP Multicast = data bytes out of the Smoothing Buffer and to re-assemble them into = complete datagrams. IP multicast data stream A collection of IP packets with the same IP = Multicast address and port number. IPM program element An MPEG-2 Program Element of stream_type 0x0D that = carries IP Multicast datagrams in DSM-CC addressable sections. IP multicast service The portion of an A/90 Data Broadcast service = comprising the IP Multicast sessions and their announcements and = descriptions. IP multicast virtual channel An ATSC virtual channel including an IP = Multicast service. The virtual channel may include other video and = audio elementary streams. kbps 1,000 bits per second. maximum transmission unit The largest amount of data that can be = transferred in a single unit across a specific physical connection. = When using the Internet Protocol, this translates to the largest IP = datagram size allowed. Mbps 1,000,000 bits per second. MPEG Refers to standards developed by the ISO/IEC JTC1/SC29 WG11, = Moving Picture Experts Group. MPEG may also refer to the Group. MPEG-2 Refers to the collection of ISO/IEC standards 13818-1 through = 13818-6. multiplexor (mux) A physical device that is capable of inserting MPEG-2 = transport stream packets into and extracting MPEG-2 transport stream = packets from an MPEG-2 transport stream. multiprotocol encapsulation The encapsulation or splitting of datagrams = in addressable sections. packet A packet is a set of contiguous bytes consisting of a header = followed by its payload. packet identifier (PID) A unique integer value used to associate = Program Elements of a program in a single or multi-program transport = stream. payload Payload refers to the bytes following the header byte in a = packet. program A collection of Program Elements. Program Elements may be = elementary streams. Program Elements need not have any defined time = base; those that do have a common time base and are intended for = synchronized presentation. The term program is also used in the context = of a "television program" such as a scheduled daily news broadcast. In = this specification the term "event" is used for the latter to avoid = ambiguity. program element A generic term for one of the elementary streams or = other data streams that may be included in an ISO/IEC 13818-1 (MPEG-2) = Program. The MPEG-2 Transport Stream packets conveying a Program = Element are referenced by a unique PID value in the MPEG-2 Program. program specific information (PSI) PSI consists of normative data which = is necessary for the demultiplexing of transport streams and the = successful regeneration of programs. profile A defined subset of data delivery characteristics. This differs = from the definition provided in ISO/IEC 13818-2. PSIP Program and System Information Protocol is a collection of tables = describing virtual channel attributes, event features, and other = information [2]. reserved This term, when used in clauses defining the coded bit stream, = indicates that the field may be used in the future for Digital = Television Standard extensions. All reserved bits shall be set to "1". SDP announcement stream A collection of Session Description Protocol = datagrams transmitted on a given IP Multicast address and pertaining to = the same sessionID. SDP stream The collection of one or more SDP announcement streams. section A data structure comprising a portion of an ISO/IEC 13818-1 or = ISO/IEC 13818-6-defined table, such as the Program Association Table = (PAT), Conditional Access Table (CAT), Program Map Table (PMT), or = DSMCC section. All sections begin with the table_id and end with the = CRC_32 field, and their starting points within a packet payload are = indicated by the pointer_field mechanism defined in the ISO/IEC 13818-1 = International Standard. service description framework The information conveyed in the Program = Element and providing the Data Service Table and optionally the Network = Resource Table of a single data service. session A collection of IP Multicast data streams bound by a common = announcement and description. Announcement and description protocols = are defined in IETF RFC 2974 and IETF RFC 2327 respectively. session announcement This term is defined explicitly in RFC2327 and = reproduced here for convenience. A session announcement is a mechanism = by which a session description is conveyed to users in a proactive = fashion, i.e., the session description was not explicitly requested by = the user. session description Information used to announce and discover a = session, which may include session identification, session version, = name, start and end times, and other information. stream An ordered series of bytes. The usual context for the term = stream is the series of bytes extracted from Transport Stream packet = payloads which have a common unique PID value (e.g., video PES packets = or Program Map Table sections). stream data A stream is a data object which has no specific start or = end. The decoding system may need only a small fraction of the total = data to activate a given application. An example includes stock ticker = services. table The collection of re-assembled sections bearing a common version = number. table instance Tables are identified by the table_id field. However, in = cases such as the Data Information Table, several instances of a table = are defined simultaneously. All instances have the same PID and = table_id but different table_id_extension. transport stream Refers to the MPEG-2 Transport Stream syntax for the = packetization and multiplexing of video, audio, and data signals for = digital broadcast systems. transport stream packet header The leading fields in a Transport Stream = packet up to and including the continuity_counter field. virtual channel A virtual channel is the designation, usually a number, = that is recognized by the user as the single entity that will provide = access to an analog TV program or a set of one or more digital = elementary streams. It is called "virtual" because its identification = (name and number) may be defined independently from its physical = location. 3.4 Section and Data Structure Syntax Notation Tables defined in this standard conform to the generic private section = syntax defined in ISO/IEC 13818-1 (MPEG-2 Systems) and the DSM-CC = Addressable section format defined in [10]. This document contains = symbolic references to syntactic elements. The notation used is = distinctive to aid the reader in recognizing elements that are the same = as they are in referenced standards. These references are = typographically distinguished by the use of a different font (e.g., = restricted), may contain the underscore character (e.g., = sequence_end_code) and may consist of character strings that are not = English words (e.g., dynrng or thisIsString). reserved-Fields in this Standard marked "reserved" shall not be = assigned by the user, but shall be available for future use. Decoders = are expected to disregard reserved fields for which no definition = exists. Each bit in the fields marked "reserved" shall be set to one = until such time as they are defined and supported. user_private-Indicates that the field is not defined within the scope = of this Standard. The owner of the field, and hence the entity defining = its meaning, is derived via its context within a message. zero-Indicates that the bit or bit field shall have the value zero. 4. MPEG TRANSPORT IP NETWORK MODEL The purpose of this section is to define a model whereby standard IP = network terminology and concepts can be applied to transmission of IP = Multicast services in an ATSC Transport Stream. When creating, = inserting, and transporting IP packets through an ATSC Transport = Stream, rules need to be established to define what constitutes a = network or sub-network. This is critical for all implementations, as = there is the strong potential for IP address conflicts without such = rules. 4.1 Mapping of an IP Network Normative Clause In an ATSC Transport Stream, the collection of Program Elements = referenced in a single ATSC A/90 Application shall be considered as a = distinct IP Network. More specifically, when making routing policies = and IP address scoping policies, it is the collection of Taps in an = ATSC A/90 Application that shall be viewed as the Network. Consequently, in a given ATSC A/90 Application, a receiver can safely = assume that there is no collision among the IP Multicast addresses = encountered in the IP datagram headers. Since an ATSC A/90 Application may reference one or multiple MPEG-2 = Program Elements of stream_type 0x0D, the mapping of an IP Network onto = an ATSC A/90 Application may be done such that the streams of an IP = Multicast service may all be conveyed in either a single or multiple = Program Elements. In one extreme case, the entire IP Multicast service = is conveyed in one Program Element, and this single Program Element = alone makes up the IP Network. In another extreme case, the IP = Multicast service is divided up among multiple Program Elements that = are all part of the same ATSC A/90 Application, and then this = collection of Program Elements makes up the IP Network. 4.2 Mapping of Sessions The purpose of this section is to document various cases that may be = encountered when an ATSC Virtual Channel includes one or more IP = Multicast sessions. For the sake of simplicity, the documented examples = involve two distinct IP Multicast sessions only. The concepts = documented in this section can be quickly generalized to cases = involving more sessions and more media streams. Normative Clause An IP Multicast session shall be announced by means of the Session = Description Protocol (SDP) [3)]. The Session Announcement Protocol = (SAP) [6] shall be used to encapsulate the SDP protocol in UDP = datagrams. 4.2.1 Notations=20 The following notation is used to reference particular IP Multicast = streams. The terms defined here refer to two distinct sessions, Session = 1 and Session 2. Each session is assumed to have a distinct sessionID = field value in the typical case, but there are some circumstances where = this may not be true. Furthermore, the term "IP Multicast address" = refers to the Internet Protocol address and port as specified in the = destination address field of the IP packet header and UDP datagram = header respectively. SDP1 and SDP2: Session Description Protocol streams of session 1 and 2, = respectively. The IP Multicast address for SDP1 and SDP2 may be = identical, but the sessionID field values are not. MS11 and MS12: IP Multicast Media stream 1 and IP Multicast Media = stream 2 for session 1. MS21 and MS22: IP Multicast Media stream 1 and IP Multicast Media = stream 2 for session 2. PID1 through PID6: PID values associated to six different Program = Elements of stream_type 0x0D. 4.2.2 Mapping Scenarios=20 The following 8 scenarios are examples of various strategies that may = be adopted for transmitting an IP Multicast service in an ATSC Virtual = Channel. Each scenario documents how two distinct SDP sessions can be = conveyed in an ATSC virtual channel. Each scenario utilizes a certain = number of MPEG-2 Program Elements. Selection of one scenario over = another may be driven by the need to improve session discovery, by = latency considerations, bandwidth allocation, insertion point in the = distribution, or by other implementation factors. Case 1 PID1 conveys SDP1 MS11 MS12 SDP2 MS21 MS22 In this case, one Program Element conveys all the IP Multicast = datagrams. By design, the Program Element referenced by PID1 is part of = a single ATSC A/90 Application and the IP Network is confined to a = single Program Element. Case 2 PID1 conveys SDP1 MS11 MS12 PID2 conveys SDP2 MS21 MS22 In this case, each IP Multicast session is conveyed in a distinct = Program Element. The sessions may be part of the same ATSC A/90 Applicat= ion or they may each belong to a separate ATSC A/90 Application. In the = latter scenario, each Program Element represents a distinct IP Network. Case 3 PID1 conveys SDP1 PID2 conveys MS11 MS12 PID3 conveys SDP2 PID4 conveys MS21 MS22 In this case, Program Elements referenced by PID1 and PID2 carry = datagrams of the same IP Multicast session and therefore they need to = belong to the same ATSC A/90 Application. For the same reason PID3 and = PID4 must belong to the same application. With these constraints, the = two alternatives for encapsulation include: 1) setting up a single = application with both sessions included, or 2) setting up two separate = applications one for each session. Depending on the selected = alternative, the result will be either one or two IP networks = respectively. Case 4 PID1 conveys SDP1 SDP2 PID2 conveys MS11 MS12 PID3 conveys MS21 MS22 In this case, one Program Element (referenced by PID1) conveys the = datagrams of all the IP Multicast announcement streams. By design, the = Program Element PID1 and the Program Elements PID2 and PID3 must belong = to a single ATSC A/90 Application. Case 5 PID1 conveys SDP1 SDP2 PID2 conveys MS11 MS12 MS21 MS22 In this case, one Program Element conveys the datagrams of all the IP = Multicast announcement streams. The other Program Element conveys the = datagrams of all the IP Multicast Media streams. By design, the Program = Element PID1 and the Program Elements PID2 must belong to a single ATSC = A/90 Application, thus resulting in a single IP network where no IP = address collisions exist. Case 6 PID1 conveys SDP1 PID2 conveys MS11 PID3 conveys MS12 PID4 conveys SDP2 PID5 conveys MS21 PID6 conveys MS22 Program Elements referenced by PID1, PID2 and PID3 must belong to the = same ATSC A/90 Application, and similarly for PID4, PID5, and PID6. Two = implementation alternatives exist in this case. Either the two sessions = are included in only one application, or two separate ATSC A/90 = applications are used. Depending on the selected alternative, the = result will be one or two IP networks respectively. Case 7 PID1 conveys SDP1 SDP2 PID2 conveys MS11 PID3 conveys MS12 PID4 conveys MS21 PID5 conveys MS22 In this case, one Program Element conveys the datagrams of all the IP = Multicast announcement streams. By design, the Program Element = referenced by PID1 and the Program Elements referenced by PID2, PID3, = PID4, and PID5 must belong to a single ATSC A/90 Application. Case 8 PID1 conveys SDP1 PID2 conveys SDP2 PID3 conveys MS11 MS12 MS21 MS22 In this case, the IP Multicast session description streams are conveyed = in distinct Program Elements and the IP Multicast Media streams = pertaining to all sessions are conveyed in the same Program Element. In = this case both sessions must belong to the same ATSC A/90 Application, = thus resulting in a single IP network where IP address collisions do = not exist. 4.2.3 Identification of the Broadcast IP Network in Data Receivers Normative Clause The value of the DST app_id_length field shall be 2 or greater. The = meaning of the DST app_id_description field shall be as specified in = ATSC A/90 [1)], and the value shall be set to 0x0002. The = app_id_description and app_id_bytes fields shall uniquely identify the = ATSC A/90 Application globally in space and time. When = app_id_description is set to 0x0002, the app_id_bytes shall be set to = the binary representation of the NTP time stamp as recommended in [3] = for sessionID. As a result, receivers can use the app_id_description and app_id_bytes = fields of an ATSC A/90 Application to identify uniquely the IP network = associated with this application. More specifically, a receiver may use = these fields to assign and manage the local IP address of the Broadcast = Network Interface (single network adaptor) that gets associated with = each ATSC A/90 Application. Multiple applications define multiple = networks resulting in a multi-home scenario. Note that the app_id_byte field may be set to the value of the = sessionId field used in an IP Multicast Service SDP record. 5. MAPPING OF IP MULTICAST SESSIONS TO PROGRAM ELEMENTS AND VIRTUAL = CHANNELS Mapping of one or multiple IP Multicast sessions onto an ATSC Transport = Stream needs to take several factors into consideration. The first consideration is the mapping of the IP Multicast sessions to = one or multiple ATSC A/90 Applications. Different criteria are listed = to guide content providers in identifying the best method. The second = consideration deals with the announcement of the IP Multicast session = announcement. This consideration allows content providers to decide = whether one or multiple ATSC Virtual Channels should be used. 5.1 Mapping to ATSC A/90 Applications 5.1.1 Multiple Sessions in the Same Application The insertion of multiple sessions in the same application (at either = one or multiple entry points in the distribution chain) requires = careful management to avoid IP address collisions if these sessions = overlap in time. The management functions may be performed through = cooperative authoring or instead, they may be applied in real time = using IP address re-mapping. The IP Multicast specifications for cable require having one IP network = per virtual channel [11]. Consequently, if compatibility becomes a = desired design premise, then all sessions can be embedded in a single = application. Moreover, this application can be the only IP Multicast = application in the MPEG-2 Program. In one extreme case, all sessions may be embedded in a single Program = Element as a method to reduce the number of PID filters required in a = receiver. In the other extreme case, every session announcement (SDP) = and every media stream are conveyed over separate Program Elements. The = advantage of the latter is that once the required session is = discovered, selective retrieval of media streams may be performed by = direct PID filtering. Receivers that detect IP Multicast streams may have to parse the = associated streams in search of all possible SDP announcements. Notice = that the signaling in the DST may not give enough information on how = many sessions are running concurrently. Receivers that know a-priori = the IP address of the particular multicast sessions of interest will = use the MAC Address List descriptor and the Tap selector structures in = the DST to pinpoint the collection of PID values to use for the PID = filters. 5.1.2 Multiple Insertion Points When sessions are inserted in multiple entry points of the distribution = chain, IP address management may become a burden. In such a case, the = inserted IP Multicast sessions may be mapped to different applications = in the same virtual channel. Cases 2, 3, and 6, described in the = previous section, are typical examples of this behavior. 5.1.3 Conditional Access Granularity The ATSC Conditional Access standard [7] describes a method to scramble = one or more Program Elements in an MPEG-2 Program. Scrambling is = performed at the Transport level, which essentially means that the = payload of the 188-byte length packets gets encrypted. If there are = several IP Multicast sessions sharing one Program Element (defined by = one PID value), then all the sessions will be scrambled if A/70 is = used. For DSM-CC Addressable Sections, ATSC A/90 offers Section-level = scrambling, however, the use of this function has not been = standardized. More details on Section-level scrambling are described in = Section 11 of this document. Transport-level scrambling can be used in conjunction with the = appropriate application design to enable authors to perform selective = scrambling of sessions and/or data components. For instance, if one = were to implement the example defined as Case 4 (see previous section), = then it would be possible to scramble the content of session 2 = independently of session 1. Case 6 is the case where each IP Multicast = stream of a session is carried in a single Program Element and = therefore each IP Multicast media stream may be encrypted = independently. Case 8 provides the opportunity for applying conditional = access collectively to the IP Multicast media streams while leaving all = session description datagrams in the clear (non-encrypted). 5.2 Mapping to ATSC Virtual Channels 5.2.1 Multiple Sessions in the Same Virtual Channel Cases 2, 3, or 6 allow use of one or multiple ATSC A/90 Applications in = the Virtual Channel containing the IP Multicast service. The fact that = such IP Multicast sessions reside in the same ATSC A/90 Application = means that they have been authored so their IP Multicast addresses do = not conflict. However, possibility for multiple insertion points may be = a driving consideration to use several ATSC A/90 Applications in the = same virtual channel. In both cases, the IP Multicast sessions and = their instances are selected based on an application-level selection = mechanism that uses the information provided in the SDP datagrams. Due = to limitations in current receivers, it may be desirable to limit only = one A/90 application per Virtual Channel if it is desired to run = multiple IP Multicast sessions in the receiver. 5.2.2 Multiple Sessions and Multiple Virtual Channels When it is desired to provide a distinct announcement in the EIT or DET = of the schedule for each IP Multicast session, or when it is desired to = allow a PSIP-based selection of an IP Multicast session, the ATSC A/90 = Application referencing the Program Elements carrying the IP Multicast = session stream can belong to a distinct PSIP Virtual Channel. In this = situation, whether Case 2, 3, or 6 is used, the Program Elements = conveying the IP Multicast session stream belongs not only to a = distinct ATSC A/90 Application but also to a distinct ATSC Virtual = Channel. The previous sections described recommendations and suggestions to = consider when mapping IP Multicast sessions into one or more = applications. However, when multiple applications exist concurrently, = it becomes possible to insert some of them in a different virtual = channel. Applications need to be inserted in a different virtual = channel mainly for two reasons: compatibility with cable [11], and the = need to separately announce or signal applications in PSIP [2)]. 6. SDP USAGE CONSIDERATIONS Normative Clause The creation of the sessionID field values shall be such that the = values are guaranteed at least not to collide with the sessionID field = values of other sessions belonging to the same ATSC A/90 Application. In order for authoring tools to ensure uniqueness of the sessionID = values, they should be created as recommended in the SDP specification = and use a hexadecimal representation of NTP time. Normative Clause The sum of the leak rates specified in all the SDP Session Descriptions = (as specified by the b=3DCT:number entry) of a Data Service shall not = exceed the leak rate specified by the sb_leak parameter associated with = the data_service_profile field in the data_service_descriptor or by the = sb_leak_rate field in the smoothing_buffer_descriptor associated with = the ATSC Virtual Channel or the sum of the sb_leak_rate field(s) in the = smoothing_buffer_descriptor(s) of the MPEG-2 Program Element(s) = carrying the IP datagrams of the session. The bandwidth signaling shall = be consistent between the SDP records, the A/90 descriptors, and the = MPEG-2 descriptors. 7. DATAGRAM ENCAPSULATION=20 7.1 Introduction IP Multicast datagrams are UDP/IP datagrams for which the IP = destination address is in the range 224.0.0.0 to 239.255.255 as defined = in [9]. Each datagram is encapsulated in DSMCC_Addressable_section = structures as defined by [10]. 7.2 Protocol Encapsulation Normative Clause Individual IP Multicast datagrams shall be conveyed by means of ATSC = A/90 DSMCC_addressable_section structures. The corresponding ATSC A/90 = protocol_encapsulation field value in the ATSC A/90 Data Service Table = (DST) shall be set to 0x04. All DSMCC_addressable_section structures = conveying the IP Multicast datagrams of an IP Multicast service shall = be transmitted in one or more MPEG-2 Program Elements. The stream_type = value associated with these Program Elements shall be equal to 0x0D. 7.3 DSM-CC Addressable sections Normative Clause When a DSM-CC Addressable section conveys an IP Multicast datagram with = unscrambled deviceId fields, the deviceId[47...40], deviceId[39...32], = and deviceId[31...24] fields shall be equal to 0x01, 0x00, and 0x5E, = respectively as specified in [4]. Furthermore, the deviceId[23] bit = shall always be set to '0' as specified in [10]. The LLCSNAP_flag field = shall be set to '0' and the maximum transmission unit (MTU) of the IP = datagrams shall be 4080 bytes.=20 7.4 Format of Device Identifier Fields The format of the deviceId fields in the DSMCC_Addressable_section = structures referenced by a Tap may be specified by the insertion of a = multiprotocol_encapsulation_descriptor in the descriptor loop of that = Tap. Normative Clause When the descriptor loop of an ATSC A/90 Tap referencing an MPEG-2 = Program Element of protocol_encapsulation value 0x04 does not include a = multiprotocol_encapsulation_descriptor structure, the default = deviceId_address_range field value shall be 0x06 meaning that all 48 = bits are valid. The default deviceId_IP_mapping_flag value shall be = equal to '1' to indicate an IP to MAC address mapping according to RFC = 1112 [4]. The default max_sections_per_datagram field value shall be = equal to 0x01. When a descriptor loop of an ATSC A/90 Tap referencing an MPEG-2 = Program Element of protocol_encapsulation value 0x04 does not include a = multiprotocol_encapsulation_descriptor structure, the value of the = deviceId_IP_mapping_flag field shall always be equal to '1' to indicate = an IP to MAC address mapping according to RFC1112 [4]. The value of the = max_sections_per_datagram field shall always be equal to 0x01. The deviceId and MAC Address are interchangeable terms. 8. SERVICE ANNOUNCEMENT AND SCHEDULE 8.1 Introduction=20 A stand-alone IP Multicast service is a data service not related to any = audio-visual event. The IP Multicast service may include one or several = IP Multicast sessions. If the service includes multiple sessions, one = or several ATSC A/90 Applications may be used to signal the sessions. = The schedule of a standalone IP Multicast service is announced by means = of instances of ATSC Data Event Tables (DET-k's). In this case, the = value of the service_type field associated with the Virtual Channel in = the PSIP Virtual Channel Table (VCT) is equal to 0x04. The one or more = data Program Elements conveying the stand-alone IP Multicast service = belong to a single and distinct ATSC Virtual Channel. Consequently, the = PSIP Service Location Descriptor associated with the stand-alone IP = Multicast service virtual channel does not include any Program Element = of type 0x02 (MPEG-2 video) or 0x81 (AC-3 audio). The schedule of a single IP Multicast service related to one or several = audio-visual events is announced by means of instances of ATSC Event = Information Tables (EIT-k's) or Data Event Tables (DET-k's). Scenarios = for using DET-k tables versus EIT-k tables are documented in the ATSC = A/90 specification. The IP Multicast service may include one or several = IP Multicast sessions. If the service includes multiple sessions, one = or several ATSC A/90 Applications may be used to signal the sessions. = The value of the service_type field associated with the Virtual Channel = in the PSIP Virtual Channel Table is equal to 0x02 if the Virtual = Channel includes a video elementary stream of stream_type 0x02. It is = equal to 0x03 if the Virtual Channel includes an audio elementary = stream of stream_type 0x81 but no video elementary stream of = stream_type 0x02. The one or more data Program Element(s) of an IP = Multicast service belong to the same virtual channel as the video = and/or audio elementary streams. In both cases, the IPM Program Elements are listed in the Service = Location Descriptor associated in the VCT with the ATSC Virtual Channel = to which the IP Multicast service belongs. The ATSC Virtual Channel = also includes one and only one MPEG-2 Program Element of stream_type = 0x95 which is used to convey Service Description Framework information = as specified in ATSC A/90 and further enhanced with the constraints and = rules specified herein. The announcement of the schedule of any IP Multicast service complies = with the ATSC A/65A specification. The schedule of any IP Multicast = service is published by means of Event Information Tables (EIT-k's) or = Data Event Tables (DET-k's). In the case of IP Multicast services related to one or multiple = audio-visual events (service_type 0x02 or 0x03 as appropriate), the = schedule (start time, duration) of the IP Multicast sessions may or may = not coincide with the schedule of the associated audio-visual event. 8.2 Data Event Table (DET)=20 DET-k's are used for announcing the event schedule of a stand-alone IP = Multicast service in an ATSC Virtual Channel. As specified in the ATSC = A/90 specification, DET-k's may also be used for announcing an event of = an IP Multicast service provided in an ATSC Virtual Channel that also = includes a video and/or audio event. In the latter case, both an EIT = and DET are used, the EIT to announce the video and/or audio event(s), = and the DET to announce the IP Multicast event(s). 8.3 Data Service Descriptor=20 As required by the ATSC A/90 specification, the descriptor loop = associated with the IP Multicast service event in a DET-k or an EIT-k = includes a data_service_descriptor structure. The value of the = data_service_profile field in this descriptor is set to indicate the = proper upper bandwidth bound used for the delivery of the IP Multicast = service. Normative Clause: The value of the data_service_level field shall be set to 0x00 to = indicate that the IP Multicast service is an asynchronous service. 8.4 PID Count Descriptor The descriptor loop associated with the IP Multicast data broadcast = event listed in a DET-k or an EIT-k may include a PID_count_descriptor = structure [1]. The value of the total_number_of_PIDs field accounts for = all the IPM Program Elements in the virtual channel. When the IP = Multicast media stream(s) and the SDP datagram stream(s) are conveyed = in the same MPEG-2 Program Element, the value of the min_number_of_PIDs = field is equal to 0x02 to indicate that a meaningful rendition of the = IP Multicast service can be obtained from only one data Program Element = and the Program Element conveying the Data Service Table. When the IP = Multicast media stream(s) and the SDP datagram stream(s) are conveyed = in distinct MPEG-2 Program Elements, the value of min_number_of_PIDs = field is equal to 0x03 to indicate that a meaningful rendition of the = IP Multicast service can be obtained from two data Program Elements = (one conveying the SDP datagrams and the other the media datagrams) and = the Program Element conveying the Data Service Table. 9. SIGNALING FOR DISCOVERY AND BINDING OF AN IP MULTICAST SERVICE 9.1 Introduction=20 This specification defines a variety of ways for signaling an IP = Multicast service within the Service Description Framework defined by = the ATSC A/90 Specification. In this section, detailed usage = recommendations are provided for each scenario. More specifically, the = scenarios that are discussed are the following: 1) A single IP Multicast session on a single ATSC Virtual Channel 2) Multiple IP Multicast sessions on a single ATSC Virtual Channel 3) Multiple IP Multicast sessions on multiple ATSC Virtual Channels Signaling information is used by the IP Multicast receiver to discover = the IP Multicast service and to bind the various IP Multicast media and = SDP announcement streams to particular MPEG-2 Program Elements. An = additional structure that may be used in the ATSC A/90 Data Service = Table is the MAC_Address_List_descriptor. This descriptor is discussed = in the following section. 9.2 THE MAC Address List Descriptor 9.2.1 Definition The MAC_Address_List_descriptor structure is defined in Section 18. = This descriptor was originally defined by SCTE [11]. The = MAC_Address_List_Descriptor may be used in the Data Service Table to = list the MAC Layer Multicast addresses used in the ATSC Virtual = Channel. 9.2.2 Use of this Descriptor in the Data Service Table (DST) Normative Clause The use of the MAC Address List descriptor is optional in the DST of a = Virtual Channel conveying an IP Multicast service. The = MAC_Address_List_descriptor may be located in the descriptor loop of a = Tap referencing a Program Element of stream_type 0x0D and conveying IP = Multicast datagrams encapsulated in DSMCC_Addressable_section = structures. If the descriptor is used, both the value of the pdu_size = field and the encapsulation_type field of the = MAC_Address_List_descriptor structure shall always be equal to '11'. The purpose of the MAC_Address_List_descriptor is to list MAC layer = Multicast addresses present in a given MPEG-2 Program Element. A data = receiver may elect to use the information provided by this descriptor = to identify the Program Elements that need to be latched and acquired. = The information provided in the descriptor is especially helpful if the = IP Multicast service includes multiple sessions in the same A/90 = Application or in the same Virtual Channel. Normative Clause In the case of an ATSC A/90 Application including an IP Multicast = service, and if the MAC_Address_List_descriptor is used in this ATSC = A/90 Application, the union set of all the MAC_Address_List_descriptor = structures pertaining to an ATSC A/90 Application shall provide an = exhaustive list of all the MAC layer Multicast addresses present in the = IP Multicast service. 9.3 Single IP Multicast Service in a Single Virtual Channel 9.3.1 Case of a Single IPM Program Element In this scenario, an IP Multicast service consists of a unique IP = Multicast session and both the SDP datagram stream and the IP Multicast = media streams are conveyed in one data Program Element. The ATSC A/90 = Application listing this IP Multicast service includes one Tap for = referencing the MPEG-2 Program Element conveying the IP Multicast = datagrams. The referencing mechanism is done according to the ATSC A/90 = specification. Consequently, an association_tag_descriptor structure is = inserted in the ES_info loop of the PMT associated with the ATSC = Virtual Channel where the IP Multicast service is delivered. It may happen that the IPM Program Element is not part of the MPEG-2 = Program, or it is not part of the same MPEG-2 Transport Stream = associated with the ATSC Virtual Channel where the IP Multicast service = is provided. In both cases, the DSM-CC deferredMPEGProgramElement = resource descriptor is included in the ATSC A/90 Network Resource Table = to allow unambiguous identification of the location of the IPM Program = Element in the external MPEG-2 Program or MPEG-2 Transport Stream. 9.3.2 Case of Multiple IPM Program Elements In this scenario, multiple data Program Elements are used to convey the = SDP stream and the IP Multicast media streams. Per ATSC A/90 [1)], at = least one Tap is associated with each Program Element conveying the = datagrams of the IP Multicast session. 9.3.3 Taps and Application All Taps are listed in the Data Service Table as belonging to a single = data application. When multiple Program Elements are used to carry the = IP Multicast session, it is possible to assign distinct leak rates and = maximum bit rates to each Program Element as described in the ATSC A/90 = specification. 9.4 Multiple IP Multicast Sessions on a Single Virtual Channel It is possible to have multiple IP Multicast sessions bound to the same = Virtual Channel within the same ATSC Transport Stream. This is = applicable whether the IP Multicast service is a stand-alone service or = a service related to an audio-visual event. In this case, each = individual media stream (the IP datagrams conveying the media datagrams = of one SDP session) may be conveyed in a distinct set of MPEG-2 Program = Elements. It is possible that an author may create multiple session instances = within a single IP Multicast session, for example to provide multiple = language options. These multiple sessions would be announced in the = standard SDP fields. As in the previous case, there is at least one Tap = associated with each MPEG-2 Program Element conveying datagrams of the = IP Multicast service. The IP Multicast sessions may be conveyed in a single or in multiple = A/90 Applications. 9.4.1 Single Application It may be desirable to group all IP Multicast sessions in a single ATSC = A/90 Application. Individual applications are not announced in the = standardized program guide (PSIP) and therefore, session selection and = schedule cannot be based solely on PSIP. A receiver that finds an = application with data Program Elements conveying IP Multicast data will = have to monitor these streams to collect the SDP packets. The receiver = application is responsible for sorting the streams out at the IP = network layer based on the information in the union of the SDP = announcements. The information retrieved from SDP packets is then used = to request session selection from users, for example, by using a small = menu superimposed on the screen. 9.4.2 Multiple Applications Instead of inserting all IP Multicast sessions into one ATSC A/90 = application, it is also possible to use a separate application per = session. The collection of applications is called in A/90 a Data = Service. Individual applications in a single Data Service are not = announced in the standardized program guide (PSIP) and therefore, = session selection and schedule cannot be based solely on PSIP. In this = case, a receiver that finds multiple applications with IP Multicast = content will have to monitor all the Program Elements that carry IP = Multicast. The receiver then collects the SDP packets that can be used = to offer session selection to users. 9.5 Multiple IP Multicast Services on Multiple Virtual Channels Instead of inserting all IP Multicast sessions in a single virtual = channel, it is also possible to use a different virtual channel per = session. In this case, each virtual channel may reference the same = video and audio elementary streams in the PSIP Service Location = Descriptor associated with the Virtual Channel (each Virtual Channel of = course, has a corresponding MPEG-2 Program and PMT). This permits the = use of EIT-k's or DET-k's to announce the schedule, rating and name of = each session. The advantage of this option is that users searching for = a particular session may do so by navigating the channel lists of the = standardized program guide (PSIP). 10. BUFFER MODEL There is an IP Multicast application buffer for each Program Element = referenced by a Tap of protocol_encapsulation value 0x04. Only IP = Multicast datagrams enter the IP Multicast application buffer. Other = bytes are discarded and may be used to control the system. Bytes enter = the IP Multicast application buffer at the rate specified by the = sb_leak parameter associated with the profile of the data service or by = the sb_leak_rate field in the smoothing_buffer_descriptor associated = with the Program Element conveying the IP Multicast datagrams. The size of the IP Multicast application buffer shall be equal to = 262144 bytes. The IP Multicast datagrams shall be sent such that the IP = Multicast application buffer shall not overflow. This corresponds to the acquisition of 65536 bytes UDP datagrams on two = distinct ports, with the assumption that one UDP datagram is being = removed from the buffer while another one is being aggregated in the = buffer. Bytes of a UDP datagram payload are removed out of the = application buffer once it has been reconstructed in the application = buffer. The application buffer corresponds to the collection of buffers = IPGRMBnk, FRAGBnkj, and UDPnkji defined in Section 17. 11. SCRAMBLING OF MAC LAYER MULTICAST ADDRESSES The method for scrambling the deviceId fields and/or the payload of = DSMCC_Addressable_section structures is outside the scope of this = specification. 11.1 Payload Scrambling The payload of DSMCC_addressable_section structures may be scrambled. = In this case, scrambling is signaled by means of the 2-bit = payload_scrambling_control field in the DSMCC_addressable_section = header, as specified by the ATSC A/90 Data Broadcast standard. 11.2 Device Identifier Scrambling=20 The deviceId fields in a DSMCC_addressable_section structure may be = scrambled or not scrambled. The presence of scrambling is signaled by = the 2-bit field address_scrambling_control in the header bytes of the = DSMCC_addressable_section structure. Scrambling has been applied when = this field is greater than 0. A MAC layer Multicast address in the = DSMCC_addressable_section structure should map to a MAC layer Multicast = address appearing either in the Tap selector_type 0x0102 structure or = in the MAC_Address_List_descriptor structure within the DST of the ATSC = A/90 Application to which the IP Multicast service belongs. Normative Clause MAC layer Multicast addresses appearing as scrambled in the header = bytes of the DSMCC_addressable_section shall also appear as scrambled = if referenced in the Data Service Table. 12. ACQUISITION PROCEDURE=20 The acquisition of the IP Multicast service is based on the various = ISO/IEC 13818-1, ATSC PSIP [2)] and ATSC A/90 [1)] structures. The Virtual Channel Table (VCT) is transmitted in Transport Stream = packets referenced by the PID value 0x1FFB. The source_id field = associated with the virtual channel in the VCT allows for the = identification of the instances of the Event Information Tables = (EIT-k's) announcing the audio-visual event schedule. It also = identifies the instances of the Data Event Tables (DET-k's) announcing = the schedule of the associated IP Multicast service. The location of = the EIT-k's and DET-k's in the Transport Stream is specified in the = PSIP Master Guide Table. The instances of the DET-k's conveying the IP = Multicast service schedule include a title text structure that may be = reported in the on-screen display of the Program Guide. The audio, video, and IPM Program Elements belong to the same virtual = channel so the audio-visual event can be enhanced by the IP Multicast = service. The PSIP Service Location Descriptor in the VCT is used to aggregate = the MPEG-2 Program Elements making up the virtual channel. A virtual = channel with an IP Multicast service includes one and only one MPEG-2 = Program Element of stream_type 0x95. The elementary_PID value PID1 = associated with the Program Element of stream_type value 0x95 specifies = the Transport Stream packets conveying the Data Service Table and the = Network Resources Table in the virtual channel. The elementary_PID = value PID2 of stream_type value 0x0D identifies the Transport Stream = packets conveying the DSM-CC Addressable sections where the IP = Multicast datagrams are encapsulated. The elementary_PID values PID1 = and PID2 are also listed in the PMT. The virtual channel may include = additional elementary_PID values for video and audio streams.=20 The Program Association Table (PAT) in the ATSC Transport Stream = identifies the PID value of the Transport Stream packets conveying the = Program Map Table (PMT). The PMT includes an MPEG-2 Program featuring = the video, audio, and IP Multicast data Program Elements aggregated by = the virtual channel. The MPEG-2 Program number in the PAT and the PMT = match the program number associated with the virtual channel listed in = the VCT. In the example, the Data Service Table consists of one IP Multicast = application featuring one Tap structure. The Tap structure includes an = associationTag allowing identification of the location (the = elementary_PID value) of the IPM Program Element within the ATSC = Transport Stream. The elementary_PID value associated with the IPM = Program Element is obtained by matching the associationTag value in the = Tap structure with the associationTag value in the Association Tag = Descriptor within the PMT. The Tap information loop includes a = Multiprotocol Encapsulation Descriptor to signal the number of active = bytes used in the deviceId fields of the DSM-CC Addressable Sections. = The deviceId_address_range field value is set to 0x06 to indicate that = all deviceId bytes are active. The deviceId_mapping_flag is set to 1 to = indicate that deviceId fields represent a MAC multicast address. The Session Description Protocol datagrams are received in DSM-CC = Addressable Sections with deviceId fields representing the SDP IP Multic= ast address. The SDP datagrams publish the IP Multicast address(es) of = the IP Multicast media streams that make up the IP Multicast session. = These non-SDP data streams can be filtered appropriately by the = receiver based on the value of the deviceId fields in the DSM-CC = Addressable Section header bytes, or at the IP network layer. In this example, all IP Multicast datagrams are carried in the same = data Program Element, and thus are not announced in separate Taps in = the DST. 13. NETWORK RESOURCE TABLE (NRT)=20 External media streams or SDP records belonging to the IP Multicast = Service and located in other Virtual Channels, other ATSC transports, = or in another IP network of the receiver are required by A/90 to be = signaled in the Network Resource Table (NRT). In general, the NRT is = used when either: 1) IP datagrams are conveyed in a data Program Element belonging to an = MPEG-2 Program or an ATSC Transport Stream other than the one used to = convey the Data Service Table of the IP Multicast service, or 2) The receiver application consuming this service requires access to = external Internet network. 14. IMPLEMENTATION INFORMATION ON THE IP NETWORK MODEL The following items are considerations and ramifications of the IP = Network Model defined in Section 4. When a Program Element (in Transport packet format) is passed through = any piece of equipment that can insert or re-multiplex Program Elements = (i.e., a multiplexor), one must make the conscious decision about = whether that piece of equipment is acting as a bridge or a router. The = latter would require enforcement of packet scoping rules, decrementing = of Time-To-Live (TTL) values, etc. It is expected that most broadcast = equipment will initially operate as bridges to avoid having to modify = the streams. When it is known that a Program Element carries IP data, multiplexing = of new IP data into the same Program Element must be done with care. = The precaution in this case is the need to ensure that there is no = conflict between IP addresses of the old and new data. Administratively scoped packets can only be inserted at the last route = before emission. Since in the general case, this point is not known to = the content author, it is difficult to use administratively scoped = addresses unless the communication is known to be between the emission = station and the receiver, such as for service and maintenance. This = case ensures a single route. Network topologies such as local 1394 = networks at the receiver end prevent any practical use of = administratively scoped addresses by general content authors, often = including broadcast studios. Administratively scoped packets cannot be forwarded across a = multiplexor that is acting as a router. When crossing any router, then the TTL must be decremented by that = router. Thus, a TTL value of 1 should not be used when authoring, even = in the broadcaster studio. And, from a receiver application perspective, each Program Element is = necessarily its own network interface model. The above are just some relevant examples. Consult general IP network = guidelines from IETF for more information and details. IP MULTICAST BUFFER MODEL The application buffer model for acquisition of the IP Multicast = datagrams assumes that datagrams are carried in UDP datagrams = encapsulated in IP datagrams. Complete Transport Stream packets containing data from Program Element = n are passed to the transport buffer for data Program Element n, TBn. = The size of TBn is fixed at 512 bytes. All bytes that enter TBn are = removed from TBn at a rate Rxn =3D 1.2 Rmax[ profile ], where Rmax [ = profile ] is the maximum data rate associated with the data service = profile as specified by the data service profile. When there is no data = in buffer TBn, rate RXn is equal to zero. Duplicate Transport Stream = packets are not delivered to SBn. The Transport Stream buffer is not = allowed to overflow. Only the header of DSMCC_addressable_section structures, payload, and = CRC_32 data bytes are delivered to buffer SBn; all other bytes do not = enter SBn and may be used to control the system. The size of SBn is = specified by data service profile. If there is data in buffer SBn, the = data is taken out of SBn at a rate specified by sb_leak, the leak value = specified by the data service or by the smoothing buffer descriptor = associated with the IPM Program Element n. The buffer SBn is not = allowed overflow. The IP Multicast datagram bytes in buffer SBn are all delivered to = their associated IP datagrams buffer at the rate specified by data = service profile or by the smoothing buffer descriptor associated with = the IPM Program Element n. Only IP datagram payload data bytes for IP = Multicast address k enter buffer IPGRMBnk. Bytes from the DSM-CC = Addressable section header bytes carrying bytes of a datagram of IP = Multicast k in data Program Element n are discarded and may be used to = control the system. Bytes from the DSM-CC Addressable section CRC_32 = fields that immediately follow the last IP datagram byte are discarded = and may be used to verify the integrity of the data. When there is no = DSM-CC Addressable section data present in SBn, no data is removed from = SBn. All data that enters SBn leaves it. All DSM-CC Addressable section = payload bytes of data Program Element n enter the IP de-multiplexor = instantaneously upon leaving SBn. DSM-CC Addressable section header = bytes and CRC32 bytes are removed instantaneously upon leaving SBn. The = buffer IPGRMBnk is not allowed to overflow. The payload bytes of the IP Multicast datagrams in buffer IPGRMBnk are = all delivered to their associated IP Fragmentation buffer at the rate = specified by the data service profile or by the smoothing buffer = descriptor associated with the IPM Program Element n. Only IP datagram = data bytes of fragment pertaining to identification j of IP datagram = with IP Multicast address k in data Program Element n enter buffer = FRAGnkj. Bytes from the IP datagram header are discarded and may be = used to control the system and verify the integrity of the IP header. = When there is no IP datagrams data present in IPGRMBnk, no data is = removed from IPGRMBnk. All data that enters IPGRMBnk leaves it. All IP = datagram payload bytes of IP Multicast address k in data Program = Element n enter the Fragmentation de-multiplexor instantaneously upon = leaving IPGRMBnk. IP datagram header bytes are removed instantaneously = upon leaving IPGRMBnk. The buffer FRAGbnkj is not allowed to overflow. The IP datagram fragment data bytes in buffer FRAGBnkj are used to = reconstruct the original, non-fragmented, IP datagram payload. Last = fragment pertaining to a re-constructed datagram may be identified by = means of the control fragmentation flag bit in the IP datagram header. = The payload bytes of the original, non-fragmented, IP datagram are all = delivered to the UDP buffer at a rate specified by the data service = profile or by the smoothing buffer descriptor associated with the IPM = Program Element n. Only UDP PDU payload data bytes of destination port = i of the IP datagram re-constructed under fragmentation identifier j of = the IP datagram with IP Multicast address k in data Program Element n = enter buffer UDPnkji. Bytes from the UDP PDU header are discarded and = may be used to control the system and may be used to verify the = integrity of the IP pseudo-header. When there are no IP payload data = bytes in the FRAGBnkj buffer, no data is removed from FRAGBnkj. All = data that enters FLAGBnkj leaves it. All IP datagram payload bytes = belonging to fragmentation of identification j of IP Multicast address = k in data Program Element n enter the UDP de-multiplexor = instantaneously upon leaving FRAGBnkj. UDP PDU header bytes are removed = instantaneously upon leaving FRAGBnkj. The buffer UDPnkji is not = allowed to overflow. Once a UDP datagram has been fully reconstructed, the payload data = bytes of the UDP PDU in buffer UDPnkji are all delivered at the rate = specified by the data service profile or by the smoothing buffer = descriptor associated with the IPM Program Element n. Only UDP PDU = payload data bytes are delivered to the output at a rate specified by = the data service or by the smoothing buffer descriptor associated with = the IPM Program Element n. Other bytes are discarded and may be used to = control the system. When there is no UDP PDU data present in UDPnkji, = no data is removed from UDPnkji. All data that enter UDPnkji leaves it. = UDP PDU header bytes are removed instantaneously upon leaving UDPnkji. = The buffer UDPnkji is not allowed to overflow. The size of the = IPGRMBnk, FRAGBnkj, and UDPBnkji is IPGRMBSnk, FRAGBSnkj, and = UDPBSnkji, respectively. 15. MAC ADDRESS LIST DESCRIPTOR (NORMATIVE) The MAC_Address_List_descriptor structure shall conform to the syntax = and semantics defined below: MAC_Address_List_descriptor() { descriptor_tag 8bits (uimsbf) descriptor_length 8bits (uimsbf) mac_addr_list 1 bit (bslbf) mac_addr_range 1bit (bslbf) pdu_size 2bits (bslbf) encapsulation_type 2bits (bslbf) reserved 2bits '11' if( mac_addr_list =3D=3D '1'){ num_in_mac_lis 8bits (uimsbf) for( i =3D0; i < num_in_mac_list; i++){ mac_address 48bits (uimsbf) } } if( mac_addr_range =3D=3D '1'){ num_of_mac_ranges 8bits (uimsbf) for( i=3D0; i; Wed, 14 Jul 2004 21:59:58 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6EKxwoh000613 for ipdvb-subscribed-users; Wed, 14 Jul 2004 21:59:58 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6EKxLH7000573; Wed, 14 Jul 2004 21:59:21 +0100 (BST) Received: from [12.161.102.11] (account marshall_eubanks HELO [10.1.2.33]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 2410472; Wed, 14 Jul 2004 16:59:01 -0400 In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC409@mail.NAB.ORG> References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC409@mail.NAB.ORG> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: internet-drafts@ietf.org, Gorry Fairhurst From: Marshall Eubanks Subject: Re: draft-ipmulticast-ipdvb-awa-01.txt Date: Wed, 14 Jul 2004 16:59:23 -0400 To: ipdvb@erg.abdn.ac.uk X-Mailer: Apple Mail (2.618) X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id i6EKxuw4000608 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Is this file properly formatted ? Or can you make a pdf version available ? I am having trouble looking / printing at it. On Jul 14, 2004, at 2:57 PM, Allison, Art wrote: >   > Please find attached the draft-ipmulticast-ipdvb-awa-01.txt as an > individual submission to be discussed further at the will of those > participating in ipdvb WG meeting at IETF 60. > > Arthur W. Allison >   >   > Regards Marshall Eubanks T.M. Eubanks e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Our New Video Service is in Beta testing http://www.americafree.tv From owner-ipdvb@erg.abdn.ac.uk Thu Jul 15 12:23:02 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6FBM9fC002333 for ; Thu, 15 Jul 2004 12:22:10 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6FBM9cY002332 for ipdvb-subscribed-users; Thu, 15 Jul 2004 12:22:09 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6FBKoYL002265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jul 2004 12:20:51 +0100 (BST) Message-ID: <40F66893.20906@erg.abdn.ac.uk> Date: Thu, 15 Jul 2004 12:20:51 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: agenda@ietf.org CC: ipdvb@erg.abdn.ac.uk Subject: ipdvb WG Agenda for IETF-60 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Here is the Agenda for the IETF-60 meeting in San Diego. Gorry Fairhurst (ipdvb WG Chair) -------- AGENDA ====== THURSDAY, August 5, 2004 1300-1500 Afternoon Sessions I ipdvb IP over digital video broadcast networks WG (Internet area) DURATION 2 hours. CHAIR: Gorry Fairhurst 1. Agenda Bashing (5 minutes) - Chair * Agenda changes * Election of scribes * Blue Sheets 2. Working Group Status and Plans (15 minutes) - Chair * Charter * Review of Milestones Active Drafts 3. Requirements/Framework (20 minutes) Marie-Jose Montpetit http://www.ietf.org/internet-drafts/draft-ipdvb-arch-00.txt * Document structure * Changes since last rev (draft-fair-ipdvb-req-05.txt). * Scenarios * Remaining issues to complete the ID for submission as RFC * Questions 4. Ultra Lightweight Encapsulation (15 minutes) - Bernhard Collini-Nocker http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-01.txt * Changes since rev -00. * Questions 5. ULE Extension Headers (10 minutes) - Bernhard Collini-Nocker http://www.ietf.org/internet-drafts/draft-collini-xule-00.txt * Questions 6. Outstanding ULE Issues to progress to a WGLC (10 minutes) - Chair * Extension Headers * Encryption * Adaptation Field * Discussion of way to proceed 7. Address Resolution (15 minutes) - Marie-Jose Montpetit http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-01.txt 8. Address Resolution with UDLR (10 minutes) - Hidetaka Izumiyama * Dynamic resolution and relation to ND (RFC 2461) 9. Other Issues / Future Work * Inputs on ip multicast over ATSC (see posting from ipdvb mailing list 14/7/04 A.Allison) * Update on status of known implementations Archive: http://www.erg.abdn.ac.uk/ip-dvb/archive From owner-ipdvb@erg.abdn.ac.uk Tue Jul 27 19:56:35 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6RIttcB000053 for ; Tue, 27 Jul 2004 19:55:55 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6RItstc000052 for ipdvb-subscribed-users; Tue, 27 Jul 2004 19:55:54 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.7] (maxp7.abdn.ac.uk [139.133.7.166]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6RIsgQ9000007 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 27 Jul 2004 19:54:52 +0100 (BST) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Mon, 26 Jul 2004 13:04:50 +0100 Subject: Status of ULE IMPLEMENTATIONS - July 2004 From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Dear ULE implementors, The core protocol spec for ULE seems fairly stable, and at this stage, I believe it would be useful to compile a list of known implementations. I'd like to encourage current ULE implementors or people planning implementations to provide a few lines of summary describing their work. Appropriate information could be: name of implementor target platform/OS air-interface (e.g. DVB-S;DVB-T; ATSC; ) implementation type (R&D; Commercial; Public-domain; etc....) status (e.g. usage, plans, requirements) URL to further information (if any) Please either send as a short email or a single slide. Please say if you are unable to be at the meeting at the ipdvb WG meeting next Thursday, and would like me to present the slide. Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Wed Jul 28 15:24:43 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6SENULL011947 for ; Wed, 28 Jul 2004 15:23:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6SENUej011946 for ipdvb-subscribed-users; Wed, 28 Jul 2004 15:23:30 +0100 (BST) Date: Wed, 28 Jul 2004 15:23:30 +0100 (BST) Message-Id: <200407281423.i6SENUej011946@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f From: "Mark Dale" To: Cc: "'Kevin Kimmich'" , "Mark Vanderaar"@mavis.erg.abdn.ac.uk X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk \(E-mail\)" Subject: RE: Status of ULE IMPLEMENTATIONS - July 2004 Date: Wed, 28 Jul 2004 10:10:49 -0400 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk Dear Mr Fairhurst: We appreciate your efforts to promote the ULE standards. We are currently using the ULE standard, in conjunction with the emerging DVB-S2 standard in broadband satellite communications applications. The information you requested is: Name of implementor: Efficient Channel Coding Target platforms/OS: P.C. based server / Linux Air interface: DVB-S2 Implementation type: Commercial Status: Prototype complete, pilot systems operational URL: www.eccincorp.com Please include us in the distribution of the final list of users and applications. Thanks Mark Dale Vice President of Business Development Efficient Channel Coding 600 Safeguard Plaza Brooklyn Hts., OH 44131 216-635-1610 (office), 216-635-1630 (fax) -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On Behalf Of Gorry Fairhurst Sent: Monday, July 26, 2004 8:05 AM To: ipdvb@erg.abdn.ac.uk Subject: Status of ULE IMPLEMENTATIONS - July 2004 Dear ULE implementors, The core protocol spec for ULE seems fairly stable, and at this stage, I believe it would be useful to compile a list of known implementations. I'd like to encourage current ULE implementors or people planning implementations to provide a few lines of summary describing their work. Appropriate information could be: name of implementor target platform/OS air-interface (e.g. DVB-S;DVB-T; ATSC; ) implementation type (R&D; Commercial; Public-domain; etc....) status (e.g. usage, plans, requirements) URL to further information (if any) Please either send as a short email or a single slide. Please say if you are unable to be at the meeting at the ipdvb WG meeting next Thursday, and would like me to present the slide. Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Wed Jul 28 20:03:48 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6SJ2rS0022258 for ; Wed, 28 Jul 2004 20:02:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i6SJ2rGx022257 for ipdvb-subscribed-users; Wed, 28 Jul 2004 20:02:53 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i6SJ1qmu022223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Jul 2004 20:01:54 +0100 (BST) Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.1439568; Wed, 28 Jul 2004 15:01:22 -0400 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jul 2004 15:01:22 -0400 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEC4AF@mail.NAB.ORG> From: "Allison, Art" To: ipdvb@erg.abdn.ac.uk Subject: Call for papers NAB 2005 Date: Wed, 28 Jul 2004 15:01:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk The National Association of Broadcasters is now soliciting technical papers for the NAB2005 Broadcast Engineering Conference to be held April 16-21, 2005 in Las Vegas, Nevada. If you, your colleagues or peers are interested in presenting a technical challenge you overcame to a broad range of engineering professionals, we invite you to participate in this 59th annual world-class conference. For information on the conference and how to submit an electronic proposal for consideration, please follow this link . Art ::{)> Arthur W. Allison Director, Science & Technology National Association of Broadcasters 202 429 5418