From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 3 17:01:52 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h63G0u8O026910 for ; Thu, 3 Jul 2003 17:00:56 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h63G0ubR026909 for ip-dvb-subscribed-users; Thu, 3 Jul 2003 17:00:56 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rsys000x.roke.co.uk (rsys000x.roke.co.uk [193.118.201.103]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h63Fxp8P026855 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 3 Jul 2003 16:59:52 +0100 (BST) Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys000x.roke.co.uk (8.12.8/8.12.8) with ESMTP id h63Fxt1H018534; Thu, 3 Jul 2003 16:59:56 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 16:59:49 +0100 Message-ID: From: "Surtees, Abigail" To: "'gorry@erg.abdn.ac.uk'" , ip-dvb@erg.abdn.ac.uk Subject: RE: Adaptation field Date: Thu, 3 Jul 2003 16:59:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MailScanner: Found to be clean, Found to be clean, Found to be clean X-MailScanner-SpamCheck: Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry, Thanks for your reply. I have eventually read the two new drafts and the diagrams have clarified things. I think the ULE draft is clear but I do still have a couple of questions about the Simple Encapsulation. On page 7, under the definitions for the sender of the AFC bits, it states '00, and 10, MUST NOT be used for transport of an encapsulated SNDU' but then on page 14 it says 'In case the SNDU or its final portion exactly fits into one TS Packet no adaptation field (0/00 PUSI/AFC) shall be used.' Which of these is correct? It is also not quite clear exactly when an adaptation header should be included. Page 12 states that 'The TS Packet that carries the last byte of the SNDU MUST carry an adaptation field.' This is a clear statement but does not seem to be consistent with the statements on P14 that follow the examples. I found it simplest to consider the cases. Please correct me if I have something wrong. PUSI AFC 1 01 first byte of SNDU, no adaptation field so new SNDU begins immediately after TS header and the SNDU is longer than 184 bytes -------- ------------------------------------- | header | start of SNDU | -------- ------------------------------------- 0 01 no start or end of SNDU - just 184 bytes of continuation -------- ------------------------------------- | header | continuation of SNDU | -------- ------------------------------------- 1 11 contains both the end of a SNDU and the beginning of one as shown in figures 7 and 8 0 11 contains the end of an SNDU but no new one (with or without padding) -------- ------------------------------------- | header | adap hdr | end of SNDU | -------- ------------------------------------- -------- ------------------------------------- | header | adap hdr | end of SNDU | padding FF | -------- ------------------------------------- However, the statement above about exactly fitting the SNDU in and not sending the adaptation field doesn't agree with this. Nor does the statement 'When there are no more SNDUs read for encapsulation the TS Packet (0.01 PUSI/AFC) shall be padded with stuffing bytes of value FF' Surely there should be an adaptation header because it is the end of an SNDU? Am I missing something? Another thought is what happens if there are exactly 184 bytes of SNDU left to go in a packet? If no adaptation header is included, then they fit in one packet, the end of the SNDU is in that packet, so an adaptation header should be included. However, if the adaptation header is included then the end of the SNDU doesn't fit in the packet and there is no need for the adaptation field. Best regards, Abbie >> >> I've just started looking ip-over-dvb and have a question >about part of >> draft-clausen-ipdvb-enc-00.txt which I hope someone can answer. >> >> On page 10 there is a table showing the meaning of the PUSI >and AFC bits in >> the TS packet header, followed by 2 paragraphs of explanation. >> The second paragraph says: >> " >> The TS Packet that carries the last byte of a SNDU >MUST always have >> an adaptation field. In case this was the last SNDU >(0/11 PUSI/AFC) >> the TS Packet is filled with stuffing bytes. In case >another SNDU >> starts in this TS Packet, another 4-byte adaptation field is >> inserted before the next SNDU. " >> >> I think this means that the adaptation field is used as >stuffing bytes >> when there are no more SNDUs, so there will be 184 - x bytes >of stuffing >> where x is the length of the last part of >> the SNDU. Is this correct? > >Yes, the adaption field could also be used as a part of the >framing, to tell >the receiver that an MPEG-2 TS Packet contains the start of a >new SNDU. If >the receiver happens to loose synch this is how it resynchs. > >> >> If there is another SNDU does 'another 4-byte adaptation >field' mean the >> one that is always carried or another one on top of that? >In other words, do you get >> ________________ ____________ ______________ >> ... end of SNDU | adap field | next SNDU ... >> ________________ ____________ ______________ >> >> or >> ________________ ____________ ____________ _____________ >> ... end of SNDU | adap field | adap field | next SNDU... >> ________________ ____________ ____________ _____________ >> >> ? > >Well, neither really. The adpoation field comes directly after the >MPEG-2 TS Packet >header. So, Bernhard has drawn some diagrams in the latest version of >this draft, >to try and get things clearer. > > > >The new rev of the draft will hopefully be clearer, but I'd still like >you to follow >up on your question and reply, if it applies also to the new rev of the >draft (-01). > >Gorry > -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 8 10:26:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h689QEbr010687 for ; Tue, 8 Jul 2003 10:26:14 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h689QEab010686 for ip-dvb-subscribed-users; Tue, 8 Jul 2003 10:26:14 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h689Pubr010671; Tue, 8 Jul 2003 10:25:58 +0100 (BST) Message-ID: <3F0A8E26.48274E4A@erg.abdn.ac.uk> Date: Tue, 08 Jul 2003 10:25:57 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Surtees, Abigail" CC: ip-dvb@erg.abdn.ac.uk Subject: Re: Adaptation field - what is it for? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Abigail, I'll try to rpovide some background to your questions.... First a little context, ISO/IEC 13818-1 defines two ways of padding variable sized IP packets to fixed sized TSA Packet payloads. ETSI TR 101 202 & EN 301 192 (that define MPE, etc) seem to allow both options. The "Simple" encapsulation currently seems to allow both options, and this is probably the source of the confusion. I think we need to get answers to the question, but before we debate the meaning of bits, it would be good to identify whether we need this approach, and what it would be used for. ************ The question I have is to all on the list: Do you see a need for an encapsulation that will allow for an adapatation field? (1) If so - what is the application, and what (adaptation) headers do you expect to use? (2) Also if an adaption field is used, would it be wiser to use only the adaption field for padding (alignment of the end of a Subnetwork PDU, i.e.IP packet) to the end of the last byte of a TS Packet. (3) Is there a need for EVERY SNDU to carry at least a minimal adapatation field? Thoughts..... on design, implemenation needs, compatibility with systems, etc Gorry "Surtees, Abigail" wrote: > > Hi Gorry, > > Thanks for your reply. I have eventually read the two new drafts and the diagrams have clarified things. > > I think the ULE draft is clear but I do still have a couple of questions about the Simple Encapsulation. > > On page 7, under the definitions for the sender of the AFC bits, it states > > '00, and 10, MUST NOT be used for transport of an encapsulated SNDU' > > but then on page 14 it says > > 'In case the SNDU or its final portion exactly fits into one TS Packet no adaptation field (0/00 PUSI/AFC) shall be used.' > > Which of these is correct? > > It is also not quite clear exactly when an adaptation header should be included. > > Page 12 states that 'The TS Packet that carries the last byte of the SNDU MUST carry an adaptation field.' > > This is a clear statement but does not seem to be consistent with the statements on P14 that follow the examples. > > I found it simplest to consider the cases. Please correct me if I have something wrong. > > PUSI AFC > 1 01 first byte of SNDU, no adaptation field so new SNDU begins immediately after TS header and the SNDU is longer than 184 bytes > -------- ------------------------------------- > | header | start of SNDU | > -------- ------------------------------------- > > 0 01 no start or end of SNDU - just 184 bytes of continuation > > -------- ------------------------------------- > | header | continuation of SNDU | > -------- ------------------------------------- > > 1 11 contains both the end of a SNDU and the beginning of one as shown in figures 7 and 8 > > 0 11 contains the end of an SNDU but no new one (with or without padding) > > -------- ------------------------------------- > | header | adap hdr | end of SNDU | > -------- ------------------------------------- > > -------- ------------------------------------- > | header | adap hdr | end of SNDU | padding FF | > -------- ------------------------------------- > > However, the statement above about exactly fitting the SNDU in and not sending the adaptation field doesn't agree with this. > > Nor does the statement > 'When there are no more SNDUs read for encapsulation the TS Packet (0.01 PUSI/AFC) shall be padded with stuffing bytes of value FF' > > Surely there should be an adaptation header because it is the end of an SNDU? > > Am I missing something? > > Another thought is what happens if there are exactly 184 bytes of SNDU left to go in a packet? > If no adaptation header is included, then they fit in one packet, the end of the SNDU is in that packet, so an adaptation header should be included. > However, if the adaptation header is included then the end of the SNDU doesn't fit in the packet and there is no need for the adaptation field. > > Best regards, > > Abbie > > >> > >> I've just started looking ip-over-dvb and have a question > >about part of > >> draft-clausen-ipdvb-enc-00.txt which I hope someone can answer. > >> > >> On page 10 there is a table showing the meaning of the PUSI > >and AFC bits in > >> the TS packet header, followed by 2 paragraphs of explanation. > >> The second paragraph says: > >> " > >> The TS Packet that carries the last byte of a SNDU > >MUST always have > >> an adaptation field. In case this was the last SNDU > >(0/11 PUSI/AFC) > >> the TS Packet is filled with stuffing bytes. In case > >another SNDU > >> starts in this TS Packet, another 4-byte adaptation field is > >> inserted before the next SNDU. " > >> > >> I think this means that the adaptation field is used as > >stuffing bytes > >> when there are no more SNDUs, so there will be 184 - x bytes > >of stuffing > >> where x is the length of the last part of > >> the SNDU. Is this correct? > > > >Yes, the adaption field could also be used as a part of the > >framing, to tell > >the receiver that an MPEG-2 TS Packet contains the start of a > >new SNDU. If > >the receiver happens to loose synch this is how it resynchs. > > > >> > >> If there is another SNDU does 'another 4-byte adaptation > >field' mean the > >> one that is always carried or another one on top of that? > >In other words, do you get > >> ________________ ____________ ______________ > >> ... end of SNDU | adap field | next SNDU ... > >> ________________ ____________ ______________ > >> > >> or > >> ________________ ____________ ____________ _____________ > >> ... end of SNDU | adap field | adap field | next SNDU... > >> ________________ ____________ ____________ _____________ > >> > >> ? > > > >Well, neither really. The adpoation field comes directly after the > >MPEG-2 TS Packet > >header. So, Bernhard has drawn some diagrams in the latest version of > >this draft, > >to try and get things clearer. > > > > > > > >The new rev of the draft will hopefully be clearer, but I'd still like > >you to follow > >up on your question and reply, if it applies also to the new rev of the > >draft (-01). > > > >Gorry > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 8 14:31:28 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h68DV6Wv015091 for ; Tue, 8 Jul 2003 14:31:06 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h68DV6Su015090 for ip-dvb-subscribed-users; Tue, 8 Jul 2003 14:31:06 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h68DUpWv015079 for ; Tue, 8 Jul 2003 14:30:52 +0100 (BST) Message-ID: <3F0AC78D.7186ACAA@erg.abdn.ac.uk> Date: Tue, 08 Jul 2003 14:30:52 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) References: <3EF77A7B.12D6E902@erg.abdn.ac.uk> <3EFEE357.3030409@csm.jcsat.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk TAKEI jun wrote: > > Gorry, > > I believe this BOF is continuous work from the unofficial BOF in Salt > lake city IETF and the situation has not been changed a lot. > The one in Salt Lake City was a BAR-BoFD - this is an OFFICIAL BOF. A few changes: (i) The encapsulsation scheme(s) is/are more advanced. (ii) The subject of address resolution now needs to be aired in the open to decide what people really think... (iii) It is likely we'll now focus on key things first. and get some action going.... things have been moving too slowly for my liking when we had too broad a charter. > Based on the information which I have and the situation in Japan, > urgent issue related on MPEG/DVB is IPv6 encapsulation. In terms of > IPv4, there are existing standard even though it was not defined by > IETF and it is not efficient ;-). If the WG try to define new > encapsulation mechanism of IPv4, it needs strong merit ,reason and a > time to make it be RFC. But IPv6, there are few mechanism which can > handle on MPEG/DVB-TS(I am not saying no standard). So my comment is > WG should focus on IPv6 encapsulation. Hopefully it should be better > that current MPE mechanism by using lessons and learned from IPv4 > experience. > If I udenrstand correctly, I'd say that IPv6 is a key goal. The new encpauslation will be oriented at the IPv6 service, and I expect will be backwards compatible with IPv4. > Second item which on the agenda, address resolution between MPEG PID > and IP address. Those address space are totally different each other. > And normally PID assignment has already done by service provider(TV > broadcasting company, IP service provider, etc.) or satellite > operator. So it is difficult to assign specific IP address to specific > PID. Maybe it is better to define new service mapping table like NIT, > PAT and PMT. > OK, so this is an interesting topic. I think one thing we can ***DEFINITELY*** look at is how to signal the IP/MAC to PID mapping. It turns out, that since the Salt Lake City Bar-BOF, DVB has published an update on their view of how to do this. This uses the INT - an MPEG-2 signalling table. This document describes the table, not tell one how to build the network service. An RFC describing how this relates to IPv4/IPv6 would be good, and identifying what can/can not be done using this mapping. Is the DVB/INT mapping good for dynamic multicast? What other options are there? How should it work with UDLR? What shoyuld happen in IP-only networks that do not send other MPEG-2 tables? Thoughts.... from people on this list??? > Anyway this is the start point of the discussion. I hope we can > define something from IETF. > Yes - we NEED to debate the charter and get to work to finish the documents. I look forward to hearing from people!!! Gorry > Best regards, > > Jun Takei > > Dr G Fairhurst wrote: > > > A BOF will be held in Vienna on the subject of building standards for IP > > networks using MPEG-2 Transport Stream transmission. This is intended to > > cover issues common to implementors/operators wishing to build efficient > > IP transmission networks using DVB, ATSC, etc. Satellite systems are > > currently a major user of this technology. The description is below. > > <> > > > > The mailing list archives are at: > > http://www.erg.abdn.ac.uk/ip-dvb/archive > > From owner-ip-dvb@erg.abdn.ac.uk Mon Jul 14 23:45:26 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6EMEkYv017911 for ; Mon, 14 Jul 2003 23:14:46 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6EMEkvK017910 for ip-dvb-subscribed-users; Mon, 14 Jul 2003 23:14:46 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6EMERYw017897 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 14 Jul 2003 23:14:28 +0100 (BST) Received: from rsys001a.roke.co.uk (rsys001a.roke.co.uk [193.118.192.110]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id h6EMDchm011837 for ; Mon, 14 Jul 2003 23:13:38 +0100 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1B2K>; Mon, 14 Jul 2003 23:14:26 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1M6Z; Mon, 14 Jul 2003 23:14:22 +0100 From: "mark.a.west" To: ip-dvb@erg.abdn.ac.uk Date: Mon, 14 Jul 2003 23:43:03 +0000 (GMT) Subject: rohc over... dvb Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean, Found to be clean, Found to be clean X-MailScanner-SpamCheck: Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, There wasn't really time to dive down this particular rat-hole at the BoF, but it seems like an opportune moment to raise the issue... [if it's already been discussed, then my apologies, but I think I'm safe!] It seemed to be that the Ethertype was felt more appropriate than PPP for the 'type' field, which seems entirely reasonable. About the only justification for the PPP type was that there is already a PPP type value for ROHC, which is seen as being useful in the IP/MPEG-2 context. It is clearly true that an Ethertype could be acquired for ROHC. However, a word of caution! This would not be the whole story... In terms of 'ROHC over Foo', this is only defined for Foo == PPP (in RFC 3241)! This specifies the negotiation that is necessary to make ROHC work. So, you would need not only an Ethertype, but also a 'ROHC over Ethernet' description to enable this. Maybe not much of an issue, but... FWIW, there was some discussion about ROHC over 802.11b (I think) a while ago (well, at S-F). However, I don't think that's gone anywhere, so..?! Cheers, Mark. Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-ip-dvb@erg.abdn.ac.uk Mon Jul 14 23:54:51 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6EMsW88018784 for ; Mon, 14 Jul 2003 23:54:32 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6EMsVZe018783 for ip-dvb-subscribed-users; Mon, 14 Jul 2003 23:54:32 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from gateway.hns.com (gateway.hns.com [208.236.67.13]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6EMsA89018770 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 14 Jul 2003 23:54:12 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6EMs9U3028599 for ; Mon, 14 Jul 2003 18:54:10 -0400 (EDT) Received: from hns.com (hnsvpnclient14.md.hns.com [139.85.221.14]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6EMrfjK006601; Mon, 14 Jul 2003 18:53:43 -0400 (EDT) Message-ID: <3F13348F.B69FA9BC@hns.com> Date: Mon, 14 Jul 2003 18:54:07 -0400 From: borderlt X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re the AR draft (http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry, I don't know, but I missed the announced re the AR draft. So, I had not read it prior to this afternoon's meeting. But, I have read it now... I think the unicast problem to be solved needs to be illustrated more clearly in the draft. Address resolution has different purposes for unicast and multicast. For multicast, it relates to determining an address to receive on. The requirements for this seem covered by the draft. But, for unicast, address resolution means figuring out the address you need to send to. With a DVB broadcast, I see three possibilities: (1) A host at the DVB broadcast receiver needs to resolve an address that is at the DVB broadcast sender; (2) A host at the DVB broadcast receiver needs to resolve an address that is at another DVB broadcast receiver; (3) A host at the DVB broadcast sender needs to resolve an address that is at a DVB broadcast receiver. Unless you are assuming mesh (which is really not DVB broadcast, and therefore is a different scope), (1) and (2) are really the same in that the host at the DVB receiver doesn't know the difference. In either case, the address which needs to be determined is the MAC address of the device at the DVB sender to which the IP packet should be forwarded (probably a router). Even if it is not a router, some device at the DVB sender has to relay the IP packet back to the DVB broadcast channel and this is really the device which then needs to resolve the specific DVB receiver MAC address. This is basically (3). So, it seems like (3) is the problem which needs to be solved. But, the draft doesn't come across that way... Of course, it is possible that I am thinking about the wrong problem. Hence my first statement re needing to more clearly define the problem being addressed... John From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 07:59:19 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6F6x088025225 for ; Tue, 15 Jul 2003 07:59:00 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6F6wx2X025224 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 07:59:00 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6F6wf89025210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 15 Jul 2003 07:58:42 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 15 Jul 2003 08:58:43 +0200 Subject: Re: Re the AR draft (http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt) From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F13348F.B69FA9BC@hns.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk On 15/7/03 12:54 am, "borderlt" wrote: > > Gorry, > > I don't know, but I missed the announced re the AR draft. So, I had not > read it prior to this afternoon's meeting. But, I have read it now... > > I think the unicast problem to be solved needs to be illustrated more > clearly in the draft. Address resolution has different purposes for unicast > and multicast. For multicast, it relates to determining an address to receive > on. The requirements for this seem covered by the draft. But, for unicast, > address resolution means figuring out the address you need to send to. With a > DVB broadcast, I see three possibilities: > > (1) A host at the DVB broadcast receiver needs to resolve an address that > is at the DVB broadcast sender; > (2) A host at the DVB broadcast receiver needs to resolve an address that > is at another DVB broadcast receiver; > (3) A host at the DVB broadcast sender needs to resolve an address that is > at a DVB broadcast receiver. > > Unless you are assuming mesh (which is really not DVB broadcast, and therefore > is a different scope), (1) and (2) are really the same in that the host at the > DVB receiver doesn't know the difference. In either case, the address which > needs to be determined is the MAC address of the device at the DVB sender to > which the IP packet should be forwarded (probably a router). Even if it is > not a router, some device at the DVB sender has to relay the IP packet back to > the DVB broadcast channel and this is really the device which then needs to > resolve the specific DVB receiver MAC address. This is basically (3). So, it > seems like (3) is the problem which needs to be solved. But, the draft > doesn't come across that way... > > Of course, it is possible that I am thinking about the wrong problem. > Hence my first statement re needing to more clearly define the problem being > addressed... > > > John > Thanks John, I saw you, and thought you were going to say something at the mic... I'll email the list, in a short while, I agree with you summary. The draft was put together in a few days to get the ball rolling, based on some detailed exchanges on multicast resolution between me and Marie-Jose. The main aim was to get something on the table to start the discussion !! Gorry From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 11:03:12 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FA2s88028317 for ; Tue, 15 Jul 2003 11:02:54 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6FA2r0D028316 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 11:02:53 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FA2R89028296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 15 Jul 2003 11:02:28 +0100 (BST) Received: from rsys001a.roke.co.uk (rsys001a.roke.co.uk [193.118.192.110]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id h6FA1dhm028163 for ; Tue, 15 Jul 2003 11:01:39 +0100 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1DVN>; Tue, 15 Jul 2003 11:02:27 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1NHH; Tue, 15 Jul 2003 11:02:17 +0100 From: "West, Mark" To: ip-dvb@erg.abdn.ac.uk Date: Tue, 15 Jul 2003 11:31:01 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: rohc over... dvb? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean, Found to be clean, Found to be clean X-MailScanner-SpamCheck: Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, There wasn't really time to dive down this particular rat-hole at the BoF, but it seems like an opportune moment to raise the issue... [if it's already been discussed, then my apologies, but I think I'm safe! And if this mail is duplicated, I can't drive my mail client properly...] It seemed to be that the Ethertype was felt more appropriate than PPP for the 'type' field, which seems entirely reasonable. About the only justification for the PPP type was that there is already a PPP type value for ROHC, which is seen as being useful in the IP/MPEG-2 context. Obviously, an Ethertype could be acquired for ROHC. However, a word of caution! This would not be the whole story... In terms of 'ROHC over Foo', this is only defined for Foo == PPP (in RFC 3241). This specifies the negotiation that is necessary to make ROHC work. So, you would need not only an Ethertype, but also a 'ROHC over Ethernet' description to enable this. Maybe not much of an issue, but... FWIW, there was some discussion about ROHC over 802.11b (I think) a while ago (well, at S-F). However, I don't think that's gone anywhere; it's certainly not on the agenda this week. Cheers, Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 Yes, I know my disclaimer is in an attachment. And no, I didn't ask for it to be like that. -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 12:21:18 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FBKw88029509 for ; Tue, 15 Jul 2003 12:20:58 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6FBKvAT029508 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 12:20:58 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FBKQ89029478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 15 Jul 2003 12:20:28 +0100 (BST) Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h6FBKK4Y024527; Tue, 15 Jul 2003 13:20:20 +0200 (MEST) Date: Tue, 15 Jul 2003 13:20:18 +0200 Subject: Re: rohc over... dvb? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann To: ip-dvb@erg.abdn.ac.uk From: Carsten Bormann In-Reply-To: Message-Id: <5089604D-B6B6-11D7-A370-00039390397C@tzi.org> X-Mailer: Apple Mail (2.552) X-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 h6FBKuNR029505 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I have attached an excerpt from the minutes of the Atlanta IETF, where we had an extensive discussion on ROHC over 802. You can find more information at http://www.ietf.org/proceedings/02nov/231.htm -- in particular, the slides (they are called "Agenda" in the proceedings, but they include all slides used -- start at slide 58). I believe some of the points made here can be discussed with different results in the specific context of DVB, but it is important to note that it is not just a simple matter of doing "ROHC over Ethernet". Gruesse, Carsten * ROHC over Wireless Ethernet Media  - Motivation and possible approaches (Kris Fleming) Kris Fleming gave a presentation of the motivation for and high level technical content of the "ROHC over Wireless Ethernet Media" draft. WLAN and WPAN links are often bandwidth limited and would therefore benefit from header compression. They have also typical loss and delay patterns that would motivate the use of ROHC in such scenarios. Since voice over IP is and will be commonly used in these networks, header compression will continue to be useful. If a generic solution for applying ROHC in these environments could be defined independent of the physical layer technology, that would simplify both standardization and implementation. Such a generic solution should in that case be defined by the IETF. Solutions that have been considered are ROHC over PPP over Ethernet, since both ROHC-over-PPP and PPP-over-Ethernet already exist. The drawbacks of combining these two into a complete solution are the unnecessary overhead, and the unnecessary complexity. The advantage is of course that all components already exist. Another potential approach that has been considered is to reuse an existing protocol for negotiation, but define something new for encapsulation. For IPv6, neighbor discovery could potentially be used for negotiation, but it is not really intended to discover link layer capabilities. The proposed "ROHC over WEM" defines a simple negotiation protocol, and an encapsulation. Kris gave a quick overview, and then asked whether there was any interest in doing this in ROHC. Carsten commented that a key question is where in the protocol stack it would make sense to do this. In the original ROHC work, Ethernet was completely ignored since adding header compression to it was considered to be of less value, e.g. due to the minimal frame size. In 802.11, the headers are rather large and are sent at a lower rate than the data. The gain from header compression could then be questioned. Greg Daley noted that with Mobile IP we might get lots of tunneling headers, and that would increase the gain from header compression. Draft: draft-fleming-rohc-wireless-ethernet-med-01.txt  - ROHC over Ethernet issues (Carsten Bormann)   Carsten had prepared some discussion material on this issue. We have a pretty large design space here, and before we do anything we must explore it so that we know what we are trying to invent. First of all, there is the issue about which negotiation protocol to use, if we would have to invent a new one. For IPv6, neighbor discovery (ND) seems to be an obvious choice. For IPv4, one could think of using ARP, but that sounds difficult at this point in the evolution of this protocol. If PPPoE was used, we would get lots of unnecessary things and still have to invent a new encapsulation. One could also potentially think of using ND also for IPv4. Secondly, we have the encapsulation issue. Ethernet requires padding, which is neither needed nor desired over the wireless links. If we do compression over the whole Ethernet, bridges between the wired and wireless parts must know about the padding scheme and translate or strip padding. This will easily get complicated. It might make sense to do this in the wireless access points instead, but then we would not get a generic scheme and it would be very unclear whether this would be a ROHC WG issue. A long discussion about the architectural placement of compression in these scenarios followed. Pat Calhoun suggested that this should be done by other bodies, for the links that would really benefit from header compression. Kris argued for doing a general solution and avoid having to do the work over and over again, while others then noticed that link specific solutions would probably give better gain, and we should remember that not all link layers would at all benefit from using compression. Carsten concluded that all comments just indicate that we do not have a clear architectural choice, there are several possible options. It is also very unclear whether this is appropriate work for the IETF and the ROHC WG. We will have to continue these discussions on the mailing list. From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 14:58:13 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FDvO88002214 for ; Tue, 15 Jul 2003 14:57:25 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6FDvORV002212 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 14:57:24 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FDuk88002184 for ; Tue, 15 Jul 2003 14:56:47 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 4C440CF for ; Tue, 15 Jul 2003 15:56:47 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 108A7685; Tue, 15 Jul 2003 15:56:47 +0200 (CEST) Message-ID: <3F1408DC.6060107@6wind.com> Date: Tue, 15 Jul 2003 15:59:56 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: fair-ipdvb-req : Some questions X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, I have some question about the draft '"Requirements for IP transport over MPEG-2 networks" (draft-fair-ipdvb-req-03.txt) As a newbie in satellite stuff, some of these questions/precisions may be irrelevant, thanks for indulgence ;-) 1) some reference don't exist [DVB-RC] [LINK-ID] [DVB-SIDAT], and maybe some other. As a newbie in that stuff, finding its way among multiple ISO/ETSI/whatever norms isn't really obvious :-( 2) About the TS-multiplex selection 2-a related to figure 2 Maybe I didn't get the point but hiw does it work : is it for the sender, a selection between multiple DVB-Sending cards ? If so, but managing one (or many ?) logical IP interface per sending card, I don't see why the 'normal' IP routing souldn't be enough. 2-b related to figure 3 The IP encapsulator has no mean to interact with the second TS multiplexor, so what is the point ? 3) Packet flows 3-a the flow itself They are associated with IP source and destination addresses. Well is it enough ? I mean, the recent flow-label discussion in the IPv6-WG ended up with a flow definition with SRC+DST+Flow_Label (http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt) 3-b the usage ? Indeed, why impase taht a single flow MUST use a single PID, I would consider it safer, but what is the rational behind it ? 4) Motivation In the needed fcts (§3 p10), there is the IPv4 broadcast packet support : is there a real need for this ? what is the use-case foreseen ? 5) Framework position The framework operates below the IP level. Couldn't it be a good place to define a logical-interface level (just for exemple, one pseudo-interface associated to a group of PID), and to see how to defien this group PID properties, in such a way that classical IP mechanisms will work 'perfectly' over this interface. By IP mechanisms I include not, only the stacks tmeselves, but also routing, ... To make myself more clear, ythe level of abstraction could be equivalment as the one we find in UDLR. Or is it over-specifying, and considered as implementation-dependant ? 6) About lenght indicator. It is said (§6.3 note ii p17) that when more than 2 payload are present in a single TS-cell, the PUSI pointer is only used for the first start. This is because the mandatory lenght indicator is enough to find the start of the next payload. In this case, why even use the PUSI pointer for the first tart in the TS-cell ? for I think lenght indicator + cell_numbering should be enough ?). Did I miss something or is this pointer removable ? 7) About address scoping I don't really see the point in managing sort of scope indicator at DVB-level, to manage muliple IPv4 private addressing that overlap. Indded, it may be out of context, and if we asume the DVB link a sort of publi link, overlapping addresses space should be managed at IP-level (with virtual routers or whatever). Or is it foreseen to addres a sub-PID managemłent, i.e. to do view a PID as a LAn, and to perform sort of VLAN management. 8) p23end of the page : excuse my ignorance, but what is the bandwitdth commonly associated to a single PID ? because can really a few Mbps recpetion (destined to be filtered at IP level) be considered as a DoS ? Even in case of a router, and strange protocol behaviuour, report, to 7) Thanks for having read so far .... Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 16:32:20 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FFW288004283 for ; Tue, 15 Jul 2003 16:32:02 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6FFW2EZ004282 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 16:32:02 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FFVg88004264 for ; Tue, 15 Jul 2003 16:31:43 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id BB4983C5 for ; Tue, 15 Jul 2003 17:31:43 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 9D404538; Tue, 15 Jul 2003 17:31:43 +0200 (CEST) Message-ID: <3F141F1C.709@6wind.com> Date: Tue, 15 Jul 2003 17:34:52 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: clausen-ipdvb-enc : Some questions X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, I have some question about the draft "Simple Encapsulation for transport of IP over MPEG-2/DVB networks" (draft-clausen-ipdvb-enc-01.txt) As a newbie in satellite stuff, some of these questions/precisions may be irrelevant, thanks for indulgence ;-) 1) SNDU format Type field : 2 bytes. Tha's sure, getting the ether_type is coll way of next header value, and can be esaily kept for other protocols, but do we really need 64K possible protocols to be transported over DVB May be it can be reduce to a single byte, wich would let a free byte (because of alignement), but I'm rather sure, people would think of plenty possible usage of those free bits ;-) 2) Usage of PUSI/AFC I don't really get the usage of the AFC. where does the pointer points in the two cases ? I think I see, but tell me if I'm wrong : 1st case +-------------------+ |Encap | Subnetwork | |Header| PU | +-------------------+ \ / \ / \ / +------*--------*--------------+------------+ |MPEG-2| Adapt. | Stuffing | SNDU | |Header| Header | bytes | | +------+--------+--------------+^-----------+ | | +----------------+ 2nd case +------------------+ +------------------+ | Subnetwork | | Subnetwork | | DU 1 | | DU 2 | +------------------+ +------------------+ \ \ / / \ \ / / \ \ / / +------*--------*--------+----------+ |MPEG-2| Adapt. | end of | start of | |Header| Header | SNDU 1 | SNDU 2 | +------+--------+--------+^---------+ | | +----------+ and in the 2nd case, is it possible to stuff bytes between end-SNDU1 and SNDU2 (for alignement purpose) ? In a more general way, wouldn't it be simpler (and cost less in overhead) to avoid any AFC header, and to impose SNDU start on 32-bits boundaries, because as SNDU will include length indicator, the padding will be automatically detected at the receiver side. Surely I miss something, and I feel it is around p14, but I don't see where this value 0x47 come from ? 3) Fluhsing the bit-stream Indeed, the fact that the encapsulator doesn't wait for another SNDU to come to pack, is enough to avoid latency. OK, it resolves the pending of an IP packet at the encaspultor level when no other IP packet comes. BUT what must be done at TS-muliplex level ? This should be specified by the encpaulsation method : if the push packet is not added, what is to be done ? Thanks again for having read so far ... Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 17:03:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FG2u88005191 for ; Tue, 15 Jul 2003 17:02:56 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6FG2u0k005190 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 17:02:56 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sh.csm.jcsat.co.jp (root@sh.csm.jcsat.co.jp [163.142.0.34]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FG2F88005166; Tue, 15 Jul 2003 17:02:16 +0100 (BST) Received: from csm.jcsat.co.jp ([81.160.96.250]) by sh.csm.jcsat.co.jp (8.12.8/3.7W) with ESMTP id h6FFeVpk018081; Wed, 16 Jul 2003 00:40:32 +0900 (JST) Message-ID: <3F142574.5070606@csm.jcsat.co.jp> Date: Wed, 16 Jul 2003 01:01:56 +0900 From: Jun Takei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: ja, en-us MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk CC: gorry Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) References: <3EFAE75C@mailandnews.com> In-Reply-To: <3EFAE75C@mailandnews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, It was so short to cover all items which related to IP-DVB on the slot of yesterday. But it was reasonable meeting because we could exchange current information. I would like to clarify one thing. Many people talked about issues or proposal based on the assumption network model in their brain. I don't think all that network model is the same. Why don't we clarify the target network model or parameters before leaving the start line? e.g. - how many node or MC ip address would be in one PID - how many PID will be used on the service (rough magnitude would be fine.) - etc. How do you think? Jun Takei, JSAT From owner-ip-dvb@erg.abdn.ac.uk Tue Jul 15 17:48:14 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FGlo88006086 for ; Tue, 15 Jul 2003 17:47:50 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6FGloMB006085 for ip-dvb-subscribed-users; Tue, 15 Jul 2003 17:47:50 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6FGlU89006072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 15 Jul 2003 17:47:31 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 15 Jul 2003 18:47:34 +0200 Subject: Re: clausen-ipdvb-enc : Some questions From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F141F1C.709@6wind.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thank you for your questions, we need to debate all the issues in the next few months so we can make sure we've got the right design. It's fine to ask any questions at this moment. I'll handle a few of these, and expect Bernhard will follow-up with some more details and the rest of the answers. On 15/7/03 5:34 pm, "alain.ritoux@6wind.com" wrote: > Hi all, > > I have some question about the draft "Simple Encapsulation for > transport of IP over MPEG-2/DVB networks" (draft-clausen-ipdvb-enc-01.txt) > As a newbie in satellite stuff, some of these questions/precisions > may be irrelevant, thanks for indulgence ;-) > > > 1) SNDU format > Type field : 2 bytes. > Tha's sure, getting the ether_type is coll way of next header > value, and can be esaily kept for other protocols, but do we really > need 64K possible protocols to be transported over DVB. OK. We *could* use an alternate type field, we need to do a detailed analysis of the pros and cons of this. Saving space is a Pro argument. > May be it can be reduce to a single byte, wich would let a free > byte (because of alignement), but I'm rather sure, people would think > of plenty possible usage of those free bits ;-) The "Simple" encapsulation uses the Adaptation Field and stuffing for alignemnet, this actually break 32-bit alignment. If you were to consider "ULE", the Byte alignment wouldn't be helped, except in the case of the first SNDU in a new TS Packet using ULE, because other SNDUs are of variable size, and the packing would loose alignment on subsequent frames. > 2) Usage of PUSI/AFC > I don't really get the usage of the AFC. where does the pointer points > in the two cases ? I think I see, but tell me if I'm wrong : > > 1st case > +-------------------+ > |Encap | Subnetwork | > |Header| PU | > +-------------------+ > \ / > \ / > \ / > +------*--------*--------------+------------+ > |MPEG-2| Adapt. | Stuffing | SNDU | > |Header| Header | bytes | | > +------+--------+--------------+^-----------+ > | | > +----------------+ > > 2nd case > +------------------+ +------------------+ > | Subnetwork | | Subnetwork | > | DU 1 | | DU 2 | > +------------------+ +------------------+ > \ \ / / > \ \ / / > \ \ / / > +------*--------*--------+----------+ > |MPEG-2| Adapt. | end of | start of | > |Header| Header | SNDU 1 | SNDU 2 | > +------+--------+--------+^---------+ > | | > +----------+ > and in the 2nd case, is it possible to stuff bytes between end-SNDU1 > and SNDU2 (for alignement purpose) ? > > In a more general way, wouldn't it be simpler (and cost less in > overhead) to avoid any AFC header, and to impose SNDU start on 32-bits > boundaries, because as SNDU will include length indicator, the padding > will be automatically detected at the receiver side. Surely I miss > something, and I feel it is around p14, but I don't see where this > value 0x47 come from ? > If you avoid the Adaptation Field header, we would create ULE - the key differences between the approaches is the use of "section-style" MPEG-2 framing (PUSI+Payload_start_pointer) or PES-style MPEG-2 framing (PUSI+AF with stuffing as needed). > 3) Fluhsing the bit-stream > Indeed, the fact that the encapsulator doesn't wait for another SNDU > to come to pack, is enough to avoid latency. OK, it resolves the pending > of an IP packet at the encaspultor level when no other IP packet comes. > > BUT what must be done at TS-muliplex level ? This should be specified by > the encpaulsation method : if the push packet is not added, what is to > be done ? > I'd like transport multiplexor manufacturers to tell us what they can do!!!! All contributions or enhancements of the problem statement would be most welcome!! > Thanks again for having read so far ... > Regards. > Alain. Hope that helps a little. Gorry From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 07:08:47 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G68V88016331 for ; Wed, 16 Jul 2003 07:08:31 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6G68VrI016330 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 07:08:31 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G67x88016307 for ; Wed, 16 Jul 2003 07:07:59 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id DC83E474 for ; Wed, 16 Jul 2003 08:07:58 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 9B96F4BA; Wed, 16 Jul 2003 08:07:58 +0200 (CEST) Message-ID: <3F14EC7B.2030906@6wind.com> Date: Wed, 16 Jul 2003 08:11:07 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: fair-ipdvb-ule : Some questions X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, I have some question about the draft "Ultra Lite Weihgt Encapsulation for transport of IP over MPEG-2/DVB networks" (draft-fair-ipdvb-ule-01.txt) 1) private data whaut is exactly meant with TS private data ? any link to "pric=vate sections" ? 2) PUSI and pointer it is not really clear in first description, that the PUSI bit set implies a pointer. btw what size is that pointer ? 3) difference with ipdvb-enc I don't really seee them : indeed, the Adaptation header is replaced by the pointer, and there is no more AFC bits set. but is that the only difference ? and what is the difference of strategy between the 2 ? they semm pretty similar to me ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 09:16:06 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G8FkBZ018362 for ; Wed, 16 Jul 2003 09:15:46 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6G8FkWA018361 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 09:15:46 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G8FOBa018348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 Jul 2003 09:15:25 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 16 Jul 2003 10:15:31 +0200 Subject: DRAFT MINUTES: IETF-57 BOF, Vienna From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F14EC7B.2030906@6wind.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-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 h6G8FjAu018358 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk The following minutes are DRAFT. Please do read and check. Send any corrections to me (chair). I intend to submit the final minutes in one week. Thank you Haitham for volunteering to be minute taker! gorry@erg.abdn.ac.uk IP-DVB Chair ---- IP over MPEG-2 Transport (IP-DVB) BoF Minutes, 14 July, IETF-57 Chairs Gorry Fairhurst (gorry@erg.abdn.ac.uk) and Bernhard Collini Nocker (bnocker@cosy.sbg.ac.at) The AD for this BOF was Thomas Narten. 4 drafts were presented: draft-fair-ipdvb-req-03.txt draft-clausen-ipdvb-enc-01.txt draft-fair-ipdvb-ule-00.txt draft-fair-ipdvb-ar-00.txt The agenda was bashed and asked the audience for any suggestions or modification. 1. Bernhard conducted the first presentation on why this is an IETF activity and presented a summary of the IP over MPEG-2 requirements. He spoke about the existing standards from DVB, including MPE (which has been deployed) and the needs for new protocols. Q: AD) Is this activity only for satellite? A: Bernhard) Satellite is an important application. There is also some interesting opportunities in the case of terrestrial transmission. A: Gorry) This WG intends to produce protocols for transporting IP over MPEG2 and DVB transmission networks, which are defined by ISO. Satellite services are important examples, as are digital terrestrial TV systems, some cable networks, etc. Q: Dino) Sending multicast packets is efficient, but unicast packets are not efficient in a broadcast network such as this. A: Gorry) Multicast is an important service, but both need to be addressed by this list. A: Bernhard) There are people building access networks using this technology too. Q: AD) Is this for IPv6 or IPv4 or both? A: Gorry) The focus should be IPv6, but we need to find a solution that will work with IPv4 as well. 2. Bernhard conducted the second presentation of the simple encapsulation of IP over DVB. He mentioned that the European Space Agency (ESA) is sponsoring this work. Q: Michael Schmidt) Does this encapsulation work for cable? A: Gorry) Yes, if it uses MPEG-2 Transmission. Q:?) There is a problem with data services using MPEG-2 transmission over IP. There can be packet re-ordering resulting in loss/reordering of TS Packets, which video can accommodate, but data services suffer. A: Gorry) The intended activity is IP-over MPEG-2 only. The WG does not address MPEG over IP issues. A discussion followed about issues with IP services over DVB over IP networks. AD: This problem was important, however the focus of the work was IP services over MPEG-2, not vice versa. Q:?) Give some examples of unicast applications A: Bernhard) Access networks, Skyplex and VPN over satellites. 3. Gorry presented the third draft on Ultra Light Encapsulation (ULE). This was an alternative to the Simple encapsulation, The main difference was an alternate framing mechanism that placed IP packets directly into MPEG-TS payload. There followed an open discussion of things raised on the list and options for implementing the framing. This discussion mostly applies to both the proposed encapsulation formats (Simple, ULE) - that is, the discussion was independent of the way in which the SNDUs were framed in the MPEG-2 Transport Stream. Q: Gorry) When are destination and source MAC addresses needed? Q:?) In the presentation the ordering for the MAC addresses was (Destination, Source) why not (Source, Destination)? A: GF:) This was a mistake, we intend to do the same as Enet. Q: ??) Do we need a ³MAC address² for IP routing? A: GF) Yes - unicast routers NEED to filter packets sent directly to them A: AD) You can¹t do unicast routing without this. A: Dino) The MAC destination address is more efficient for multicast filtering, this is even more the case for IPv6 multicast filters Q: Gorry) Also need to discuss what happens with bridging, can the IETF define a L2 forwarding operation? A: AD) Yes, if it complements the work for IP. Q: ?) It is easier for hardware can recognise MAC addresses in a fixed place and they are always present A: GF) We could look at this on the list. Q: GF) Apart from bridging, who needs a source MAC address? A: Dino) IS-IS expects a MAC source address A: Gorry) We should discuss this on the mailing list to get a good feedback on this issue. A:AD) The list needs to consider Pros/Cons very carefully and must document the reasons why decisions are made. Q: AD) Is the Ethernet type sufficient? - It may be, and would not require a separate IANA registry. A: Gorry) Yes for now. Q: ?) Ether types include a subset of LLC/SNAP - Do you need LLC/SNAP as well? Q: Gorry) Does anything rely on this? A: Dino) LLC-SNAP is used by Spanning Tree A: Gorry) Yes, and by some discovery protocols too. A: AD) The ID needs to specify the behaviour, one way or the other Q:Dino) Are the lessons of ATM fragmentation learnt here? A: Gorry) Yes, the draft addresses these issues clearly, any other observations are welcome. Q: Sebastien) What about MPLS? A: Gorry) This is not part of the base spec, we could add later. A: AD) keep the door open, but start simple. Q: ???) Should receivers know about the type of encapsulation (MPE, SIMPLE or ULE)? A: Gorry) I think it may be possible to find a way to let receivers know which is being used. We¹d need to take this to the list. Q: Gorry?) Is there a desire to have two standards for two cases or one? A: AD) One is always very much better, More design details should be put into SIMPLE and ULE and merge them if needed. 4. Gorry presented the address resolution draft and emphasized the need to translate IP addresses to MPEG PID and physical media ID. He mentioned 3 methods: Manual configuration, SI tables (e.g INT method) and a dynamic IP-level approach (re-using IPv6 ND address resolution). Q: AD) What is the size of the INT table, how many systems do you expect in a satellite network really? A: Bernhard) For satellite, due to costs of the satellite transponder many end systems will share it and, hence, the INT may get huge. Q: Dino) How large is the PID space? A: Bernhard) 13 bits Q: Dino) Is this fixed? (could we have more than the current 13 bits) A: Gorry) Yes, thats given, defined by the ISO spec for MPEG-2. 5. Gorry presented the WG road map for standard RFC for encapsulation and informational RFCs for architecture and address resolution and security. Q: AD) Why security. This was not part of the Charter? A: Gorry) Security poses issues for flat networks, this may provide useful inputs for the requirements, but is unlikely to be a work item of this group. Sebastein presented 2 slides on Alcatel¹s work on securing satellite DVB by adopting a similar approach to GDOI from the MSEC group. (see draft-duquer-fmke-00.txt) Q:AD) You mention MIBs - what are these used for? IP functions? or something esle? A: Gorry) I think it's mainly to identify how the IP level is functioning for the encapsulation / address resolution. A: Bernhard) You may also wish to set / view the tuning parameters that identify which TS Multiplex the receiver is receiving. Q: AD) Security does not work with ARP - Do we need security for address resolution? A: Haitham) Securing IPv6 ND is not resolved yet in the IETF and we should wait for their results (SEND WG). Haitham mentioned that IPSEC and MSEC work can be adopted here. A: AD) Any security issues should be addressed to other security WGs. A: Gorry) We should discuss the specific needs on the mailing list. WRAP UP: AD asked for show of hands from people who will support this work. More that half the audience showed interest. AD asked for show of hand from new people who think they will benefit from this work. There were a group of IETF attendees interested in developing these drafts. Minutes were taken by Haitham Cruickshank, University of Surrey UK. From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 09:57:00 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G8uaBZ019159 for ; Wed, 16 Jul 2003 09:56:36 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6G8uZSc019158 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 09:56:35 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G8u5Ba019133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 Jul 2003 09:56:06 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 16 Jul 2003 10:56:11 +0200 Subject: Re: Re the AR draft (http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt) From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F13348F.B69FA9BC@hns.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Good questions, see below. On 15/7/03 12:54 am, "borderlt" wrote: > > Gorry, > > I don't know, but I missed the announced re the AR draft. So, I had not > read it prior to this afternoon's meeting. But, I have read it now... > > I think the unicast problem to be solved needs to be illustrated more > clearly in the draft. Address resolution has different purposes for unicast > and multicast. For multicast, it relates to determining an address to receive > on. The requirements for this seem covered by the draft. But, for unicast, > address resolution means figuring out the address you need to send to. With a > DVB broadcast, I see three possibilities: > > (1) A host at the DVB broadcast receiver needs to resolve an address that > is at the DVB broadcast sender; > (2) A host at the DVB broadcast receiver needs to resolve an address that > is at another DVB broadcast receiver; > (3) A host at the DVB broadcast sender needs to resolve an address that is > at a DVB broadcast receiver. > > Unless you are assuming mesh (which is really not DVB broadcast, and therefore > is a different scope), (1) and (2) are really the same in that the host at the > DVB receiver doesn't know the difference. In either case, the address which > needs to be determined is the MAC address of the device at the DVB sender to > which the IP packet should be forwarded (probably a router). Even if it is > not a router, some device at the DVB sender has to relay the IP packet back to > the DVB broadcast channel and this is really the device which then needs to > resolve the specific DVB receiver MAC address. This is basically (3). So, it > seems like (3) is the problem which needs to be solved. But, the draft > doesn't come across that way... > > Of course, it is possible that I am thinking about the wrong problem. > Hence my first statement re needing to more clearly define the problem being > addressed... > > > John > I agree with what you say, but I am not sure I yet know what you want to be added to the ID. Let me try to reflect what you say in different words and see if I do understood this correctly, if not, please do tell me where I go wrong. Can we first define "TS Multiplex" - as a single physical bearer (carrier, another TS sent on a different carrier / channel, whatever) Looking at the three cases: (1) Seems to be the use of AR for an IP packet send operation, where the resolved address is a (PID, MAC/NPA address) that resolves to this TS Multiplex. The sender already has an AR database with an entry for the IP address. (2) As above, but where the address is not currently being sent. It may resolve to a different MPEG TS Multiplex - So this could be mesh connectivity or could be a MPEG-2 transmission system with multiple outbound links. There's a need to co-ordinate between a number of separate address resolution databases (for each TS Multiplex). The AR could be performed by another system, or we could have this function centralised in one or more (replicated) databases so a receiver can do the address mapping with AR information from a known place. (3) Seems to have three definite uses: (i) At a sender (encapsulation gateway), where AR provides the (MPEG TS Multiplex, PID, MAC/NPA address) to be used to send unicast, IPv4 subnet broadcast and multicast packets. (ii) At a receiver, where AR resolves an IP unicast or IPv4 broadcast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the receiver to set filters to let this traffic pass to the IP layer. This is true for unicast, and IPv4 subnet broadcast. Usually this operation is infrequent, e.g. Following the equivalent of an "ifconfig" on the interface. (iii) At a receiver, where AR resolves an IP multicast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the receiver to set filters to let this traffic pass to the IP layer. This operation may need to be performed many times based on IGMP, MLD, and Multicast Routing protocol operation. --- John, Is this text going the right way??? Would section 3.3 of the AR ID be a good place for this sort of description? Gorry From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 10:05:00 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G94dBZ019344 for ; Wed, 16 Jul 2003 10:04:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6G94cAA019343 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 10:04:38 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G949Ba019327 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Jul 2003 10:04:10 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 16 Jul 2003 11:04:14 +0200 Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) From: Gorry Fairhurst To: Jun Takei , Message-ID: In-Reply-To: <3F142574.5070606@csm.jcsat.co.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk On 15/7/03 6:01 pm, "Jun Takei" wrote: > Hi all, > > It was so short to cover all items which related to IP-DVB on the slot > of yesterday. But it was reasonable meeting because we could exchange > current information. > Yes, I do think the BOF went well. > I would like to clarify one thing. Many people talked about issues or > proposal based on the assumption network model in their brain. I don't > think all that network model is the same. Why don't we clarify the > target network model or parameters before leaving the start line? > e.g. - how many node or MC ip address would be in one PID > - how many PID will be used on the service > (rough magnitude would be fine.) > - etc. > > How do you think? > > Jun Takei, JSAT > > I like this idea, let's try to find some sample use cases. We do need this sort of discussion in the requirements draft, it would be very useful there. Can you propose some text which others could add to? Gorry From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 10:11:44 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G9BQBZ019463 for ; Wed, 16 Jul 2003 10:11:26 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6G9BQbq019462 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 10:11:26 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G9B7BZ019449 for ; Wed, 16 Jul 2003 10:11:07 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id A9C005F9 for ; Wed, 16 Jul 2003 11:11:07 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 8BC596F1; Wed, 16 Jul 2003 11:11:07 +0200 (CEST) Message-ID: <3F151768.6030009@6wind.com> Date: Wed, 16 Jul 2003 11:14:16 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: Encspulation Methods : Some questions. X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, 1) Precision about byte ordering About the encapsulation methods (both), a precision should be added in the SNDU format, about byte order telling that : - length is in network order - type is in network order network order being MSB first, hence a 1000 bytes IPv4 packet encapsulation would begin with : 0x03 0xE8 0x08 0x00 0x45 ... 2) The length field itself In description of IPv4/v6 SNDU it is said "the payload shall be a complete IPv4 datagram" My understanding (correct me if I'm wrong) is that it can be IPv4/v6 fragments, not necesseraly re-assembled IP datagrams, for it would introduce : - latency - work on both sides (re-ass in the sending, and frag on the recv side before IP processing) So, indeed IP packet may be up to 64Ko, BUT IP provides fragmentation and it will be IP fragments that will flow through the DVB-link, so what should be decided is what is the optimal MTU value for the DVB link. Maybe something like 1500 (a-la ethernet), or 4096 ?? In such case Length field could be limited to 12 bits (leaving 4 more bits for any other stuff) 3) The CRC Where is the exact CRC-32 defined ? More over, is tehr some CR/whatever mechansim at TS(or below) level, ensuring that TS frames are OK ? If yes, then is raly a CRC needed in the encapsulation, for IP checksum will be check by end user, and so maybe we don't need extr checks (and overhead), in the same p^hilosophy that lead the IPv6 header to not have checksum anymore. Thanks for all Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 11:01:15 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6GA0WBZ020624 for ; Wed, 16 Jul 2003 11:00:32 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6GA0WQx020623 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 11:00:32 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6G9xkBa020573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 Jul 2003 10:59:47 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 16 Jul 2003 11:59:51 +0200 Subject: Re: Encspulation Methods : Some questions. From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F151768.6030009@6wind.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk On 16/7/03 11:14 am, "alain.ritoux@6wind.com" wrote: > Hi all, > > 1) Precision about byte ordering > About the encapsulation methods (both), a precision should be > added in the SNDU format, about byte order telling that : > - length is in network order > - type is in network order > network order being MSB first, hence a 1000 bytes IPv4 packet > encapsulation would begin with : > 0x03 0xE8 0x08 0x00 0x45 ... Yes, good point, we need to add this in the next revision. > 2) The length field itself > In description of IPv4/v6 SNDU it is said > "the payload shall be a complete IPv4 datagram" > My understanding (correct me if I'm wrong) is that it can be IPv4/v6 > fragments, not necesseraly re-assembled IP datagrams, for it would > introduce : > - latency > - work on both sides (re-ass in the sending, and frag on the > recv side before IP processing) > > So, indeed IP packet may be up to 64Ko, BUT IP provides fragmentation > and it will be IP fragments that will flow through the DVB-link, so > what should be decided is what is the optimal MTU value for the DVB > link. Maybe something like 1500 (a-la ethernet), or 4096 ?? > > In such case Length field could be limited to 12 bits (leaving 4 > more bits for any other stuff) I meant that an IP Packet should be read the same as IP Datagram. See, draft-ietf-pilc-link-design-13.txt "IPv4 packets (datagrams) vary in size from 20 bytes (the size of the IPv4 header alone) to a maximum of 65535 bytes. Subnetworks need not support maximum-sized (64KB) IP packets, as IP provides a scheme that breaks packets that are too large for a given subnetwork into fragments that travel as independent IP packets and are reassembled at the destination. The maximum packet size supported by a subnetwork is known as its Maximum Transmission Unit (MTU)." Why do you want a small MTU? > > 3) The CRC > > Where is the exact CRC-32 defined ? > We will need to specify this in a later revision, I assumed the Ethernet CRC-32. > > More over, is tehr some CR/whatever mechansim at TS(or below) level, > ensuring that TS frames are OK ? Which part of MPEG-2 TS do you mean? > If yes, then is raly a CRC needed in > the encapsulation, for IP checksum will be check by end user, and so > maybe we don't need extr checks (and overhead), in the same p^hilosophy > that lead the IPv6 header to not have checksum anymore. > Arguably a design mistake. IPv6 REQUIRES a strong link checksum. For discussion, see draft-ietf-pilc-link-design-13.txt > > Thanks for all > Regards. > > Alain. gorry From owner-ip-dvb@erg.abdn.ac.uk Wed Jul 16 14:34:29 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6GDR8gD025682 for ; Wed, 16 Jul 2003 14:27:08 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6GDR7u4025679 for ip-dvb-subscribed-users; Wed, 16 Jul 2003 14:27:08 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from gateway.hns.com ([208.236.67.14]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6GDQ0gE025608 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 16 Jul 2003 14:26:04 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6GDMDU3006773 for ; Wed, 16 Jul 2003 09:22:13 -0400 (EDT) Received: from hns.com (hnsvpnclient46.md.hns.com [139.85.221.46]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6GDM5jK020240; Wed, 16 Jul 2003 09:22:06 -0400 (EDT) Message-ID: <3F153EB9.56EC6D76@hns.com> Date: Wed, 16 Jul 2003 08:02:01 -0400 From: borderlt X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Re the AR draft (http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk (ii) is where I see an issue. I think it is needed. But it is not ARP. It is closer to reverse-ARP because, if I understand what you are saying, the question is what MPEG TS Multiplex, PID, MAC/NPA address should I use to listen for stuff sent to me. So, the comparison to existing mechanisms needs to be described carefully... John Gorry Fairhurst wrote: > > Good questions, see below. > > On 15/7/03 12:54 am, "borderlt" wrote: > > > > > Gorry, > > > > I don't know, but I missed the announced re the AR draft. So, I had not > > read it prior to this afternoon's meeting. But, I have read it now... > > > > I think the unicast problem to be solved needs to be illustrated more > > clearly in the draft. Address resolution has different purposes for unicast > > and multicast. For multicast, it relates to determining an address to receive > > on. The requirements for this seem covered by the draft. But, for unicast, > > address resolution means figuring out the address you need to send to. With a > > DVB broadcast, I see three possibilities: > > > > (1) A host at the DVB broadcast receiver needs to resolve an address that > > is at the DVB broadcast sender; > > (2) A host at the DVB broadcast receiver needs to resolve an address that > > is at another DVB broadcast receiver; > > (3) A host at the DVB broadcast sender needs to resolve an address that is > > at a DVB broadcast receiver. > > > > Unless you are assuming mesh (which is really not DVB broadcast, and therefore > > is a different scope), (1) and (2) are really the same in that the host at the > > DVB receiver doesn't know the difference. In either case, the address which > > needs to be determined is the MAC address of the device at the DVB sender to > > which the IP packet should be forwarded (probably a router). Even if it is > > not a router, some device at the DVB sender has to relay the IP packet back to > > the DVB broadcast channel and this is really the device which then needs to > > resolve the specific DVB receiver MAC address. This is basically (3). So, it > > seems like (3) is the problem which needs to be solved. But, the draft > > doesn't come across that way... > > > > Of course, it is possible that I am thinking about the wrong problem. > > Hence my first statement re needing to more clearly define the problem being > > addressed... > > > > > > John > > > > I agree with what you say, but I am not sure I yet know what you want to be > added to the ID. Let me try to reflect what you say in different words and > see if I do understood this correctly, if not, please do tell me where I go > wrong. > > Can we first define "TS Multiplex" - as a single physical bearer (carrier, > another TS sent on a different carrier / channel, whatever) > > Looking at the three cases: > > (1) Seems to be the use of AR for an IP packet send operation, where the > resolved address is a (PID, MAC/NPA address) that resolves to this TS > Multiplex. The sender already has an AR database with an entry for the IP > address. > > (2) As above, but where the address is not currently being sent. It may > resolve to a different MPEG TS Multiplex - So this could be mesh > connectivity or could be a MPEG-2 transmission system with multiple outbound > links. There's a need to co-ordinate between a number of separate address > resolution databases (for each TS Multiplex). The AR could be performed by > another system, or we could have this function centralised in one or more > (replicated) databases so a receiver can do the address mapping with AR > information from a known place. > > (3) Seems to have three definite uses: > > (i) At a sender (encapsulation gateway), where AR provides the (MPEG TS > Multiplex, PID, MAC/NPA address) to be used to send unicast, IPv4 subnet > broadcast and multicast packets. > > (ii) At a receiver, where AR resolves an IP unicast or IPv4 broadcast > address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the > receiver to set filters to let this traffic pass to the IP layer. This is > true for unicast, and IPv4 subnet broadcast. Usually this operation is > infrequent, e.g. Following the equivalent of an "ifconfig" on the interface. > > (iii) At a receiver, where AR resolves an IP multicast address to the (MPEG > TS Multiplex, PID, MAC/NPA address), and allows the receiver to set filters > to let this traffic pass to the IP layer. This operation may need to be > performed many times based on IGMP, MLD, and Multicast Routing protocol > operation. > > --- > > John, Is this text going the right way??? > > Would section 3.3 of the AR ID be a good place for this sort of description? > > Gorry From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 17 06:20:51 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H5KVEF009433 for ; Thu, 17 Jul 2003 06:20:31 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6H5KVRg009432 for ip-dvb-subscribed-users; Thu, 17 Jul 2003 06:20:31 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from isis-08 (proqos.cosy.sbg.ac.at [141.201.2.218]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H5KCEF009418 for ; Thu, 17 Jul 2003 06:20:12 +0100 (BST) Received: from milbe ([141.201.2.21]) by isis-08 with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 07:20:11 +0200 From: "Bernhard Collini-Nocker" To: Subject: RE: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) Date: Thu, 17 Jul 2003 07:20:11 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F142574.5070606@csm.jcsat.co.jp> X-OriginalArrivalTime: 17 Jul 2003 05:20:11.0594 (UTC) FILETIME=[188C9AA0:01C34C23] X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi, > Hi all, > > It was so short to cover all items which related to IP-DVB on the slot > of yesterday. But it was reasonable meeting because we could exchange > current information. > I would like to clarify one thing. Many people talked about issues or > proposal based on the assumption network model in their brain. I don't > think all that network model is the same. Why don't we clarify the > target network model or parameters before leaving the start line? > e.g. - how many node or MC ip address would be in one PID What is your experience? There is some concern from our side, that the PID can not be easily used to separate/slit the address range, but it would be extremely helpful if you could provide some insight from an operator. Operators we know typically use not more than a couple of PIDs for data services. > - how many PID will be used on the service Same concern and request for your assistance as above. > (rough magnitude would be fine.) > - etc. > > How do you think? > > Jun Takei, JSAT Best regards, Bernhard From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 17 08:27:35 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H7R1EF010990 for ; Thu, 17 Jul 2003 08:27:02 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6H7R13o010989 for ip-dvb-subscribed-users; Thu, 17 Jul 2003 08:27:01 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sh.csm.jcsat.co.jp (root@sh.csm.jcsat.co.jp [163.142.0.34]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H7QZEF010973; Thu, 17 Jul 2003 08:26:37 +0100 (BST) Received: from csm.jcsat.co.jp ([81.160.98.239]) by sh.csm.jcsat.co.jp (8.12.8/3.7W) with ESMTP id h6H74bpk025711; Thu, 17 Jul 2003 16:04:38 +0900 (JST) Message-ID: <3F164F97.8050603@csm.jcsat.co.jp> Date: Thu, 17 Jul 2003 16:26:15 +0900 From: Jun Takei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: ja, en-us MIME-Version: 1.0 To: Gorry Fairhurst CC: ip-dvb@erg.abdn.ac.uk Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry, Gorry Fairhurst wrote: >>I would like to clarify one thing. Many people talked about issues or >>proposal based on the assumption network model in their brain. I don't >>think all that network model is the same. Why don't we clarify the >>target network model or parameters before leaving the start line? >>e.g. - how many node or MC ip address would be in one PID >>- how many PID will be used on the service >> (rough magnitude would be fine.) >>- etc. >> >>How do you think? >> >>Jun Takei, JSAT > > I like this idea, let's try to find some sample use cases. > > We do need this sort of discussion in the requirements draft, it would be > very useful there. Can you propose some text which others could add to? OK. I will write down a sample network topology and some parameters in the satellite network point of view. BTW, what kind other network(e.g. cable, terestrial, etc.) should we add on the draft? Jun From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 17 08:46:39 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H7kLEF011285 for ; Thu, 17 Jul 2003 08:46:21 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6H7kLgP011284 for ip-dvb-subscribed-users; Thu, 17 Jul 2003 08:46:21 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sh.csm.jcsat.co.jp (root@sh.csm.jcsat.co.jp [163.142.0.34]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H7jsEF011265 for ; Thu, 17 Jul 2003 08:45:56 +0100 (BST) Received: from csm.jcsat.co.jp ([81.160.98.239]) by sh.csm.jcsat.co.jp (8.12.8/3.7W) with ESMTP id h6H7Nxpk025762 for ; Thu, 17 Jul 2003 16:24:00 +0900 (JST) Message-ID: <3F165421.9030607@csm.jcsat.co.jp> Date: Thu, 17 Jul 2003 16:45:37 +0900 From: Jun Takei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: ja, en-us MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk >>I would like to clarify one thing. Many people talked about issues or >>proposal based on the assumption network model in their brain. I don't >>think all that network model is the same. Why don't we clarify the >>target network model or parameters before leaving the start line? >>e.g. - how many node or MC ip address would be in one PID > > > What is your experience? There is some concern from our side, that the > PID can not be easily used to separate/slit the address range, but it > would be extremely helpful if you could provide some insight from an > operator. > Operators we know typically use not more than a couple of PIDs for data > services. Actually we also used some PID for data service and user have not to move between PID in normal operation. This is unicast IP connectivity service. In other case, we studied to provide multicast data streaming service via satellite and it may have several PID and user will choose those PID in some way. At that time we didn't have mapping mechanism between Multicast IP address and PID using service information(SI) table. Therefore web based EPG like mechanism had been provided and the channel control order are sent to driver directory from the application. This is a sample mechanism and some other provider may employ similar system. So in terms of mapping mechanism of multicast ip address and PID is not necessary mechanism on L2. That means there are another way to map L2 and L3 address beside using DVB/MPEG tables. But in terms of unicast IP address I am not sure it is necessary or not. Regards, Jun From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 17 09:39:17 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H8cvEF012158 for ; Thu, 17 Jul 2003 09:38:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6H8cvXw012157 for ip-dvb-subscribed-users; Thu, 17 Jul 2003 09:38:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6H8cXEG012142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 17 Jul 2003 09:38:34 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 17 Jul 2003 10:38:38 +0200 Subject: Re: Re the AR draft (http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt) From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F153EB9.56EC6D76@hns.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk On 16/7/03 2:02 pm, "borderlt" wrote: > > (ii) is where I see an issue. Agreed in that this is the thing we need to drive a MPEG-2 receiver (i.e. "tune/filter"). > I think it is needed. But it is not ARP. It > is closer to reverse-ARP because, if I understand what you are saying, the > question is what MPEG TS Multiplex, PID, MAC/NPA address should I use to > listen for stuff sent to me. Yes, I agree this function matches (ii). It not "rarp" as I understand it, reverse-arp is about: "given a L2 address (MAC, etc) what IPv4 address does this have?" rarp is, e.g., typically used for auto-configuration of an interface. So... IMHO, (ii) could be called "address resolution", let's look at the function: are you trying to relate a IP address to a L2 address? - *BUT* as you say, the use you make of this information at the Receiver is somehwhat different. So we do have to be careful we identify this, ... Are there other similar networks that use the information in the same way, so we can learn from them? > So, the comparison to existing mechanisms needs > to be described carefully... > YES, I'd like more precision of the function. Gorry > > John > > > Gorry Fairhurst wrote: >> >> Good questions, see below. >> >> On 15/7/03 12:54 am, "borderlt" wrote: >> >>> >>> Gorry, >>> >>> I don't know, but I missed the announced re the AR draft. So, I had not >>> read it prior to this afternoon's meeting. But, I have read it now... >>> >>> I think the unicast problem to be solved needs to be illustrated more >>> clearly in the draft. Address resolution has different purposes for unicast >>> and multicast. For multicast, it relates to determining an address to >>> receive >>> on. The requirements for this seem covered by the draft. But, for unicast, >>> address resolution means figuring out the address you need to send to. With >>> a >>> DVB broadcast, I see three possibilities: >>> >>> (1) A host at the DVB broadcast receiver needs to resolve an address that >>> is at the DVB broadcast sender; >>> (2) A host at the DVB broadcast receiver needs to resolve an address that >>> is at another DVB broadcast receiver; >>> (3) A host at the DVB broadcast sender needs to resolve an address that is >>> at a DVB broadcast receiver. >>> >>> Unless you are assuming mesh (which is really not DVB broadcast, and >>> therefore >>> is a different scope), (1) and (2) are really the same in that the host at >>> the >>> DVB receiver doesn't know the difference. In either case, the address which >>> needs to be determined is the MAC address of the device at the DVB sender to >>> which the IP packet should be forwarded (probably a router). Even if it is >>> not a router, some device at the DVB sender has to relay the IP packet back >>> to >>> the DVB broadcast channel and this is really the device which then needs to >>> resolve the specific DVB receiver MAC address. This is basically (3). So, >>> it >>> seems like (3) is the problem which needs to be solved. But, the draft >>> doesn't come across that way... >>> >>> Of course, it is possible that I am thinking about the wrong problem. >>> Hence my first statement re needing to more clearly define the problem being >>> addressed... >>> >>> >>> John >>> >> >> I agree with what you say, but I am not sure I yet know what you want to be >> added to the ID. Let me try to reflect what you say in different words and >> see if I do understood this correctly, if not, please do tell me where I go >> wrong. >> >> Can we first define "TS Multiplex" - as a single physical bearer (carrier, >> another TS sent on a different carrier / channel, whatever) >> >> Looking at the three cases: >> >> (1) Seems to be the use of AR for an IP packet send operation, where the >> resolved address is a (PID, MAC/NPA address) that resolves to this TS >> Multiplex. The sender already has an AR database with an entry for the IP >> address. >> >> (2) As above, but where the address is not currently being sent. It may >> resolve to a different MPEG TS Multiplex - So this could be mesh >> connectivity or could be a MPEG-2 transmission system with multiple outbound >> links. There's a need to co-ordinate between a number of separate address >> resolution databases (for each TS Multiplex). The AR could be performed by >> another system, or we could have this function centralised in one or more >> (replicated) databases so a receiver can do the address mapping with AR >> information from a known place. >> >> (3) Seems to have three definite uses: >> >> (i) At a sender (encapsulation gateway), where AR provides the (MPEG TS >> Multiplex, PID, MAC/NPA address) to be used to send unicast, IPv4 subnet >> broadcast and multicast packets. >> >> (ii) At a receiver, where AR resolves an IP unicast or IPv4 broadcast >> address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the >> receiver to set filters to let this traffic pass to the IP layer. This is >> true for unicast, and IPv4 subnet broadcast. Usually this operation is >> infrequent, e.g. Following the equivalent of an "ifconfig" on the interface. >> >> (iii) At a receiver, where AR resolves an IP multicast address to the (MPEG >> TS Multiplex, PID, MAC/NPA address), and allows the receiver to set filters >> to let this traffic pass to the IP layer. This operation may need to be >> performed many times based on IGMP, MLD, and Multicast Routing protocol >> operation. >> >> --- >> >> John, Is this text going the right way??? >> >> Would section 3.3 of the AR ID be a good place for this sort of description? >> >> Gorry > > > From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 17 16:21:41 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6HFLMgf019569 for ; Thu, 17 Jul 2003 16:21:22 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6HFLMDt019568 for ip-dvb-subscribed-users; Thu, 17 Jul 2003 16:21:22 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6HFKwgf019551 for ; Thu, 17 Jul 2003 16:20:58 +0100 (BST) Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h6HFKoUL026843 for ; Thu, 17 Jul 2003 17:20:53 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D66.0054018A ; Thu, 17 Jul 2003 17:17:34 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Sebastien.Josset@space.alcatel.fr To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Thu, 17 Jul 2003 17:18:41 +0200 Subject: IETF-57 BOF, Vienna Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=66M5vRelu9RbdUysiElN4qA9HvvKF4aIQbVgVdhJzkjtCdST2N9uyplL" Content-Disposition: inline X-Virus-Scanned: by amavisd-new X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk --0__=66M5vRelu9RbdUysiElN4qA9HvvKF4aIQbVgVdhJzkjtCdST2N9uyplL Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable Dear Gorry, you'll find in attachement a pdf version of the slides I presented at t= he meeting. (See attached file: Alcatel_BOF_Vienna_v2.pdf) Best regards, S=E9bastien Josset ALCATEL SPACE Research Department/Advanced Telecom Satellite Systems Tel : +33 (0)53435 5104 / Fax : +33 (0)53435 5560 Porte : W218 / E-Mail : sebastien.josset@space.alcatel.fr = --0__=66M5vRelu9RbdUysiElN4qA9HvvKF4aIQbVgVdhJzkjtCdST2N9uyplL Content-type: application/pdf; name="Alcatel_BOF_Vienna_v2.pdf" Content-Disposition: attachment; filename="Alcatel_BOF_Vienna_v2.pdf" Content-transfer-encoding: base64 Content-Description: Adobe Portable Document JVBERi0xLjINJeLjz9MNCjEyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAxNCANL0ggWyA3 MjIgMTg0IF0gDS9MIDQ1MDcxIA0vRSAzOTA3OSANL04gNCANL1QgNDQ3MTMgDT4+IA1lbmRvYmoN ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTEyIDE2IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2NjcgMDAwMDAgbg0KMDAw MDAwMDkwNiAwMDAwMCBuDQowMDAwMDAxMDYxIDAwMDAwIG4NCjAwMDAwMDEyNTYgMDAwMDAgbg0K MDAwMDAwMTQzNiAwMDAwMCBuDQowMDAwMDAxODcyIDAwMDAwIG4NCjAwMDAwMDIwNTYgMDAwMDAg bg0KMDAwMDAwMjQ4MyAwMDAwMCBuDQowMDAwMDAyNjcwIDAwMDAwIG4NCjAwMDAwMDMzOTQgMDAw MDAgbg0KMDAwMDAwMzgzNiAwMDAwMCBuDQowMDAwMDA0MDI3IDAwMDAwIG4NCjAwMDAwMDQxMDUg MDAwMDAgbg0KMDAwMDAwMDcyMiAwMDAwMCBuDQowMDAwMDAwODg2IDAwMDAwIG4NCnRyYWlsZXIN PDwNL1NpemUgMjgNL0luZm8gMTEgMCBSIA0vUm9vdCAxMyAwIFIgDS9QcmV2IDQ0NzAzIA0vSURb PDYyM2JmZTVlMTY5MjNmYjE4MmU1MGQzNjZiMDQyOTI4Pjw2MjNiZmU1ZTE2OTIzZmIxODJlNTBk MzY2YjA0MjkyOD5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTEzIDAgb2JqDTw8IA0vVHlw ZSAvQ2F0YWxvZyANL1BhZ2VzIDEwIDAgUiANPj4gDWVuZG9iag0yNiAwIG9iag08PCAvUyA1NCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI3IDAgUiA+PiANc3RyZWFtDQpIiWJgYGBmYGC6 xMDCwMB6nEGAAQFAbKAoA8cEhr59TIFM3AxwGkkFDxQzMPgB+b4MpQxpjGkMWYyxDLlMbYw5DIUM DO07GBgAAgwA8TALqw1lbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqDTgwIA1lbmRvYmoNMTQgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEwIDAgUiANL1Jlc291cmNlcyAxNSAwIFIgDS9D b250ZW50cyAxNyAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9D cm9wQm94IFsgMSAxIDU5NSA4NDEgXSANPj4gDWVuZG9iag0xNSAwIG9iag08PCANL1Byb2NTZXQg WyAvUERGIC9UZXh0IC9JbWFnZUMgXSANL0ZvbnQgPDwgL1RUMiAxOSAwIFIgL1RUNCAyMSAwIFIg L1RUNiAyMiAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgMjUgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgMjQgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE2IDAgUiA+PiANPj4gDWVuZG9i ag0xNiAwIG9iag1bIA0vQ2FsUkdCIDw8IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAv R2FtbWEgWyAyLjIyMjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEy NiAwLjAxOTMgMC4zNTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4g DQ1dDWVuZG9iag0xNyAwIG9iag08PCAvTGVuZ3RoIDM2MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiYySy07DMBBF9/6KWbYSTsaOnce2T7US4hGrLBCLtHKhSG2gror45P4FYycE BKrUWHFs+frcO7HjodOwciBCcysWT0sBz44J2AATEaKAXImoSAXoQgHPFdIE9pat2TvDsChQZMB1 kUQFPYCk1LQTNXgAprDasni2FTCq2R0bGBYbI8nOrAkgCUovQpKROid1KtJIKhqYLa37RrkQTOg+ WA/65tUjVIuIpCaNGTGOZCdlUNIoS7z8sTcbmwloSgiLje3zvLfbVf0nM/8VgwcIF5FKPOhiM8y8 sidUjFksEZNW/Q+rOux5Ijb/rE2v0uBfnpaVO2zsDua1c/ZwddZBX5o8+ORe2NXgjQ6nt5dqZ2FY b5fWtZvT7pgyf+y8+dAU06igDqT8OatwW3yJs1uoj3YP17fjKZfxaDGAwc3kTx6fWghddJHS79Kx KV3yh+oTSrs/blbWNURC8fth6VFjw74EGAChQZz+CmVuZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmoN PDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5NjIgDS9DYXBIZWlnaHQgMCANL0Rl c2NlbnQgLTIzNSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtMTY3IC0yMzYgMTEwMCA5NjMgXSAN L0ZvbnROYW1lIC9GdXR1cmFBQmtCVCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiANZW5k b2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RD aGFyIDMyIA0vTGFzdENoYXIgMTUwIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NjQgDTAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDM1MCA1MDAgXSAN L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbiANL0Zv bnREZXNjcmlwdG9yIDIwIDAgUiANPj4gDWVuZG9iag0yMCAwIG9iag08PCANL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0vRmxh Z3MgMzQgDS9Gb250QkJveCBbIC0xNjcgLTMwNyAxMDA5IDEwMDcgXSANL0ZvbnROYW1lIC9UaW1l c05ld1JvbWFuIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDT4+IA1lbmRvYmoNMjEgMCBvYmoN PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0 Q2hhciAyMzMgDS9XaWR0aHMgWyAyOTUgMzE5IDAgMCAwIDAgNjY5IDAgMjg4IDI4OCAwIDAgMjk1 IDM2NiAyOTUgNDE3IDU5MCA1OTAgNTkwIDU5MCANNTkwIDU5MCA1OTAgNTkwIDAgMCAzMTkgMCAw IDAgMCAwIDAgNjI1IDU2MiA3MjUgNzI1IDUyMSA1MDcgODE0IA03MjIgMjU5IDM4NyA1OTEgNDU2 IDgzOCA3NzUgMCA1MDggMCA1MzUgNTE0IDUwNyA3MjAgNTgwIDkxMyAwIDAgDTAgMCAwIDAgMCAw IDAgNTY5IDU3MiA0NDkgNTcyIDUxNCAyODkgNTcxIDU1NyAyNDIgMjQyIDQ5MyAyNDIgODQ4IA01 NTcgNTY5IDU3MiA1NzIgMzUxIDQwNyAyNTkgNTQ3IDQ0OSA2OTIgNDMzIDQ0MCA0MzEgMCAwIDAg MCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQzNSA0MzUgMCAwIDAg MCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgNTE0IF0g DS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0Z1dHVyYUFCa0JUIA0vRm9u dERlc2NyaXB0b3IgMTggMCBSIA0+PiANZW5kb2JqDTIyIDAgb2JqDTw8IA0vVHlwZSAvRm9udCAN L1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIxIA0vV2lkdGhz IFsgMzEzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ1NiAwIDQ1OCAwIDAgNjI1IDAgMCAwIDAg MCAwIDAgMCAwIDAgDTAgMCAwIDAgMCA2NzggNjI4IDc2NiA1NjcgNTQ0IDg0MyAwIDM1OSAwIDAg MCA5MjUgMCA4NTYgNjM0IDAgNjQxIA01ODEgMCAwIDcxMSA5NzAgMCAwIDAgMCAwIDAgMCAwIDAg NjYwIDY2MCA0NjEgNjYwIDYxMSAzNTEgMCA2NTMgDTMxMiAwIDY0MSAzMTIgOTQ4IDY1MyA2MjMg MCA2NjAgNDQ3IDQ4NCAzNTMgNjMxIDU2NCA4MDMgMCA1MzIgXSANL0VuY29kaW5nIC9XaW5BbnNp RW5jb2RpbmcgDS9CYXNlRm9udCAvRnV0dXJhQUJrQlQsQm9sZCANL0ZvbnREZXNjcmlwdG9yIDIz IDAgUiANPj4gDWVuZG9iag0yMyAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNj ZW50IDk2MiANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjM2IA0vRmxhZ3MgMzIgDS9Gb250QkJv eCBbIC0xNjcgLTIzNyAxMzAzIDk2MyBdIA0vRm9udE5hbWUgL0Z1dHVyYUFCa0JULEJvbGQgDS9J dGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMzIA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8IA0vVHlwZSAv RXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIgL0lkZW50aXR5IA0+PiANZW5kb2Jq DTI1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODQ3IC9I ZWlnaHQgNTkyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE2IDAgUiAvTGVuZ3Ro IDM0NjU0IC9GaWx0ZXIgL0RDVERlY29kZSA+PiANc3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/ 2wCEAA4KCgoLCg4LCw4VDQwNFRgSDg4SGBwWFhcWFhwbFRcXFxcVGxsgISMhIBsrKy4uKys+PT09 PkBAQEBAQEBAQEABDw0NDxEPExAQExQPEQ8UFxIUFBIXIhcXGRcXIiwfGxsbGx8sJikjIyMpJi8v LCwvLzs7OTs7QEBAQEBAQEBAQP/AABEIAlADTwMBIgACEQEDEQH/3QAEADX/xAE/AAABBQEBAQEB AQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIE AgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRai soMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dn d4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi 4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl 9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOaTo32LL/0L/wDNKf7Fl/6F/wDm lDhl2P2K4o9whRK+VP7Fl/6F/wDmlErxMkHWp33FHhl2P2K4o9wzA0TwijHvj+bd9yf7Pd/o3fcj wy7H7EcQ7ho5A0VNad+LkOGlTj8iqgwcz/Qv/wA0qSMTWxWGQ7hq3D2KWIPYj24GYWQKXn+yVLGw ctrfdS8f2SncJrYo4h3ZNCK0KbcTI/0TvuRG41/+jd9yHCexTxDuGdRQuotDscnuFYZRcPzD9yHk 4972ForcfkmmMuxSCO4Q4T/Y34K4CqWLjZLGAOqcI8QVeFVsfQP3Jkoy7H7F0ZR7hdOnFdn7p+5P 6dn7p+5M4Jfun7F3FHuPtUCi1321/RdA8DqEP03/ALpT7H/ulLgl+6fsVxR7j7WyMlrnAvbB8Rx9 y1MXLpIABB/KsPY/wKcNf4FGpjofsUTE9R9r1LLmdkRzmOC5mvIya+CSPAq5V1F3DgW/iEal+6fs W6dx9reuA8FWc5oUX5IcPpD70EuaTq4J3DLsfsRxDuEpl/bRTa0NCau6kDkJn3VnhwS4Zdj9irHc JJCfcED1WfvBL1mfvBLhl2P2I4h3DY3BLcgeqz94fepC2v8AeH3pcMux+xPEO4S7lbY4eiPgqHrV fvBHZk0enHqNBjxQ4Zdj9iuIdwiH0ikSoerVP0h96f1af3h96XDLsfsVY7hi5vdJr40KXq1fvD71 Bz6+zh96XDLsfsVxDuGwHBLcgNtZ3cFP1av3h96XDLsfsVY7hnKUqHq1fvj70vVq/eH3pcMux+xX EO4SPMhBIhOba/3h96i6ys8OCXDLsfsVxDuF4S2phZX+8E/qV/vD70uGXY/YriHcLEJNCb1GfvBP 6lcfSCXDLsfsVxDuF4Kbal6lf7w+9L1K/wB4felwy7H7FcQ7hTgk3hNvrP5w+9NvYPzglwy7H7Fc Q7hmkm9Sv94felvr/eH3pcMux+xXEO4VCRgcpb6/3h96BlWRS41+50aAamUuGXY/YoEXuHM6p1Vt bjTW7UfS8B8VgZPVDZ7Q6R8ICWbi9RseQ2iwhxlxDTBVIdM6mST9ms8vaUz25HUg/Yy+5GIoEN7B o3mG6ufyY1XS4uEymraG6xyqvRME49IdcIsPIPIW011enuGiilGd1wy+xswljEbMo35ucaXHcCIj RCawtfJJ+S1bfTdqHCVVsrBEtiUOCf7svsTxw/ej9rSuMTP3+Kx8tjgSWag9hqtW+u4ghjHEeACy 8jHziCG0WH4NKdGE/wB0/YxTnD94fa4lzmkkfeOFXI10V+3pnUXun7Naf7BQz0rqX/cW3/MKmEJd j9jXMo9w0lNoLW+Ss/srqZMfZbf8wqZ6T1KYOLYR/VKPDLsfsRxDuGgSm1K0q+i9QefdjvaB4tIW ti/Vv9E590tcB7W95QII6H7Exo9R9ry8FPtWrf0nNDyGY1jgOCGlV/2V1L/uLb/mFHhl2P2I4h3D Xroc7UBX68KQHOIcD2JhDZ07qjTIxrR/YKtVY3Vm/wCBtjzrKPDLsUcQ7hZuIxg5dW7trIUHkt0d E/vNVo1dUIIOM50+LCgWYGcTP2SwH+S0o8MuxVxDuGja/WRqFXc7VXn9M6kT/Rbf8woR6V1P/uLb /mFDhl2P2Ksdw09O6Ywrh6V1P/uJb/mFN+yep/8AcS3/ADChwy7H7E8Q7hplJXP2T1P/ALiW/wCY Uv2T1P8A7iW/5hR4Zdj9iuIdw00lb/ZHU/8AuJb/AJhS/ZHU/wDuJb/mFLhl2P2K4h3DUBRWuBBR /wBk9T/7iW/5hTjpXUx/2kt/zClwy7H7FcQ7hpq70vLOLlMf+bMOTfsrqf8A3Et/zCnb0vqYM/Zb f8wocEux+xXEO4fRMXNFlLSNdOUb7W6FgdCdlNxhVk1PrczQbgRIWtIQEJdj9iuIdwze8uMlDKdM jwy7H7EcQ7hYpoTpJcMux+xXEO4YwmIUkyXDLsfsVxDuGEapd1LaltMo8Mux+xVjuGO0lJrJKOGt DedUTGqrc6bHhg8yhwy7H7FWO4Y14wPaSjfY3v0AWhSMFg1uYfmFYGVhNGlrPvCbUux+xdce4aFH SGjV6ufZaa26BO7Ox+1rfvQn5VDv8K37whU+x+xVx7hG6usv0CGaWSNFP16N0+o370zrqJH6RvPi jwz7H7FcUe4f/9Cf2nG/0zP84f3pfacb/TM/zguZSU/3o/uhh+7j94vTfacf/Ss/zgnGRQeLWH+0 FzKNTyl96P7oV93H7xeh9Wr99v3hP6tX77fvCymjROAj95P7oR93HcumbqRzY0f2go/acf8A0rP8 4LGyBoVTAKeMxPRacIHV6U5OMObmD+0E4yMc8WsP9oLmLQdiJS2GBO909ke0O70nr0/6Rv8AnBL1 qv32/eFhtBRGgoe6eyvaHd2PVq/fb94S9an/AEjf84LHeSBCGSA0lMPMEdAuGAHqXbF9B4saf7QU vUr/AHx94WFjt3OlXAmnmj+6Fw5Ydy6PqV/vD7wlvZ+8PvWHl5wxbGMLNwcJmVKrqeK/Qu2Hwch9 7l+6Ffdo/vF2t7P3h96fez94fes9r2uEtII8lMFL73L90J+7D94t3e394felub4hVAnS+9y/dCvu w/eLa3N8Qlub4hVk4S+9y/dCvuw/eLY3N8Qlub4hAlJL73L90K+7D94p5HipbXeBQERlr2fRMeXZ L73L90K+7D94pNj/AN0/clsf+6fuU2ZfZ4+YRm2Nf9Eg+XdH72ewQeW8S1tj/wB0/clsf+6fuVtP CP3k/uhHsDuWnsf+6fuSFdh4YT8iriNUYal95P7oV7A7lzdj/wB0/clsf+6fuV53JShL7yf3Qr2B 3LR2P/dP3JbH/un7lehNCX3k/uhXsDuWlsf+6fuTbHeB+5XoTQl95P7oV7A7lp7H/un7ktj/AN0/ croCeEvvJ/dCvYHctH03/un7ktj/AN0/cr6ZL7yf3Qr2B3LR2P8A3T9yWx/7p+5Xk0JfeT+6FewO 5aWx/wC6fuS2P/dP3K8QlCX3k/uhXsDuWjsf+6fuS2P/AHT9yvQlCX3k/uhXsDuWjsf+6fuS2P8A 3T9yu6pJfeT+6FewO5aWx/7p+5LY/wDdP3K+mhL7yf3Qr2B3LR2P/dP3KL/YNz/aPE6BaEIOXR6+ O+vuRol95P7oUOXHcuf9rxRP6evTn3t0/FSbkY7wSy1jgOYcDC5PIZ6Fl9VjYcYc35HVXOlBjjcz gu2uaPEAofe5fuhd91jfzF6RPtd4FHZUA0IjRChPPyB+Qfazj4fGr4z9jUg+CaQOSrFsFVLAJR+/ y/cH2q/0fH98/YubKxy4D5hRORjjm1g+LggurDuyDZhtcCCEfv0v3R9qPuEf3j9jZObhjnIqH9tv 96X27B/7k1f57f71g5nSxMgR5qkcalkhzASe+o/gnDnD+6GM8lX6RerGbhkwMisnwD2/3ojL6bHb a7Gvd4NcCfwXHsLKgSNvk0DT5zqV0v1cxgMc5Th7rTDPJo/vKEudkBfCEx5IE1xFv7Hfun7kx9v0 tPirj3hjVk5twAJPdNjz8j+gPtXy5GA/TP2JXZWM36VzG/FwH8VA5+COcmr/ALcb/euXziHmZWTY 3XVTDmT+6GA8uAdy999vwf8AuTV/243+9P8AbcP/ALkVf57f7154JR6vhKX3k/uhHsDuXvftmJ/p 6/8APb/emOdhDnIqH9tv964ncB+bCFY4Hv8Ael95P7oV7A7l7r7fg/8Acmr/ALcb/el+0MD/ALlV f9uN/vXn7j9ygYS+8nsFfdx3L6H+0MD/ALlVf9uN/vS/aGB/3Kp/7cb/AHrzuEyX3k/uhX3cdy+i /tDA/wC5VP8A243+9L9oYH/cqn/txv8AevOU4S+8n90K+7juX0X9oYH/AHKp/wC3G/3pftDA/wC5 VP8A243+9edJJfeT+6Ffdx3L6L+0MD/uVV/243+9L9oYH/cqr/txv9687SS+8n90K+7juX0T9oYH /cqr/txv96X7QwP+5VX/AG43+9edpJfeT+6Ffdx3L6KM7CcQG5FRJ4Ae0n8qONdRqvN6XFtjXDkE FeiYFnq47XHuAl95P7oV93HcpIKUFEIShL7yf3Qr2B3KOElOEoS+8n90K9gdywSRQw8qLxCX3k/u hXsDuWEE8KQY88NJ+ATNa4nRW6GPbqSl95l+6FewO5a3pW/uO+4pelb+477itNrvvTOklD71L90K +7juXM9Oz9w/cU/oXf6N3+aVpAQ5W6hKB5uX7oT93HcuH6F/+jd/mlL7Pf8A6J/+aV0YY0c6qL7m DT8iX3uX7oV92H7xed9G7/Ru+4pejd/o3fcVtmxu4HhObqwYS+9y/dCvuw/eL//R51JJIJqV0anl BR6OUgputGikBqk0aJwNU9DWyG6KoGrdr6W7IHOnkrNX1aB5lWIx01YZS1easb7UauuGhdFmfV1l eOXtGoVzpfRca7Ga+xoJKdQq7W2XlmsUw1dwzoeA3/Bg/JRyej4PoPLamggTMJhlHuuo9nhH8qnm 2+nXAOpV69oZY8DgErDz7S+4NHYqKQ1ZAdHXwfoz5K4qeF9EfBXFCd2QOJ1972W0Fvdp0+ay/tDm mLGEH/XxWt19hcaCBJG7j5LNzn1WOY6t06a6QnxA4bWE+qmVWXtMssLD9y0KerZDY3EWBYRASBc3 VpISpNvV09Xodo8Fh+8K9XkVWCWPDvmuKbkWt5h3xR680A6y0+ITeFNvZynXN4/VbmwG2h48HLRq 6ww6WsjzGqFJt1E6r1ZePb9B4nwOhRwUEsk4UU4SUyTg+CinlJSdmRY3k7h5o7Mmt3PtPmqYSSRQ dGRz+KLWRCy2vcz6JhHqzC0Q9s+YTge60js2XOG4pbghNeywy0z5d0SE5bqy3JtwTQlCVKtfcE24 JQmhKlWuHBS3BRATwlSrXkJpCQCRCVKtW4Jbk0JQlSrX3BLcmhKEqVa+4JbgmhKEaVa8hKQmgJbU qVbLcEtwTQmhKlWvuCfcFHaltQpVuF9Yulm1n2ugS9k72ju0rC6PcBkMx7NLAYYT31mF3UaR2PZY +X0Gl2TXlUjY+t7XEDgwZQIXxlfm6GdmVYdO9/I0A81jjq112rXbWqP1oD3vbtJ2gzCwzlto5+Si 4A2DkP0egb1B4+lr5owzanjmCuY/aOSTArkHhWMW2++xoayD3SONMcl7PTVbXhG9MQh4tZZWN3KI 9+0KIswa91Qc0+ayb8VhBI0jkLStvGqzr3nc4juiLRIBzLaGTpqTyF2OCwU4lNf7rAuZpoddkMY0 SXOC60VnbtHYQEsh0AWwFElrZDzBiVg9RsG2Q4z3XQWsgQVkZmPuBEaFKBoqnGw89ZYHz3PiqVoa r2VQ+pxLfuWfaZ5GqsxOjTkCDqiJAKmy4t0lBMJkUN7c17Y3bY+9V3jU91odE6fTlPdblO20Vnjj cfCV1NWb0dlf2dmPUBxMAkpksgBrdlx4DIXYDwRhRXa9Q+r2Fl1G7FApsidPon5Lj7qH1WOqfo5p gp0ZCWy3JjMDr9qFLROQoorF0ydJJSkkkklLhJJJJSkkkklMqxL2gckr0Pp0sxK2kawuE6dSbsut kSJEr0CmvYwDwCSCU0qQhPtOyUKSEUWlABU2hg1VaT4qTSYSVad1jRoEMlpKASZTiZSpVtpm1oRq 3bgW/cqjSj1y0ghAhNpGOh0FWms3IBax/u4KI27YI8E0pZOaGujuk2xwMBV7bpMof2kjhKlW6Jc4 jUobiAOVQOS9QN9hR4VW3S5sjVPuYs02vS9R/ilSLf/S51OkkmJUrFHKArGPyiFFvNGidvKQ4Uhy pBuEPQdM4C1gYWP006BaoKsFr3qw6g79Vcn6RphtQeou/VijdJP6o0JEeg+agdXQQssxjWf1SihA zdMW3+qVB1ZOj5vnP2B58yucscXWz4lbPVbPc5o8VkBnDj4p5CLd/C+iPgriqYf0R8FbVY7s7kfW CRXQ4GCHO1HwWM59zPbZ3HDhK2+vtnGqjX3x94WVkPZZQ2RttbAIjt8VJD5Tqxy3GjUSSSSSpNCs 4uO28vBJBaJEIlnTrmn2kO/BOEDVhaZC6LShTZdaz6Lj8DqpPouZ9JhhDTa7rrbLM5w+m35hX8fq z26NtI/ku4WOkgQm3q6esT/OMn+U1Xqc3Gt+i8A+B0K4hr7GfRcR8FYZm2t+mA7z4KBinie4BTrl Mbq7mQG2Fnk7hatHWQf5xsj95qbSbdgcJKtTm49v0XifA6FWAUlLpJaJBJSp+SKzIsboTuHmhQkk pv0Wtve2se17jAB4lX/2bleDfvWRinbkVO8HNP4rsE8LCHF/ZmV4D70v2ZleDfvW0kiinG/ZuV4D 70v2bleA+9bKSSqcb9nZX7o+9L9m5XgPvC2UklU437NyvAfeE37Oyv3R94W0kkqnF/ZuV+6PvCX7 Nyv3R962kklU437Nyv3R96b9nZX7o+8LaSSVTi/s7K/dH3hL9nZX7v4hbSSSqcUdOyv3PxCX7Oyf 3fxC2kklU4v7Oyv3PxCb9n5X7n4hbaSSqcT9n5X7n4hL9n5X7n4hbaSSqeP6v0O0YbrCD7HTB1gH z+K4fNodU8tcJC9hzWtfi2tdwWlcdl9IquJBbMqOcgJDybGOJlA+BeVoZY6sOdqXE6rpOl4zQ0GN VUHSzS7Y3iZWvTtxqQO6jySvZlxwpNbDB4LNyb4kAqd+STyVnXWSSZTAGUmln2E90BziUi4nTunD SnUsJdPolLPUfa7kCG/Nb7NsaGVxIzbaMg01nUiQ35KxR1vIY8ts0HiUJYzuiOQbeL01zZ5VC5gJ gJqeoG4ATM+KK4A8pjI5OZiB7TpquYy6H1PLSu6dTM91h9SwQSSRHdS45dGHLCxbyjhBTBpJgK1b QGuPh2U8XGmwEjRTE0LawiSabDXPpxG1cck/EqOFORZ6Y0d2KsvrDiQfkqmPe3EsduaRYOCo9we7 PtWuju15l2H+gyZgj2PHCwutbHZAtYdXjX5Le9VnUcKske8GJWH1lgruFbeyEPmXZtYOWmT9kw4U zVUkknSUsknhJJSydKEoSUsnTJ0lPRfVLCfkZT3NaXFg4Hmu0+w5Y09J5+RVL/FtQ1uFlXRq57Wg +QC7aERS0gl5r7Nl7C30X/5pQvseX/oX/wCaV1UJI6Ko93k/seV/oX/5pUhiZUR6L/8ANK6qEktF UXk/seV/oX/5pS+x5X+hf/mldYlCWiqLyoxcr/Qv/wA0ojassD+Zf/mldNCUJaKovMlmX/oX/wCa UhXlf6F/3FdMlCWiqLzDqMsnSl/+aUM42ZP8y/8AzSurShLTxVReU+z5n+hf/mlMcbN7UP8A80rr ISS08VUXkfsud/oH/wCaUvs2b/oH/wCaV1ySWniqj3f/0+eSCSdMXKVjG5VdWcblEboLfaNFIJN4 TjlSDda7XTzoFqgrIwDoFrNOisnZrndB1E/qxRukn9XaEDqP9HKL0r+jtSPyfVXV0wq/UTGHaf5J VgKp1UxgW/1Soa1C/o+VZx32u+KrPbDW/FXL2y9x81WtaYB8087FHV2MP6I+CtKrifRHwVtVC2XL 68P1Np8LB+QrEDrBUHbTB0Dp0lb3XBOAT4Pb/FY32ndgij0z7TIeOFJDYrJ7hppJ0ySm507W1zfF v5CtHY4GW/Lsszp5jIA8QQtZoJPiPAcqfH8rBk+Zj7tS4bvGUN9VFmrmDzI/1CO6YIGiVYY6A8wD OvmnkLQWi7pzHfQdtJ7H/aq1mBezgbgtjbIJ7DlLae3xhNOOJXCcg4Dq3MMOaQfNMtu2ouMiPMRo qz8Rp5ZHm1MOM9Fwyd3NgKTHPYZY4hWHYn7jvk7RBfVYzlvz5CYYkdF4kOhTMznt0eJ8xoVoY3Vn tgMsP9VyxgFJrPFNMQut6unrLDpcyP5TdQtCrJpuE1vDvLuuHFtlRhrjHh2VirNj6QLT+8EOFPE9 rKcLnMbq9zIh4sb4FauJ1Si57a3Ate7QdxKFJdOkQ9p8CuxHC5FgghdYwy1p8QE6lrJJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTU6nZsxj/KIH8Vz9lrhPmt3qe0itju JJWVY7AbPqkadlWyn1lu4BWMeJtyxc1z4J1UMm4dkDqWVjeq30CASYAHmqdl7joeRygAvJpndaCq pdqoPsMqAeSnALDJO0gom4cquCkbEqVbV6hjudY3IpO2xvdAq+2XNstewFlUb38RKvDdY4MbqXGA PiiZOO+q+zH/ADLWh39pqfE9CxTj+kGfTBZu+loO4XQVAkaqjg4XpUMBEE6kLQaQ0KCZBOjPjBEd WYb9yz+otBaQe44Vqy/aPFY3UMovGh1nVGA1RkOjhZVbWvI7ToFcwqQWAjkqllODnmFq9LZurB8F NLZgh8xdLE6fjeg+24SGiSuXzX41uQ8MEAH2ldHnXuqxXAaA9k3QujdPZjtyspguyLvcA76LR20U cTVk/RmMboAebRwa3VY9Tf3yXR5LJ6tZvyXHwC6jqn2fFa6xp9xENaOAuNvcX2lx1lPx6m1mbSPC 1zwmRCFCFK1lk4CSSSlapJJJKUklKSSlJxymThJT6D9T/rP0vB6fVgXbm5D7CNBodx0JK72ZXgTS WkOBgjhaTeudZ2hgzbtvAG8oofayQOdEl4hZn9RLgXZFjvi4/wB61umfWbq2GQWXGxg5Y8yPxSU+ sp1zfSfrj07Ma1mU4Y150Id9EnyK6Jj2PaHMcHNPBBkJKZJk6SSlk6SSSlk6SSSlJJJJKWSSSSUp JJJJT//U59JJJMXLqzjcqsrOLynR3QXRbwnHKQ4SHKk6rXWwuAtasysnCGgWrUrJ2a53QdS/o6L0 s/q7UHqX8wi9M/mGpfofVHV1GnRU+sH9Qt+CtMKp9aMYFnwUX6QX9HzW1suPxVPJeNzWDxV65wAJ WS9xdcD5oy2SBq9BifRHwVpVsT6PyVlVC2Gh1oT0+zyLfyrnq8fIsqdZW0mtv0iF0nVxPT7vLb/1 QWHi221UWMDS5tg0IPBT4dVs2kmU3tLTDhBCiihNiOjIZHjH4LYqta14czaXNPYwVi45i+s/ygny PbkWR+8VJGXDH6sco8R+j0oy63fztZ/KkG4dvcN8uPyrmmZN7Po2GPCZ/KrDOpXD6bWv/BPGSPks OMu+enyA6p4PkhHFyanbtsxx3WdV1OudQ6s+RkK9T1Sfo3B3k7T8qcJROxWmMh0YukTuaQSfuTaT E6q6M1rx+lqDh4jVNGBZwTW4oqaLmNMggFDOOOQS1aBwDE1vDx4Ibse1v0mkBJTnuw92rmh3mNCh Owu7DHk5ae1QsIaB7d06JhiCuEiHEtHHkjYzN4c3xadVG4fSjxRsAD1AD8PvCiG7IdmlUS25saSV udMb+tVu8CFiOG24eTv4roenNixp8wmSXh6hnZdVSZqYf5I/IuWYJhdPja49X9UfkRUlSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSS4X1nfk00NupaXAAtJHYrz+49TyXv 2b9o1cWgleuEAiCJB7Jm11sBaxjWg8gAAFN4Bd92QZSI8PZ8l6fRa/Kr3kuDDJnxWln0A6tMO/Kr PVcjB6X1HIrDHOduJAGgAOqw87rb8gbaqtsmJmSoyCZaDZlEhw6ndkGumDyp7YVeg5IZNvKIbD3S UCycYQXO1Sc+UIzKVKt1uiU+plG1wltIn5nQLZvxan2MuOpBQ+j4ZpwWkiHW+93z4VkEbhrweFEZ erTyZRH0a+anua0QFUsuiUG68ydYMqs+xxOqHCriXvyCQRKxsix0mT8loPBPz7qjk0O3Ajg8qWDD MktI+4QfFb3S4FAI7dliNaS7QcHVamDurDvB2sJ09luPQtnLmxzWxuE6hSycp9AYANgA0ahutDLA 8dlmdRzH3OPnooxG2YyrVBnZz73kTKpFvdOBqibZUo00DDIk6lrkd0IiCrTmkKu5qcGIsYSTpkUL Jk6SSlkk8BKUlK0Ug08pgddVsdIzMSm0jIx23NcIaHcA+KIq9UEuRrKsVMiD27rR63Zim9hpYAW/ S2gAfCAs51s8aDwRIo1doBsMnESU49ug7oM+5ObNZ8EEpy7c3zC3fq517IwchtbrXek780mW/CFz bXHVHYQ5kgw5FD7Xj3i6ptnG4SjLhvqd9ZN1TcDMOrTFVn8HLt2nTxSUD0LJJJJBKkkkySl0ySSS l0kySSlJJJJKf//V59JJOmLlK1i8qr2VrE5To7oLpAaJJDhJSLXXwBIC1WCAszp3AWqBorB2YDu0 +p/zCJ03+YaodTH6up9N/mGo/oLero1ql10/5Ps+CusVDrx/UXgdwo/0gufNso8hZ0fpW/FaGWCC QVn8Wt+KE9l0d3osX6PyVlV8X6PyVhVS2Gr1QT0+/wDq/wAQuYqrsfJY0nbqYXVdQE4N4/kFc3hZ LqC4saC8xBJiE+FHdbPTZAdeTJ81EhJxduM8zqmBRQyqMWMPgR+VGyWbsmwTGs/ggNPuHxVvJG3L d2kA8x2Tj8h81v6Q8ms+vYGmZ3CfxI/goo1/0az/AFhzP5yCmg6JK6SSdFDNl1lf0HlvwKO3qF4H uh48wqqeNEQSNiggHcOlR1Nk6h1Z8WmVp0dS3fRsDvJ2hXNN5RQnDIeuq0wD1H2iiwfpa4/lBV8i qogek4wefJYld91f0XkeSuUZtj3tY8AyYngpwmD4I4CGpe3a97eYSwnRezzKLmN2ZLx5/wAFWoO2 5p8HBM6/Vf0+jDKG293k7+K6HAGrT8FhdQEXv+K3+n611nyCZNfDZ6WvgLpcT+jVf1Qubr4HwXR4 RnFq/qolATpJJIJUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpodR6 Z07LrfZlYzLnMaTJEOMDiRqvL7a6qr7PRZtaHGPvXrxWD1zoeBZiusqqbTaDMtET4gpEXovjLheF q3ObxKjYyNVpejXQ0juFnZNoJICh60z9Gs5XekYP2zKAf/NVw6w/kHzVEytzpWRTi9ONpPvfYd3w AEJSujSo1xAF6R9Vr6gyoQ3iQs23EyMV7XvMgnUp8f6wsDPc4eQQcvrJyXMaCNpcAB81CB4M5PiH NyXfpyAe/CUSNOVZyMb9LuUSwAdvgnsSBo1ABkpPq3N1Cm0EFJxkpIaxqY3gQSn3BgjxRXccIFoc it2R2OmQFm3VmVoEEIVjARCcNFbuaGaogarHowpCko2imqWaKs+oytUUpn4wImEgUGNuI9pBUFfv xSCSQqbmQU8FiIpgklCSKFJlNtT3cDTxU/Qd4SlSrRBGrmZ8EMD3QVYDWHySQjedxk6qGsormsHe Shu07fJFSpTSlH+5KPFBS8wpseWocSU6Km/07MOJlC4fRnUL1Po3U68jHrcHbmPHt8R8V5BUddV0 fQOrX4NoaDNJ+nPYeITgVpD6qE6qYOWzJpa9pmQD8laQK4GwpJJJBSkkk6Slkk6SSlkk6SSn/9bn 062f2Ti+L/vH9yX7JxfF/wB4/uUn3bJ4fax+/DxcdWcTlaH7KxfF33j+5Tr6fRX9Eu+Z/wBiI5bJ 4far34eKm8Jd0cVNHil6TfNP9ifgt96Hi6GAYha44XP1Xvq+jHzVkdUyR2b9x/vUpgWPjFtvqf8A MKfTf5hqzL8269u14EeQUqc++lgYwNgeI/2o8B4aW8Qt6Jqodd/ohVEdYyx2Z9x/vQsrqF+VX6do bt/kiD+VN9uVp4w8d1EQ/RZcTa0ea667pWLeZeXfIj+5A/5vYG4OmyR/KH/kUJYpHsuGSPihxvoj 4KwrLMGlggF33/7FP7LX5qD7tk8PtZvvEPFzs0Th3j+Q78i5Omiy922sSV3dmHTZW6t07XgtMHsd FVxuhYWK8vrLyTp7iD/31Ohy8xvS2WeJ2t4t7Cx5YeQYKW3SV17/AKt9Pe5z3OsJcZPuHf8Aspv+ bPToibP84f8AkUfYn4I96Hi8gFdyv6Q0+LRrMLov+bHTfG3/ADh/5FEf0DBe4PLrAWiBDgP4I+xP hI0Qc0bB1eTvM1sP8pw5nwQl17vq509zQ0us0JM7hyY/k+Sj/wA2OnfvW/5w/wDIpo5eYHT7U+9D xeSThdZ/zZ6d+9Z/nD/yKcfVnp371n+cP/Io+xPwR70fF5QDxT9l1X/Nvp/jZ/nD/wAin/5udP8A Gz/OH/kUfYn4K92Pi8kOUULp/wDm107xs/zh/wCRUh9XcAd7P84f+RS9ifgr3Y+LzACJSYtZ/WC6 P/m9geNn+cP/ACKk3oGC0hwNkjUe4f8AkUhgn4K92Pi4XUR+tu8wD+CpDSz4EFdbd0XDvfveXzAG hHb5IX/N3AmZs/zh/wCRROGdk6IGWNB5zqI/TE+IBW50zXGqP8kKzd0HBuMvNkxGjh2+Ss4/T6Me ttdZdtboJMn8ibLBMnSl0c0Bvbq0/Rb8F0OD/Ra/gfyrl23PaABEBW6usZdVYraGQOJB/vS9ifgr 3oeL0qS539u5vgz7j/el+3c3wZ9x/vS9ifgn3oeL0SS539u5vgz7j/el+3c3wZ9x/vS9ifgr3oeL 0SS539u5vgz7j/el+3c3wZ9x/vS9ifgr3oeL0SS539u5vgz7j/el+3c3wZ9x/vS+7z8Fe9DxeiSX O/t3N8Gfcf70v27m+DPuP96XsT8Fe9DxeiSXO/t3N8Gfcf70v27m+DPuP96X3efgr3oeL0SS539u 5vgz7j/el+3c3wZ9x/vS+7z8Fe9DxeiSXO/t3N8Gfcf70v27m+DPuP8Ael93n4K96Hi9Ekud/bub 4M+4/wB6X7dzfBn3H+9L7vPwV70PF6JJc7+3c3wZ9x/vS/bub4M+4/3pfd5+Cveh4vRJLnf27m+D PuP96X7dzfBn3H+9L7vPwV70PF6Iqvk0NvYGOJADgTHeOyxf25m+DPuP96Y9bzD2Z9x/vS9ifgg5 oeLjda6Nm0WOdW02Uky17ROnnCw3YOQPc9haPE6Lr7+o5N4h8AeAEfxVG6pl4iySPBD7tLwX/ehs 8fk2Fkhvbuq1OVayWk7mu5aV1VvQsK36RePgR/chD6t9OBkGz/OH/kUfu8uwWe+Luy4N3ptDbffL /wA3doI+S2Oh4FmTkV5D/wCaYA4A93K3Z0LBtDQ4vAaIEEf3LRx2txqm1VCGsAAnnRMny0yKFfay Y+agDciVspjW2OCzrpDjHYLTsHqGXcoTset3MqP7nlv9H7WT73i8fsc4E90x58FfOHSfH70xwaT3 d9/+xL7nl/q/ar73i8fsc8mEKxwHxWoen0Hu77x/coHpeMdS5/3j+5Ecpl8PtQebx+P2OM5wHOqB ZYt49GxD3f8AeP7lA9Dwj3s+8f3J33XJ4faj71j8fscak7jqrTKp7LSr6PiV/RL/AJkf3IwwaAI9 33/7EDymXw+1I5rF4/Y5QqHyTGpa/wBip8/vS+xU+f3ofdMvh9qfveLx+x5/IqERCy7qNdF2LunY zuZ+/wD2ITui4bjrv+8f3Jw5bKO32rJcziPf7HjG41tjwxjS5x4AWljdE73e9/7o4HxK6WrpeLS0 hgInkzqUcY1QEAQApI8vLrTGc8OluCOmMA4+XZCuxK2Agc+C6M49Z8R8EA9MxiSSXa+f+xO9mXgj 3oeLwVoLbXA6QUwd4rs7fq10215e42AnmHD/AMiof81emfvW/wCcP/Iph5efgn3oeLyYsAHtAHn3 SBBMePJXWf8ANXpn71v+cP8AyKX/ADW6Z+9b/nD/AMil93yeCveh4vKudWwQ0SVD03fSdouuH1X6 aDO63/OH/kU7vqz053Lrf84f+RS+7z8Fe9DxeOJhMSuw/wCavTP3rf8AOH/kUv8Amr0z963/ADh/ 5FL7vPwV70PF5Fhggq7XbrB4PZdF/wA1+m/vW/5w/wDIqX/Nvp8zut0/lD/yKIwT8PtQc0PF0Pqb 1Z/rDFefYdGA+C7oLgsTp2Ph5DMijcH18AnQ/Fbn7czfBn3H+9I4J+Chmh4vQp1zv7dzfBn3H+9L 9uZvgz7j/el93n4J96Hi9Ekud/bub4M+4/3pft3N8Gfcf70vYn4K96Hi9Ekud/bub4M+4/3pft3N 8Gfcf70vu8/BXvQ8Xoklzv7dzfBn3H+9L9u5vgz7j/el93n4K96Hi//XpftLO/0I/wA1396X7Szf 9CP813963/8AnF0r/SO/zHf3J/8AnF0r/SH/ADHf3LL/ANLc/wD+Jcn4/wDes33Tl/34/wAvq8/+ 0c3/AEI/zXf3o1OZlP8ApVR/Zctr/nD0v/SH/Md/cpM6505/0bCf7J/uRHxbn/8AxJk/H/vVfdOX /fi5wdaR9H8CnDrf3fwK1h1PDP5x+4pftLE/eP3FO/0tz/8A4jy/j/3qPumD/OR/l9WpRjep9KQt Gvo+O4SbHA/Ef3KdNjbv5vX8Eb0LfD8U4/F+f/8AEOUfb/3q37pg/wA9H+X1c7O6dXj17q3OcfAw fyBPi9NqurD3uc0nsIH5Qr1zTSwvs0aPmnrqfawPYJa7UJf6X5+v9w5PPX/vUfc8F/z0f5fVC3ou KebH/eP7lXz+mU42ObanOe4djB/IFo/ZbvAfeh3tOPWbbdGN5PKH+l+fv/cWT8f+9T9zwf52P8vq 8lblZbWuLawSPEO/vWb+2upbw37O2CYJ2v8A71146xgGfedOfaVWd9aOjNdsNrt0x9B39yJ+Lc// AOIco+3/AL1Q5Tl/87H+X1curKyXj3Vx8iievf8A6P8AArYb1vp79WvP+af7lL9r4P75/wA0qL/S 3P8A/iXJ+P8A3rJ905f9+P8AL6uI+/IDHOFckAkCDyAsnF611XIe5px2sgTPpvP/AH5dier4IBJe YGv0SqH/ADx6D/p3f9tv/uTo/F+f/wDEmSX2/wDerTymD/ORDzV/XerU2ur+zsdt/ODHwf8ApIf/ ADi6t/3Fb/mP/wDJLqT9cegj/DuPwrd/cm/55dB/07v+23/3Jf6W5/8A8R5fx/71X3Tl/wDOR/l9 Xl/+cPVv+4rf8x//AJJWLet9SY6oNxmkPaC72u5+9dD/AM8eg/6d3/bb/wC5Sf8AWzojA0uucA8S 32O4+5H/AEtz9H+h5fx/71B5Tl7H6yP8vq80/rvVGs3DGbO6I2vOkT2chjr/AFY/9pm/5j//ACS6 o/WvooaXG50AxOx3J18Ew+tvRD/hnf8Abbv7kB8W5/8A8SZT9v8A3qvunL/5yP8AL6vLft/qw5xW /wCY/wD8kk36wdVJj7K3/Mf/AOSXWD6z9HLd3quA82O/uUD9beiAwbnT/wAW7+5H/S3xD/xHl/H/ AL1X3TB/nI/y+rzJ671UGDitB/qP/wDJJx1zqpIAxmyf5D//ACS6YfWzohIHrO1/kO/uSP1s6IDH rO0/kO/uS/0tz+/3LLX1/wC9V90wf5yP8vq80/rfVBOzHY4Dn2P/APJKTes9SAmzHa3+SGPJ/wCq XRH63dDH+Gd/227+5SP1p6MIm10ESPY7+5H/AEvz3/iLJ9sv+9V905f/ADsf5fV5sdb6gXf0YAf1 Xf3p/wBsdTkA47YPcNf/AHrpR9ZukOEi10HT6Du3ySH1m6QeLHf5jv7kP9L8/wD+Isn4/wDeq+6c v/nY/wAvq4GX1PPoc0V0Bwc2TLXHX5FVP271SY+zN/zH/wB67erPx7SAzcd2o9pCqZP1j6Vi3Gi+ xzbG8jY4/wAET8W5+/8AcWUfb/3qBynL1/Ox/l9XmMnrHUqdhbjtIc0O+i/n71dwM3LyaG2W1Brj IIAcPyrYs+s/SKmtc+1wDxLfY7j7kXH6903Jr9SmwlsxJa4flCbL4tz/AP4jyx+3/vV0eU5f/ORP 8vNDVQHtBMglaWN0fFtqD32PDj2BA/KEzMql4BaZB40Vqul9rN7BIS/0tz//AIjy/j/3qvumD/OR /l9Uf7Cw/wDSv+9v/kU/7Cw/9K/72/3Iv2S7938Ql9lv/d/EJf6W5/8A8R5fx/71X3TB/nI/y+qH 9hYf+lf97f7kv2Fh/wClf97f/Io32W/938Ql9lv/AHfxCX+luf8A/EeX8f8AvVfdMH+cj/L6ov2F h/6V/wB7f7k37Cw/9K/72/8AkUb7Ld+7+IS+y3fu/iEv9Lc//wCI8v4/96r7pg/zkf5fVD+wsP8A 0r/vb/cn/YWH/pX/AHt/8ii/Zbv3fxCX2W7938Ql/pbn/wDxHl/H/vVfdMH+cj/L6of2Fh/6V/3t /wDIpfsLD/0r/vb/AHI32W7938Ql9lu/d/EJf6W5/wD8R5fx/wC9V90wf5yP8vqi/YWH/pX/AHt/ 8im/YeH/AKV/3t/uRvst37v4hL7Ld+6PvCX+luf/APEeX8f+9V90wf5yP8vqh/YWH/pX/e3+5L9h Yf8ApX/e3+5G+y3fu/iEvsl37v4hL/S3P/8AiPL+P/eq+6YP85H+X1Q/sPD/ANK/72/+RS/YeH/p X/e3+5G+y3/u/iEvsl37v4hL/S3P/wDiPL+P/eq+6YP85H+X1Q/sLD/0r/vb/cn/AGFh/wClf97f 7kX7Ld+7+IS+y3fu/iEv9Lc//wCI8v4/96r7pg/zkf5fVD+wsP8A0r/vb/cl+wsP/Sv+9v8AcjfZ bv3fxCX2W7938Ql/pbn/APxHl/H/AL1X3TB/nI/y+qH9hYf+lf8Ae3/yKX7Cw/8ASv8Avb/cjfZb v3fxCX2W7938Ql/pbn//ABHl/H/vVfdMH+cj/L6oH9Ew2tLvVfp5t/uVS3p1FYJDnnwGn9y0XUWM EuH4qs++usw6R8kR8W5//wAR5fx/71B5Tl/85H+X1af2GsV7i47vAKlkNdUwuYC4jxC1W5+M55YH HcNSIKhd1PDpE2PI+RKX+luf/wDEWX8f+9V905f/ADsf5fV4/K6z1Gl0Mx2uE92v/vVrpeb1DMa9 91La2t0ENcCfvK2bPrT0aogPtcCf5Dv7leb1HFfW2wOO1w3DQ8FL/S3P/wDiPL+P/eq+6cv/AJ2P 8vq8jm9W6hRkPrqoDmt0BLXH8hUR1nONQeMcbvzhtd/eulP1j6S2ZscI59jv7lGv6z9HssFbLXFz jAGxw1+5A/Fuf/8AEeX8f+9SOU5f9+J/l5uZgZlmVj+o+sssBILYI+eqK62wfmfgVqft3phs9MWk v8A0oZ+snSQdptcCO2x39yYfi3xD/wATZfx/71k+6cuNzFx35uQ06VT/AGSq7uqZomKBp/Jd/eug P1l6QP8ACn/Md/coH60dGGhtd/mO/uS/0t8Q/wDEuX8f+9R915fvF549Yz/+44/zXf3qH7a6h/3H H+a/+9dH/wA6uij/AAzv8x39yX/Ovov+md/mO/uR/wBLc/8A+Jcv4/8Aeo+6cv8AvRebPWupf9x2 /wCa/wDvSb1rqRMHHb/mv/vXSf8AOvon+md/mO/uSH1r6KeLXf5jv7kv9Lc//wCJcn4/96r7py/7 0XIp6hl2c0wf6rlYbkZDj/N/gVqM+sXSn/RtJ/sO/uRh1jAdw8/5pTT8W5//AMTZPx/71eOU5f8A qlyPVv8A9H+BS9W/9z8Ctj9rYP75/wA0qX7Tw4J3mBydpSHxb4gdBy+X8f4JPKcuNTwuKLMgn6EA ckgp/UuJ0Zp8CtgdVwiYDzP9UpP6rgsEueR8ipI/FfiAGvJ5Zfb/AN6xS5XlydJwH8vNyHWWtbJY Z8IKhXbk2PgVwO5IK26+p4lv0HGP6pCm7Pxm8u1+BTv9Lc//AOIsv4/96j7pg/zkf5fVxnPLX7SC fAAGU9jnVtlzTJ4bElaw6jikxuM/AqYzcc8OMDvBS/0tz/8A4iy/j/3qvumD/OR/l9Xl8jK6ixhf VS2Bxua4z9xCyrOvdbr5w2x2Ox//AJJd3+0MYmAST/VKkMuk8T9xSPxb4h/4iy/j/wB6r7pg/wA5 H+X1fPv+cnV/+4rP8x//AJJL/nJ1f/uKz/Mf/wCSXoH23H8T9xULOp4lYJc4wPBpKb/pX4h/4jy/ j/3qvunL/wCcj/L6vBf85Or/APcRn+Y//wAkkPrJ1f8A7is/zH/+SXWP+uHQq3Fr7ngjkem/+5R/ 56fV/wD07v8Att/9yX+luf8A/EeX8f8AvVfdMH+cj/L6vLf85Or/APcVn+Y//wAkpD6xdWjXFb/m P/8AJLp/+en1f/07v+23/wByX/PPoH+nd/22/wDuS/0vz/8A4jy/j/3qvumD/OR/l9Xl/wDnH1b/ ALit/wAx/wD5JOPrF1b/ALit/wAx/wD5JdR/zz6B/p3f9tv/ALkv+eXQP9O7/tt/9yX+luf/APEe X8f+9V90wf5yP8vq8/jdZ6pfYGnGaB39rxp967fE6Ri349dr3va54BLZGh+5Z+L9ZukZdgrotc55 4Gxw/KFttx7XAEDQ+aX+luf/APEeX8f+9V90wf5yP8vqi/YWH/pX/e3+5L9h4f8ApX/e3+5G+y3f u/iEvst/7v4hL/S3P/8AiPL+P/eq+6YP85H+X1Q/sLD/ANK/72/3JfsPD/0r/vb/AORRvst37v4h L7Ld+7+IS/0tz/8A4jyfj/3qvumD/OR/l9UP7Dw/9K/72/3JfsPD/wBK/wC9v/kUb7Ld+7+IS+y3 fu/iEv8AS3P/APiPL+P/AHqvumD/ADkf5fVD+w8P/Sv+9v8Acl+w8P8A0r/vb/cjfZbv3R94S+y3 fuj7wl/pbn//ABHl/H/vVfdMH+cj/L6v/9Dn067z9m9P/wC4tX+Y3+5L9m9P/wC4tX+Y3+5Yn+nM X+an9obf3WX7weEVrE5XY/s3p/8A3Fq/zG/3JxgYLfo49Y+DG/3Ij45i/wA1P7Qj7pL94OA3hSHK 6D7Jjf6Fn+aEvsuN/omf5oTv9P4f81P7Qj7nL94MOmHQLXbws9jGs+gA34aKe9/7x+9PP/GHCf8A JT+0LPuM/wB6LLqp/VijYB/Va/gqzyXja87h4HVJrnMAawloHAGiX/KHDw17U9+4V9xnd8UXTVDr ZjAsUfVt/fd96jYTa0ss97Ty12oTR8fw3ftT+0LjyUq+YPGMOr1gZI/WgP5S9K+w4f8AoK9efaEN 3SumOdudiUl3ia2z+ROl/wAYcJ/yU/tC0cjMfpB5TH+ijLqRg4Q4x6x/YH9yf7Fif6Cv/NCh/wBO Yv8ANz+0Mv3WX7weVP0T8CuNrqNjy0ea9c+xYn+gr/zQgt6P0pp3NwqGniRW0c/JOj8dwjfFM/UI lykjtIPlFjDW/aVFesHo3SHGTg0E+dTf7k37E6P/ANwcf/tpn9yP+nsP+an9oQOTl+8HyiVayf5v G/qL039i9H/7gY//AG0z+5SPR+kuADsKghugmtun4Ij4/hoj2p6+IQeSlY9Q0fM9jnVOAH57SZgR ofDRO01s497vHsP716X+x+kwW/YqIOpHptiR8k37G6T/ANwqP+22/wByEfj+ED+anfmFfc5fvB82 NhcZJkqL2yJHZemfsfpX/cKj/ttv9yX7I6X/ANw6f+22/wByX+n8X+an9oV9yl+8HzEBS2xyOV6Z +yOlf9wqP+22/wByc9K6YYnDpMaCa28fcl/p7F/mp/aFfcpfvB8uc2XwO6uip1gIaCdroHw/1C9D /ZHSpn7FRPj6bf7lNnTsCv6GNU2eYY0fwS/09h/zU/tCPuM/3g8Zi9JvsNe72gan5rZq6VRjwImI 5W+MegcVtHyCc00nljT8giPj+Ef5Kf2hX3GX7wabIYWRoIXF/WcR1V7v3gCvQfSr/dH3IFvTen3u 33YtVjv3nMaT+IRP/GDCTftT+0KHIzquIPnObri45/kkLR6B/RCPB5XZu6V0xzQ12JSWjgGtsD8F Ovp2BUNtWNUwHWGsaB+ATZfHsJ/yU/tCY8nIfpBpYv8ANs+C6Hp39H+ZVAU1NENY0AcAAIrXvYIY 4tHgDCX+nsVfzU/tCfucr+YOoksz1bf33feUvVt/fd95Q/09i/zU/tCvukv3g6aSzPVt/fd95S9W 39933lL/AE9i/wA1P7Qr7pL94Omksz1bf33feUvVt/fd95S/09i/zU/tCvukv3g6aSzPVt/fd95S 9W39933lL/T2L/NT+0K+5y/eDppLM9W39933lL1bf33feUv9PYv81P7Qr7nL94Omksz1bf33feUv Vt/fd95S/wBPYv8ANT+0K+5y/eDppLM9W39933lL1bf33feUv9PYv81P7Qr7nL94Omksz1bf33fe UvVt/fd95S/09i/zU/tCvukv3g6aSzPVt/fd95S9W39933lL/T2L/NT+0K+5y/eDppLM9W39933l L1bf33feUv8AT2L/ADU/tCvucv3g6aSzPVt/fd95S9W39933lL/T2L/NT+0K+6S/eDcu1MeCo5OM bBI5T+pZ+8fvS3v/AHj96I+P4v8ANT+0IPJS/eDQo6eWWvucPzVz/V7PcWhdcXEiCZBVd+Dh2GX0 VuPiWg/wR/5QYf8ANT+0I+4y/eD5llDfktb8B95XYZeRThYfqWmAGhrR3JjgLZ/ZPTNwd9jp3Dh3 ptn8indgYORHr49du3jewOj7wl/ygw/5qf2hX3GX7weCB9eltobG6THhqqb2uY0OGjwZBHZekN6b 09rQ1uLU1o4AY0D8iY9L6aecSk/9bb/ch/p7D/mp/aE/c5fvB876fkludV6one4CR56LR6viivIc 9vB5+K7IdJ6YHBww6Q5plpFbZBHyRH4WHYZsorefFzQfyhNPxzF0xT+0LxysusgXzV8jyQiZXpZ6 V0w84dJ/623+5N+yOlf9wqP+22/3If6cxf5qf2hP3aX7wfMiY80pXpv7H6V/3Co/7bb/AHJfsfpX /cKj/ttv9yX+nMX+an9oV92l+8HzGVJp1C9M/Y/Sf+4VH/bbf7kv2P0r/uFR/wBtt/uS/wBOYv8A NT+0K+7S/eDwWNPZaVRMSeAutb0zpzfo4tQ+DG/3KX2DC/7j1/5g/uTT8axH/Jz+0L44COoeZrG8 8wOSfAIhJf7W6MHAXSDDxAIFDADyNoTjFxhxSwf2Qn4/jmCP+SmT5hbk5ecv0gA86GljdNSeAFOv FbIstO49h2C6D7Nj/wCiZ/mhI42Oeamn5BSf8oMP+an9oY/ucv3g4N2VVQIaJedAB4qLPVfq4e48 nwC3fsWHId6Fcjg7R/cpjHoHFbR8gl/ygw/5qf2hX3OX7wcmqgASZg/eUX0p50C0/Sr/AHB9yXpV fuD7kv8AlBh/zU/tCvucv3g0GV1s4180z3dhytD06/3R9yb0av3G/cEv+UGH/NT+0K+5y/eDkOYq 9le6Qt800nljfuCb7PR/o2/cEv8AlBh/zU/tCvucv3g+ddb6U9pN9Yn94Bc8dDBXsrsTFdo6lh+L Qq7ui9HcZdg45J5JqZ/cmn49hP8Akp/aFfc5fvB8jhIAr1v9h9G/7gY//bTP7kv2J0b/ALgY/wD2 0z+5D/T2H/NT+0K+5y/eD5JOqm0EkAakr1j9h9G/7gY//bTP7kv2J0f/ALgY/wD20z+5L/T2H/NT +0K+6S/eDyP1c6a8kZNRO9h9zfIL02gzSw+IH5FlU42PQIoqbUPBjQ38iOLLBoHEfNOPx/DX81P7 QgclO/mDppLM9W39933lL1bf33feU3/T2L/NT+0J+6S/eDppLM9W39933lL1bf33feUv9PYf81P7 Qr7nL94Omksz1bf33feUvVt/fd95S/09h/zU/tCvucv3g6aZZvq2/vu+8perb++77yl/p7D/AJqf 2hX3OX7wf//R6ZJJJcI6ykkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklP/9LpkkklwjrKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSU//0+mSSSXCOspJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJT//U6ZJJJcI6ykkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklP/9XpkkklwjrKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSU//1umSXnPqP/eP3lP6j/3j96wP9BH/AD//ADP7W597/q/i+ipLzoWP /eP3qzjvfP0j96X+gj/n/wDmf2q+9/1fxe8SXJNe6OT96fe7xP3o/wCgT/n/APmf2q+9/wBT8XrE lyldrgdSfvV3GvbBkpw/4vE/5f8A8b/tV97H7v4u8kuM6tY/c0hxifFGodaKN0mPinf8nD/4o/8A G/8A0JYee/qf87+x61JYFNznVBsmVWynOBGp+9I/8XT/AOKP/G//AEJQ5/8Aqf8AO/seoSXF2W2D hx+9RGTdEF0hMPwAj/L/APM/tXDnL/Q/F7ZJcWx7o+kfvU97/wB4/emf6DP+e/5n9q771/V/F7FJ cdvd+8fvRK7SDrJ+aX+gz/nv+Z/ar71/V/F61JcyMkjt+KmMxw7fil/oM/57/mf2q+9f1fxejSXP DOf4fiUvt1nh+JS/0Gf89/zP7Vfev6v4vQpLn/t1vgPxT/brfAfil/oM/wCe/wCZ/ar71/V/F30l g/brfAfinGbb5Jf6DP8Anv8Amf2q+9f1fxd1JYf2uzyS+1WeSX+gj/nv+Z/ar71/V/F3EliDJsPg pDIsS/0Ef89/zP7Vfeh+7+LspLHF71IWuR/0Ef8APD/E/tV97H7v4usksr1CU4d4pf6BP+eH+J/a j72P3fxdRJZmiBkOc1uiX+gT/nh/if2q+9j938XaSWLjuPpjVa/Sam2Gwv1iIRHwEn/L/wDjf9qD zlfofizSWh6NY4CX2eo/mhH/AEAf8/8A+N/2o++H/N/87+xz0loDHqH5oSfUwtIhL/QH+v8A/G// AEJX30/5v/nf2Oekmf7XFp7JMYXuCP8AyfP+f/8AG/8A0JZ/pD/V/wDO/sXSVwVe0BIN2STqEv8A k+f8/wD+N/2rxzv9T/nNNJXm2t8E+4Hsl/yel/n/APxv+1X34fu/i0Elo6eCXyQ/5Pn/AD//AI3/ AGp++j9z8XOSV9xA5CQLSj/yel/n/wDmf2o+/D9z8WgktEwkGgpf8nz/AJ//AMb/ALVffR+5+LnJ LRgeCRAQ/wBAH/P/APjf9qvvv9T8XOSVx7ADPZZ+bfoY0HZR5PgnBX6+yf6n9rJi5gz/AEKHmkSX M5eS7cdSsy7Iefzj96A+Ck/5b/mf2rzmA6PcpLzuy18/SP3oQfYTG8/eU4fAj/nv+Z/asPM1+j+L 6SkuJ6dcR1XDx9xgHc/XuV6P7Qyeyf8A8nzV+/8A+N/2sZ50A1wf85zkkrrh6sjgLRrLXMDhwUB8 BJ/y/wD43/agc8D+h/znOSWnDVE7Uf8AQB/z/wD43/an76P3Pxc5JX3NY4FrgCDyCue6p9Wa75tw X+jZz6ZJ2H4eCX/J8/5//wAb/tV9+H7n4ukkuFy8TqOGS2+p7Y/O1I+8Kz0XGttcb7Sdjfogk6lH /k+f8/8A+N/2q++j9z/nPYpLJdb6TS93J4CrW5ZAknUo/wDJ4/5//wAb/wDQk/fP6n4u+kuPtuss d9I/ekyqyx3Jj4of8nj/AJ//AMb/APQlffP6n4vYJLn6MZw5JV1rYCX/ACeP+f8A/G//AEJX3z+p +LppLKc/byVRyMqJgpf8nj/4o/8AG/8A0JX3z+p+L0aS4uzIse76R+9PULHO1cY+JS/5Pn/P/wDj f9qvvn9T8Xs0lxWdmuqZ6dbjJ7yqNBewGx7iT8Sl/wAnz/n/APxv+1X3z+p+L6GkuAo9W+7cXHaP MqXUc41N9Njju+KX/J8/5/8A8b/tV98/qfi96kvMaXv1sse7XzKTLnvunc4VjnUof8nz/n//ABv+ 1X3z+p+L6ckvPnZEgMqcdOTKTbXO4edPNL/k+f8AP/8Ajf8Aar75/U/F9BSXCssf+8fvQMu1/Zx+ 9L/k+f8AP/8Ajf8Aar75/U/F9BSXmzb3tH0j96KzJfP0j96X+gD/AJ//AJn9qvvn9T8X0RJcBZc8 idx+9C9az94/eUv9AH/P/wDjf9qfvn9T8X0RJea2us3Ah5j4lHDrH16OM/Eo/wDJ8/5//wAb/tR9 8/qfi+hpLzumy5jvc46ea0G3PbDtxIPOqB/4vn/P/wDjf9qvvn9T8XtElQ+rV7Xmyl2sjc2fxXQi pg4aEv8AQB/z/wD43/ao85/U/wCc5qS0hW2Z2hSAA7Jf6AP+f/8AG/7Ufff6n/O/sctJaTmNdyE+ 0REJf6AP+f8A/G/7U/fP6n/Of//X51OmTpi5QVnH5VZWcflJTfbwnKZvCdOQicYJhSq9WRHdCsPu AV6sNbUCpcYWTNBq9TqIrY48q1XW5uGNNYVfqVodXWB3IW01rDhtA8Ape7EejWx64qa/yVXNMlaE htMBZmXyE2S4NOwocwVJ5UBBKhmyxbDOFJRZwpKJepSaoqTUlMk8pkkksgVJQUgkhkE6gFIFJTJS ChKdJTMFSCgCpAoqZhSCgFIJKZhSBUApAooZgp9VEKQRQvJULRurMojSClY2WlKlIaP5sLZ6K502 jtosanRgW30WP0v9n+KMeiC6hlIEpFKU5QC8pFNKUpKpr2UNc6e6kylrEaEtqFreALBOWByZ3tEp mXNdoOyXEnzX9Jo7J9gTyU4R4j3RwhjtCUBSSStNMdgKQY0dlJNKXEe6OEK2hKIT6qDntaNSmmYG 5TSiNUlFtjX8IeRbsbA5P5EJZAImSoR4pUEWTbIIbwFiZt4AM8q/dbAWJmB1rjCp2ZSst+MeGNBy 73GxxhVrGECStBtETuVXLIClBWSDnPMJUAF8u+i3Un4KFh1Se414r3d3naCpYhgmatL0ix1vWan9 y+QvSMq6xlDfPlebfV4T1aj4r0/IxvWqa3iFN0ast2ljEPbMSVcxXQ5zAdBwFXrxXVgiUfFxrG2O scYaeAloKULbu2UN9Z5B+SMmhC2QjRAWuITCs+KOWBNBRRXdA8ANPqQ5veQsHJsprLrAAysGQ0aB avU7xWzaTAiXfBcfmZb8m7Yz+baU61AUlflWPcbT9HsEF7zaZIjyU66nv/qhWqsSTMJLmvTjk6rS oxw0TCJXj7UYCElMQ0Qh2WBo1KV1zWAyYhYef1MCQCkpsZecBIaVlPvc90TqVVN77XKzSwDU8oXa ktVfijWWimvTlQ3hokqta8vMnhJSEA2P3vUnkvcGNTkwESgBg9RyCkr7GYtE/nQsRznX2l7jojZ2 SbX7QdEFo2tjuUlJI9Vwrb9EImWa6aRUwe48qVDRW0vKpW2+pYXHhJTZoLnsDAdo7lWmtZVAaZ8V Rxnw7cRPgFea22z3OAa1JSZh5Ve8yEQO7BBt7pFTXkcKBeWqLnQUOZKCm/XaXMUST2KZs7R2TJJX EnlWscqs0ayUeo68aIhCexsqeM6Wlh+Sg4iOfkoVuLHghGSg6/Rsz7LnVlxhswfgV3wIIBHBXmb9 HB4Xb/V/qH2vDDXH9LV7XeY7FMOh80uskkkkhSYpJHlJRf/Q51OmCdMXLhWMflV1Yx+UlN9vCSTe Ek5DVyDDgUZtznM2wq2WYKv4NbbaQVLjWz2aOa6PTb3lbuI5zqWg+Cx+p07La/CVvYrG+iIUg2Yk eRLWhUc+AGlaOaBsAWX1AmGgppOiaogNB5UWnVNYVGpxLlDIssW2zhTUGcKUqNeupNUFIJJZpAqM pwkpklKgHtJgeYBjQxzqmL5Dgyd2oBjTcBxKSksp5QWmGt0dueYDCZMxqpb/AKIA1dwCY80lJZUp Qd+oAAkgnUxwpF537RHEweTrGiSkoKkCgst3WuZI9sadyCOUUFJCQFSBQwpBFSQKQKgFIJIZSpAq A5ToqZBxNjWCAXdypmRLTyNCqtgcHtc2TB7I4JOp5KIKFmaCPitjomvqn4LHGi2uh/Qu+I/IiFOp CZSTJygsloouTtCC5kkokgJMcDqEtFpU8FwI8UOio1zu7o6UIVra0i1J0xKgx8z5FFF6pExMJSs7 Pytrwxp45SJpUpU6SYhCxrN9TT4hGKShqEVtvpMJWTdmOLjqtTIbuYQRosK2A8jwUc4i1pJb+HfM kod9xc8mVFg9Kn+U78irW2Qq+WV1EbBu8tjqPEd5ML7eyp8mU9tklV7Lg0coAM5K97mhpCxcp/Ma qxk5MzBWbbYXFSwDDOTGut99raqxLnmAFpfWHAGBhY9J+nMvPnC2/qt0F1bB1HJEOcJpYfD94ql9 eP8ABf1v4KzAaEtTJKzTj/VYA9ax58V6t2XlP1VE9ao+K9WHCSAw2hTCUJQgqqVKeUySSV1WyMpl LSeSpZNwpZPJOjQub6nmlrSCZe5EBQPVo9Y6jZkWGthmeSg4mNtAkSTyU2PQbH7+fErRZX+aBCep VdQmI0CtsaGjhNWzaFMkBJK5IAVTKy21tOsKOXlsraSTELk+o9Vda5zWnRBBbPUOrOJLWlYxfZe/ VBLnPd4ytHEoDQCQhupNjUbAPFWpDRJUR7RJQ3v3mEVLufu+CEXSdOAmsfAgKG4lBSRvudrwoZeR tbsanc/02eaoPc57iSkpZrZO4orAS6TwojiESdjElMcm07doVQBSc4udKdo1QU2qvTqYHO5PCssF +Q2Gna0KhO94B4Cv1McY2na3uQipmMWytu5zpQLtCrbmveRXVLgOSquTW5jofykVNG3Ryi0y4Kd3 MqFQl6AUW4T7QotUncQog9kikJGmEdvEqu2AdUZtnaNEghPt3DTQob2lmpU2HTwULNfNOU2anB9a 0ei9QdhZjXH6DjtePIrJxn9kWdrpTCLCX01rg5oc0yCJBUlkfV7OGRgtY4y+r2n4dlqykEFkhl43 7e/KlKHtAfu7nREIJf/R51OmTpi5SsY/Krqxj8pKdBvCSTeEinIc/OdCvdGumrb4LO6iYBU+jXax KfA6hbLUFvdZdLq45lauC93otDvBYXVXfpaviFs4pitvwUoGhY7rVbOe8PbHEoWfS+5g9MSW6o+Y Qaw4chROXU0aak6aIGtiqzu8/ZLSQeRyE1MF4Wnk4dN7fUY4iw8jsmxunhh3O1KhLLEo9pbykrmR T+j3RwqSjIpeCupBQUkkrpcJpSlJSmDbILi4SS0H82TJSDQzeWcukgE6A+SaNZn5J+UlLNYHsG8E HTRx1Dh30U3hr43DjUKLWgcKUA8pKXJYSHOjTUFSLmhwJ+l2PdMBOgCKzHvf9Cp7vg0lJTDcJ8+E QI7Ol9Qfxj2fMEflVhnQupu/wO3+s5o/ijRRYaQKk0rTZ9Xc8/SdW35k/kCO36t3fnXtHwaT/clR 7KsOQJ7JxPflb1H1foY6brDaP3R7Qit6FhB+473CZ2l2nw4R4SjiDzrZ1n5KUrpn9KwXu3eiARpp IH3KTenYjRpS37pRED3Wmfg8uIOnKK2u08MdHwXStxammWsA+ATvqBbCPCjj8HnGYuRY6G1n56Lc 6Xi2Y1TvU+k8zA7AItNG0yVYiEQFRlakxJjROmRX2hLzKIwkoRcN8IwiElFhbq1PUIYELJtDGqWM /fWCmndjvVOnlMkim2L90aKq15bZtHJ5CtOMBUwR9oaUq1WHdNe60VktWLY6XGTJW/bHpu+C50n3 k+aZPdEnY6e2xtcn6J4CvhV8MzQ1WE8bL47LOAIhYb8cfa3NP0WGStt87Tt57LIu3V7g7V7jLlHl lUbXY4ceQDoNSiuskrPvs5R7ngBZeVkATqqsRZdDYIr7w2ddVQuyCe6hfduPKqvdKmjFhlJVlhJ5 Wj0DpLs/KFlgjHrMuPj5KngYN2fkCtg9o+m7wC7bExhi0NqrENbopYhr5clChu7G5jaw1mgAgBcR 9eOavj/BdoGQwLifrwffV8f4KUfKWEm6cv6pkftqheqjheVfVQT1mleqjgJq8HSl0kySSV0HIyGU M3HU9gnvvbSwud8h4rGuudY82POnZEBDHLyyQbbDr2Hguee5+VfMzKP1DKdfYKWcI+Hi+kySNSnq SU1CpgaArVbBElPXX3KI4hoSUsYCo5mW2tp14T5mY2ph1XJdT6k6wlrTokpXUupuscWtOiyCS4pE lxkqdbJKbuhPi0ydxWnWICBjVmATwjuPZqIUp7iTAQnPDBHdPY8Mb5qqXF5koJZbtxkog117BRYz uUO+4NG1qSmF9u50DhDAhMwfnFImSgpmNTPZRufpCkPa2UBxJKSFlNs8KIRa2yQEktjGo3O4Wg9o qYB4pYVYYNxRHM9WzyCd0UvVbtrhvtWblPJedZVvIJbo1UMiQJJ1KBUGtbwE9AG5RedFKgaoBRbL ghzroiO4Qi4pFQStEozWwgVSVYr1KSkoEhQcxFkcJEjhOQirlr1ZJ0VV5hwRS/gJvVLr9Fz/ALLe dYDh+K7WjLovHseCRyF5rU+LAZ4K6bp+G62o3vv9GeNUgAiV9HqxB4QL3Br6/N4H3lU8fOxsSgVu sNrhyYVe/qdVl1bwCGscCR30MpBBsh//0udSXU/t7of/AHGP/bTP70v270P/ALjH/tpn96zfv3Mf +JMv2tj2of5yLy6sY/K6H9u9D/7jH/ttn96nX1ro7vo45H/W2f3pffeY/wDEeX7Ve1D/ADkXLbwm W4Op9N/0J/zG/wB6X7T6Z/oT/mN/vR+/cx/4jy/aj2of5yLzPUMY3V+3lVum41lNku4XYDqPTnf4 H/oN/vUxmdPPFP8A0Gojn+Y/8R5ftR7MP87F5zLo9Z7Hfuq/U/awDwC1hl4J/wAF/wBFqkMrD/0f /RCP+kOa/wDEeX7Uexj/AM5Fym2WERCb7OXGSIWv9qxP3P8AohL7Xi/uf9EJHnuZO/J5ftT7OPpk i5rMcBGbU0cq79qxv3fwCX2rG/c/AJffuY/8RZftR7UP87Fy+ouZXiuc47QOSudPUsMf4QfLVddn 9T6fi47rcmovrHLQ1rvwJWL/AM6/qv8A9w3f9s1/+STZc7zBP+48v2ro4oD/ACsXIPVsQfnE/AFR PWMfs1xWz/zr+rH/AHDd/wBs1/8Akk//ADr+rH/cN3/bNf8A5JD75zH/AIjy/an24f5yLhnrDO1Z +aj+2Hdq/wAVvf8AOv6s/wDcN3/bNf8A5JOPrV9Wf+4bv+2a/wDySX3zP/4jy/ar24/52LhM6jc8 wGgLY6dS3JINsmfAwjD61fVvtiOH/Wa//JI1f1q6EfoUPb/1tg/78iOdz/8AiLKfqg44/wCdi9D0 7o3Tvs7HvoD3mZLpPf4q+3p+Cz6ONWP7Df7lzLPrZ02Ib6rR/VA/78rFf1jwbPovePj/AL0fvvMd OSy/aEe1D/OxekbXU36LGt+AAUljU51V30LufEkK42q5wltgI/rFH77zP/iLL9qPax/52LdSVP7P kfv/AIlL7Pkfv/iUPv3M/wDiPL9qfax/52LcSVP7Nkfv/iUvs2R+9+JS+/cx/wCI8v2q9mH+di3E lT+zZH7/AOJS+zZH7/4lL79zH/iPL9qvZh/nYtpxDRJ7IP2qr94IL6LmtJc6QOdSqZtrB1b+CI5/ mf8AxFl+1acMP89FvOzqR3Qn9SqHCqetT+4fuCf1KT+Z+AS/0hzHXk8v2o9nH/nopx1SscorOo0v VP1KP3PwCQsp7N/AIf6Rz/8AiPL/AIyRixj/AC0XUbexwkGUnWGOFSpBs+hpHyRHVWN5d+KX+kOY /wDEeX7V/t4/85FlqXyUdrxEFUH2hhhxUPtLfEpff+YP/gPL9quDH/nYpeoWADRNhZbA0NQXZFZ5 BPylIW1dmx8gh995m7+55ftWHDju/di6rLWu1BRJCyW2g/RBRmNsfwSPij9+5n/xHl+1XtY/87Fu vcIKpNO29pdxqiehd4/ioPpe3nVL79zP/iPL9qDggdfdj9ifItaKnQZJGixPs9hJK1BTY7spDGs8 gged5gnXk8v2qODGf8rFniWAVNadCFM3umANEIY1vYj70/2a7xH3lL79zX/iPL9qfYx/52KY3gML naR2WNk3y4uPJVq6wVkteZjmNVTtz8Rn02k/2QVDk57PM191yaeLZw4YwF8QN9XLysmJWLk3lxK6 KzrfSW6OpJ/sNP8AFBPX+h98c/8AbbP70Y83nH/gTJ9q6Qif0wHmHHujdP6fk9SyBRjtnu5x4aPE rqun5/TOo3jHxsQucdSTWwNaPEmVt1dPNM+i1lc87Pb+QJ45zmP/ABHl+1iMYf5yKLpvRaOn44qZ Bdy9/clXRjN7of2bI/e/EpfZ8j978Sn/AH7mP/EWX7WI4IHfLFLa2GadlwX13P6SoeZ/Iu2fTc1p c50gc6lYXVurdLwnNGbSbS7iGNf/ANUU77/zNH+hZftW+xjv+di8r9UR/lqn5r1QcLjMH6w9DuyW 142O6u08O9NjfxaV0zarntDmv0Oo1Kb9/wCY/wDEeX7UjDD/ADsW6o2WNrYXvMAKqaLwJL9B5lVH 3t4cS4BEc9zP/iLL9qfZh/nYo773X2SeOw8Fl9Qyw0em3laV2Zj0iXg/AAIdWVh36tp+ZaE77/zP /iLL9qfZh/nYuVhYpcfUdq4rVZWIRxZT2bHyCc21gcfgl9/5n/xFl+1Xsw/zsUJIaJKo5WYK2kkw rl3UcSoEvBgeQWbf9ZuiVnbZU93/AFtp/K5L7/zI/wDAWX7Ve1D/ADsXmupdSdY5waVjOcSZK7U/ Wf6t98Rx/wCs1/8Akkv+c31b/wC4Z/7Zr/8AJIHn+Z/8RZftR7MP87F4oCSrmPVJC6xn1i+rrvo4 h/7Zr/8AJKw3rXRIkYxH/Wmf3pffuZ/8RZftV7MP87F50Da0DuoPcGiV0x650UCTjn/ttn96EfrF 0Hg4zj/1pn/kkvv/ADP/AIiy/ar2Yf52LyNjy93kjVVTqeAuqb1vobtRikf9aZ/ekev9DH/ac/8A bbP70vv/ADP/AIiy/ar2Yf52LyttgAIaqUF7pK7M/WP6vzH2Vx/60z/ySR+sP1fAn7Kf+2mf3off +Z/8RZftV7MP87F41xhM0TqV2P8Azj+rx/7SH/tpn/kk5+sf1eaJOKf+2mf+SS+/8z/4iy/ar2Yf 52LxljuyEfJdqfrN9W/+4jv+2a//ACSQ+sv1bP8A2kP/AGzX/wCSS+/8z/4jy/ar2Yf52LxrQrmL TucNF1LfrD9XjxiH/tqv/wAkrFfWejO+jjEf9bYP4pffuZ/8RZftV7MP87FxGthoAThza2ku0W+e rdKAn0T/AJjf71RyPrV9X6iWWUOd8K2H8rk77/zP/iLL/jK9mH+di8xmdVYHFlTZPcqkbX2CXLrR 9avqw46Ybv8Atmv/AMkif85vq3/3DdH/ABNf/kk37/zH/iPL9qfZh/nYvGOOiPjQusP1n+rcf0Q/ 9s1/+SU2fWP6vO+jiEf9ar/8kkOe5n/xFl+1Xsw/zsXlnnshLsHfWL6vjnFP/bTP/JJv+cX1e/7i n/tpn96R5/mf/EeX7VezD/OxeVqhWGNMrpW9f6CeMU/9tM/vU/270T/uOf8Attn96X37mf8AxFl+ 1Xsw/wA7F5wCOUgQV0n7c6L/ANxz/wBts/vT/tvosf0c/wDbbP70fv8AzP8A4iy/ar2Yf52Lyljt U+/SV0zuv9Cb9LGP/bTP71E/WLoA5xj/ANtM/vQPP8z/AOIsv2q9mH+di83W/WV0GPkuNDPd2RB9 Y+gHjGP/AG0z+9WautdJe2WUkDw2N/vQ+/8AMf8AiPL9qvZh/nYtU2kwQZT+oeeFe/avTY/mj8Nj f71L9pYEfzJ8Y2N/vS+/cx/4jy/an2of52L/AP/T51JMnTFy6sY/KrKxj8pKdFvCRTN4TlOQyYYR 2vVYIrSkpsBxUw4oLSiAo2hKCnBUAVIIqSApKIThFDlfWQ/5OeFw0Lt/rKf1AhcVCad1BZPCcNUt qVpYwnAUg1TDCeAgpiAiskJ21PP5p+5FZj2n80pWqmTHFHY8jgqLMa391GbjWeQS4lU2sfNtrIhy 3en9btbA3Lnm4zu7gFZqp2md5RGSlGD3eL1Wu0AO0Kvssa4SCuHx7jXHvK1MfNs0G5xHkncUSt4S HqAq+T1DCxCBk3spLvoh7gJWNZ1DKcNosLWjQRoY+K4367ZVt2RjB/5rND4oWk2+hHr/AEYc5tX+ cEx+sXRB/wBrav8AOC8Yk+KeTKKNX2N31k6DEHNqI+KCfrB9Wv8AuTV/r8l5FqlJhJT65/zi+rX/ AHJq+7/Yl/zi+rI/7U1fd/sXkaY/SCFIp9YzsnGscx+KQWOHI0BUGBxEoPTsR12FQ4CfaPyLUqxH NHCZKGtrUeO99Zn8EWy4uUnUECQEPY7sEKIQSge1zyi14hdyrFFYJ1CuNYGjRPjsoNIYQRG4bfBW C9jeTCkHNPdOXaIW47GorawOExsaDHJUwZQ4grRUIdkaSiqDmbkk2uIAUPXqBidUQMEQoiisHRoS 1QbXa8O4UMm8U1k/nHhEO1jS46ALEzMne8unTsFHlnwxrqWfBjMpWdg18m+JJOqxczIGuqPmZMTJ WDl5O5xUEItqcq0R3WlziliYmRnZDMehpe95j4eZUMei/LvbRS0vseYAC9H6D0OnpWPrDsl4/S2f 99HkrADWnJP0bpFHSsUU1gOsdrbZ3cf7loJJJ7EpJJJJSHKMUuPkvOfrg6b6vmvRM3+jvPkvNvrY ZyK/mnforD8zQ6EJ6jWvUaLSypo8l5d0EOPUqgBqvTWtLKhu8NFFIG9EscjKe9uwaDuqT3bAXu4H CM8akk6d1m5D3X2BjdGBTAUKXBCWPybZd9GVoVVNY0AJY9IY2e6KYCSVaASqeXlNY06pZeUKwdVz PU+okggHUooJY9T6mXEtadFhPeXmTqlZYXmSoJpKFKbWyVEBWaK5SUnxquCVc8+wQ2NgAcKN1m0Q EVMb7d3tHCjXVJkpVs3GSjN8uAgpckAQOFWtfyAi2O7DhB2z8ElMWt7odjpMDhEsf+a1Qa2NTykp QAAQrXSUR5I5QSZQUxhSaokqdTS4pJbVDCTotSoBrVToZtHgjWXCtkpwQwzssV1kA6lc7bYbHknV WM3INjjqqjQmyKQlrARz9HlAaIRe2hlBSp4CtUTCrBuqtVEAIhDM+JUOSpP4UWCSkUp6xwrDGwgM /IjbgAipmCAExtEIbnmPJV32JKVfZJQLLPYEOx5JTfSYWoFSm26rdwNxobpzrJXOUNfZa2tokkwu qxmNYxreNojwKb1S2Gsnnjz1RgdC2P7lAPEeXimDxHKcp//UN/zSx/8AuQ//ADQl/wA08f8A7kP/ AM0LoElyP+k+c/zp+wfwdL2Mf7rz/wDzTx/+5D/80IjPqxQzi9x+QW4kl/pPnP8AOn7B/BXsY/3X KHQah/hnfcEv2FV/pXfcFqpJf6T5z/On7B/BXsYv3XL/AGFV/pXfcE46LUP8K77gtNJL/SfOf50/ YP4K9jF+65w6RWP8IfuCkOlVj/CH7gr6SX+k+d/zx+yP8Fexi/daP7MZ/pD9wT/s1n75+5XUkv8A SnO/54/ZH+CvYxfutQdPZ++fuS+wN/fP3K2kj/pTnf8APH7I/wAEfd8X7rlZ/Qqc6n0n2uaPEAFZ n/MbD/7kv/zQuoSQ/wBJ87/nj9kf4K9jF+68wPqRhj/tQ/8AzQn/AOZWJ/3If/mhdMkl/pPnP86f sH8E+xi/debH1MxR/wBqH/5oUh9UMccZL/8ANC6JJL/SfOf50/YP4K9jH+64A+qlA/7UPP8AZCl/ zWo/7kP/AM0LdSQ/0lzn+dP2D+CvZx/uuGPqxQP8O77gnH1apH+Hf9wW2kl/pLnP86fsH8Fezj/d cb/m3T/p3fcERnQMdv8AhHO+MLVSR/0lzn+dP2R/gr2Mf7rQb0qlvDvwCL9hb++VaSS/0nzv+eP2 R/gr2MX7rV+wt/fKzuqfVjG6kWOsucwsEAgArbSS/wBJ87/nj9kf4I9jF+68r/zEwv8AuTZ/mhP/ AMxMP/uS/wDzQupSR/0pzv8Anj9kf4K+74v3Xlv+YmH/ANyX/wCaEv8AmJh/9ybP80LqUkv9Kc7/ AJ4/ZH+Cvu+L915b/mJh/wDcl/8AmhIfUTCkE5NhjttC6lJL/SnO/wCeP2R/gr7vi/dZ4j24uPXQ xoLawGgnyRvtjv3AqySX+lOd/wA8fsj/AAV93xfuhs/bD+4EvtZ/cCrJJf6U53/PH7I/wV93xfuB s/az+4Evtjv3AqySX+lOd/zx+yP8Ffd8X7obByieWBL7Wf3Aq6SH+lOd/wA8fsj/AAV92w/uBsfa z+4E/wBsP7g+9Vkkv9Kc7/nj/ix/gr7vi/dDZ+2O/dCX2x37oVZJH/SnO/54/ZH+Cvu+L90Nn7Y7 90JfbHfuhVkkv9Kc7/nj9kf4K+74v3Ut977mbPog8wqD8EP/AMIR8laSTD8R5smzlJ+g/gvjjjEU BTj3/V+u7nIcPgAqp+p+Oecl/wDmhdEkiPiXNjbKfsH8EHFA7hp9H6Xi9JDjU31bnc2u5jwHgtX7 a790feqySP8ApPnf88fsj/Bb7GL91s/bHfuj70vtjv3R96rJI/6U53/PH7I/wV93xfutn7Y790fe l9sd+6PvVZJL/SnO/wCeP2R/gr7vi/dTXZDra3VkQHCJXPdS+rNPUbG2PvdXt7AArbSS/wBKc7/n j9kf4K+7Yd+H83B6Z9Vcfp+U3Jbe60t/NcAB+C6G15siREcKCSX+lOd/zx+yP8Ffd8X7qK2j1W7d xb8EJmCxn5xKtJJf6V57/PH7I/wV93xfuo/RHYqLsfcI3EIySX+lee/zx+yP8Fexi/dcvI6I3IOt 7mjwACzrfqXRYZdl2f5oXSpJf6V57/PH7I/wV93xfuvLf8xcX/uXZ/mtTf8AMXF/7l2f5oXVJJf6 U53/ADx+yP8ABX3fF+68uPqPij/tU/8AzQjM+p+MzjIf/mhdEkl/pTnf88fsj/BX3fF+64X/ADWo iPtDv80IZ+qOOTJyX/5oXQpJf6V53/PH7I/wV93xfuuB/wA1McCBkP8A80Jf81KIj7Q//NC30kv9 K87/AJ4/ZH+Cvu+L9157/mjjn/tS/wDzQmP1Qxz/ANqXj+yF0SSX+lOd/wA8fsj/AAV93xfuvN/8 zMbn7S+f6oS/5m4//cl/+aF0iSX+lOd/zx+yP8Ffd8X7rzJ+pWMecp/+aFE/UfG/7l2f5oXUJJf6 U53/ADx+yP8ABX3fF+68sfqNjH/tXZ/mtRK/qXjV8ZTz/ZC6VJL/AEpzv+eP2R/gr7vi/dcD/mpR /wByH/5oQ7vqfRaIOU8f2QujSS/0rzv+eP2R/gr7vi/deRd9QMRxk5ln+a1OPqBiD/tZZ/mtXWpI f6U53/PH7I/wV93xfuvKD6hYn/cuz/Nan/5iYnbKsH9kLqkkf9Kc7/nj9kf4K+74v3Xlh9RsUf8A auz/ADQpt+pWM3/tS/8AzQumSS/0pzv+eP2R/gr7vi/deb/5mY3/AHJf/mhOPqfjD/tS/wDzQujS S/0pzv8Anj9kf4K+74v3Xnv+aOP/ANyX/wCaEv8Amjj/APcl/wDmhdCkl/pTnf8APH7I/wAFfd8X 7rzp+qGOf+1L/wDNCG/6lYzv+1Tx/ZC6ZJL/AEpzv+eP2R/gr7vi/deVP1FxT/2rs/zQnb9RsVpn 7XZ/mhdSkl/pTnf88fsj/BX3fF+68zV9S8alznV5Lw53JLQUZn1UY0z9ssP9kLoEkv8ASnO/54/Z H+Cvu+L91xR9W6x/2pf/AJoUh9XagP590+MBbCSH+k+d/wA8fsH8E+xi/df/1emSSSXCOspJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT//W6ZJJJcI6ykkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklP/9fpkkklwjrK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//0OmSSSXC OspJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT//R6ZJJ JcI6ykkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklP/9Lp kkklwjrKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU// 0+mSSSXCOspJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ T//U6ZJJJcI6ykkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklP/9XR+35PiPuS+35PiPuVZJT/AOjeR/8AE+H/ABA1fvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/ o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfc l9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/ AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh /wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3 Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nx H3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvO f/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf /E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vy fEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs /b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQ K+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl /o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jf b8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT /wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H /ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfc qySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8n xH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85 /wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3k f/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nx H3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZ s/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECv vOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX +jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3J fb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDO T/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+ H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ADk/8Zs/b8nxH3Jfb8nxH3Ks kl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR/wDE+H/ECvvOf/OT/wAZs/b8 nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/ ADk/8Zs/b8nxH3Jfb8nxH3Kskl/o3kf/ABPh/wAQK+85/wDOT/xmz9vyfEfcl9vyfEfcqySX+jeR /wDE+H/ECvvOf/OT/wAZs/b8nxH3Jfb8nxH3Kskl/o3kf/E+H/ECvvOf/OT/AMZ//9awkkktJoKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//XsJJJLSaC kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklP/0LCS6j7J i/6Cv/Mb/cl9kxf9BX/mN/uVr7yP3S1vu57h5dJdR9kxf9BX/mN/uS+yYv8AoK/8xv8Acl95H7pV 93PcPLpLqPsmL/oK/wDMb/cl9kxf9BX/AJjf7kvvI/dKvu57h5dJdR9kxf8AQV/5jf7kvsmL/oK/ 8xv9yX3kfulX3c9w8ukuo+yYv+gr/wAxv9yX2TF/0Ff+Y3+5L7yP3Sr7ue4eXSXUfZMX/QV/5jf7 kvsmL/oK/wDMb/cl95H7pV93PcPLpLqPsmL/AKCv/Mb/AHJfZMX/AEFf+Y3+5L7yP3Sr7ue4eXSX UfZMX/QV/wCY3+5L7Ji/6Cv/ADG/3JfeR+6Vfdz3Dy6S6j7Ji/6Cv/Mb/cl9kxf9BX/mN/uS+8j9 0q+7nuHl0l1H2TF/0Ff+Y3+5L7Ji/wCgr/zG/wByX3kfulX3c9w8ukuo+yYv+gr/AMxv9yX2TF/0 Ff8AmN/uS+8j90q+7nuHl0l1H2TF/wBBX/mN/uS+yYv+gr/zG/3JfeR+6Vfdz3Dy6S6j7Ji/6Cv/ ADG/3JfZMX/QV/5jf7kvvI/dKvu57h5dJdR9kxf9BX/mN/uS+yYv+gr/AMxv9yX3kfulX3c9w8uk uo+yYv8AoK/8xv8Acl9kxf8AQV/5jf7kvvI/dKvu57h5dJdR9kxf9BX/AJjf7kvsmL/oK/8AMb/c l95H7pV93PcPLpLqPsmL/oK/8xv9yX2TF/0Ff+Y3+5L7yP3Sr7ue4eXSXUfZMX/QV/5jf7kvsmL/ AKCv/Mb/AHJfeR+6Vfdz3Dy6S6j7Ji/6Cv8AzG/3JfZMX/QV/wCY3+5L7yP3Sr7ue4eXSXUfZMX/ AEFf+Y3+5L7Ji/6Cv/Mb/cl95H7pV93PcPLpLqPsmL/oK/8AMb/cl9kxf9BX/mN/uS+8j90q+7nu Hl0l1H2TF/0Ff+Y3+5L7Ji/6Cv8AzG/3JfeR+6Vfdz3Dy6S6j7Ji/wCgr/zG/wByX2TF/wBBX/mN /uS+8j90q+7nuHl0l1H2TF/0Ff8AmN/uS+yYv+gr/wAxv9yX3kfulX3c9w8ukuo+yYv+gr/zG/3J fZMX/QV/5jf7kvvI/dKvu57h5dJdR9kxf9BX/mN/uS+yYv8AoK/8xv8Acl95H7pV93PcPLpLqPsm L/oK/wDMb/cl9kxf9BX/AJjf7kvvI/dKvu57h5dJdR9kxf8AQV/5jf7kvsmL/oK/8xv9yX3kfulX 3c9w8ukuo+yYv+gr/wAxv9yX2TF/0Ff+Y3+5L7yP3Sr7ue4eXSXUfZMX/QV/5jf7kvsmL/oK/wDM b/cl95H7pV93PcPLpLqPsmL/AKCv/Mb/AHJfZMX/AEFf+Y3+5L7yP3Sr7ue4eXSXUfZMX/QV/wCY 3+5L7Ji/6Cv/ADG/3JfeR+6Vfdz3Dy6S6j7Ji/6Cv/Mb/cl9kxf9BX/mN/uS+8j90q+7nuHl0l1H 2TF/0Ff+Y3+5L7Ji/wCgr/zG/wByX3kfulX3c9w8ukuo+yYv+gr/AMxv9yX2TF/0Ff8AmN/uS+8j 90q+7nuHl0l1H2TF/wBBX/mN/uS+yYv+gr/zG/3JfeR+6Vfdz3Dy6S6j7Ji/6Cv/ADG/3JfZMX/Q V/5jf7kvvI/dKvu57h5dJdR9kxf9BX/mN/uS+yYv+gr/AMxv9yX3kfulX3c9w8ukuo+yYv8AoK/8 xv8Acl9kxf8AQV/5jf7kvvI/dKvu57h5dJdR9kxf9BX/AJjf7kvsmL/oK/8AMb/cl95H7pV93PcP LpLqPsmL/oK/8xv9yX2TF/0Ff+Y3+5L7yP3Sr7ue4eXSXUfZMX/QV/5jf7kvsmL/AKCv/Mb/AHJf eR+6Vfdz3Dy6S6j7Ji/6Cv8AzG/3JfZMX/QV/wCY3+5L7yP3Sr7ue4eXSXUfZMX/AEFf+Y3+5L7J i/6Cv/Mb/cl95H7pV93PcPLpLqPsmL/oK/8AMb/cl9kxf9BX/mN/uS+8j90q+7nuHl0l1H2TF/0F f+Y3+5L7Ji/6Cv8AzG/3JfeR+6Vfdz3Dy6S6j7Ji/wCgr/zG/wByX2TF/wBBX/mN/uS+8j90q+7n uHl0l1H2TF/0Ff8AmN/uS+yYv+gr/wAxv9yX3kfulX3c9w8ukuo+yYv+gr/zG/3JfZMX/QV/5jf7 kvvI/dKvu57h5dJdR9kxf9BX/mN/uS+yYv8AoK/8xv8Acl95H7pV93PcPLpLqPsmL/oK/wDMb/cl 9kxf9BX/AJjf7kvvI/dKvu57h5dJdR9kxf8AQV/5jf7kvsmL/oK/8xv9yX3kfulX3c9w8ukuo+yY v+gr/wAxv9yX2TF/0Ff+Y3+5L7yP3Sr7ue4f/9HtkkkkkKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU/wD/0u2SSSSQpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT/AP/T7ZJJJJCkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklP8A/9kKZW5kc3RyZWFtDWVuZG9iag0xIDAg b2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxMCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9D b250ZW50cyAzIDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Ny b3BCb3ggWyAxIDEgNTk1IDg0MSBdIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE5IDAgUiAvVFQ0IDIxIDAgUiAvVFQ2IDIyIDAg UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI0IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAx NiAwIFIgPj4gDT4+IA1lbmRvYmoNMyAwIG9iag08PCAvTGVuZ3RoIDE2ODggL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0V9tu20YQfddXTF+KZWHRyzuZhwK+BIkDGHAtIXlI8kCJ tMWYIhUuFcP9j/5vz+wuKUG248JIYUDkLPcyc/bMmfHxmYpoqcjTf2o5OX438+hWTTyqaOK5UnqU hp6bxR5FWUjTNJQwqCsnN5PvEz9yY8ww82LfjXzaTfhEDbaRbgJT8t529tR30yCj9Z6dRRnBSvzR epikiZumo11P0lSfYu3nLN55OcxNw8jNsGe9G4hdGXp0aJqjBlN7yr4MA/Xg6jAwmmb/H5ObPyZ/ AQ/P9fwRDobhJ2iYuSMYo8nxeK4f7kEB98I9JBJ9HdZ82jAwGHOHwmCbIA4tPmMHgXFhh4Dxb7AH 6zB+6YbpAEDgHsZ/zGw7mwGFME7wG8sUv5mMaXY2kfQBFPxGAd2TJ+mSPn+VVEw83/V2Aa7Z9tN9 x2Y4+XQ+OZ7PY6yf32Ajn79hiX5IihI3iXFIGLphiOd8jTnS3MJUsq9Yt5zwG+bP7yefxXX5fVt1 5bpsekU3bUc3237blfTpHd23zjR0U9HdOV/nH/hcfzyXEwXn6ockz8/gqzk4ioeD+SQ+RPzpzL/x 8tAsB+A+ezs/N55kPFO7JxPj1Mly2XZF1dxS35IzjdxQ9KvSAdGENZervOvNSHcE1PeCUKt2Wxe0 bBtVFWU3rjfB2F26vLktdViSprhjL0wHf7xo9McLjD/tDV1eYWEs3r6b+rTIVekkbiQKZxoL2tR5 D+TWipbbrjNfmr5+oC+iHY7Pm75aVpu8LwuOaVF+ceyXqrEvW1U+xlma+5Xmfr2E8xf4pvIpnP+x OA/0cLOUaSc1+bwktsnoBalB38To7+C3nDj/eDq9RmiA68wJxQwBs4uJUPCeQ1Z57+CmAeY0cT1R 15W1aV2qFV4zURZmCakHZT+u1RBfOMRnuYn4Yt9P9zixuwPf+ER5h10CHKl3XTgBIDMGeOL4sKhw Mj2IdYH4YT7W7WZ/tNAuTIcD+eozADOCscMiMud+EW+dSMxOjt9fgACBmDlYk4qrk9nJnE4u+eO1 Ydb7ixk89MGHrv1WLvsjcmLRNtNFm3cFnazzvzG3bXKFBwHBUs+ueXEggKCxwQ7+vjBcmP9hQQjG vE2NXzXDG4scOCRiy5cViMaBeHjIDVwTaOXjQr84B5yaWgLsRf4Eg8ZMPSBLmAx+BPZeOC/hSSQU B5KAArl56Rhw8IAGB37GSkQeIe92B8lkdxOZOakp70EmgAT+9T8hU4y9kv29/HhwmuWPtzoiDV8m KgcuiDuGjyniY2+6uPoRH9E9TwjECvjGmKZnLxnfSKyYi0ZMkBmFpoXd74HUdrNpO07zxQO1dtiy DkUjQjSHpJPBTnAsqqqtt30FBTNsf0P9qlIQ5O6uahze8ZZuu3a7ITNhxVh7Iq9rlj3H+ipBJyii o++CHc/15N7x4Hir3xuzENvrRZVyX5L6AFIvXy31yaP8uryCpGoIfcbKM6nBimLEBECyguC+ab1V /Z6aR1rLdXBaCyDBZgDioLXLWrZg2HJQFjvV96Xvj6of7y7ByuB91a+ATEkb1Jpqua3zruqrUvEY 8xCKs+hYfEJ2+81L4h0kGSB8UbyfSz1vZLH0hoRAMAmQ03X7v6RZ4GYBWom9NMtGB0C6EvVLK3kq Hp7LrsBNfRnuZ9coCQN5CeVy02/od/yuOdM4gaRo7tShFqVuGqfBK7Xo/wEk2Adkmde5yfSFA7qI CrR8FpnIlRGa0b29/EeNBEOz5NRLRdOgRlT2ndMWiQoedWakRvNQm1fkK8YVlmICOIepZmmj6De0 EbnZAghbmUl1pI9Km/eozl9dnFNRqb6rFtg65TLCGchb6+PRTLW6mN9AJlGUrrgE+uJcQQBLw/pF yV0aty5sFg7XRvbqJRkJ0+D1HeNey+KNKkKrXPd+9w0hohZe1dW66nOOhu9QVyiPAbx3O7d3jaRC TwtTPPlqoDRsZMA8YPFcHzL2UVJH0rbcr0tqGJbDvmVIzmqWcj3hW+84eUqH3bYfClNWH2hVmebr dlWbl8HmlZlYcQkqtjyGDt5+AyjnvE0gPjIksTidOpyE4vrMDM/MMBC0xzX8iEVhTe1P4WidLsqb YVszqTI+93YUsP+i1uMwmex/CaDucquU5qRu79i1jF0Df1EhdE2nC92PX8E3cXyuK8LHU1rnehXy WfMEHeqv7JJk/ETzohsX6FM66FPeUG7MoisVF/KQIYQk4Z6MjCm0cnrd2rSDb+eTfwcA+i3jJgpl bmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEwIDAgUiAN L1Jlc291cmNlcyA1IDAgUiANL0NvbnRlbnRzIDYgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3gg WyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDEgMSA1OTUgODQxIF0gDT4+IA1lbmRvYmoNNSAw IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTkgMCBSIC9U VDQgMjEgMCBSIC9UVDYgMjIgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjQgMCBSID4+IA0v Q29sb3JTcGFjZSA8PCAvQ3M1IDE2IDAgUiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5n dGggMTYxOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaxX227bRhB951fMU7As SprLO/tQwLGDIEFSuJbaPsR5oEXKZkyRDknZ9Xc07ff2zA4pKnIuaFIY0HJ253Lmuuujkz6iVU/a /PUr6+j5QtNVb2mqyNKu52lKQ+1msaYoC8lJQw8EdaW1tt5bfuTG4BC+2Hcjn2aGP6iBGs9NQHqs e+R2fDcNMtrs0VmUEajE31EPVpq4abqjaytNjZWR/hzFmlcTbxpGbgad9bwRu16o6ZAUUxNpkDKW aaOeoE4bO1L031nrH6xfEQ/tan8XDg7DF6IhvLtg7Ej2R7t+uBcKwAv3IpGYdIzkpwkJg5BzFCZa nDik2MYcAoEwR0DwTfREHfrvuWE6BSBwD/0/4mo7WSAKYZzgN/ZS/GZeTIsTy6OXKMF3FNA9aY9e 05u3HhWW9l09O7hh2k/3gS1g+enSOlouY8gv11Dk8xlEzOJRlLhJDCNh6IYh1uUGPJ5kwfGA1Uto OX2GtLy31FnbV0PVNnTfDbTadl3ZDPTCOe3t5Ts25e9McW/AlFk80hpxS8VWFE+2oNwzan8exUMR B6/PAJenlrGdzTASw39evt9WXbmB9Z7N00+P7Hviqieu6iByQw92U+9T9v8+tK91kAoAY9Y3rGw/ Yv43qmMAthO5geps7aZqxLJuO9sJXV9Rsb2thaH8k8avykadq+ZmonPb8dWDHbO8zdWpup4u1Onv Tx3bSdQ52H11sriwKW8K2pT9dVmAO1PUP/RDuentt8uXcMEB4CyJZ7jRhFcL3P46NyZTVdNlSXlR QBHLziFzRqf3dP2XAM0RSg4iFJkIxQcRCucIRRyhvlxtbSeGv90oNTzQBDtS40KXcD/hYAUKXhji /3bFi3bVpvdcMdVmY/4p44RtHKPerCsb7KHK6/zSTvFRl2TH6gmVdgj+9bpaVfDd5Jk223qoVnk/ jLLwRaMU0EsVPM7FREF1/iDSHfmfybJUpQANBOmqhZnE1apjgJztC94DmKa0gZNbFwTt8dU/0tkL 831Ked8bseqKuTZckqFiwcb21IAylONrUHnNlYQjU0xYD5PwaAT4aYzB9o0jwE93vvqx+PqsWeW3 /bZGlGKVD1gAHJPphWNycNpjKDyC9PFUCDCVvPSbp0KwK3o9Fj0aOuDmv6m4lhG3gqatBRIdqu6O Sa3G85VQJS1uzfFIV+uPz+mkbUZB0YLBEKurspnleXvLpeSry1qEuYJ2zCiEEUk/AkKGJ5SmnfpW Djbcapx28BwzQ6aWRsXrx3XozRU4Dsbj41dcJ9c51HOJIBcZg/a49tGxTHLH8vqJBGnuWo5xEGup Fq3j/dwgLf8cpGV/DAWHY6jCNZWzF6lqePQ17J3PocL9CYSPRge7F/I1/PHU+IJRPQ+MaWJMVmGz amTcrTgralvwaEBbI2EJ2v7YDpCAcwYYKDm5UIvyimdlbrpVZuUTOTsvRYwbFR+xRDZRG5NzXCUO T9oLG8xI+VpG/lYmDBcLnmcKWg0y28fmj6K3mneo7Yqyo6Gds+1PXRgEk6fIinh6bUZHLpV3h/GQ yVXGg4H6yoy45gpMPBXRoyjmxS9YM3X6G7Hbibo1/SqH3bj3+sxmv5/hN1DPEaRMOf5H/LlM3huR G74vj8a5ecREoThXmtnS2BxpjGwDaWvDE67uocJPK4ckZ9eGwJ2F2ic+HkXrbTH2AeujiXC4GU1t cBYDvvlidTvYGT8V2p043zYxR2YXmEy9Woiq3HB53FTSUn/NF1IwoZNfMb4S2DsxxionvWD5cJB3 6atw11ephGbTymhAPV+oWr6rG8489AGFKdMXNk+nMzxmMoDitsc8qhibzxDNkBJq4NkTy2UYq+KD yONCons+SVUuJnoqqvFrVLBFJ6RYe9EuURrBNXh4YGu4Hh9itMlH6VrMVvt8Vw7Dz3beCMuofjCu oLO+csuF+J/pm285nTyep0XRlchfgvyQTOau7Nt6O8hdd/r1Wy7CvwbfccvxTJtAjX2BBypufIfh aHV+gpCHakG3Xcutmaq2z2tq13xr4UibSuObi7lX/JKoxgPm4HeIL+8VhJ7Oxq/B5oHSrtravALl scEistyZJ8g2H4QsPvdESg/+c8AV3XCnQFG1Jn5shVPRrUpT/32fdw94IG1ua9kYZClcY+PZ0vp3 AJbUqRQKZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAx MCAwIFIgDS9SZXNvdXJjZXMgOCAwIFIgDS9Db250ZW50cyA5IDAgUiANL1JvdGF0ZSA5MCANL01l ZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAxIDEgNTk1IDg0MSBdIA0+PiANZW5k b2JqDTggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE5 IDAgUiAvVFQ0IDIxIDAgUiAvVFQ2IDIyIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDI0IDAg UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAxNiAwIFIgPj4gDT4+IA1lbmRvYmoNOSAwIG9iag08 PCAvTGVuZ3RoIDEwOTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsVlFv2zYQ ftevuKeCHCCGpCiK2sOAxUmLdvPQwQL2EPRBleXEhSxnkrwgP6T7vbsjJdlxumzdigCmjjrefffx u1MuFn0KVQ/K//VVdPFmpeC2jxRsIVJCSgXOKJFbBWluIHZGogFdHW2i3yOdCosewc9qkWo4OvwG LYaRIkNTUuzRO9bCJTnsTuw8zQGtTM/WY+Qy4dxsN5FzPsto/51FkavJ15lU5BizOW5YIY2CczOk mkyPlLBMG80EddqYzRD/j2jzXfQr8qGE0jMdRMMLbATfmYzZpHqU0OaECoRnTpjI/HWM5peNQEMw jyxMdiji3KIcRwoChCMDAd9kT9Z5/VIYNxGQiPP6L0htixWyYGyGv1Y6/M2lhdUikvAOJfgJEngA JWEJNx8krCOlhToWuCNbu1NgK8x8WUQXRWHxfLHBQJre4RG/SLC5yCwmMUYYg2uxQx8ZbiGWhNVA UeFe8RCxVV0duu3wyItPFFPPMakJMKZfJKgkE9KFoKmdgmIU9sN40oSTyKMmEMVVRKlkRk4+q0wp 4Q37sYW37VDfduVQr2HKD6vqrt7VsNl3cGi3VdkPF7tDM/gn4HEqDFu+v34Ta/6heIe5Y7oTqadE Kp0TqSQk6h+5EQnrh3rXQ3+3PzRr+FjDut5s23r9vY/zpGQZaJSBRuVS4SSW6uTTkgNxn8/rVipx oXCPQlvvS3hUwLM48NgKy7qubgfoh7Jdlx2PjXBszSUihZ7ICDtb3FEMeSG4VH7OEDTRE97Dvq3h gV4krOQoF8vQl1s0R/fNZszXjxv79qzkeARNa55ZT+W/KtBfZ3Ik3IUCf6lrnooUq0mEZojVw+lg /chzLKYtd9sKysPAM0R1hwWmrG7RJ2V0zd552IZDrX8Lr6Aa7c32ljuMekDZzD7fqJwgT3dUahbq +bl8rFFCBkvglmm8Hm/hHdVwVWKpmg0l3DdlWz8TkyIcFF9bKTTJSCn7JR39eYbrFJKZIWV5gLQ8 NHT/ORswvaKrJqOiJWWhU6zI2CtY+svPGXZQ3NNjyvZcoXDG/Y40k7GqJhMvqwyRUFHkVHbnFcWK eDU0yJ7y+gJ+pY+UmoD/siQtZqxHLe9bbIJuHzbaWyib8Hg7buFYuNv1/w/H2QzS42h4X3ew4TGO bNZwTb1BhsPy/2EoJFbhp/I/D4XTptFPRJaPIuN0K0FpOSkNWwm7hG5FMYAF9g7rGrjn2kP3FZAS kUAe08R4QYkJ/hugzdcqkbAmaoZtxt54vec0erqHMqzYrzjGsASEsqemRulR22MxrzgNb7icFIvX x+K17+Yt6iwJAsZhh1t2cgjhQyAUBhk0C2jdITeW3aOaUxbejGfKkzPDt9Cv778btqpIkCkLAkU8 H5vnNJ99ME2ehG/eV34wlXmmkNfLn67hbXwF913d46ejxvlpcMhi46ImygGWq+uFx3NdRH8NAC6K bccKZW5kc3RyZWFtDWVuZG9iag0xMCAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDE0 IDAgUiAxIDAgUiA0IDAgUiA3IDAgUiBdIA0vQ291bnQgNCANPj4gDWVuZG9iag0xMSAwIG9iag08 PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDAzMDcxNzE1MDk0OSkNL1Byb2R1Y2VyIChBY3JvYmF0IERp c3RpbGxlciA0LjA1IGZvciBXaW5kb3dzKQ0vTW9kRGF0ZSAoRDoyMDAzMDcxNzE1MDk1MCswMicw MCcpDT4+IA1lbmRvYmoNeHJlZg0wIDEyIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMzg5Mjcg MDAwMDAgbg0KMDAwMDAzOTA3OSAwMDAwMCBuDQowMDAwMDM5MjM3IDAwMDAwIG4NCjAwMDAwNDA5 OTkgMDAwMDAgbg0KMDAwMDA0MTE1MSAwMDAwMCBuDQowMDAwMDQxMzA5IDAwMDAwIG4NCjAwMDAw NDMwMDEgMDAwMDAgbg0KMDAwMDA0MzE1MyAwMDAwMCBuDQowMDAwMDQzMzExIDAwMDAwIG4NCjAw MDAwNDQ0ODAgMDAwMDAgbg0KMDAwMDA0NDU2NCAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDEy DS9JRFs8NjIzYmZlNWUxNjkyM2ZiMTgyZTUwZDM2NmIwNDI5Mjg+PDYyM2JmZTVlMTY5MjNmYjE4 MmU1MGQzNjZiMDQyOTI4Pl0NPj4Nc3RhcnR4cmVmDTE3Mw0lJUVPRg0= --0__=66M5vRelu9RbdUysiElN4qA9HvvKF4aIQbVgVdhJzkjtCdST2N9uyplL-- From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 17 21:08:51 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6HK8Zgf024198 for ; Thu, 17 Jul 2003 21:08:35 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6HK8Zbs024197 for ip-dvb-subscribed-users; Thu, 17 Jul 2003 21:08:35 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6HK8Cgg024181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 17 Jul 2003 21:08:13 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 17 Jul 2003 22:08:21 +0200 Subject: IETF-57 BOF meeting - copies of meeting slides From: Gorry Fairhurst To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I've placed PDF copies of all presentations from the IETF-57 BOF meeting on the web link below, so you can down-load them. I'll also place a copy of the minutes in this directory when they are finalised. These will also appear in the official IETF proceedings for IETF-57. http://www.erg.abdn.ac.uk/ip-dvb/meetings/IETF-57-Vienna/ Gorry Fairhurst From owner-ip-dvb@erg.abdn.ac.uk Fri Jul 18 08:10:12 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I79Ugf002972 for ; Fri, 18 Jul 2003 08:09:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6I79UwP002971 for ip-dvb-subscribed-users; Fri, 18 Jul 2003 08:09:30 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I78dgg002951 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 18 Jul 2003 08:08:42 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 17 Jul 2003 22:45:06 +0200 Subject: Re: fair-ipdvb-req : Some questions From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F1408DC.6060107@6wind.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-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 h6I79T7q002968 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk On 15/7/03 3:59 pm, "alain.ritoux@6wind.com" wrote: > Hi all, > > I have some question about the draft '"Requirements for IP > transport over MPEG-2 networks" (draft-fair-ipdvb-req-03.txt) > As a newbie in satellite stuff, some of these questions/precisions > may be irrelevant, thanks for indulgence ;-) > > > 1) some reference don't exist [DVB-RC] [LINK-ID] [DVB-SIDAT], > and maybe some other. As a newbie in that stuff, finding its way > among multiple ISO/ETSI/whatever norms isn't really obvious :-( > Thanks - you're quite right, they'll be in the next rev. [LINK] http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-13.txt > > 2) About the TS-multiplex selection > 2-a related to figure 2 > Maybe I didn't get the point but hiw does it work : is it for > the sender, a selection between multiple DVB-Sending cards ? > If so, but managing one (or many ?) logical IP interface per > sending card, I don't see why the 'normal' IP routing souldn't > be enough. I don't understand the question. > 2-b related to figure 3 > The IP encapsulator has no mean to interact with the second TS > multiplexor, so what is the point ? > The second TS multiplexor simply multiplexes the TS Packets from a set of TS at the input from one or more places, to produce another TS Multiplex. In reality, for a TV service this also involves a lot of other sub-actions, such as building the correct control information (tables) and inserting information at the correct time into the TS. > 3) Packet flows > 3-a the flow itself > They are associated with IP source and destination addresses. > Well is it enough ? I mean, the recent flow-label discussion in > the IPv6-WG ended up with a flow definition with SRC+DST+Flow_Label > (http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt) > 3-b the usage ? > Indeed, why impase taht a single flow MUST use a single PID, > I would consider it safer, but what is the rational behind it ? > What do you propose? > 4) Motivation > In the needed fcts (§3 p10), there is the IPv4 broadcast packet support > : is there a real need for this ? what is the use-case foreseen ? > "Use cases" should be developed, Jun, sent something about this, and it is good to collect as many different use cases as we can. (This has been repeated in many places over the last few days). > 5) Framework position > The framework operates below the IP level. Couldn't it be a good > place to define a logical-interface level (just for exemple, one > pseudo-interface associated to a group of PID), and to see how to > defien this group PID properties, in such a way that classical IP > mechanisms will work 'perfectly' over this interface. By IP mechanisms > I include not, only the stacks tmeselves, but also routing, ... > To make myself more clear, ythe level of abstraction could be > equivalment as the one we find in UDLR. > Or is it over-specifying, and considered as implementation-dependant ? I'm keen to focus on subnetwork issues first so we can get the basic encapsulation protocol out of the way, or at least into a stable draft. We will need to look at this when we do the address resolution. > 6) About lenght indicator. > It is said (§6.3 note ii p17) that when more than 2 payload are present > in a single TS-cell, the PUSI pointer is only used for the first start. > This is because the mandatory lenght indicator is enough to find the > start of the next payload. > In this case, why even use the PUSI pointer for the first tart in the > TS-cell ? for I think lenght indicator + cell_numbering should be > enough ?). Would be so, assuming total synch. But if you loose/miss a TS Packet, then you rely on these hints to get resynch. They also substantially improve the ability to detect mis-alignment due to implementation errors. > Did I miss something or is this pointer removable ? No, this is required in MPEG-2. > > 7) About address scoping > I don't really see the point in managing sort of scope indicator > at DVB-level, to manage muliple IPv4 private addressing that overlap. > Indded, it may be out of context, and if we asume the DVB link a > sort of publi link, overlapping addresses space should be managed > at IP-level (with virtual routers or whatever). > Or is it foreseen to addres a sub-PID managemłent, i.e. to do view a > PID as a LAn, and to perform sort of VLAN management. > We need text from people deploying links to give some clear "use cases" so we can identify what is needed. If you have use-cases send them to the list, and we can add them to the AR or architectural requirements Ids. > 8) p23end of the page : > excuse my ignorance, but what is the bandwitdth commonly associated to a > single PID ? because can really a few Mbps recpetion (destined to be > filtered at IP level) be considered as a DoS ? > This is purely a layer 1 (PHY) issue, if we change modulation, coding, channel we are using, etc. Examples may be 1-100 Mbps the rates could increase beyond this, or be much smaller. The IP technology needs to work in all cases. > Even in case of a router, and strange protocol behaviuour, report, to 7) > > > Thanks for having read so far .... > Regards. > > Alain. From owner-ip-dvb@erg.abdn.ac.uk Fri Jul 18 10:12:28 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I9C2gf004905 for ; Fri, 18 Jul 2003 10:12:03 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6I9C2B9004904 for ip-dvb-subscribed-users; Fri, 18 Jul 2003 10:12:02 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I9BZgf004877 for ; Fri, 18 Jul 2003 10:11:35 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 31F43681 for ; Fri, 18 Jul 2003 11:11:36 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id C4EC65DA; Fri, 18 Jul 2003 11:11:35 +0200 (CEST) Message-ID: <3F17BA85.8010003@6wind.com> Date: Fri, 18 Jul 2003 11:14:45 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: About dest MAC@ X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Still some thoughts about filtering and the need of MAC@: - If the IRD is a Host, indeed MAC filtering is not needed (it may of course improve the receiver capacities), but IP level filtering is enough - If the IRD is itself a router, there is still the case (that may be of (most?) common usage ??) that the network behind it is a leaf-network, and by no mean a transit network. In this case, the router acts as a CPE, and usually "knows" what is behind him, let's say my_site_prefix::/48. The firewall rule with something like 100 deny ipv6 from any to !my_site_prefix::/48 via dvb0 in will give the needed filering, without any MAC address needed. or even a mechanism based on the redirect-conditions, I mean if this is a CPE, it will have a typical ::/0 route through the logical dvb interface (that can use SPCP, RCS, whatever mean for the return link), and a packet not addressed to a host present in the site will be naturally forwarded through the dvb interface, which is a potential case for a redirect (i.e. sam ingoing/outgoing interface). If the interface is configured with a feat such as : - if the redirect conditions matches, then DROP packet silenly It will perform the same filtering as abiven but without the /48 delegation stored into a firewal rule (sort of RPF check), which is even more cool. Your thoughts ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Jul 18 10:09:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I98ogf004826 for ; Fri, 18 Jul 2003 10:08:50 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6I98oAF004825 for ip-dvb-subscribed-users; Fri, 18 Jul 2003 10:08:50 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I98Jgf004806 for ; Fri, 18 Jul 2003 10:08:19 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id A7FEC642 for ; Fri, 18 Jul 2003 11:08:19 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 4C86D5DA; Fri, 18 Jul 2003 11:08:19 +0200 (CEST) Message-ID: <3F17B9C0.2020001@6wind.com> Date: Fri, 18 Jul 2003 11:11:28 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: fair-ipdvb-req : Some questions References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry Fairhurst wrote: >>2) About the TS-multiplex selection >> 2-a related to figure 2 >>Maybe I didn't get the point but hiw does it work : is it for >>the sender, a selection between multiple DVB-Sending cards ? >>If so, but managing one (or many ?) logical IP interface per >>sending card, I don't see why the 'normal' IP routing souldn't >>be enough. > > > I don't understand the question. I just meant that if a logical IP-interface is associated to each TSQ multiplex (in case of the sebder has diretc acces to various Ts multiplex), then the standard Ip routing will select the outgoing interface, and then what will still need resolution is only the PID. > >>3) Packet flows >> 3-a the flow itself >>They are associated with IP source and destination addresses. >>Well is it enough ? I mean, the recent flow-label discussion in >>the IPv6-WG ended up with a flow definition with SRC+DST+Flow_Label >>(http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt) >> 3-b the usage ? >>Indeed, why impase taht a single flow MUST use a single PID, >>I would consider it safer, but what is the rational behind it ? >> > > What do you propose? About the flows definition it was to stick to IPv6 flow definition, hence imposing to alwaus use the same PID for a single (SRC+DST+FLOW) 3-uple. But indeed I don't understand why a flow must be associted to a single PID. > >>4) Motivation >>In the needed fcts (§3 p10), there is the IPv4 broadcast packet support >>: is there a real need for this ? what is the use-case foreseen ? >> > > > "Use cases" should be developed, Jun, sent something about this, and it is > good to collect as many different use cases as we can. (This has been > repeated in many places over the last few days). I'm halas, not experienced with staellite techniques and/or usage, and can not provide such pieces of information. > > >>5) Framework position >>... >>To make myself more clear, ythe level of abstraction could be >>equivalment as the one we find in UDLR. >>Or is it over-specifying, and considered as implementation-dependant ? > > > I'm keen to focus on subnetwork issues first so we can get the basic > encapsulation protocol out of the way, or at least into a stable draft. We > will need to look at this when we do the address resolution. OK I see. This place will also be the good place for the MTU definition of such interface. >>Did I miss something or is this pointer removable ? > > > No, this is required in MPEG-2. I still have to read 13818-1. It's a little bit BIGGER tahn I expected but I'll read it :-( Just need to find a couple of hours; -) I think i'm still confused about PUSI_pointer, Payload_Pointer, and the pointer in ten Adaptation Field .... > > >>7) About address scoping >>I don't really see the point in managing sort of scope indicator >>at DVB-level, to manage muliple IPv4 private addressing that overlap. >>Indded, it may be out of context, and if we asume the DVB link a >>sort of publi link, overlapping addresses space should be managed >>at IP-level (with virtual routers or whatever). >>Or is it foreseen to addres a sub-PID managemłent, i.e. to do view a >>PID as a LAn, and to perform sort of VLAN management. >> > > We need text from people deploying links to give some clear "use cases" so > we can identify what is needed. If you have use-cases send them to the list, > and we can add them to the AR or architectural requirements Ids. Same answer as before ... but if there's no REAL use-case (and maybe even if there is some ..) I think this req should be removed, because I think VPN-stuff should be managed above IP level and not below. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Mon Jul 21 13:06:52 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6LC6Ogf003111 for ; Mon, 21 Jul 2003 13:06:24 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6LC6N8q003110 for ip-dvb-subscribed-users; Mon, 21 Jul 2003 13:06:23 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6LC5Ngf003069 for ; Mon, 21 Jul 2003 13:05:23 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 874EB648 for ; Mon, 21 Jul 2003 14:05:25 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 2178B646; Mon, 21 Jul 2003 14:05:23 +0200 (CEST) Message-ID: <3F1BD7C0.9070704@6wind.com> Date: Mon, 21 Jul 2003 14:08:32 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: encaps metghods X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi all, Some other questions about encapsulation methods. I The "enc" one ================== I-1) Alignement stuff - Well, it is said that the AF maintains a 4-bytes alignement, this is sure a plus, but is it a requirement ? - As described, nothing prevent the stuffing of multiple SNDU into a single TS cell, to loose this alignement. Indeed, if 4-bytes alignement is an important feature, I think it should be said that it MUST be enforced with stuffing bytes i.e leading to (figure 8) : +------------------+ +------------------+ | Subnetwork | | Subnetwork | | DU 1 | | DU 2 | +------------------+ +------------------+ \ \ / / \ \ / / \ \ / / +------*--------*--------+----------+----------+ |MPEG-2| Adapt. | end of | Stuffing | start of | |Header| Header | SNDU 1 | bytes | SNDU 2 | +------+--------+--------+----------+^---------+ | | | | +---------------------+ So that Start of SNDU2, is on a 4-bytes boundary The same thing should apply if SNDU2 is fully sorted in the TS-cell and a next SNDU3 starts here, it should be said that all SNDU are re-constructed thanks to their inner length, and that padding is added to preserve alignement. I-2) The AF itself Indeed, the descrption of the AF is : 0 7 8 15 16 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ad.hdr.length=3| flags 1 | priv.length=1 | pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ but the pointer, is only a private attribute, and hence not described in 13818-1, so it should be described in the draft (how to compute, etc ...) I-3) The AF usage The first usage descrition of AF, I don('t really see why. it seems to me a special case that could be avoided, hence the use case in figure 7 : +-------------------+ |Encap | Subnetwork | |Header| PU | +-------------------+ \ / \ / \ / +------*--------*--------------+------------+ |MPEG-2| Adapt. | Stuffing | SNDU | |Header| Header | bytes | | +------+--------+--------------+------------+ could become +-------------------+ |Encap | Subnetwork | |Header| PU | +-------------------+ \ / \ / \ / +------*--------*------------+---------------+ |MPEG-2| Adapt. | SNDU | Padding bytes | |Header| Header | | (0xFF) | +------+--------+------------+---------------+ with : PUSI = 1 AFC = 11 AF.pointer = 0 hence allowing: the AF is always followed by the end of SNDU. I-4) when to put the AF some case are not reallyu explained, (or I missed them ?) or I think should be explained more in detail, that is when - The last piece of SNDU is 184 bytes, hence TS cell is full OK, no AF ==> slight error : (0/00 PUSI/AFC) should be (0/01 PUSI/AFC) - No more SNDU available : OK no AF paddinbg wiht 0xFF What to do when : - the last piece of SNDU is 181-183 bytes ! hence, ther is not enough room to store an AF ? I would think : teat is as if there are no other SNDU to stuff, i.e. (0/01 PUSI/AFC) no AF, and padding with 0xFF - the last piece of SNDU is 180 bytes allowing just an AF to be stored which is not reallu usefull, for nor further SNDu is to be found, so 2 solutions are possible + (0/11 PUSI/AFC) AF present AF.pointer=0; + (0/01 PUSI/AFC) no AF, padding the last 4 bytes with 0xFF it would be good to have only one of those allowed. More over, in a more general sens, bette than a long explication, and exemple for each of those case would be great (with the PUSI/AFC and pointer values detailed). It REALLY helps remove ANY amibiguity. II) Both methods ================== I don't really get the pros and cons of the ule/enc methods, but as MPE already exists (and is deployed), I don't feel really easy about having 2 possible new methods for IP/MPEG-2, I think they should be selected/merged The difference bewteen the 2 : This document contains the Simple Encapsulation, a simple and lean encapsulation mechanism for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS) This document contains an alternative Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IP Datagrams directly over ISO MPEG-2 Transport Streams (TS) as TS private data After reading 13818-1 does this mean (Indeed, I have troubles with this norm, and still may be confusing things, if I'm wrong, please tell me) : - for ENC method, there can be intermedaite layer between TS and the ENC method, i.e. intermediate header such as PES or PSI packet header, in this case it is not really shown in the various figures ? ==> is it really needed to carry ENC-packets into such other packets (huge ovberhead) - ULE is strictly for TS private data, ==> dose this mean, only for PID such as the associated Strrema type is bewteen 0x80-0xFF (table 2.29) ? III) The ULDE method ====================== III-1) format and semantic As it is meant for private data, the semantic of PUSI/AFC is to be defined in the draft, which means that the semantic/format of the pointer should also be explained in the draft. Here again, some exemples would really help. III-2) payload pointer Indeed as it is TS private data, meaning of PUSI/AFC is not normalized, and may be the payload pointer may be omitted in some cases (especially as the emission of a next available SNDU in the ame TS cell is only a MAY) To play with this, one could use th AFC bits : 01 : No payload pointer 11 : 1st bute is payload pointer In case of SNDU starting on new TS-cells, it would help - gain 1 byte - keep the 4-byte alignement. I don't know if it's worth the effort ... III-3) remaining single byte p11 it is said : For the case of one remaining byte this MAY be assigned the value of 0x00, but this value MUST NOT be required at the receiver. For interop purpose, and possible re-definition (in case of brilliant ideas to come ...) it is usually better to say For the case of one remaining byte this MUST be assigned the value of 0x00, this value MUST be ignored at the receiver. Thanks for reading so far. Any comments/corections welcomed. Bests regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 11:14:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VAECc4016408 for ; Thu, 31 Jul 2003 11:14:12 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VAECeD016407 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 11:14:12 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VADLc4016374; Thu, 31 Jul 2003 11:13:21 +0100 (BST) Message-ID: <3F28EBC2.B0933AD2@erg.abdn.ac.uk> Date: Thu, 31 Jul 2003 11:13:22 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: minutes@ietf.org, gorry@erg.abdn.ac.uk CC: ip-dvb@erg.abdn.ac.uk, bnocker@cosy.sbg.ac.at Subject: IP-DVB BOF Minutes: 14th July, PM Session II: 15:30 - 17:30. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk The following minutes are FINAL. Thank you Haitham for volunteering to be minute taker, and for the corrections received from Bernhard. gorry@erg.abdn.ac.uk IP-DVB Chair ---- IP over MPEG-2 Transport (IP-DVB) BoF Minutes, 14 July, IETF-57 Chairs: Gorry Fairhurst (gorry@erg.abdn.ac.uk) and Bernhard Collini Nocker (bnocker@cosy.sbg.ac.at) Mailing list: ip-dvb@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/ip-dvb/ The AD for this BOF was Thomas Narten. 4 drafts were presented: draft-fair-ipdvb-req-03.txt draft-clausen-ipdvb-enc-01.txt draft-fair-ipdvb-ule-00.txt draft-fair-ipdvb-ar-00.txt The agenda was bashed and asked the audience for any suggestions or modification. Minute taker was Haitham Cruickshank from the University of Surrey UK. 1. Bernhard conducted the first presentation on why this is an IETF activity and presented a summary of the IP over MPEG-2 requirements. He spoke about the existing standards from DVB, including MPE (which has been deployed) and the needs for new protocols. [Copies of slides are in the proceedings.] Q: AD) Is this activity only for satellite? A: Bernhard) Satellite is an important application. There is also some interesting opportunities in the case of terrestrial transmission. A: Gorry) This WG intends to produce protocols for transporting IP over MPEG2 and DVB transmission networks, which are defined by ISO. Satellite services are important examples, as are digital terrestrial TV systems, some cable networks, etc. Q: Dino) Sending multicast packets is efficient, but unicast packets are not efficient in a broadcast network such as this. A: Gorry) Multicast is an important service, but both need to be addressed by this list. A: Bernhard) There are people building access networks using this technology too. Q: AD) Is this for IPv6 or IPv4 or both? A: Gorry) The focus should be IPv6, but we need to find a solution that will work with IPv4 as well. 2. Bernhard conducted the second presentation of the simple encapsulation of IP over DVB. He mentioned that the European Space Agency (ESA) is sponsoring this work. [Copies of slides are in the proceedings.] Q: Michael Schmidt) Does this encapsulation work for cable? A: Gorry) Yes, if it uses MPEG-2 Transmission. Q:?) There is a problem with data services using MPEG-2 transmission over IP. There can be packet re-ordering resulting in loss/reordering of TS Packets, which video can accommodate, but data services suffer. A: Gorry) The intended activity is IP-over MPEG-2 only. The WG does not address MPEG over IP issues. A discussion followed about issues with IP services over DVB over IP networks. AD: This problem was important, however the focus of the work was IP services over MPEG-2, not vice versa. Q:?) Give some examples of unicast applications A: Bernhard) Access networks, Skyplex and VPN over satellites. 3. Gorry presented the third draft on Ultra Light Encapsulation (ULE). This was an alternative to the Simple encapsulation, The main difference was an alternate framing mechanism that placed IP packets directly into MPEG-TS payload. [Copies of slides are in the proceedings.] There followed an open discussion of things raised on the list and options for implementing the framing. This discussion mostly applies to both the proposed encapsulation formats (Simple, ULE) - that is, the discussion was independent of the way in which the SNDUs were framed in the MPEG-2 Transport Stream. Q: Gorry) When are destination and source MAC addresses needed? Q:?) In the presentation the ordering for the MAC addresses was (Destination, Source) why not (Source, Destination)? A: GF:) This was a mistake, we intend to do the same as Enet. Q: ??) Do we need a 3MAC address2 for IP routing? A: GF) Yes - unicast routers NEED to filter packets sent directly to them A: AD) You can1t do unicast routing without this. A: Dino) The MAC destination address is more efficient for multicast filtering, this is even more the case for IPv6 multicast filters Q: Gorry) Also need to discuss what happens with bridging, can the IETF define a L2 forwarding operation? A: AD) Yes, if it complements the work for IP. Q: ?) It is easier for hardware can recognise MAC addresses in a fixed place and they are always present A: GF) We could look at this on the list. Q: GF) Apart from bridging, who needs a source MAC address? A: Dino) IS-IS expects a MAC source address A: Gorry) We should discuss this on the mailing list to get a good feedback on this issue. A:AD) The list needs to consider Pros/Cons very carefully and must document the reasons why decisions are made. Q: AD) Is the Ethernet type sufficient? - It may be, and would not require a separate IANA registry. A: Gorry) Yes for now. Q: ?) Ether types include a subset of LLC/SNAP - Do you need LLC/SNAP as well? Q: Gorry) Does anything rely on this? A: Dino) LLC-SNAP is used by Spanning Tree A: Gorry) Yes, and by some discovery protocols too. A: AD) The ID needs to specify the behaviour, one way or the other Q:Dino) Are the lessons of ATM fragmentation learnt here? A: Gorry) Yes, the draft addresses these issues clearly, any other observations are welcome. Q: Sebastien) What about MPLS? A: Gorry) This is not part of the base spec, we could add later. A: AD) keep the door open, but start simple. Q: ???) Should receivers know about the type of encapsulation (MPE, SIMPLE or ULE)? A: Gorry) I think it may be possible to find a way to let receivers know which is being used. We1d need to take this to the list. Q: Gorry?) Is there a desire to have two standards for two cases or one? A: AD) One is always very much better, More design details should be put into SIMPLE and ULE and merge them if needed. 4. Gorry presented the address resolution draft and emphasized the need to translate IP addresses to MPEG PID and physical media ID. He mentioned 3 methods: Manual configuration, SI tables (e.g INT method) and a dynamic IP-level approach (re-using IPv6 ND address resolution). [Copies of slides are in the proceedings.] Q: AD) What is the size of the INT table, how many systems do you expect in a satellite network really? A: Bernhard) For satellite, due to costs of the satellite transponder many end systems will share it and, hence, the INT may get huge. Q: Dino) How large is the PID space? A: Bernhard) 13 bits Q: Dino) Is this fixed? (could we have more than the current 13 bits) A: Gorry) Yes, thats given, defined by the ISO spec for MPEG-2. 5. Gorry presented the WG road map for standard RFC for encapsulation and [Copies of slides are in the proceedings.] Q: AD) Why security. This was not part of the Charter? A: Gorry) Security poses issues for flat networks, this may provide useful inputs for the requirements, but is unlikely to be a work item of this group. Sebastein presented 2 slides on Alcatel1s work on securing satellite DVB by adopting a similar approach to GDOI from the MSEC group. (see draft-duquer-fmke-00.txt). [Copies of slides are in the proceedings.] Q:AD) You mention MIBs - what are these used for? IP functions? or something esle? A: Gorry) I think it's mainly to identify how the IP level is functioning for the encapsulation / address resolution. A: Bernhard) You may also wish to set / view the tuning parameters that identify which TS Multiplex the receiver is receiving. Q: AD) Security does not work with ARP - Do we need security for address resolution? A: Haitham) Securing IPv6 ND is not resolved yet in the IETF and we should wait for their results (SEND WG). Haitham mentioned that IPSEC and MSEC work can be adopted here. A: AD) Any security issues should be addressed to other security WGs. A: Gorry) We should discuss the specific needs on the mailing list. WRAP UP: The AD asked for show of hands from people who will support this work. More that half the audience showed interest. The AD asked for a show of hands from new people who think they will benefit from this work. There was a group of IETF attendees interested in developing these as IETF work items beyond those who authored the current individual drafts. From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 13:44:01 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VChUc4019367 for ; Thu, 31 Jul 2003 13:43:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VChTkr019366 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 13:43:30 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VCguc4019334 for ; Thu, 31 Jul 2003 13:42:56 +0100 (BST) Message-ID: <3F290ED2.AEDB5044@erg.abdn.ac.uk> Date: Thu, 31 Jul 2003 13:42:58 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: About dest MAC@ References: <3F17BA85.8010003@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk alain.ritoux@6wind.com wrote: > > Still some thoughts about filtering and the need of MAC@: > > - If the IRD is a Host, indeed MAC filtering is not needed (it may of > course improve the receiver capacities), It does have the advantage of placing a field in a well known position, which can be used by a variety of protocols types. This in itself does not imply *faster* processing. We also need to weigh the placement of the MAC address(es), and the fact that making it optional can incur extra processing cost. > but IP level filtering is enough OK. > - If the IRD is itself a router, there is still the case (that may be > of (most?) common usage ??) that the network behind it is a > leaf-network, and by no mean a transit network. OK, so specifically you mean a leaf network where routing protocols are not used to determine forwarding to the "leaf" network. One example is a network with one external receive interface (via the MPEG-2 port). That is, theer are no alternative delivery paths, and therefore no reachability via other routers that may also receive the packet. Specifically you must also require all other routers to silently drop packets with an unreachable network address. If you do all this, I agree - but although this would work, it seems a "tweak", and I'm not sure the latter is a robust recommendation (if one router returns an ICMP message to the source, what happens??) > In this case, the router > acts as a CPE, and usually "knows" what is behind him, let's say > my_site_prefix::/48. The firewall rule with something like > 100 deny ipv6 from any to !my_site_prefix::/48 via dvb0 in > will give the needed filering, without any MAC address needed. > OK, and all other routers must REJECT (filter & silenetly discard) packets with no MAC address and that do not match their own site prefix. > or even a mechanism based on the redirect-conditions, I mean if this is > a CPE, it will have a typical ::/0 route through the logical dvb > interface (that can use SPCP, RCS, whatever mean for the return link), > and a packet not addressed to a host present in the site will be > naturally forwarded through the dvb interface, which is a potential case > for a redirect (i.e. sam ingoing/outgoing interface). > If the interface is configured with a feat such as : > - if the redirect conditions matches, then DROP packet silenly > It will perform the same filtering as abiven but without the /48 > delegation stored into a firewal rule (sort of RPF check), which is even > more cool. > > Your thoughts ? My thoughts are that we have some cases here that can use IP packets without MAC addresses, providing: (a) they can efficiently filter on IP level addresses AND (b) If they are routers they MUST also differentiate packets with a MAC dest address from those without a MAC address, and MUST discard packets with no MAC address that do not correspond to their own IP address (or with all the rules above to the prefix used for hosts on a leaf IP network.) > Regards. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 14:25:46 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VDPOc4020311 for ; Thu, 31 Jul 2003 14:25:24 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VDPO95020310 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 14:25:24 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VDOxc4020291 for ; Thu, 31 Jul 2003 14:24:59 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 0AF5C5F9 for ; Thu, 31 Jul 2003 15:25:01 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id CFB4553A for ; Thu, 31 Jul 2003 15:25:00 +0200 (CEST) Message-ID: <3F29196C.3080300@6wind.com> Date: Thu, 31 Jul 2003 15:28:12 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: About dest MAC@ References: <3F17BA85.8010003@6wind.com> <3F290ED2.AEDB5044@erg.abdn.ac.uk> In-Reply-To: <3F290ED2.AEDB5044@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dr G Fairhurst wrote: > >>- If the IRD is itself a router, there is still the case (that may be >>of (most?) common usage ??) that the network behind it is a >>leaf-network, and by no mean a transit network. > > > OK, so specifically you mean a leaf network where routing protocols are > not used to determine forwarding to the "leaf" network. One example is a > network with one external receive interface (via the MPEG-2 port). Not exactly, in fact, the "leaf" network I had in mind could have several point of access (i.e CPE), but does NOT provide transit, hence only packets destined to the "leaf" network should be accepted. > > That is, theer are no alternative delivery paths, and therefore no > reachability via other routers that may also receive the packet. Specifically > you must also require all other routers to silently drop packets with > an unreachable network address. If you do all this, I agree - but > although this would work, it seems a "tweak", and I'm not sure the > latter I admit this is tweaky, and I'm not definitly proud of it ;-) > is a robust recommendation (if one router returns an ICMP message to > the source, what happens??) Well, the source is informed that dest is unreachable, and may stop. So indeed, it works only when ALL routers perform the same trick, which is somehow fragile I admit. > > My thoughts are that we have some cases here that can use IP packets > without MAC addresses, providing: > > (a) they can efficiently filter on IP level addresses > > AND > > (b) If they are routers they MUST also differentiate packets with > a MAC dest address from those without a MAC address, and MUST discard > packets with no MAC address that do not correspond to their own IP address > (or with all the rules above to the prefix used for hosts on a leaf IP network.) Definitely agree, the trick was only for the case where there's no MAC addr. Of course, if there is a MAC addr, is MUST be used to reject or accept packets whatever their dst IP addr is. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 14:57:54 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VDv6c4020958 for ; Thu, 31 Jul 2003 14:57:06 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VDv6PM020957 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 14:57:06 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VDumc4020940 for ; Thu, 31 Jul 2003 14:56:49 +0100 (BST) Message-ID: <3F292023.2FC2017B@erg.abdn.ac.uk> Date: Thu, 31 Jul 2003 14:56:50 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: About dest MAC@ References: <3F17BA85.8010003@6wind.com> <3F290ED2.AEDB5044@erg.abdn.ac.uk> <3F29196C.3080300@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk alain.ritoux@6wind.com wrote: > > Dr G Fairhurst wrote: > > > > >>- If the IRD is itself a router, there is still the case (that may be > >>of (most?) common usage ??) that the network behind it is a > >>leaf-network, and by no mean a transit network. > > > > > > OK, so specifically you mean a leaf network where routing protocols are > > not used to determine forwarding to the "leaf" network. One example is a > > network with one external receive interface (via the MPEG-2 port). > > Not exactly, in fact, the "leaf" network I had in mind could have > several point of access (i.e CPE), but does NOT provide transit, hence > only packets destined to the "leaf" network should be accepted. > OK, but what happens whene there are several places (networks) via which the "leaf: network may receive an Ip packet? - routers normally advertise that a site is reachable via an interface. Do routers do this on each network to which they are attached? If so, how do the routers connected to the MPEG-2 feed know whether to forward the packet from the MPEG-2 feed via the other network(s) to the destination end host, or to discard this packet because someone else will be forwarding? - This is usually the function of the IP routing protocol in combination with the link MAC address. In the case of just one receive interface, the above point is moot, and we don't have the same routing issues. > > > > That is, theer are no alternative delivery paths, and therefore no > > reachability via other routers that may also receive the packet. Specifically > > you must also require all other routers to silently drop packets with > > an unreachable network address. If you do all this, I agree - but > > although this would work, it seems a "tweak", and I'm not sure the > > latter > I admit this is tweaky, and I'm not definitly proud of it ;-) > > > is a robust recommendation (if one router returns an ICMP message to > > the source, what happens??) > Well, the source is informed that dest is unreachable, and may stop. > So indeed, it works only when ALL routers perform the same trick, which > is somehow fragile I admit. > Ok, so, you can do it this way if you have an operational need, but it's probably not a recommended solution. > > > > My thoughts are that we have some cases here that can use IP packets > > without MAC addresses, providing: > > > > (a) they can efficiently filter on IP level addresses > > > > AND > > > > (b) If they are routers they MUST also differentiate packets with > > a MAC dest address from those without a MAC address, and MUST discard > > packets with no MAC address that do not correspond to their own IP address > > (or with all the rules above to the prefix used for hosts on a leaf IP network.) > Definitely agree, the trick was only for the case where there's no MAC > addr. Of course, if there is a MAC addr, is MUST be used to reject or > accept packets whatever their dst IP addr is. > > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 15:28:29 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VESAc4021846 for ; Thu, 31 Jul 2003 15:28:10 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VES9Q9021845 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 15:28:10 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rover.inria.fr (IDENT:root@rover.inria.fr [138.96.88.61]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VERkc4021816 for ; Thu, 31 Jul 2003 15:27:47 +0100 (BST) Received: from sophia.inria.fr (localhost [127.0.0.1]) by rover.inria.fr (8.12.8/8.12.5) with ESMTP id h6VDqi3f005970; Thu, 31 Jul 2003 15:52:44 +0200 Message-ID: <3F291F2C.1030804@sophia.inria.fr> Date: Thu, 31 Jul 2003 15:52:44 +0200 From: Fethi Filali Organization: INRIA Sophia-Antipolis (http://www.inria.fr) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk, udlr@udcast.fr Subject: Paper on Multicast Support over "next-generation" DVB-based satellite systems Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi, I would like to announce you our work on multicast support over DVB-based satellite systems that will appear in JSAC Journal which I guess may interest some of you: Title: Efficient Support of IP Multicast in the Next-Generation of GEO Satellites Abstract: The satellites are expected to have an important role in providing the IP multicast service to complementing next generation terrestrial networks. In this paper, we focus on the deployment of IP multicast over the next-generation of DVB-based GEO satellites supporting multiple spot-beams and on-board switching technologies. We propose a new encapsulation scheme optimized for IP multicast which has two distinct modes enabling two alternative on-board switching approaches: the self-switching and the label-switching. We also detail a set of mechanisms and protocols for ground stations as well as for the on-board processor to allow an efficient multicast forwarding in such type of environment, while reducing the load of control and data messages in the satellite segment, and building efficient multicast delivery trees reaching only the spot beams containing at least one member of the corresponding multicast session. To integrate satellite links in the terrestrial Internet, we present SMAP (Satellite Multicast Adaptation Protocol), a protocol which is implemented in satellite stations to process incoming PIM-SM messages sent by terrestrial nodes to the satellite system. SMAP helps to update the tables required for the mapping between IP packets and MPEG-2 data segments, their switching on-board the satellite, and their filtering at the satellite receivers. The paper is available at : ftp://ftp-sop.inria.fr/rodeo/filali/pub/filali-jsac03.pdf Regards, Fethi Filali. From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 16:10:39 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VF9oc4022972 for ; Thu, 31 Jul 2003 16:09:50 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VF9nqE022969 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 16:09:49 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from cpt077.canal-plus.fr (cpt077.canal-plus.fr [194.2.208.77]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VF8tc4022914 for ; Thu, 31 Jul 2003 16:08:55 +0100 (BST) Received: from antivirus-gw.ctechno.net (servap08 [192.168.240.200]) by cpt077.canal-plus.fr (8.12.9/8.12.9) with ESMTP id h6VF8q6H015699 for ; Thu, 31 Jul 2003 17:08:52 +0200 (MEST) Content-Class: urn:content-classes:message Received: from servap08.ctechno.net ([127.0.0.1]) by antivirus-gw.ctechno.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 31 Jul 2003 17:08:52 +0200 Received: from intranet.canal-plus.fr ([172.20.11.68]) by mail2.ctechno.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 17:08:51 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Received: from canal-plus.fr ([192.168.243.239]) by intranet.canal-plus.fr (8.11.1/8.11.1) with ESMTP id h6VF8px11632 for ; Thu, 31 Jul 2003 17:08:51 +0200 (MET DST) Message-ID: <3F293119.3DF80B28@canal-plus.fr> Date: Thu, 31 Jul 2003 17:09:13 +0200 From: "Bertrand WENDLING" Organization: CANAL+ Technologies X-Mailer: Mozilla 4.7 [en]C-CCK-MCD C+ (Win98; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: Subject: Re: About dest MAC@ References: <3F17BA85.8010003@6wind.com> <3F290ED2.AEDB5044@erg.abdn.ac.uk> <3F29196C.3080300@6wind.com> <3F292023.2FC2017B@erg.abdn.ac.uk> Content-Type: multipart/mixed; boundary="------------1FF5D2B75594DE81267D275E" X-OriginalArrivalTime: 31 Jul 2003 15:08:51.0874 (UTC) FILETIME=[A6DC2020:01C35775] X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------1FF5D2B75594DE81267D275E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alain, dear Gorry, I am a little puzzled by this discussion, you should not forget that in = a broadcast world (meaning DVB-MPEG2), it is very uncommon for the broadcaster to = know the MAC and even the IP address of a receiver (today nearly all of them don't even = have one). Receivers are bought in any kind of retail shop and are plug and play = when connected to a dish. In a broadcast mode the only thing you need to know on the = receiver side is what IP service I have to listen to in order to get access the expected = service (the IP address is here used as another filtering criteria to extract the = relevant IP sections in an IP stream). Regarding the broadcast technology (still meaning = DVB-MPEG2), except for specific B to B application, it is uncommon to do unicast, just = because of the cost of the bandwidth. Now, the interesting point is when a receiver have a broadcast access = (e.g. a dish to get the MPEG2 signal), and a DSL access. In this case, the receiver will = work in the same way as a PC connected to the DSL network, but might access data = from both network (the MPEG 2 and the DSL one) for various application where two streams = may be needed (the common one broadcasted, and the user specific one streamed over = DSL). Now, assume that in case the broadcaster wants to send data to a = specific user over the DVB-MPEG2 network, based on a request coming through the DSL network = (back channel), he will have to give the receiver the DVB triplet (to locate the TS and = PID) and an IP address to filter on. In any case, the only way the receiver can be = known by the broadcaster is when he has a return channel (e.g. a DSL connection, and = then, the IP address is allocated by the ISP). Could you perhaps explain a little more the concrete scenarios and = operational configurations you have in mind ? Best regards Bertrand Dr G Fairhurst wrote: > alain.ritoux@6wind.com wrote: > > > > Dr G Fairhurst wrote: > > > > > > > >>- If the IRD is itself a router, there is still the case (that may = be > > >>of (most?) common usage ??) that the network behind it is a > > >>leaf-network, and by no mean a transit network. > > > > > > > > > OK, so specifically you mean a leaf network where routing = protocols are > > > not used to determine forwarding to the "leaf" network. One = example is a > > > network with one external receive interface (via the MPEG-2 port). > > > > Not exactly, in fact, the "leaf" network I had in mind could have > > several point of access (i.e CPE), but does NOT provide transit, = hence > > only packets destined to the "leaf" network should be accepted. > > > > OK, but what happens whene there are several places (networks) > via which the "leaf: network may receive an Ip packet? > - routers normally advertise that a site is reachable > via an interface. Do routers do this on each network to which they > are attached? > > If so, how do the routers connected to the MPEG-2 feed know whether > to forward the packet from the MPEG-2 feed via the other network(s) > to the destination end host, or to discard this packet because > someone else will be forwarding? - This is usually the function of the > IP routing protocol in combination with the link MAC address. > > In the case of just one receive interface, the above point is moot, > and we don't have the same routing issues. > > > > > > > That is, theer are no alternative delivery paths, and therefore no > > > reachability via other routers that may also receive the packet. = Specifically > > > you must also require all other routers to silently drop packets = with > > > an unreachable network address. If you do all this, I agree - but > > > although this would work, it seems a "tweak", and I'm not sure the > > > latter > > I admit this is tweaky, and I'm not definitly proud of it ;-) > > > > > is a robust recommendation (if one router returns an ICMP message = to > > > the source, what happens??) > > Well, the source is informed that dest is unreachable, and may stop. > > So indeed, it works only when ALL routers perform the same trick, = which > > is somehow fragile I admit. > > > > Ok, so, you can do it this way if you have an operational need, but > it's probably not a recommended solution. > > > > > > > My thoughts are that we have some cases here that can use IP = packets > > > without MAC addresses, providing: > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > AND > > > > > > (b) If they are routers they MUST also differentiate packets with > > > a MAC dest address from those without a MAC address, and MUST = discard > > > packets with no MAC address that do not correspond to their own IP = address > > > (or with all the rules above to the prefix used for hosts on a = leaf IP network.) > > > Definitely agree, the trick was only for the case where there's no = MAC > > addr. Of course, if there is a MAC addr, is MUST be used to reject = or > > accept packets whatever their dst IP addr is. > > > > Alain. > > -- > > Alain RITOUX > > Tel +33-1-39-30-92-32 > > Fax +33-1-39-30-92-11 > > visit our web http://www.6wind.com -- This message and any attachments (the "message") is intended solely for = the addressees and is confidential. If you receive this message in error, = please delete it and immediately notify the sender. Any use not in accordance with its purpose, any dissemination or = disclosure, either whole or partial, is prohibited except formal approval. The E-Mail transmission can not guarantee the integrity of this message. CANAL+TECHNOLOGIES will not therefore be liable for the message if = modified. --------------1FF5D2B75594DE81267D275E Content-Type: text/x-vcard; charset="us-ascii"; name="wendling.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bertrand WENDLING Content-Disposition: attachment; filename="wendling.vcf" begin:vcard n:Bertrand;WENDLING tel;cell:+33 6 03 45 86 54 tel;fax:+33 1 71 71 50 51 tel;work:+33 1 71 71 53 57 x-mozilla-html:TRUE url:www.canalplus-technologies.com org:CANAL+ Technologies;Advanced Studies & Standardisation Department adr:;;34 place Raoul Dautry;75738 PARIS Cedex 15;;;France version:2.1 email;internet:wendling@canal-plus.fr title:Standards Officer fn:WENDLING Bertrand end:vcard --------------1FF5D2B75594DE81267D275E-- From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 16:10:50 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VFAFc4023011 for ; Thu, 31 Jul 2003 16:10:15 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VFAFZC023010 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 16:10:15 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VF9Lc4022945 for ; Thu, 31 Jul 2003 16:09:22 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 35F29F5 for ; Thu, 31 Jul 2003 17:09:24 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 3A8FC53A; Thu, 31 Jul 2003 17:09:24 +0200 (CEST) Message-ID: <3F2931E3.2000507@6wind.com> Date: Thu, 31 Jul 2003 17:12:35 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: About dest MAC@ References: <3F17BA85.8010003@6wind.com> <3F290ED2.AEDB5044@erg.abdn.ac.uk> <3F29196C.3080300@6wind.com> <3F292023.2FC2017B@erg.abdn.ac.uk> In-Reply-To: <3F292023.2FC2017B@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dr G Fairhurst wrote: > > alain.ritoux@6wind.com wrote: > > > OK, but what happens whene there are several places (networks) > via which the "leaf: network may receive an Ip packet? > - routers normally advertise that a site is reachable > via an interface. Do routers do this on each network to which they > are attached? I would think so > If so, how do the routers connected to the MPEG-2 feed know whether > to forward the packet from the MPEG-2 feed via the other network(s) > to the destination end host, or to discard this packet because > someone else will be forwarding? - This is usually the function of the > IP routing protocol in combination with the link MAC address. Indeed, I would rely on IP routing, to provide it only once, in fact it should work unless, two attachements of the leaf network are connected to the same MPEG2-feed. Or if I get your point : if some of the transit networks for secondary attachłent points are linked to the same MPEG2-feed : so in this case, the former route annoucement spoils everything. So it can not work as soon as 2 or more acces networks (which can be the "leaf" network itself) are connected to a single XXX-feed, i.e. a network that has this annoying property of not having MAC addrs. This will indeed be far too difficult todefine properly, and OK the proposed filtering mechanism is only safely appliable when we restrict the "leaf" network as : only one acces ! > > In the case of just one receive interface, the above point is moot, > and we don't have the same routing issues. OK. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Jul 31 19:16:35 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VIFwc4026793 for ; Thu, 31 Jul 2003 19:15:58 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h6VIFw7R026792 for ip-dvb-subscribed-users; Thu, 31 Jul 2003 19:15:58 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail1.iabg.de (mail1.iabg.de [194.139.245.9]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6VIF6c4026753 for ; Thu, 31 Jul 2003 19:15:07 +0100 (BST) Received: from mail1.iabg.de (localhost [127.0.0.1]) by localhost (Mailserver IABG) with ESMTP id 1A6FB6E58 for ; Thu, 31 Jul 2003 20:15:02 +0200 (CEST) Received: from exchange.iabg.de (exchange.iabg.de [10.128.200.12]) by mail1.iabg.de (Mailserver IABG) with ESMTP id 027D86DFA for ; Thu, 31 Jul 2003 20:15:02 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: About dest MAC@ Date: Thu, 31 Jul 2003 20:15:04 +0200 Message-ID: <3141ED5F60D45E4BA847F18B2DFD92A801258372@exchange.iabg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About dest MAC@ Thread-Index: AcNXeEybRwB3jIm7Tq601YcT7MZE6QAFIhEQ From: "Fritsche Wolfgang" To: X-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 h6VIFtdm026785 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Bertrand, assume the following example operational scenario: A teleport service provider provides broadband Internet access via DVB-S to smaller ISPs located in regions without terrestrial broadband access. This teleport provider serves more customer on the same transponder. It assigns to each of them a global routable IP address space. Receiving traffic from the Internet destined to one of its customer's IP address space the teleport service provider will broadcast the traffic on the DVB-S link. As this link is shared by more customer, the traffic "physically" will be received by all of them. In order to allow efficient filtering, the teleport provider uses a specific PID for each customer as well as the MAC address of the customer's receiving equipment. This scenario could also include a "kind of manually configured and therefore static address resolution" (mapping of customer's IP address space to customer's PID / MAC address). Doing things like address resolution automatically is somewhat difficult if we're talking about uni-directional links. However this example operational scenario reflect many aspects Alain and Gorry discussed: - The connected minor ISP could use the teleport service provider as the only external access (leaf network with single access point) - The connected minor ISP could use also other teleport service providers / peering ISPs but do not transit traffic between them (leaf network with several access points) - The connected minor ISP could use also other teleport service providers / peering ISPs and do transit traffic between them (transit network with several access points) What I do not see so far as a common operational scenario is that one customer will receive for its IP address range traffic via several access router connected to the same DVB-S transponder. But also this could change in future if IPv6 brings more possibilities for multihoming and network renumbering. Cheers, Wolfgang > > > Dear Alain, dear Gorry, > I am a little puzzled by this discussion, you should not > forget that in a broadcast world (meaning DVB-MPEG2), it is > very uncommon for the broadcaster to know the MAC and even > the IP address of a receiver (today nearly all of them don't > even have one). Receivers are bought in any kind of retail > shop and are plug and play when connected to a dish. In a > broadcast mode the only thing you need to know on the > receiver side is what IP service I have to listen to in order > to get access the expected service (the IP address is here > used as another filtering criteria to extract the relevant IP > sections in an IP stream). Regarding the broadcast technology > (still meaning DVB-MPEG2), except for specific B to B > application, it is uncommon to do unicast, just because of > the cost of the bandwidth. Now, the interesting point is when > a receiver have a broadcast access (e.g. a dish to get the > MPEG2 signal), and a DSL access. In this case, the receiver > will work in the same way as a PC connected to the DSL > network, but might access data from both network (the MPEG 2 > and the DSL one) for various application where two streams > may be needed (the common one broadcasted, and the user > specific one streamed over DSL). Now, assume that in case the > broadcaster wants to send data to a specific user over the > DVB-MPEG2 network, based on a request coming through the DSL > network (back channel), he will have to give the receiver the > DVB triplet (to locate the TS and PID) and an IP address to > filter on. In any case, the only way the receiver can be > known by the broadcaster is when he has a return channel > (e.g. a DSL connection, and then, the IP address is allocated > by the ISP). Could you perhaps explain a little more the > concrete scenarios and operational configurations you have in > mind ? Best regards Bertrand > > Dr G Fairhurst wrote: > > > alain.ritoux@6wind.com wrote: > > > > > > Dr G Fairhurst wrote: > > > > > > > > > > >>- If the IRD is itself a router, there is still the > case (that may > > > >>be of (most?) common usage ??) that the network behind it is a > > > >>leaf-network, and by no mean a transit network. > > > > > > > > > > > > OK, so specifically you mean a leaf network where routing > > > > protocols are not used to determine forwarding to the "leaf" > > > > network. One example is a network with one external receive > > > > interface (via the MPEG-2 port). > > > > > > Not exactly, in fact, the "leaf" network I had in mind could have > > > several point of access (i.e CPE), but does NOT provide transit, > > > hence only packets destined to the "leaf" network should be > > > accepted. > > > > > > > OK, but what happens whene there are several places (networks) via > > which the "leaf: network may receive an Ip packet? > > - routers normally advertise that a site is reachable > > via an interface. Do routers do this on each network to > which they are > > attached? > > > > If so, how do the routers connected to the MPEG-2 feed know > whether to > > forward the packet from the MPEG-2 feed via the other network(s) to > > the destination end host, or to discard this packet because someone > > else will be forwarding? - This is usually the function of the IP > > routing protocol in combination with the link MAC address. > > > > In the case of just one receive interface, the above point is moot, > > and we don't have the same routing issues. > > > > > > > > > > That is, theer are no alternative delivery paths, and > therefore no > > > > reachability via other routers that may also receive > the packet. > > > > Specifically you must also require all other routers to > silently > > > > drop packets with an unreachable network address. If you do all > > > > this, I agree - but although this would work, it seems > a "tweak", > > > > and I'm not sure the latter > > > I admit this is tweaky, and I'm not definitly proud of it ;-) > > > > > > > is a robust recommendation (if one router returns an > ICMP message > > > > to the source, what happens??) > > > Well, the source is informed that dest is unreachable, > and may stop. > > > So indeed, it works only when ALL routers perform the same trick, > > > which is somehow fragile I admit. > > > > > > > Ok, so, you can do it this way if you have an operational need, but > > it's probably not a recommended solution. > > > > > > > > > > My thoughts are that we have some cases here that can use IP > > > > packets without MAC addresses, providing: > > > > > > > > (a) they can efficiently filter on IP level addresses > > > > > > > > AND > > > > > > > > (b) If they are routers they MUST also differentiate > packets with > > > > a MAC dest address from those without a MAC address, and MUST > > > > discard packets with no MAC address that do not correspond to > > > > their own IP address (or with all the rules above to the prefix > > > > used for hosts on a leaf IP network.) > > > > > Definitely agree, the trick was only for the case where > there's no > > > MAC addr. Of course, if there is a MAC addr, is MUST be used to > > > reject or accept packets whatever their dst IP addr is. > > > > > > Alain. > > > -- > > > Alain RITOUX > > > Tel +33-1-39-30-92-32 > > > Fax +33-1-39-30-92-11 > > > visit our web http://www.6wind.com > > -- > This message and any attachments (the "message") is intended > solely for the addressees and is confidential. If you receive > this message in error, please delete it and immediately > notify the sender. Any use not in accordance with its > purpose, any dissemination or disclosure, either whole or > partial, is prohibited except formal approval. The E-Mail > transmission can not guarantee the integrity of this message. > CANAL+TECHNOLOGIES will not therefore be liable for the message if > CANAL+modified. > > >