From 6lowpan-bounces@ietf.org Fri Jan 05 04:06:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2l1S-00084W-2B; Fri, 05 Jan 2007 04:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2l1Q-00084R-At for 6lowpan@lists.ietf.org; Fri, 05 Jan 2007 04:05:56 -0500 Received: from maily.danfoss.com ([193.162.34.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2l1L-0008Qa-Sx for 6lowpan@lists.ietf.org; Fri, 05 Jan 2007 04:05:55 -0500 Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 10:05:48 +0100 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security Suite; Fri, 05 Jan 2007 10:05:48 +0100 Received: from DKDN01MX34.danfoss.net ([10.12.128.16]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 10:05:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] WG last call on Format document Date: Fri, 5 Jan 2007 10:05:46 +0100 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7B4BC91@DKDN01MX34.danfoss.net> In-Reply-To: <21F0CDBA-E61A-42AF-AB72-115A874226B8@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WG last call on Format document thread-index: AccfpiSALgyBKUV7TC6n0VC26mcUrwRATWTA From: "Schumacher Christian Peter Pii" To: "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 05 Jan 2007 09:05:48.0172 (UTC) FILETIME=[B0C57CC0:01C730A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear 6lowpanners=20 The deadline for the last call has passed. There have been a few comments on the list: Comment 1. Reassembly (Philip Levis and Carsten Bormann): - Carsten assumes a mesh forwarder doesn't need to reassemble. - Philip believes a mesh forwarder must reassemble, as that would be more energy efficient. Comment 2. IANA considerations (Philip Levis): - Is arbitration of the 00xxxxxx values under its =20 purview? (Regarding NALP) To resolve comment 1: I urge the mailing list to respond with your opinions on this matter. To resolve comment 2: I believe it is within the purview of IANA, but can anyone confirm this? A final question, is there anyone who doesn't feel the format document is ready for IESG review? Regards Christian -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: 14. december 2006 17:47 To: Carsten Bormann Cc: 6lowpan Subject: Re: [6lowpan] WG last call on Format document On Dec 14, 2006, at 12:58 AM, Carsten Bormann wrote: >> I still have a concern about the ordering of the fragmentation and =20 >> mesh delivery headers. Can anyone offer a good argument on why =20 >> fragmentation is within mesh and not vice versa? > > I think the general rule is that a node should only have to parse =20 > the subheaders that it is concerned with. > > I'm assuming a mesh forwarder does not reassemble (I don't happen =20 > to know any good reason why it should). Energy. Imagine a theoretical route from N0 to NX of nodes N0, N1, =20 N2, ... NX. Let us suppose that each link (NZ,NZ+1) has a packet loss =20 rate of L. If you have no e2e fragment recovery, then an IPv6 packet =20 P composed of F fragments has a ((1-L)^X)^F probability of successful =20 delivery. The probability of any fragment being delivered =20 successfully is (1-L)^X, and the probability of all of them being =20 delivered successfully is (1-L)^X^F. It decreases exponentially with =20 path length and packet size. With no fragment recovery, you have to =20 resend the entire packet when this occurs. So the cost of a single =20 fragment failure is FX transmissions and the overall cost to deliver =20 a packet successfully is approximately FX + FX * (1-L)^-XF. With multihop reassembly, a single fragment loss requires control =20 traffic to request the fragment, which itself also has a loss rate of =20 (1-L)^X, then the fragment being retransmitted. So the cost of a =20 single fragment failure is 2X transmissions, and the cost to deliver =20 a packet successfully is approximately FX + 2FX * (1-L)^-X. With single-hop reassembly, each hop reassembles the packet as =20 needed. Because losses are locally recovered, you do not have the =20 exponential growth in packet loss. Unlike multihop recovery, where =20 the number of packets transmitted is going to approximately be FX * =20 ((1-L)^X)^-1, (the expected number of transmissions per packet is the =20 inverse of the loss rate), in single-hop recovery the equation is =20 multiplicative: FX* (1-L)^-1. Each link sends only (1-L)^-1 copies of =20 its each fragment, with retransmissions caused by local failures. So =20 the cost becomes FX + 2FX * (1-L)^-1. Recap: F is number of fragments X is length of route L is loss rate on each hop Multihop reassembly with full packet retransmission: FX + FX * (1-L)^-XF Multihop reassembly with fragment retransmission: FX + 2FX * (1-L)^-X Single-hop reassembly with fragment retransmission: FX + 2FX * (1-L)-1 Additionally, if you layer mesh on top of fragmentation, then every =20 mesh packet has a fragmentation header in it. If the mesh header =20 length is M and the fragment header length is G, then each fragment =20 has M+G bytes added to it, for a total of F * (M + G). If you reverse =20 the layering, then only the first fragment has the mesh header, and =20 so you have a header cost of M + FG. Finally, it is (in my experience, others might differ on this) also =20 easier to manage the state and retransmission policies, as reassembly =20 does not have to worry about greatly different latencies caused by =20 route changes between fragments. That being said, if X, F, and L are always going to be small, then =20 the exponents don't matter. But there's a fundamental scalability =20 problem. > So a mesh forwarder is concerned with the forwarding header only; =20 > these therefore should come first. > Only at the L2 destination is it necessary to peek further into the =20 > header, e.g. the fragmentation header for reassembly. > > Compare this with IPv6: The forwarding header (here the IP header) =20 > is in front of the fragmentation header, which is a destination =20 > header (only "opened" at the destination address set in the IP =20 > header). > Two mails ago: I have one concern with the current draft: the ordering of the =20 fragmentation and mesh headers. In his presentation at IETF 67, =20 Jonathan noted that the order followed the model presented by =20 standard IPv6. In IPv6, fragmentation/reassembly must be end-to-end, =20 so the ordering makes sense. However, this is sub-IP. I think that =20 most of the real-world experiments with 15.4 radios, as well as basic =20 loss models, suggest that per-hop fragmentation/reassembly is greatly =20 preferable to e2e, particularly for energy reasons. You don't need to =20 add a mesh header on each fragment, you have fewer retransmissions, =20 and less state maintenance. Including a mesh routing header is =20 essentially to provide IP routing; following the guidelines of RFC =20 2460 Section 5, I believe the order of these two headers should be =20 reversed: a node fragments and reassembles a mesh packet on a per-hop =20 basis, rather than routing an IPv6 datagram one fragment at a time. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jan 05 13:16:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tcA-0006Xh-By; Fri, 05 Jan 2007 13:16:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tc8-0006Vp-SA for 6lowpan@ietf.org; Fri, 05 Jan 2007 13:16:25 -0500 Received: from web81915.mail.mud.yahoo.com ([68.142.207.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2tc5-0000ou-VH for 6lowpan@ietf.org; Fri, 05 Jan 2007 13:16:24 -0500 Received: (qmail 24099 invoked by uid 60001); 5 Jan 2007 18:16:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=DaeSONb+HXsgedvsaztwB1+yQAqhQ3YOGC9DLggi1mpexxSTme8GWPYYZu5p0B+xN0/x5+K9AMytBdZfgDqj0Q4eFBDOJTx8QDQ8jlcNk25ySNtqPj5H97QLrRnCCUyAt/lbnuBzekpqJJTf7DHO1Q/q6UZ224x6+z+wN5Qc6iA= ; Message-ID: <20070105181621.24097.qmail@web81915.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81915.mail.mud.yahoo.com via HTTP; Fri, 05 Jan 2007 10:16:21 PST Date: Fri, 5 Jan 2007 10:16:21 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] WG last call on Format document To: Schumacher Christian Peter Pii MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1729704189==" Errors-To: 6lowpan-bounces@ietf.org --===============1729704189== Content-Type: multipart/alternative; boundary="0-773962659-1168020981=:21803" --0-773962659-1168020981=:21803 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable On Comment 1: Reassembly: I don't think we should delay the draft because o= f this.=0AI think this is an interesting research topic. I notice that ther= e are similarities with=0Athe folks applying DTN to sensor networks (projec= ts at UCLA's LECS, SICS, Trinity College, etc).=0ADTN is itself a research = group in the IRTF, so similarly, I see such extensions to LoWPAN=0Aas possi= ble alternatives once the basic draft in its current form is done. One pos= sible =0Aavenue is to reuse AODV to do the discovery of the DTN-capable dev= ices, and integrate with =0Athe routing layer such that the proper tradeoff= s (end-to-end, hop-by-hop or anything in the=0Amiddle) are possible. Such a= n approach was discussed recently at the CHANTS workshop and =0AIRTF DTNRG:= =0Apaper: http://doi.acm.org/10.1145/1162654.1162659=0Aslides: http://www= 3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf=0ASuch functionality shoul= d be worked on subsequent to the base spec.=0A=0AOn Comment 2: are NALP val= ues handled by IANA?=0AI think it doesn't need to be. But someone should ha= ndle this assignment space=0Aif it is to serve its purpose of avoiding conf= licts. So IANA *could* maintain the=0Arepository, but as a convenience only= . This suggests that (from RFC2434) =0A"First Come First Served" is an appr= opriate policy.=0A=0AI note that there is one remaining item which fell thr= ough the cracks:=0Awe need to define the format of future dispatch headers.= The length of the=0Adispatch headers defined in the base spec is known, so= protocol parsing can=0Aproceed. For future dispatch headers, we need to in= clude a length field in =0Aa well-known place in the header, otherwise prop= er parsing is not possible.=0AThis needs to be in the base spec.=0A=0AAlso,= there are some remaining notes that should be deleted before progressing.= =0A=0A-gabriel =0A=0A----- Original Message ----=0AFrom: Schumacher Christi= an Peter Pii =0ATo: 6lowpan <6lowpan@lists.ietf.org= >=0ACc: Carsten Bormann =0ASent: Friday, January 5, 2007 1:05= :46 AM=0ASubject: RE: [6lowpan] WG last call on Format document=0A=0ADear 6= lowpanners =0AThe deadline for the last call has passed.=0A=0AThere have be= en a few comments on the list:=0A=0AComment 1. Reassembly (Philip Levis and= Carsten Bormann):=0A- Carsten assumes a mesh forwarder doesn't need to rea= ssemble.=0A- Philip believes a mesh forwarder must reassemble, as that woul= d be=0Amore energy efficient.=0A=0AComment 2. IANA considerations (Philip L= evis):=0A- Is arbitration of the 00xxxxxx values under its =0Apurview? (Re= garding NALP)=0A=0ATo resolve comment 1: I urge the mailing list to respond= with your=0Aopinions on this matter.=0ATo resolve comment 2: I believe it = is within the purview of IANA, but=0Acan anyone confirm this?=0A=0AA final = question, is there anyone who doesn't feel the format document=0Ais ready f= or IESG review?=0A=0ARegards=0AChristian=0A=0A=0A=0A-----Original Message--= ---=0AFrom: Philip Levis [mailto:pal@cs.stanford.edu] =0ASent: 14. december= 2006 17:47=0ATo: Carsten Bormann=0ACc: 6lowpan=0ASubject: Re: [6lowpan] WG= last call on Format document=0A=0AOn Dec 14, 2006, at 12:58 AM, Carsten Bo= rmann wrote:=0A=0A>> I still have a concern about the ordering of the fragm= entation and =0A>> mesh delivery headers. Can anyone offer a good argument= on why =0A>> fragmentation is within mesh and not vice versa?=0A>=0A> I t= hink the general rule is that a node should only have to parse =0A> the su= bheaders that it is concerned with.=0A>=0A> I'm assuming a mesh forwarder d= oes not reassemble (I don't happen =0A> to know any good reason why it sho= uld).=0A=0AEnergy. Imagine a theoretical route from N0 to NX of nodes N0, N= 1, =0AN2, ... NX. Let us suppose that each link (NZ,NZ+1) has a packet los= s =0Arate of L. If you have no e2e fragment recovery, then an IPv6 packet = =0AP composed of F fragments has a ((1-L)^X)^F probability of successful = =0Adelivery. The probability of any fragment being delivered =0Asuccessful= ly is (1-L)^X, and the probability of all of them being =0Adelivered succe= ssfully is (1-L)^X^F. It decreases exponentially with =0Apath length and p= acket size. With no fragment recovery, you have to =0Aresend the entire pa= cket when this occurs. So the cost of a single =0Afragment failure is FX t= ransmissions and the overall cost to deliver =0Aa packet successfully is a= pproximately FX + FX * (1-L)^-XF.=0A=0AWith multihop reassembly, a single f= ragment loss requires control =0Atraffic to request the fragment, which it= self also has a loss rate of =0A(1-L)^X, then the fragment being retransmi= tted. So the cost of a =0Asingle fragment failure is 2X transmissions, and= the cost to deliver =0Aa packet successfully is approximately FX + 2FX * = (1-L)^-X.=0A=0AWith single-hop reassembly, each hop reassembles the packet = as =0Aneeded. Because losses are locally recovered, you do not have the = =0Aexponential growth in packet loss. Unlike multihop recovery, where =0At= he number of packets transmitted is going to approximately be FX * =0A((1-= L)^X)^-1, (the expected number of transmissions per packet is the =0Ainver= se of the loss rate), in single-hop recovery the equation is =0Amultiplica= tive: FX* (1-L)^-1. Each link sends only (1-L)^-1 copies of =0Aits each fr= agment, with retransmissions caused by local failures. So =0Athe cost beco= mes FX + 2FX * (1-L)^-1.=0A=0ARecap:=0A=0AF is number of fragments=0AX is l= ength of route=0AL is loss rate on each hop=0A=0AMultihop reassembly with f= ull packet retransmission: FX + FX * (1-L)^-XF=0AMultihop reassembly with f= ragment retransmission: FX + 2FX * (1-L)^-X=0ASingle-hop reassembly with fr= agment retransmission: FX + 2FX * (1-L)-1=0A=0AAdditionally, if you layer m= esh on top of fragmentation, then every =0Amesh packet has a fragmentation= header in it. If the mesh header =0Alength is M and the fragment header l= ength is G, then each fragment =0Ahas M+G bytes added to it, for a total o= f F * (M + G). If you reverse =0Athe layering, then only the first fragmen= t has the mesh header, and =0Aso you have a header cost of M + FG.=0A=0AFi= nally, it is (in my experience, others might differ on this) also =0Aeasie= r to manage the state and retransmission policies, as reassembly =0Adoes n= ot have to worry about greatly different latencies caused by =0Aroute chan= ges between fragments.=0A=0AThat being said, if X, F, and L are always goin= g to be small, then =0Athe exponents don't matter. But there's a fundament= al scalability =0Aproblem.=0A=0A> So a mesh forwarder is concerned with th= e forwarding header only; =0A> these therefore should come first.=0A> Only= at the L2 destination is it necessary to peek further into the =0A> heade= r, e.g. the fragmentation header for reassembly.=0A>=0A> Compare this with = IPv6: The forwarding header (here the IP header) =0A> is in front of the f= ragmentation header, which is a destination =0A> header (only "opened" at = the destination address set in the IP =0A> header).=0A>=0A=0ATwo mails ago= :=0A=0AI have one concern with the current draft: the ordering of the =0Af= ragmentation and mesh headers. In his presentation at IETF 67, =0AJonathan= noted that the order followed the model presented by =0Astandard IPv6. In= IPv6, fragmentation/reassembly must be end-to-end, =0Aso the ordering mak= es sense. However, this is sub-IP. I think that =0Amost of the real-world = experiments with 15.4 radios, as well as basic =0Aloss models, suggest tha= t per-hop fragmentation/reassembly is greatly =0Apreferable to e2e, partic= ularly for energy reasons. You don't need to =0Aadd a mesh header on each = fragment, you have fewer retransmissions, =0Aand less state maintenance. I= ncluding a mesh routing header is =0Aessentially to provide IP routing; fo= llowing the guidelines of RFC =0A2460 Section 5, I believe the order of th= ese two headers should be =0Areversed: a node fragments and reassembles a = mesh packet on a per-hop =0Abasis, rather than routing an IPv6 datagram on= e fragment at a time.=0A=0APhil=0A=0A______________________________________= _________=0A6lowpan mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org= /mailman/listinfo/6lowpan=0A=0A____________________________________________= ___=0A6lowpan mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailm= an/listinfo/6lowpan=0A=0A=0A=0A=0A --0-773962659-1168020981=:21803 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
On Comment 1: Reassembly: I don't think we should del= ay the draft because of this.
I think this is an interesting research to= pic. I notice that there are similarities with
the folks applying DTN to= sensor networks (projects at UCLA's LECS, SICS, Trinity College, etc).
= DTN is itself a research group in the IRTF, so similarly, I see such extens= ions to LoWPAN
as possible  alternatives once the basic draft in it= s current form is done. One possible
avenue is to reuse AODV to do the = discovery of the DTN-capable devices, and integrate with
the routing la= yer such that the proper tradeoffs (end-to-end, hop-by-hop or anything in t= he
middle) are possible. Such an approach was discussed recently at the = CHANTS workshop and
IRTF DTNRG:
paper:  http://doi.acm.org/10.1145/1162654.1162659
slide= s: http://www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf=
Such functionality should be worked on subsequent to the bas= e spec.

On Comment 2: are NALP values handled by IANA?
I think it= doesn't need to be. But someone should handle this assignment space
if = it is to serve its purpose of avoiding conflicts. So IANA *could* maintain = the
repository, but as a convenience only. This suggests that (from RFC2= 434)
"First Come First Served" is an appropriate policy.

I note = that there is one remaining item which fell through the cracks:
we need = to define the format of future dispatch headers. The length of the
dispa= tch headers defined in the base spec is known, so protocol parsing can
p= roceed. For future dispatch headers, we need to include a length field in
a well-known pl= ace in the header, otherwise proper parsing is not possible.
This needs = to be in the base spec.

Also, there are some remaining notes that sh= ould be deleted before progressing.

-gabriel

----- O= riginal Message ----
From: Schumacher Christian Peter Pii <schumacher= @danfoss.com>
To: 6lowpan <6lowpan@lists.ietf.org>
Cc: Carst= en Bormann <cabo@tzi.org>
Sent: Friday, January 5, 2007 1:05:46 AM=
Subject: RE: [6lowpan] WG last call on Format document

Dear= 6lowpanners
The deadline for the last call has passed.

There ha= ve been a few comments on the list:

Comment 1. Reassembly (Philip Le= vis and Carsten Bormann):
- Carsten assumes a mesh forwarder doesn't nee= d to reassemble.
- Philip believes a mesh forwarder must reassemble, as = that would be
more energy efficient.

Comment 2. IANA considerations (Philip= Levis):
- Is arbitration of the 00xxxxxx values under its  purview? (Regarding NALP)

To resolve comment 1: I urge the mailing= list to respond with your
opinions on this matter.
To resolve commen= t 2: I believe it is within the purview of IANA, but
can anyone confirm = this?

A final question, is there anyone who doesn't feel the format = document
is ready for IESG review?

Regards
Christian


-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanf= ord.edu]
Sent: 14. december 2006 17:47
To: Carsten Bormann
Cc: 6l= owpan
Subject: Re: [6lowpan] WG last call on Format document

On D= ec 14, 2006, at 12:58 AM, Carsten Bormann wrote:

>> I still ha= ve a concern about the ordering of the fragmentation and  
>= ;> mesh delivery headers. Can anyone offer a good argument on why  
>> fragmentation is within mesh and not vice vers= a?
>
> I think the general rule is that a node should only have= to parse  
> the subheaders that it is concerned with.
= >
> I'm assuming a mesh forwarder does not reassemble (I don't hap= pen  
> to know any good reason why it should).

Ener= gy. Imagine a theoretical route from N0 to NX of nodes N0, N1,  <= br>N2, ... NX. Let us suppose that each link (NZ,NZ+1) has a packet loss&nb= sp; 
rate of L. If you have no e2e fragment recovery, then an IPv6 = packet  
P composed of F fragments has a ((1-L)^X)^F probabili= ty of successful  
delivery. The probability of any fragment b= eing delivered  
successfully is (1-L)^X, and the probability = of all of them being  
delivered successfully is (1-L)^X^F. It= decreases exponentially with  
path length and packet size. W= ith no fragment recovery, you have to  
resend the entire packet whe= n this occurs. So the cost of a single  
fragment failure is F= X transmissions and the overall cost to deliver  
a packet suc= cessfully is approximately FX + FX * (1-L)^-XF.

With multihop reasse= mbly, a single fragment loss requires control  
traffic to req= uest the fragment, which itself also has a loss rate of  
(1-L= )^X, then the fragment being retransmitted. So the cost of a  single fragment failure is 2X transmissions, and the cost to deliver =  
a packet successfully is approximately FX + 2FX * (1-L)^-X.
With single-hop reassembly, each hop reassembles the packet as  = ;
needed. Because losses are locally recovered, you do not have the = ; 
exponential growth in packet loss. Unlike multihop recovery, whe= re  
the number of packets transmitted is going to approximate= ly be FX *  
((1-L)^X)^-1, (the expected number of transmissions per p= acket is the  
inverse of the loss rate), in single-hop recove= ry the equation is  
multiplicative: FX* (1-L)^-1. Each link s= ends only (1-L)^-1 copies of  
its each fragment, with retrans= missions caused by local failures. So  
the cost becomes FX + = 2FX * (1-L)^-1.

Recap:

F is number of fragments
X is lengt= h of route
L is loss rate on each hop

Multihop reassembly with fu= ll packet retransmission: FX + FX * (1-L)^-XF
Multihop reassembly with f= ragment retransmission: FX + 2FX * (1-L)^-X
Single-hop reassembly with f= ragment retransmission: FX + 2FX * (1-L)-1

Additionally, if you laye= r mesh on top of fragmentation, then every  
mesh packet has a= fragmentation header in it. If the mesh header  
length is M = and the fragment header length is G, then each fragment  
has = M+G bytes added to it, for a total of F * (M + G). If you reverse  
the= layering, then only the first fragment has the mesh header, and  = ;
so you have a header cost of M + FG.

Finally, it is (in my expe= rience, others might differ on this) also  
easier to manage t= he state and retransmission policies, as reassembly  
does not= have to worry about greatly different latencies caused by  
r= oute changes between fragments.

That being said, if X, F, and L are = always going to be small, then  
the exponents don't matter. B= ut there's a fundamental scalability  
problem.

> So= a mesh forwarder is concerned with the forwarding header only;  =
> these therefore should come first.
> Only at the L2 destinat= ion is it necessary to peek further into the  
> header, e.= g. the fragmentation header for reassembly.
>
> Compare this wi= th IPv6: The forwarding header (here the IP header)  
> is in front of = the fragmentation header, which is a destination  
> header= (only "opened" at the destination address set in the IP  
>= ; header).
>

Two mails ago:

I have one concern with the= current draft: the ordering of the  
fragmentation and mesh h= eaders. In his presentation at IETF 67,  
Jonathan noted that = the order followed the model presented by  
standard IPv6. In = IPv6, fragmentation/reassembly must be end-to-end,  
so the or= dering makes sense. However, this is sub-IP. I think that  
mo= st of the real-world experiments with 15.4 radios, as well as basic &n= bsp;
loss models, suggest that per-hop fragmentation/reassembly is great= ly  
preferable to e2e, particularly for energy reasons. You d= on't need to  
add a mesh header on each fragment, you have fe= wer retransmissions,  
and less state maintenance. Including a me= sh routing header is  
essentially to provide IP routing; foll= owing the guidelines of RFC  
2460 Section 5, I believe the or= der of these two headers should be  
reversed: a node fragment= s and reassembles a mesh packet on a per-hop  
basis, rather t= han routing an IPv6 datagram one fragment at a time.

Phil

___= ____________________________________________
6lowpan mailing list
6lo= wpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan<= br>

--0-773962659-1168020981=:21803-- --===============1729704189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1729704189==-- From 6lowpan-bounces@ietf.org Fri Jan 05 17:02:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2x8j-0003wn-Rm; Fri, 05 Jan 2007 17:02:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2x8j-0003uA-0V for 6lowpan@lists.ietf.org; Fri, 05 Jan 2007 17:02:17 -0500 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2x8h-0001T2-BT for 6lowpan@lists.ietf.org; Fri, 05 Jan 2007 17:02:16 -0500 Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l05M1wRV097593; Fri, 5 Jan 2007 16:02:10 -0600 (CST) (envelope-from salo@saloits.com) Message-ID: <459ECAA7.7030807@saloits.com> Date: Fri, 05 Jan 2007 16:01:11 -0600 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] WG last call on Format document References: <1166056349.5614.62.camel@localhost> <21F0CDBA-E61A-42AF-AB72-115A874226B8@cs.stanford.edu> In-Reply-To: <21F0CDBA-E61A-42AF-AB72-115A874226B8@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Philip Levis wrote: > On Dec 14, 2006, at 12:58 AM, Carsten Bormann wrote: > >>> I still have a concern about the ordering of the fragmentation and >>> mesh delivery headers. Can anyone offer a good argument on why >>> fragmentation is within mesh and not vice versa? >> >> I think the general rule is that a node should only have to parse the >> subheaders that it is concerned with. >> >> I'm assuming a mesh forwarder does not reassemble (I don't happen to >> know any good reason why it should). > > Energy. ... With no fragment recovery, you have to resend the > entire packet when this occurs. So the cost of a single fragment failure > is FX transmissions and the overall cost to deliver a packet > successfully is approximately FX + FX * (1-L)^-XF. > > With multihop reassembly, a single fragment loss requires control > traffic to request the fragment, which itself also has a loss rate of > (1-L)^X, then the fragment being retransmitted. ... > > With single-hop reassembly, each hop reassembles the packet as needed. > Because losses are locally recovered, you do not have the exponential > growth in packet loss. ... I believe that hop-by-hop reassembly is one potential solution, and perhaps not the best solution, to a more general problem. In heavily resource-constrained environments, it may be reasonable to expect that no data are ever retransmitted unnecessarily (at least as a result of the design of the protocol). That is, once a fragment is successfully received, it should never be transmitted again. Of course, actually achieving this objective in a nontrivial network is not particularly easy. It is not clear to me that hop-by-hop reassembly within the WLAN is necessarily a good idea for several reasons: o This may fail in the face of topology changes or node failures. In these cases, you would like some better way to recover than simply loosing the packet and letting the higher-layer protocols retransmit (or not). o Hop-by-hop reassembly requires buffering, which will probably be at a premium in this environment. There are at least several possible approaches: - Each node could have enough memory that it never runs out of buffers. Clearly, this isn't much of a solution. - A hop-by-hop buffer reservation protocol could be created that would prevent reassembly lockup. While I think this would work well, it requires some thought and perhaps even modeling. - A node could simply discard fragments if it runs out of buffers, but then we are back to discarding data that were correctly received and perhaps retransmitting something from somewhere. I suspect that hop-by-hop retransmission may be much preferable to hop-by-hop reassembly. I forget what the format document says about this... And, yes, hop-by-hop retransmissions _can_ result in poor interactions with TCP congestion control algorithms. However, I am not convinced that this is necessarily an issue in this case because: o The retransmission timeout on the WLAN should be, or should be made, very small compared to the end-to-end round-trip-time and retransmission timeout. o In actual practice, the granularity of TCP's retransmission timer is pretty large. I don't have time to look it up, but isn't it 500 ms on BSD systems? Our timescales should be so much smaller than that, that we ought to be able to make lots of attempts to get a packet through the WLAN before TCP decides to retransmit. Hop-by-hop retransmission still has the problem that if the route changes or a node fails, the packet will be lost. How should we recover from this? I think that a reasonable approach is to probably do hop-by-hop retransmissions and when that fails, retransmit (either the packet or select fragments) from the IP/WSN gateway. This, of course, raises a number of, largely non-technical, issues. Perhaps, the most significant one is that we don't appear to have the resources in this Working Group to tackle this issue. Now, a few more general thoughts. To me, this discussion is the sort of thing that should have occurred in an architecture specification. I think that there are a number of these issues that we may discuss piecemeal (or, perhaps at all). I don't believe that discussing architectural issues piecemeal as they come up is a reliable way to create a strong architecture. I believe that we would have a stronger technical solution if we thought more carefully about what functionality should be implemented in the gateway between the wireless sensor network (WSN) and the IP network to which it is attached. Above, I essentially suggested that this gateway should include a particular type of performance-enhancing proxy (PEP). I believe that there are actually a number of these PEPs that we ought to consider for implementation in the WSN/IP gateway. As an example of the range of things we might consider, I have suggested privately that the WSN/IP gateway should (maybe) translate pretty much all IPv6 addresses to 16-bit addresses. (By the way, I think that our focus on running IPv6 over IEEE 802.15.4 networks, rather than interconnecting IEEE 802.15.4 networks with IPv4 and IPv6 networks has tended to narrow the range of technical solutions that we consider.) Having said all that, that leaves the question of what we should do about all this. It seems pretty clear to me that we simply don't have the resources within the Working Group to do much. If this observation is correct, then it might be reasonable to conclude that we should focus on pushing _something_ out the door and hope that wireless sensor networks will generate more interest within the IETF at some point in the future. (For what it is worth, I am trying to find resources that would permit me to spend a lot more time on this, but the outcome is uncertain. And, while I would like to think that I could make a real difference to the Working Group if I spend more time on this, there is no reason to believe that this notion is universally accepted...) -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jan 06 16:17:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Iua-0002gC-UE; Sat, 06 Jan 2007 16:17:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IuZ-0002g6-K4 for 6lowpan@ietf.org; Sat, 06 Jan 2007 16:17:07 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3IuY-00005x-6N for 6lowpan@ietf.org; Sat, 06 Jan 2007 16:17:07 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1H3IuV-00088S-SZ; Sat, 06 Jan 2007 13:17:05 -0800 In-Reply-To: <20070105181621.24097.qmail@web81915.mail.mud.yahoo.com> References: <20070105181621.24097.qmail@web81915.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <214C5229-9A8C-443D-A344-1FEFDAB8541A@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] WG last call on Format document Date: Sat, 6 Jan 2007 13:17:11 -0800 To: gabriel montenegro X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Jan 5, 2007, at 10:16 AM, gabriel montenegro wrote: > On Comment 1: Reassembly: I don't think we should delay the draft > because of this. > I think this is an interesting research topic. I notice that there > are similarities with > the folks applying DTN to sensor networks (projects at UCLA's LECS, > SICS, Trinity College, etc). > DTN is itself a research group in the IRTF, so similarly, I see > such extensions to LoWPAN > as possible alternatives once the basic draft in its current form > is done. One possible > avenue is to reuse AODV to do the discovery of the DTN-capable > devices, and integrate with > the routing layer such that the proper tradeoffs (end-to-end, hop- > by-hop or anything in the > middle) are possible. Such an approach was discussed recently at > the CHANTS workshop and > IRTF DTNRG: > paper: http://doi.acm.org/10.1145/1162654.1162659 > slides: http://www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf > Such functionality should be worked on subsequent to the base spec. > My point isn't take the document should specify single-hop reassembly. It's that, as written, it precludes single-hop reassembly. If the spec were, for example, to say that the two headers could be in either order, then there would be no problem. My concern is that the document -- without any technical justification for the decision -- is digging itself into a hole where producing efficient (in terms of energy, RAM, and code space) implementations will be difficult. It might be that a new mesh2 header emerges that reverses the order, with the cost of a few extra bits in each packet. That being said, there is the point to be made that large packets in 6lowpan are expected to be very rare and mostly present for complete interoperability than for core use cases. So this might in the end be entirely irrelevant. Given the lateness in the process and lack of forward progress, having something is better than nothing. So I'll shelve my concern and am happy to agree on the document. > > I note that there is one remaining item which fell through the cracks: > we need to define the format of future dispatch headers. The length > of the > dispatch headers defined in the base spec is known, so protocol > parsing can > proceed. For future dispatch headers, we need to include a length > field in > a well-known place in the header, otherwise proper parsing is not > possible. > This needs to be in the base spec. I had thought that the discussion went down the road of "if you don't know the header type, drop the packet," keeping packet processing simple. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jan 07 05:54:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Vew-0000sg-Lk; Sun, 07 Jan 2007 05:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Vev-0000sa-Jl for 6lowpan@ietf.org; Sun, 07 Jan 2007 05:53:49 -0500 Received: from maily.danfoss.com ([193.162.34.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Vet-000750-W3 for 6lowpan@ietf.org; Sun, 07 Jan 2007 05:53:49 -0500 Received: from DKDN04MX64.dkdn04.danfoss.net ([10.6.2.64]) by maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 11:53:44 +0100 Received: from dkdn01mx22.danfoss.net ([10.12.129.22]) by DKDN04MX64.dkdn04.danfoss.net with InterScan Message Security Suite; Sun, 07 Jan 2007 11:53:44 +0100 Received: from DKDN01MX34.danfoss.net ([10.12.128.16]) by dkdn01mx22.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 11:53:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: SV: [6lowpan] WG last call on Format document Date: Sun, 7 Jan 2007 11:52:15 +0100 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7139395@DKDN01MX34.danfoss.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WG last call on Format document thread-index: Accx3H2qPcc9eQY0TL2bTnIaJlv7oQAbWcI5 References: <20070105181621.24097.qmail@web81915.mail.mud.yahoo.com> <214C5229-9A8C-443D-A344-1FEFDAB8541A@cs.stanford.edu> From: "Schumacher Christian Peter Pii" To: "Philip Levis" , "gabriel montenegro" , , "Geoff Mulligan" X-OriginalArrivalTime: 07 Jan 2007 10:53:43.0753 (UTC) FILETIME=[19583B90:01C7324A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0646384610==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0646384610== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7324A.193595EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7324A.193595EB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the feedback, I believe the chairs can submit the documents for = IESG review. Regards Christian -----Oprindelig meddelelse----- Fra: Philip Levis [mailto:pal@cs.stanford.edu] Sendt: l=F8 1/6/2007 10:17 Til: gabriel montenegro Cc: Schumacher Christian Peter Pii; 6lowpan@ietf.org Emne: Re: [6lowpan] WG last call on Format document =20 On Jan 5, 2007, at 10:16 AM, gabriel montenegro wrote: > On Comment 1: Reassembly: I don't think we should delay the draft =20 > because of this. > I think this is an interesting research topic. I notice that there =20 > are similarities with > the folks applying DTN to sensor networks (projects at UCLA's LECS, =20 > SICS, Trinity College, etc). > DTN is itself a research group in the IRTF, so similarly, I see =20 > such extensions to LoWPAN > as possible alternatives once the basic draft in its current form =20 > is done. One possible > avenue is to reuse AODV to do the discovery of the DTN-capable =20 > devices, and integrate with > the routing layer such that the proper tradeoffs (end-to-end, hop-=20 > by-hop or anything in the > middle) are possible. Such an approach was discussed recently at =20 > the CHANTS workshop and > IRTF DTNRG: > paper: http://doi.acm.org/10.1145/1162654.1162659 > slides: http://www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf > Such functionality should be worked on subsequent to the base spec. > My point isn't take the document should specify single-hop =20 reassembly. It's that, as written, it precludes single-hop =20 reassembly. If the spec were, for example, to say that the two =20 headers could be in either order, then there would be no problem. My =20 concern is that the document -- without any technical justification =20 for the decision -- is digging itself into a hole where producing =20 efficient (in terms of energy, RAM, and code space) implementations =20 will be difficult. It might be that a new mesh2 header emerges that =20 reverses the order, with the cost of a few extra bits in each packet. That being said, there is the point to be made that large packets in =20 6lowpan are expected to be very rare and mostly present for complete =20 interoperability than for core use cases. So this might in the end be =20 entirely irrelevant. Given the lateness in the process and lack of =20 forward progress, having something is better than nothing. So I'll =20 shelve my concern and am happy to agree on the document. > > I note that there is one remaining item which fell through the cracks: > we need to define the format of future dispatch headers. The length =20 > of the > dispatch headers defined in the base spec is known, so protocol =20 > parsing can > proceed. For future dispatch headers, we need to include a length =20 > field in > a well-known place in the header, otherwise proper parsing is not =20 > possible. > This needs to be in the base spec. I had thought that the discussion went down the road of "if you don't =20 know the header type, drop the packet," keeping packet processing =20 simple. Phil ------_=_NextPart_001_01C7324A.193595EB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SV: [6lowpan] WG last call on Format document

Given the feedback, I believe the chairs can submit = the documents for IESG review.

Regards
Christian


-----Oprindelig meddelelse-----
Fra: Philip Levis [mailto:pal@cs.stanford.edu]
Sendt: l=F8 1/6/2007 10:17
Til: gabriel montenegro
Cc: Schumacher Christian Peter Pii; 6lowpan@ietf.org
Emne: Re: [6lowpan] WG last call on Format document

On Jan 5, 2007, at 10:16 AM, gabriel montenegro wrote:

> On Comment 1: Reassembly: I don't think we should delay the = draft 
> because of this.
> I think this is an interesting research topic. I notice that = there 
> are similarities with
> the folks applying DTN to sensor networks (projects at UCLA's = LECS, 
> SICS, Trinity College, etc).
> DTN is itself a research group in the IRTF, so similarly, I = see 
> such extensions to LoWPAN
> as possible  alternatives once the basic draft in its current = form 
> is done. One possible
> avenue is to reuse AODV to do the discovery of the = DTN-capable 
> devices, and integrate with
> the routing layer such that the proper tradeoffs (end-to-end, = hop-
> by-hop or anything in the
> middle) are possible. Such an approach was discussed recently = at 
> the CHANTS workshop and
> IRTF DTNRG:
> paper:  http://doi.acm.org/10= .1145/1162654.1162659
> slides: http:= //www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf
> Such functionality should be worked on subsequent to the base = spec.
>

My point isn't take the document should specify single-hop 
reassembly. It's that, as written, it precludes single-hop 
reassembly. If the spec were, for example, to say that the two 
headers could be in either order, then there would be no problem. = My 
concern is that the document -- without any technical = justification 
for the decision -- is digging itself into a hole where = producing 
efficient (in terms of energy, RAM, and code space) = implementations 
will be difficult. It might be that a new mesh2 header emerges = that 
reverses the order, with the cost of a few extra bits in each = packet.

That being said, there is the point to be made that large packets = in 
6lowpan are expected to be very rare and mostly present for = complete 
interoperability than for core use cases. So this might in the end = be 
entirely irrelevant. Given the lateness in the process and lack = of 
forward progress, having something is better than nothing. So = I'll 
shelve my concern and am happy to agree on the document.

>
> I note that there is one remaining item which fell through the = cracks:
> we need to define the format of future dispatch headers. The = length 
> of the
> dispatch headers defined in the base spec is known, so = protocol 
> parsing can
> proceed. For future dispatch headers, we need to include a = length 
> field in
> a well-known place in the header, otherwise proper parsing is = not 
> possible.
> This needs to be in the base spec.

I had thought that the discussion went down the road of "if you = don't 
know the header type, drop the packet," keeping packet = processing 
simple.

Phil

------_=_NextPart_001_01C7324A.193595EB-- --===============0646384610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0646384610==-- From 6lowpan-bounces@ietf.org Sun Jan 07 13:31:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3cno-0007AO-GQ; Sun, 07 Jan 2007 13:31:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3cnm-0007AH-Mr for 6lowpan@ietf.org; Sun, 07 Jan 2007 13:31:26 -0500 Received: from web81901.mail.mud.yahoo.com ([68.142.207.180]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3cnl-0000g5-3c for 6lowpan@ietf.org; Sun, 07 Jan 2007 13:31:26 -0500 Received: (qmail 53564 invoked by uid 60001); 7 Jan 2007 18:31:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=uMXbAodNfK0yqOORSch2y+8+623Z6LJkb/uWnNWUUeSM+iFIiBVuayH7D3BnlYjlsD0kjCEvBDjBrraDLvd4j4K0KvPvJkokFld7ULGi3D9AeCyEF3HR81LYDJS7jQPzZ3pF3QgoGKHdpMH5zz/L8jEeMO7RkfEHjOYR8jhjj5o= ; Message-ID: <20070107183109.53562.qmail@web81901.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81901.mail.mud.yahoo.com via HTTP; Sun, 07 Jan 2007 10:31:09 PST Date: Sun, 7 Jan 2007 10:31:09 -0800 (PST) From: gabriel montenegro Subject: Re: SV: [6lowpan] WG last call on Format document To: Schumacher Christian Peter Pii , Philip Levis , cabo@tzi.org, Geoff Mulligan MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0370795652==" Errors-To: 6lowpan-bounces@ietf.org --===============0370795652== Content-Type: multipart/alternative; boundary="0-487160399-1168194669=:49094" --0-487160399-1168194669=:49094 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sounds good. =0A=0ABy the way, Phil, I thought you meant changing the fragm= entation/reassembly=0Aalgorithm outright, it was not clear to me that you j= ust wished to relax the order=0Aof the headers. =0A=0AI'd suggest capturing= Phil's issue in the writeup used by the=0Achairs to advance the document a= s per:=0A=0A http://www.ietf.org/IESG/content/Doc-Writeup.html=0A=0AThat = way we can invite discussion from the IESG on this item.=0A=0AThis concern = (and perhaps the one related to extension dispatch headers as well)=0Acould= be mentioned in 1.d or in 1.k ("working group summary") in the Doc-Writeup= .=0A=0A-gabriel=0A=0A----- Original Message ----=0AFrom: Schumacher Christi= an Peter Pii =0ATo: Philip Levis ; gabriel montenegro ; cabo@tzi.org; = Geoff Mulligan =0ACc: 6lowpan@ietf.org=0ASent: Sunday, = January 7, 2007 2:52:15 AM=0ASubject: SV: [6lowpan] WG last call on Format = document=0A=0ASV: [6lowpan] WG last call on Format document=0A=0A=0A =0A = =0A=0A=0A=0A=0AGiven the feedback, I believe the chairs can submit the docu= ments for IESG review.=0A=0A=0A=0ARegards=0A=0AChristian=0A=0A=0A=0A=0A=0A-= ----Oprindelig meddelelse-----=0A=0AFra: Philip Levis [mailto:pal@cs.stanfo= rd.edu]=0A=0ASendt: l=F8 1/6/2007 10:17=0A=0ATil: gabriel montenegro=0A=0AC= c: Schumacher Christian Peter Pii; 6lowpan@ietf.org=0A=0AEmne: Re: [6lowpan= ] WG last call on Format document=0A=0A=0A=0AOn Jan 5, 2007, at 10:16 AM, g= abriel montenegro wrote:=0A=0A=0A=0A> On Comment 1: Reassembly: I don't thi= nk we should delay the draft =0A=0A> because of this.=0A=0A> I think this i= s an interesting research topic. I notice that there =0A=0A> are similariti= es with=0A=0A> the folks applying DTN to sensor networks (projects at UCLA'= s LECS, =0A=0A> SICS, Trinity College, etc).=0A=0A> DTN is itself a researc= h group in the IRTF, so similarly, I see =0A=0A> such extensions to LoWPAN= =0A=0A> as possible alternatives once the basic draft in its current form = =0A=0A> is done. One possible=0A=0A> avenue is to reuse AODV to do the disc= overy of the DTN-capable =0A=0A> devices, and integrate with=0A=0A> the rou= ting layer such that the proper tradeoffs (end-to-end, hop-=0A=0A> by-hop o= r anything in the=0A=0A> middle) are possible. Such an approach was discuss= ed recently at =0A=0A> the CHANTS workshop and=0A=0A> IRTF DTNRG:=0A=0A> pa= per: http://doi.acm.org/10.1145/1162654.1162659=0A=0A> slides: http://www3= .ietf.org/proceedings/06nov/slides/DTNRG-11.pdf=0A=0A> Such functionality s= hould be worked on subsequent to the base spec.=0A=0A>=0A=0A=0A=0AMy point = isn't take the document should specify single-hop =0A=0Areassembly. It's th= at, as written, it precludes single-hop =0A=0Areassembly. If the spec were,= for example, to say that the two =0A=0Aheaders could be in either order, t= hen there would be no problem. My =0A=0Aconcern is that the document -- wit= hout any technical justification =0A=0Afor the decision -- is digging itsel= f into a hole where producing =0A=0Aefficient (in terms of energy, RAM, and= code space) implementations =0A=0Awill be difficult. It might be that a ne= w mesh2 header emerges that =0A=0Areverses the order, with the cost of a fe= w extra bits in each packet.=0A=0A=0A=0AThat being said, there is the point= to be made that large packets in =0A=0A6lowpan are expected to be very rar= e and mostly present for complete =0A=0Ainteroperability than for core use = cases. So this might in the end be =0A=0Aentirely irrelevant. Given the lat= eness in the process and lack of =0A=0Aforward progress, having something i= s better than nothing. So I'll =0A=0Ashelve my concern and am happy to agre= e on the document.=0A=0A=0A=0A>=0A=0A> I note that there is one remaining i= tem which fell through the cracks:=0A=0A> we need to define the format of f= uture dispatch headers. The length =0A=0A> of the=0A=0A> dispatch headers d= efined in the base spec is known, so protocol =0A=0A> parsing can=0A=0A> pr= oceed. For future dispatch headers, we need to include a length =0A=0A> fie= ld in=0A=0A> a well-known place in the header, otherwise proper parsing is = not =0A=0A> possible.=0A=0A> This needs to be in the base spec.=0A=0A=0A=0A= I had thought that the discussion went down the road of "if you don't =0A= =0Aknow the header type, drop the packet," keeping packet processing =0A=0A= simple.=0A=0A=0A=0APhil=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A --0-487160399-1168194669=:49094 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Sounds good.

By the way, Phil, I thought you = meant changing the fragmentation/reassembly
algorithm outright, it was n= ot clear to me that you just wished to relax the order
of the headers. <= br>
I'd suggest capturing Phil's issue in the writeup used by the
cha= irs to advance the document as per:

   http://www.ietf.org/IESG/content/Doc-Writeup.html

That = way we can invite discussion from the IESG on this item.

This concer= n (and perhaps the one related to extension dispatch headers as well)
co= uld be mentioned in 1.d or in 1.k ("working group summary") in the Doc-Writeup.

-gabriel

----- Original Message = ----
From: Schumacher Christian Peter Pii <schumacher@danfoss.com>=
To: Philip Levis <pal@cs.stanford.edu>; gabriel montenegro <ga= briel_montenegro_2000@yahoo.com>; cabo@tzi.org; Geoff Mulligan <geoff= @mulligan.com>
Cc: 6lowpan@ietf.org
Sent: Sunday, January 7, 2007 = 2:52:15 AM
Subject: SV: [6lowpan] WG last call on Format document
SV: [6lowpan] WG last call on Format document=0A=0A=0A =0A = =0A=0A=0A=0A=0A

Given the feedback, I believe the chairs= can submit the documents for IESG review.
=0A
=0ARegards
=0AChris= tian
=0A
=0A
=0A-----Oprindelig meddelelse-----
=0AFra: Philip = Levis [mailto:pal@cs.stanford.edu]
=0ASendt: l=F8 1/6/2007 10:17
= =0ATil: gabriel montenegro
=0ACc: Schumacher Christian Peter Pii; 6lowpa= n@ietf.org
=0AEmne: Re: [6lowpan] WG last call on Format document
=0A=
=0AOn Jan 5, 2007, at 10:16 AM, gabriel montenegro wrote:
=0A
=0A= > On Comment 1: Reassembly: I don't think we should delay the draft = ;
=0A> because of this.
=0A> I think this is an interesting res= earch topic. I notice that there 
=0A> are similarities with
= =0A> the folks applying DTN to sensor networks (projects at UCLA's LECS,=  
=0A> SICS, Trinity College, etc).
=0A> DTN is itself a r= esearch group in the IRTF, so similarly, I see 
=0A> such extens= ions to LoWPAN
=0A> as possible  alternatives once the basic dra= ft in its current form 
=0A> is done. One possible
=0A> av= enue is to reuse AODV to do the discovery of the DTN-capable 
=0A&g= t; devices, and integrate with
=0A> the routing layer such that the p= roper tradeoffs (end-to-end, hop-
=0A> by-hop or anything in the
= =0A> middle) are possible. Such an approach was discussed recently at&nb= sp;
=0A> the CHANTS workshop and
=0A> IRTF DTNRG:
=0A> pa= per:  http://doi.acm.org/10.1145/1162654.1162659=0A> slides: http://www3.ietf.org/procee= dings/06nov/slides/DTNRG-11.pdf
=0A> Such functionality should be= worked on subsequent to the base spec.
=0A>
=0A
=0AMy point is= n't take the document should specify single-hop 
=0Areassembly. It'= s that, as written, it precludes single-hop 
=0Areassembly. If the = spec were, for example, to say that the two 
=0Aheaders could be in= either order, then there would be no problem. My 
=0Aconcern is th= at the document -- without any technical justification 
=0Afor the = decision -- is digging itself into a hole where producing 
=0Aeffic= ient (in terms of energy, RAM, and code space) implementations 
=0A= will be difficult. It might be that a new mesh2 header emerges that =0Areverses the order, with the cost of a few extra bits in each packet.<= br>=0A
=0AThat being said, there is the point to be made that large pack= ets in 
=0A6lowpan are expected to be very rare and mostly present = for complete 
=0Ainteroperability than for core use cases. So this = might in the end be 
=0Aentirely irrelevant. Given the lateness in = the process and lack of 
=0Aforward progress, having something is b= etter than nothing. So I'll 
=0Ashelve my concern and am happy to a= gree on the document.
=0A
=0A>
=0A> I note that there is one= remaining item which fell through the cracks:
=0A> we need to define= the format of future dispatch headers. The length 
=0A> of the<= br>=0A> dispatch headers defined in the base spec is known, so protocol&= nbsp;
=0A> parsing can
=0A> proceed. For future dispatch header= s, we need to include a length 
=0A> field in
=0A> a well-= known place in the header, otherwise proper parsing is not 
=0A>= possible.
=0A> This needs to be in the base spec.
=0A
=0AI had= thought that the discussion went down the road of "if you don't 
= =0Aknow the header type, drop the packet," keeping packet processing <= br>=0Asimple.
=0A
=0APhil
=0A
=0A=0A

=0A=0A

=
--0-487160399-1168194669=:49094-- --===============0370795652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0370795652==-- From 6lowpan-bounces@ietf.org Sun Jan 07 15:14:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ePV-0004tL-Ds; Sun, 07 Jan 2007 15:14:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ePU-0004tG-9O for 6lowpan@ietf.org; Sun, 07 Jan 2007 15:14:28 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3ePS-00083L-NW for 6lowpan@ietf.org; Sun, 07 Jan 2007 15:14:28 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id l07K99oB006460; Sun, 7 Jan 2007 21:09:09 +0100 (CET) In-Reply-To: <20070107183109.53562.qmail@web81901.mail.mud.yahoo.com> References: <20070107183109.53562.qmail@web81901.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <343C8613-7D5A-47F3-B076-E0164CBC8EF2@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: SV: [6lowpan] WG last call on Format document Date: Sun, 7 Jan 2007 21:09:08 +0100 To: gabriel montenegro X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Carsten Bormann , 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > I'd suggest capturing Phil's issue in the writeup used by the > chairs to advance the document as per: > > http://www.ietf.org/IESG/content/Doc-Writeup.html > > That way we can invite discussion from the IESG on this item. While it is always a good thing to obtain input from the IESG, I don't think delegating this issue to the IESG during document submission is the right approach here. The WG is the domain expert on the kind of network we are discussing here. The WG should come to a conclusion. The IESG can then check that we followed process and that the document fits into the wider IETF picture (which is *not* dominated by the relevant considerations here). On the reassembly issue, I see two approaches: 1) keep with the reassembly at destination 2) open up the sequence such that reassembly-before-forwarding becomes an alternative, chosen by the sender. 3) only allow reassembly before forwarding, i.e. forward only full datagrams. (As far as I can see, nobody argues for 3, that's why I see *two* approaches.) The advantage of 2 is more options (Philip has explained why this can be a good thing). The obvious disadvantage of 2 is more options (i.e., increased burden on an implementation). With 2, the sender gets to decide whether a forwarder has to reassemble before forwarding; the forwarder has to play with that decision. (Reassembly at the forwarder also means different fragments cannot choose different paths; maybe a more theoretical consideration.) I'd like to hear more people taking sides on 1 or 2 before we declare consensus. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jan 08 12:30:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3yK1-0007CN-OW; Mon, 08 Jan 2007 12:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3yK0-0007CF-D4 for 6lowpan@ietf.org; Mon, 08 Jan 2007 12:30:08 -0500 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3yJy-0007qi-0C for 6lowpan@ietf.org; Mon, 08 Jan 2007 12:30:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SV: [6lowpan] WG last call on Format document Date: Mon, 8 Jan 2007 09:29:58 -0800 Message-ID: <3D8BC6C339A9894C9955EF58D3722D6577AA44@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SV: [6lowpan] WG last call on Format document Thread-Index: AccymKg6ixvVuf7BT/erEM89sBqQNgAqjphd From: "Kris Pister" To: <6lowpan@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org >> (Reassembly at the forwarder also means different fragments cannot=20 >> choose different paths; maybe a more theoretical consideration.) =20 This is absolutely not a theoretical consideration. We call these = networks and headers "mesh" for a reason: there's an intuitive sense = that multiple routes provide better performance. This intuition is now = supported by substantial empirical evidence (in addition to theory and = simulation): implementations that say "mesh" and deliver quasi-static = trees are not reliable. Zigbee did a disservice to the community by = defining "mesh" to be "multi-hop" in the 2003 standard. =20 Phil makes a good case for single-hop reassembly in his 12/14 treatise, = and his arguments are valid from a tinyOS and/or Zigbee perspective. F, = X, and L will be large, and if link-level acknowledgements are not used, = then the energy cost of multi-hop reassembly will be prohibitive. = Indeed, the probability of success decreases so rapidly with increasing = F and X that the question "does it work at all?" takes precedence over = "is it energy efficient?". =20 There are two international sensor networking standards in the works = right now (HART and SP100) which will both include mesh routing and = link-level acknowledgements. Both will support energy-efficient = fragmentation and end-to-end reassembly with large F, X, and L. Both = are based on existing products built on top of 802.15.4. =20 I think that option 2 below is probably still fine. Giving people this = level of flexibility is still useful as we explore this comparatively = young space, but let's do it informed by the pre-existing solutions to = similar problems. =20 ksjp Prof. EECS, UC Berkeley Founder and CTO, Dust Networks ________________________________ From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Sun 1/7/2007 12:09 PM To: gabriel montenegro Cc: Carsten Bormann; 6lowpan@ietf.org Subject: Re: SV: [6lowpan] WG last call on Format document > I'd suggest capturing Phil's issue in the writeup used by the > chairs to advance the document as per: > > http://www.ietf.org/IESG/content/Doc-Writeup.html > > That way we can invite discussion from the IESG on this item. While it is always a good thing to obtain input from the IESG, I=20 don't think delegating this issue to the IESG during document=20 submission is the right approach here. The WG is the domain expert on the kind of network we are discussing=20 here. The WG should come to a conclusion. The IESG can then check that we followed process and that the=20 document fits into the wider IETF picture (which is *not* dominated=20 by the relevant considerations here). On the reassembly issue, I see two approaches: 1) keep with the reassembly at destination 2) open up the sequence such that reassembly-before-forwarding=20 becomes an alternative, chosen by the sender. 3) only allow reassembly before forwarding, i.e. forward only full=20 datagrams. (As far as I can see, nobody argues for 3, that's why I see *two*=20 approaches.) The advantage of 2 is more options (Philip has explained why this=20 can be a good thing). The obvious disadvantage of 2 is more options (i.e., increased=20 burden on an implementation). With 2, the sender gets to decide whether a forwarder has to=20 reassemble before forwarding; the forwarder has to play with that=20 decision. (Reassembly at the forwarder also means different fragments cannot=20 choose different paths; maybe a more theoretical consideration.) I'd like to hear more people taking sides on 1 or 2 before we declare=20 consensus. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jan 08 13:18:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3z4o-0002ul-PZ; Mon, 08 Jan 2007 13:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3z4n-0002ug-Ih for 6lowpan@ietf.org; Mon, 08 Jan 2007 13:18:29 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3z4a-0007E5-BB for 6lowpan@ietf.org; Mon, 08 Jan 2007 13:18:29 -0500 Received: from dnab42236a.stanford.edu ([171.66.35.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1H3z4U-00018s-Jl; Mon, 08 Jan 2007 10:18:13 -0800 In-Reply-To: <3D8BC6C339A9894C9955EF58D3722D6577AA44@dust-exch-02.dusthq.dust-inc.com> References: <3D8BC6C339A9894C9955EF58D3722D6577AA44@dust-exch-02.dusthq.dust-inc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21F796B8-0EDD-450F-B350-CB4AF0674E56@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: SV: [6lowpan] WG last call on Format document Date: Mon, 8 Jan 2007 10:18:19 -0800 To: "Kris Pister" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 1423d2bdf1536ba32d3e1b7a7c800682 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Jan 8, 2007, at 9:29 AM, Kris Pister wrote: >>> (Reassembly at the forwarder also means different fragments cannot >>> choose different paths; maybe a more theoretical consideration.) > > This is absolutely not a theoretical consideration. We call these > networks and headers "mesh" for a reason: there's an intuitive > sense that multiple routes provide better performance. This > intuition is now supported by substantial empirical evidence (in > addition to theory and simulation): implementations that say "mesh" > and deliver quasi-static trees are not reliable. Zigbee did a > disservice to the community by defining "mesh" to be "multi-hop" in > the 2003 standard. Right -- the big question is the rate at which the routes can adapt. Multiple routes do not in and of themselves necessarily provide better robustness; unlike in the wired case, nodes are physically correlated and so can fail together. I'm personally not convinced that one of fine-grained packet next-hop diversity or rapid route failover is inherently superior to the other. I'd argue that the lack of reliability we've seen in quasi-static trees has been due to a mismatch between route adaptation and data traffic, with no backpressure. That is, if your route changes at most every 8 seconds, you can buffer 10 packets, the sender drops on layer 2 acknowledgment, and there is no way to slow down your reception rate of 5 packets per second, then a route failure will lead to packet loss. If you look at the current layer in TinyOS 2.0, for example, it delivers two nines, with the packet losses being due to false positives on layer 2 acks. I know that this is well below what Dust can deliver, but to be fair, it uses an ad-hoc rather than centralized approach and has been written by a few grad students spread across the country rather than an experienced development team. > Phil makes a good case for single-hop reassembly in his 12/14 > treatise, and his arguments are valid from a tinyOS and/or Zigbee > perspective. F, X, and L will be large, and if link-level > acknowledgements are not used, then the energy cost of multi-hop > reassembly will be prohibitive. Indeed, the probability of success > decreases so rapidly with increasing F and X that the question > "does it work at all?" takes precedence over "is it energy > efficient?". > > There are two international sensor networking standards in the > works right now (HART and SP100) which will both include mesh > routing and link-level acknowledgements. Both will support energy- > efficient fragmentation and end-to-end reassembly with large F, X, > and L. Both are based on existing products built on top of 802.15.4. > > I think that option 2 below is probably still fine. Giving people > this level of flexibility is still useful as we explore this > comparatively young space, but let's do it informed by the pre- > existing solutions to similar problems. > Does saying headers can appear in either order break from IPv6? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jan 08 14:09:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zsO-0001YK-HF; Mon, 08 Jan 2007 14:09:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zsN-0001TG-4P for 6lowpan@ietf.org; Mon, 08 Jan 2007 14:09:43 -0500 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zsL-000180-Cl for 6lowpan@ietf.org; Mon, 08 Jan 2007 14:09:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SV: [6lowpan] WG last call on Format document Date: Mon, 8 Jan 2007 11:05:57 -0800 Message-ID: <3D8BC6C339A9894C9955EF58D3722D6577AA4D@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SV: [6lowpan] WG last call on Format document Thread-Index: AcczUVzgTfX936xiReqyb4wfjMV4RQABqoZA From: "Kris Pister" To: <6lowpan@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I agree with you that rapid route fail-over is a perfectly viable = alternative (and probably provably superior in many cases) to next-hop = diversity. But whichever you use, it makes single-hop reassembly of = packets difficult. =20 That's great news about tinyOS 2 reliability. =20 ksjp ________________________________ From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Mon 1/8/2007 10:18 AM To: Kris Pister Cc: 6lowpan@ietf.org Subject: Re: SV: [6lowpan] WG last call on Format document On Jan 8, 2007, at 9:29 AM, Kris Pister wrote: >>> (Reassembly at the forwarder also means different fragments cannot >>> choose different paths; maybe a more theoretical consideration.) > > This is absolutely not a theoretical consideration. We call these=20 > networks and headers "mesh" for a reason: there's an intuitive=20 > sense that multiple routes provide better performance. This=20 > intuition is now supported by substantial empirical evidence (in=20 > addition to theory and simulation): implementations that say "mesh"=20 > and deliver quasi-static trees are not reliable. Zigbee did a=20 > disservice to the community by defining "mesh" to be "multi-hop" in=20 > the 2003 standard. Right -- the big question is the rate at which the routes can adapt.=20 Multiple routes do not in and of themselves necessarily provide=20 better robustness; unlike in the wired case, nodes are physically=20 correlated and so can fail together. I'm personally not convinced=20 that one of fine-grained packet next-hop diversity or rapid route=20 failover is inherently superior to the other. I'd argue that the lack of reliability we've seen in quasi-static=20 trees has been due to a mismatch between route adaptation and data=20 traffic, with no backpressure. That is, if your route changes at most=20 every 8 seconds, you can buffer 10 packets, the sender drops on layer=20 2 acknowledgment, and there is no way to slow down your reception=20 rate of 5 packets per second, then a route failure will lead to=20 packet loss. If you look at the current layer in TinyOS 2.0, for=20 example, it delivers two nines, with the packet losses being due to=20 false positives on layer 2 acks. I know that this is well below what=20 Dust can deliver, but to be fair, it uses an ad-hoc rather than=20 centralized approach and has been written by a few grad students=20 spread across the country rather than an experienced development team. > Phil makes a good case for single-hop reassembly in his 12/14=20 > treatise, and his arguments are valid from a tinyOS and/or Zigbee=20 > perspective. F, X, and L will be large, and if link-level=20 > acknowledgements are not used, then the energy cost of multi-hop=20 > reassembly will be prohibitive. Indeed, the probability of success=20 > decreases so rapidly with increasing F and X that the question=20 > "does it work at all?" takes precedence over "is it energy=20 > efficient?". > > There are two international sensor networking standards in the=20 > works right now (HART and SP100) which will both include mesh=20 > routing and link-level acknowledgements. Both will support energy- > efficient fragmentation and end-to-end reassembly with large F, X,=20 > and L. Both are based on existing products built on top of 802.15.4. > > I think that option 2 below is probably still fine. Giving people=20 > this level of flexibility is still useful as we explore this=20 > comparatively young space, but let's do it informed by the pre- > existing solutions to similar problems. > Does saying headers can appear in either order break from IPv6? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jan 15 16:06:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z1f-0007C4-4f; Mon, 15 Jan 2007 16:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z1e-0007Bx-4Z for 6lowpan@ietf.org; Mon, 15 Jan 2007 16:05:54 -0500 Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6Z1c-0003dd-HC for 6lowpan@ietf.org; Mon, 15 Jan 2007 16:05:54 -0500 Received: (qmail 14541 invoked by uid 60001); 15 Jan 2007 21:05:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=0C2lU9x6hdRMcrMd037vxwVv/SYtWfaHRVgmZpF2TgOnBl68Zg1179Jo6oPKccZ8hc7JHqw/ur+q1TpYjC5G3XLSNx01fINkqfI9Wb1kNP2aQf8fRAxPZ+oaCxIiqRkK3m5tQ3DQmbJzoCs1gQQnS+BnDsP2hHyM/04ne+WrpSg= ; Message-ID: <20070115210551.14539.qmail@web81907.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81907.mail.mud.yahoo.com via HTTP; Mon, 15 Jan 2007 13:05:51 PST Date: Mon, 15 Jan 2007 13:05:51 -0800 (PST) From: gabriel montenegro Subject: Re: SV: [6lowpan] WG last call on Format document To: Carsten Bormann MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Carsten Bormann , 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1097909010==" Errors-To: 6lowpan-bounces@ietf.org --===============1097909010== Content-Type: multipart/alternative; boundary="0-2099553887-1168895151=:13381" --0-2099553887-1168895151=:13381 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Going back to Carsten's 3 options. Now that it's clear that nobody was aski= ng for option 3=0Abelow perhaps we can move forward. As I see it, relaxing = the order of the headers=0Aas per Option 2 by itself does not help much. Ho= w does this next hop know if it is the=0Asole recipient of all the fragment= s? Kris eloquently points out that this is a real=0Aproblem in a mesh. Perh= aps what is needed is some negotiation in addition to merely=0Arelaxing the= ordering of the headers (as done, for example, with DTN). If so, I=0Acould= change the text as follows:=0A=0AAFTER:=0A When more than one LoWPAN hea= der is used in the same packet, they=0A MUST appear in the following orde= r:=0A=0A Mesh Addressing Header=0A Broadcast Header=0A Fragm= entation HeaderADD:=0A=0A Future revisions of these processes may relax = the above header ordering.=0A=0ASo whereas this ordering is currently manda= ted, we would keep the door open=0Afor future variations to be specified se= parately.=0A=0AAnd to answer Phil's question: this does not contravene=0AIP= v6. Even though the current header format may have been inspired by IPv6,= =0AIPv6 itself is impervious to it as this is hidden under IP. =0A=0ADoes t= his work? =0A=0AIf so, I can prepare a new version of the doc with the abov= e change=0Aas well as some typo and editorial fixes (e.g., delete an outdat= ed "NOTE") =0Ain preparation for IESG.=0A=0A-gabriel=0A=0A----- Original Me= ssage ----=0AFrom: Carsten Bormann =0ATo: gabriel montenegro = =0ACc: Carsten Bormann ; S= chumacher Christian Peter Pii ; Philip Levis ; Geoff Mulligan ; 6lowpan@ietf.org=0ASe= nt: Sunday, January 7, 2007 12:09:08 PM=0ASubject: Re: SV: [6lowpan] WG las= t call on Format document=0A=0A> I'd suggest capturing Phil's issue in the = writeup used by the=0A> chairs to advance the document as per:=0A>=0A> h= ttp://www.ietf.org/IESG/content/Doc-Writeup.html=0A>=0A> That way we can in= vite discussion from the IESG on this item.=0A=0AWhile it is always a good = thing to obtain input from the IESG, I =0Adon't think delegating this issu= e to the IESG during document =0Asubmission is the right approach here.=0A= =0AThe WG is the domain expert on the kind of network we are discussing = =0Ahere.=0AThe WG should come to a conclusion.=0AThe IESG can then check th= at we followed process and that the =0Adocument fits into the wider IETF p= icture (which is *not* dominated =0Aby the relevant considerations here).= =0A=0A=0A On the reassembly issue, I see two approa= ches:=0A=0A 1) keep with the reassembly at destination=0A 2) open up th= e sequence such that reassembly-before-forwarding =0Abecomes an alternativ= e, chosen by the sender.=0A 3) only allow reassembly before forwarding, i= .e. forward only full =0Adatagrams.=0A=0A (As far as I can see, nobody a= rgues for 3, that's why I see *two* =0Aapproaches.)=0A=0A The advantage = of 2 is more options (Philip has explained why this =0Acan be a good thing= ).=0A=0A The obvious disadvantage of 2 is more options (i.e., increased = =0Aburden on an implementation).=0A With 2, the sender gets to decide whe= ther a forwarder has to =0Areassemble before forwarding; the forwarder has= to play with that =0Adecision.=0A (Reassembly at the forwarder also mea= ns different fragments cannot =0Achoose different paths; maybe a more theo= retical consideration.)=0A=0A=0AI'd like to hear more people tak= ing sides on 1 or 2 before we declare =0Aconsensus.=0A=0AGruesse, Carsten= =0A=0A=0A=0A=0A=0A --0-2099553887-1168895151=:13381 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Going back to Carsten's 3 options. Now that it's clea= r that nobody was asking for option 3
below perhaps we can move forward.= As I see it, relaxing the order of the headers
as per Option 2 by itsel= f does not help much. How does this next hop know if it is the
sole reci= pient of all the fragments? Kris eloquently points out that this is a real<= br>problem in a mesh. Perhaps what is needed is some negotiation in additio= n to merely
relaxing the ordering of the headers (as done, for example, = with DTN). If so, I
could change the text as follows:

AFTER:
<= pre> When more than one LoWPAN header is used in the same packet, they MUST appear in the following order:

Mesh Addressing Header=
Broadcast Header
Fragmentation HeaderADD:

    F= uture revisions of these processes may relax the above header ordering.
=
So whereas this ordering is currently mandated, we would keep the door = open
for future variations to be specified separately.

And to ans= wer Phil's question: this does not contravene
IPv6. Even though the curr= ent header format may have been inspired by IPv6,
IPv6 itself is impervi= ous to it as this is hidden under IP.

Does this work?

If so= , I can prepare a new version of the doc with the above change
as well a= s some typo and editorial fixes (e.g., delete an outdated "NOTE")
in pr= eparation for IESG.

-gabriel

----- Original Message -= ---
From: Carsten Bormann <cabo@tzi.org>
To: gabriel montenegro= <gabriel_montenegro_2000@yahoo.com>
Cc: Carsten Bormann <cabo@= tzi.org>; Schumacher Christian Peter Pii <schumacher@danfoss.com>; Philip Levi= s <pal@cs.stanford.edu>; Geoff Mulligan <geoff@mulligan.com>; 6= lowpan@ietf.org
Sent: Sunday, January 7, 2007 12:09:08 PM
Subject: Re= : SV: [6lowpan] WG last call on Format document

> I'd sugges= t capturing Phil's issue in the writeup used by the
> chairs to advan= ce the document as per:
>
>    http://= www.ietf.org/IESG/content/Doc-Writeup.html
>
> That way we = can invite discussion from the IESG on this item.

While it is always= a good thing to obtain input from the IESG, I  
don't think d= elegating this issue to the IESG during document  
submission = is the right approach here.

The WG is the domain expert on the kind = of network we are discussing  
here.
The WG should come to = a conclusion.
The IESG can then check that we followed process and that t= he  
document fits into the wider IETF picture (which is *not*= dominated  
by the relevant considerations here).

<= wg-chair hat=3D"off">
   On the reassembly issue, I see two= approaches:

   1) keep with the reassembly at destination=
   2) open up the sequence such that reassembly-before-forwar= ding  
becomes an alternative, chosen by the sender.
 =   3) only allow reassembly before forwarding, i.e. forward only full&n= bsp; 
datagrams.

   (As far as I can see, nobody a= rgues for 3, that's why I see *two*  
approaches.)

&nbs= p;  The advantage of 2 is more options (Philip has explained why this&= nbsp; 
can be a good thing).

   The obvious disadv= antage of 2 is more options (i.e., increased  
burden on an implementation).
   With 2, the sender gets to decide whether= a forwarder has to  
reassemble before forwarding; the forwar= der has to play with that  
decision.
   (Reassem= bly at the forwarder also means different fragments cannot  
c= hoose different paths; maybe a more theoretical consideration.)
</wg-= chair>

I'd like to hear more people taking sides on 1 or 2 before= we declare  
consensus.

Gruesse, Carsten

=

--0-2099553887-1168895151=:13381-- --===============1097909010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1097909010==-- From 6lowpan-bounces@ietf.org Mon Jan 15 20:05:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6clf-0001XJ-TU; Mon, 15 Jan 2007 20:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6cle-0001XD-Mc for 6lowpan@ietf.org; Mon, 15 Jan 2007 20:05:38 -0500 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6clc-0005Bw-AR for 6lowpan@ietf.org; Mon, 15 Jan 2007 20:05:38 -0500 Received: from dnab42230b.stanford.edu ([171.66.35.11]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1H6clY-0005Ge-Gt; Mon, 15 Jan 2007 17:05:33 -0800 In-Reply-To: <20070115210551.14539.qmail@web81907.mail.mud.yahoo.com> References: <20070115210551.14539.qmail@web81907.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A01B4A4-D01E-4960-97F7-B7BB65F32102@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: SV: [6lowpan] WG last call on Format document Date: Mon, 15 Jan 2007 17:05:43 -0800 To: gabriel montenegro X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-2.Stanford.EDU X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Carsten Bormann , 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Jan 15, 2007, at 1:05 PM, gabriel montenegro wrote: > Going back to Carsten's 3 options. Now that it's clear that nobody > was asking for option 3 > below perhaps we can move forward. As I see it, relaxing the order > of the headers > as per Option 2 by itself does not help much. How does this next > hop know if it is the > sole recipient of all the fragments? Kris eloquently points out > that this is a real > problem in a mesh. Perhaps what is needed is some negotiation in > addition to merely > relaxing the ordering of the headers (as done, for example, with > DTN). If so, I > could change the text as follows: > > AFTER: > When more than one LoWPAN header is used in the same packet, they > MUST appear in the following order: > > Mesh Addressing Header > Broadcast Header > Fragmentation HeaderADD: > > Future revisions of these processes may relax the above header > ordering. > > So whereas this ordering is currently mandated, we would keep the > door open > for future variations to be specified separately. > > And to answer Phil's question: this does not contravene > IPv6. Even though the current header format may have been inspired > by IPv6, > IPv6 itself is impervious to it as this is hidden under IP. > > Does this work? Give that the current proposal allows for new headers to be introduced along with their ordering, I think the "may relax" statement is not necessary. We can always introduce a new fragmentation (or routing) header that switches the order around. That being said, if you want to hedge your bets, then best to be more precise: MUST the ordering on transmit and SHOULD the fact that you need to accept either. But of course this is going to make the whole thing harder to implement. I think it's better to leave out the addendum. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 01:37:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7QtY-00088w-GG; Thu, 18 Jan 2007 01:37:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7QtX-00088l-HX for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 01:37:07 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7QtV-0003YH-Jk for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 01:37:06 -0500 Received: from dev20.coslabs.com (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l0I6asQg003812 for <6lowpan@lists.ietf.org>; Wed, 17 Jan 2007 23:36:56 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Wed, 17 Jan 2007 23:36:52 -0700 Message-Id: <1169102212.5192.101.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [6lowpan] Slight problem with format document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org While reviewing the format document I realized that we didn't describe handling of ICMPv6 error messages. Since the 6lowpan headers may be compressed it is necessary to uncompress the original IP and transport headers before sending the ICMP error message. Here is my proposed text for a new section 12... 12. Handling ICMPv6 messages ICMPv6 (RFC2463) is used to report errors and carry IP layer information and functions such as diagnostics. There are two groups of ICMPv6 messages: error messages and informational messages. Each message consists of a type field (if the high order bit is 0 it is an error message), a code and checksum field. These fields are followed by the ICMPv6 message body. For ICMPv6 error messages (Type <128) the message body shall contain as much of the original (offending) IP message without exceeded the minimum IPv6 MTU. As described in the preceding section (Header Compression), the original IPv6 and Transport (TCP or UDP) headers may be compressed via HC1 and HC2 encoding. So that the destination node of an ICMPv6 error message can properly process the message the source node must decompress the IPv6 and transport headers before sending the ICMPv6 message. This is necessary because the original MAC addresses and the HC1 and HC2 encoding headers will be lost and the recipient would have no ability to reconstruct the original message nor compute the proper checksum. The ICMPv6 message itself is carried inside and IPv6 packet and this packet may be transmitted over the 6LoWPAN network utilizing header compression. ICMPv6 messages that are larger than the available payload of the 6LoWPAN network will need to be fragmented. Assuming the maximum frame overhead, maximum link layer security and including a 6LoWPAN Mesh Header, Fragmentation Header and Dispatch Header, sending the uncompressed IPv6 and transport headers should still allow for 25 octets of the original packet payload. Packets using short addresses, no security, and just a 6LoWPAN Dispatch header will be able to carry 61 octets of the original packet. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 02:07:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RMy-00013D-R9; Thu, 18 Jan 2007 02:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RMx-00011P-6F for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:07:31 -0500 Received: from web81914.mail.mud.yahoo.com ([68.142.207.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7RMv-0006uR-AB for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:07:31 -0500 Received: (qmail 17984 invoked by uid 60001); 18 Jan 2007 07:07:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=DAPPV7pOfrg/gPnqX74kCRU1m+v4tNSIs25WGm6VecRC+CkbJPSdPNvh/bTGaF8WuFEZV4gpbsk1Bsmz7DH7toTaGYpb2IFzfS2+PR/jtT8ewj2MtL14Lcgti8lK/mRPI+nY6zrnJGVOwSjPWU6cjsmJH4NGFk9fk8U1uY9p6ho= ; Message-ID: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81914.mail.mud.yahoo.com via HTTP; Wed, 17 Jan 2007 23:07:28 PST Date: Wed, 17 Jan 2007 23:07:28 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] Slight problem with format document To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0042300667==" Errors-To: 6lowpan-bounces@ietf.org --===============0042300667== Content-Type: multipart/alternative; boundary="0-814678170-1169104048=:17415" --0-814678170-1169104048=:17415 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Is this even necessary to be said? ICMP msgs will never be sent by intermed= iate nodes=0Ain a lowpan mesh, but only by the IPv6 end nodes as part of no= rmal IPv6 processing.=0AThis processing takes place after the lowpan layer = delivers packets to the=0AIPv6 stack. So by the time the IPv6 stack gets th= e packet, it will have been=0Adecompressed. This is the same for lowpan hea= der compression or any other type=0Aof header compression.=0A=0ASo I wonder= if the text below is needed. It would be needed if the entity sending=0Aba= ck ICMP messages was the lowpan layer. Yes, it would see compressed headers= .=0ABut the entity is the IPv6 stack, which does not see those compressed h= eaders.=0A=0AComments? Am I missing something?=0A=0A-gabriel=0A=0A----- Ori= ginal Message ----=0AFrom: Geoff Mulligan =0ATo: 6lowpa= n <6lowpan@lists.ietf.org>=0ASent: Wednesday, January 17, 2007 10:36:52 PM= =0ASubject: [6lowpan] Slight problem with format document=0A=0AWhile review= ing the format document I realized that we didn't describe=0Ahandling of IC= MPv6 error messages. Since the 6lowpan headers may be=0Acompressed it is n= ecessary to uncompress the original IP and transport=0Aheaders before sendi= ng the ICMP error message.=0A=0AHere is my proposed text for a new section = 12...=0A=0A12. Handling ICMPv6 messages=0A=0AICMPv6 (RFC2463) is used to re= port errors and carry IP layer information=0Aand functions such as diagnost= ics. There are two groups of ICMPv6=0Amessages: error messages and informa= tional messages. Each message=0Aconsists of a type field (if the high order= bit is 0 it is an error=0Amessage), a code and checksum field. These fiel= ds are followed by the=0AICMPv6 message body. For ICMPv6 error messages (T= ype <128) the message=0Abody shall contain as much of the original (offendi= ng) IP message=0Awithout exceeded the minimum IPv6 MTU. =0A=0AAs described= in the preceding section (Header Compression), the original=0AIPv6 and Tra= nsport (TCP or UDP) headers may be compressed via HC1 and=0AHC2 encoding. = So that the destination node of an ICMPv6 error message=0Acan properly proc= ess the message the source node must decompress the=0AIPv6 and transport he= aders before sending the ICMPv6 message. This is=0Anecessary because the o= riginal MAC addresses and the HC1 and HC2=0Aencoding headers will be lost a= nd the recipient would have no ability to=0Areconstruct the original messag= e nor compute the proper checksum. =0A=0AThe ICMPv6 message itself is carr= ied inside and IPv6 packet and this=0Apacket may be transmitted over the 6L= oWPAN network utilizing header=0Acompression. ICMPv6 messages that are lar= ger than the available payload=0Aof the 6LoWPAN network will need to be fra= gmented. Assuming the maximum=0Aframe overhead, maximum link layer security= and including a 6LoWPAN Mesh=0AHeader, Fragmentation Header and Dispatch H= eader, sending the=0Auncompressed IPv6 and transport headers should still a= llow for 25 octets=0Aof the original packet payload. Packets using short a= ddresses, no=0Asecurity, and just a 6LoWPAN Dispatch header will be able to= carry 61=0Aoctets of the original packet.=0A=0A =0A=0A=0A________________= _______________________________=0A6lowpan mailing list=0A6lowpan@ietf.org= =0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan=0A=0A=0A=0A=0A --0-814678170-1169104048=:17415 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Is this even necessary to be said? ICMP msgs will nev= er be sent by intermediate nodes
in a lowpan mesh, but only by the IPv6 = end nodes as part of normal IPv6 processing.
This processing takes place= after the lowpan layer delivers packets to the
IPv6 stack. So by the ti= me the IPv6 stack gets the packet, it will have been
decompressed. This = is the same for lowpan header compression or any other type
of header co= mpression.

So I wonder if the text below is needed. It would be need= ed if the entity sending
back ICMP messages was the lowpan layer. Yes, i= t would see compressed headers.
But the entity is the IPv6 stack, which = does not see those compressed headers.

Comments? Am I missing something?

-gabriel

----- Original Message ----
F= rom: Geoff Mulligan <geoff@mulligan.com>
To: 6lowpan <6lowpan@l= ists.ietf.org>
Sent: Wednesday, January 17, 2007 10:36:52 PM
Subje= ct: [6lowpan] Slight problem with format document

While reviewi= ng the format document I realized that we didn't describe
handling of IC= MPv6 error messages.  Since the 6lowpan headers may be
compres= sed it is necessary to uncompress the original IP and transport
headers = before sending the ICMP error message.

Here is my proposed text for = a new section 12...

12. Handling ICMPv6 messages

ICMPv6 (RFC2= 463) is used to report errors and carry IP layer information
and functio= ns such as diagnostics.  There are two groups of ICMPv6
messag= es: error messages and informational messages. Each message
consists of = a type field (if the high order bit is 0 it is an error
message), a code and checksu= m field.  These fields are followed by the
ICMPv6 message body= .  For ICMPv6 error messages (Type <128) the message
body s= hall contain as much of the original (offending) IP message
without exce= eded the minimum IPv6 MTU.  

As described in the preceding= section (Header Compression), the original
IPv6 and Transport (TCP or U= DP) headers may be compressed via HC1 and
HC2 encoding.  So th= at the destination node of an ICMPv6 error message
can properly process = the message the source node must decompress the
IPv6 and transport heade= rs before sending the ICMPv6 message.  This is
necessary becau= se the original MAC addresses and the HC1 and HC2
encoding headers will = be lost and the recipient would have no ability to
reconstruct the origi= nal message nor compute the proper checksum.  

The ICMPv6 = message itself is carried inside and IPv6 packet and this
packet may be transmi= tted over the 6LoWPAN network utilizing header
compression.  I= CMPv6 messages that are larger than the available payload
of the 6LoWPAN= network will need to be fragmented. Assuming the maximum
frame overhead= , maximum link layer security and including a 6LoWPAN Mesh
Header, Fragm= entation Header and Dispatch Header, sending the
uncompressed IPv6 and t= ransport headers should still allow for 25 octets
of the original packet= payload.  Packets using short addresses, no
security, and jus= t a 6LoWPAN Dispatch header will be able to carry 61
octets of the origi= nal packet.

  


________________________________= _______________
6lowpan mailing list
6lowpan@ietf.org
https://ww= w1.ietf.org/mailman/listinfo/6lowpan

--0-814678170-1169104048=:17415-- --===============0042300667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0042300667==-- From 6lowpan-bounces@ietf.org Thu Jan 18 02:44:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Rwx-00076r-Nx; Thu, 18 Jan 2007 02:44:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Rww-00076i-1x for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:44:42 -0500 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7RuS-000371-Lc for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:42:09 -0500 Received: by an-out-0708.google.com with SMTP id c18so47468anc for <6lowpan@lists.ietf.org>; Wed, 17 Jan 2007 23:42:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qF8qVWIpMxsiQWu+CGxqQlQgumoViklCpI9rvdOcSbluoNjHHMzyhr7EFIySMgnHKuMy01uxgbEzfh8J1Y4iLUoat2t42f5DFd0s4Ul0WnmX1l5A231WdMah+z5EHcfX1i95bxTxGoR9XpfUyTwxq+/FJhBPopnTf3LxkmA3gNo= Received: by 10.100.13.12 with SMTP id 12mr156434anm.1169106128211; Wed, 17 Jan 2007 23:42:08 -0800 (PST) Received: by 10.100.13.14 with HTTP; Wed, 17 Jan 2007 23:42:08 -0800 (PST) Message-ID: Date: Thu, 18 Jan 2007 16:42:08 +0900 From: "Daniel Park" To: "gabriel montenegro" Subject: Re: [6lowpan] Slight problem with format document In-Reply-To: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Agree with Gabriel's opinion. ICMPv6 is one of next header of IPv6 header, thus its processing will take place after the 6lowpan layer delivers packets to the IPv6 node. Hence I don't think we need to spell out this aspect in the 6lowpan format document. Daniel On 1/18/07, gabriel montenegro wrote: > > Is this even necessary to be said? ICMP msgs will never be sent by > intermediate nodes > in a lowpan mesh, but only by the IPv6 end nodes as part of normal IPv6 > processing. > This processing takes place after the lowpan layer delivers packets to the > IPv6 stack. So by the time the IPv6 stack gets the packet, it will have been > decompressed. This is the same for lowpan header compression or any other > type > of header compression. > > So I wonder if the text below is needed. It would be needed if the entity > sending > back ICMP messages was the lowpan layer. Yes, it would see compressed > headers. > But the entity is the IPv6 stack, which does not see those compressed > headers. > > Comments? Am I missing something? > > -gabriel > > > ----- Original Message ---- > From: Geoff Mulligan > To: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, January 17, 2007 10:36:52 PM > Subject: [6lowpan] Slight problem with format document > > While reviewing the format document I realized that we didn't describe > handling of ICMPv6 error messages. Since the 6lowpan headers may be > compressed it is necessary to uncompress the original IP and transport > headers before sending the ICMP error message. > > Here is my proposed text for a new section 12... > > 12. Handling ICMPv6 messages > > ICMPv6 (RFC2463) is used to report errors and carry IP layer information > and functions such as diagnostics. There are two groups of ICMPv6 > messages: error messages and informational messages. Each message > consists of a type field (if the high order bit is 0 it is an error > message), a code and checksum field. These fields are followed by the > ICMPv6 message body. For ICMPv6 error messages (Type <128) the message > body shall contain as much of the original (offending) IP message > without exceeded the minimum IPv6 MTU. > > As described in the preceding section (Header Compression), the original > IPv6 and Transport (TCP or UDP) headers may be compressed via HC1 and > HC2 encoding. So that the destination node of an ICMPv6 error message > can properly process the message the source node must decompress the > IPv6 and transport headers before sending the ICMPv6 message. This is > necessary because the original MAC addresses and the HC1 and HC2 > encoding headers will be lost and the recipient would have no ability to > reconstruct the original message nor compute the proper checksum. > > The ICMPv6 message itself is carried inside and IPv6 packet and this > packet may be transmitted over the 6LoWPAN network utilizing header > compression. ICMPv6 messages that are larger than the available payload > of the 6LoWPAN network will need to be fragmented. Assuming the maximum > frame overhead, maximum link layer security and including a 6LoWPAN Mesh > Header, Fragmentation Header and Dispatch Header, sending the > uncompressed IPv6 and transport headers should still allow for 25 octets > of the original packet payload. Packets using short addresses, no > security, and just a 6LoWPAN Dispatch header will be able to carry 61 > octets of the original packet. > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > -- Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 02:49:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7S1U-0001tI-Mq; Thu, 18 Jan 2007 02:49:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7S1T-0001tC-Lo for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:49:23 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7S1O-0004Fp-4h for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:49:23 -0500 Received: by nz-out-0506.google.com with SMTP id o37so85117nzf for <6lowpan@lists.ietf.org>; Wed, 17 Jan 2007 23:49:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:to:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=FzPJ1Yl7Tt0OZ+a/8CD80n+kXgvAUWVlnfk1r8OwFoLM8pkbVmMGQ4PXOC0P9acmHPA8n7glJtYN7U6ZKhqbXnQe98dbBtg6hsX536x84Y7MiMHzSgvBl8j5wyClsRKQNqyYsZRF7GyCl/ZWQz5cySKI/t9jbJIKmjE+MG1b1aE= Received: by 10.35.91.10 with SMTP id t10mr1058151pyl.1169106557693; Wed, 17 Jan 2007 23:49:17 -0800 (PST) Received: from Maoer ( [211.144.102.58]) by mx.google.com with ESMTP id c12sm1618167nzc.2007.01.17.23.49.11; Wed, 17 Jan 2007 23:49:17 -0800 (PST) Message-ID: <001b01c73ad5$7585da60$7fc0a8c0@netlab.cs.ecnu.edu.cn> To: "gabriel montenegro" , "Geoff Mulligan" , "6lowpan" <6lowpan@lists.ietf.org> References: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> Subject: Re: [6lowpan] Slight problem with format document Date: Thu, 18 Jan 2007 15:51:09 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 From: Mario Mao X-Spam-Score: 0.2 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1203447482==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1203447482== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C73B18.78965340" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C73B18.78965340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIGdhYnJpZWwsIHRoZXJlIGlzIG5vIGludGVyZmVyZW5jZSBiZXR3ZWVuIGhl YWRlciBjb21wcmVzc2lvbiBhbmQgSUNNUC4gSG93ZXZlciwgSSBiZWxpZXZlIHR3byBwb2ludHMg c2hvdWxkIGJlIG5vdGVkIHdoaWNoIG1heSBjYXVzZSBpbmZvcm1hdGlvbiBsb3NzLg0KDQoxLiBJ ZiB0aGUgcHJvY2Vzc2luZyBub2RlIGlzIGxvd3BhbiBnYXRld2F5L3JvdXRlciBhbmQgdGhlIHNl bnQgcGFja2V0IGNvbWVzIGZyb20gSW50ZXJuZXQgYnV0IG5vdCBvcmlnaW5hdGVzIGJ5IHRoZSBn YXRld2F5L3JvdXRlciBpdHNlbGYsIHRoZSBJSUQgb2YgSVAgc291cmNlIGFkZHJlc3Mgc2hvdWxk bid0IGJlIGNvbXByZXNzZWQuDQoyLiBJZiB0aGUgSVAgZGVzdGluYXRpb24gaXNuJ3QgYW4gIm9u LWxpbmsiIG5vZGUgKHRoYXQgbWVhbnMgdGhlIGRlc3RpbmF0aW9uIGlzIG1vcmUgdGhhbiBvbmUg aG9wIGF3YXkgZnJvbSBzb3VyY2Ugbm9kZSksIHRoZSBJSUQgb2YgSVAgZGVzdGluYXRpb24gYWRk cmVzcyBzaG91bGRuJ3QgYmUgY29tcHJlc3NlZC4NCg0KSW4gYSB3b3JkLCA2bG93cGFuIG5vZGUg Y291bGQgb25seSBjb21wcmVzcyB0aGUgSUlEIHRoYXQgZGVyaXZlcyBmcm9tIElFRUUgODAyLjE1 LjQgTUFDIGFkZHJlc3MuIEkgdGhpbmsgdGhhdCBwb2ludCBzaG91bGQgYmUgZW1waGFzaXplZCBp biBkcmFmdCwgaXNuJ3QgaXQ/DQoNClJlZ2FyZHMsDQoNCk1hcmlvDQoNCiAgLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogZ2FicmllbCBtb250ZW5lZ3JvIA0KICBUbzogR2Vv ZmYgTXVsbGlnYW4gOyA2bG93cGFuIA0KICBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxOCwgMjAw NyAzOjA3IFBNDQogIFN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gU2xpZ2h0IHByb2JsZW0gd2l0aCBm b3JtYXQgZG9jdW1lbnQNCg0KDQogIElzIHRoaXMgZXZlbiBuZWNlc3NhcnkgdG8gYmUgc2FpZD8g SUNNUCBtc2dzIHdpbGwgbmV2ZXIgYmUgc2VudCBieSBpbnRlcm1lZGlhdGUgbm9kZXMNCiAgaW4g YSBsb3dwYW4gbWVzaCwgYnV0IG9ubHkgYnkgdGhlIElQdjYgZW5kIG5vZGVzIGFzIHBhcnQgb2Yg bm9ybWFsIElQdjYgcHJvY2Vzc2luZy4NCiAgVGhpcyBwcm9jZXNzaW5nIHRha2VzIHBsYWNlIGFm dGVyIHRoZSBsb3dwYW4gbGF5ZXIgZGVsaXZlcnMgcGFja2V0cyB0byB0aGUNCiAgSVB2NiBzdGFj ay4gU28gYnkgdGhlIHRpbWUgdGhlIElQdjYgc3RhY2sgZ2V0cyB0aGUgcGFja2V0LCBpdCB3aWxs IGhhdmUgYmVlbg0KICBkZWNvbXByZXNzZWQuIFRoaXMgaXMgdGhlIHNhbWUgZm9yIGxvd3BhbiBo ZWFkZXIgY29tcHJlc3Npb24gb3IgYW55IG90aGVyIHR5cGUNCiAgb2YgaGVhZGVyIGNvbXByZXNz aW9uLg0KDQogIFNvIEkgd29uZGVyIGlmIHRoZSB0ZXh0IGJlbG93IGlzIG5lZWRlZC4gSXQgd291 bGQgYmUgbmVlZGVkIGlmIHRoZSBlbnRpdHkgc2VuZGluZw0KICBiYWNrIElDTVAgbWVzc2FnZXMg d2FzIHRoZSBsb3dwYW4gbGF5ZXIuIFllcywgaXQgd291bGQgc2VlIGNvbXByZXNzZWQgaGVhZGVy cy4NCiAgQnV0IHRoZSBlbnRpdHkgaXMgdGhlIElQdjYgc3RhY2ssIHdoaWNoIGRvZXMgbm90IHNl ZSB0aG9zZSBjb21wcmVzc2VkIGhlYWRlcnMuDQoNCiAgQ29tbWVudHM/IEFtIEkgbWlzc2luZyBz b21ldGhpbmc/DQoNCiAgLWdhYnJpZWwNCg0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LQ0KICBGcm9tOiBHZW9mZiBNdWxsaWdhbiA8Z2VvZmZAbXVsbGlnYW4uY29tPg0KICBUbzogNmxv d3BhbiA8Nmxvd3BhbkBsaXN0cy5pZXRmLm9yZz4NCiAgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDE3LCAyMDA3IDEwOjM2OjUyIFBNDQogIFN1YmplY3Q6IFs2bG93cGFuXSBTbGlnaHQgcHJvYmxl bSB3aXRoIGZvcm1hdCBkb2N1bWVudA0KDQoNCiAgV2hpbGUgcmV2aWV3aW5nIHRoZSBmb3JtYXQg ZG9jdW1lbnQgSSByZWFsaXplZCB0aGF0IHdlIGRpZG4ndCBkZXNjcmliZQ0KICBoYW5kbGluZyBv ZiBJQ01QdjYgZXJyb3IgbWVzc2FnZXMuICBTaW5jZSB0aGUgNmxvd3BhbiBoZWFkZXJzIG1heSBi ZQ0KICBjb21wcmVzc2VkIGl0IGlzIG5lY2Vzc2FyeSB0byB1bmNvbXByZXNzIHRoZSBvcmlnaW5h bCBJUCBhbmQgdHJhbnNwb3J0DQogIGhlYWRlcnMgYmVmb3JlIHNlbmRpbmcgdGhlIElDTVAgZXJy b3IgbWVzc2FnZS4NCg0KICBIZXJlIGlzIG15IHByb3Bvc2VkIHRleHQgZm9yIGEgbmV3IHNlY3Rp b24gMTIuLi4NCg0KICAxMi4gSGFuZGxpbmcgSUNNUHY2IG1lc3NhZ2VzDQoNCiAgSUNNUHY2IChS RkMyNDYzKSBpcyB1c2VkIHRvIHJlcG9ydCBlcnJvcnMgYW5kIGNhcnJ5IElQIGxheWVyIGluZm9y bWF0aW9uDQogIGFuZCBmdW5jdGlvbnMgc3VjaCBhcyBkaWFnbm9zdGljcy4gIFRoZXJlIGFyZSB0 d28gZ3JvdXBzIG9mIElDTVB2Ng0KICBtZXNzYWdlczogZXJyb3IgbWVzc2FnZXMgYW5kIGluZm9y bWF0aW9uYWwgbWVzc2FnZXMuIEVhY2ggbWVzc2FnZQ0KICBjb25zaXN0cyBvZiBhIHR5cGUgZmll bGQgKGlmIHRoZSBoaWdoIG9yZGVyIGJpdCBpcyAwIGl0IGlzIGFuIGVycm9yDQogIG1lc3NhZ2Up LCBhIGNvZGUgYW5kIGNoZWNrc3VtIGZpZWxkLiAgVGhlc2UgZmllbGRzIGFyZSBmb2xsb3dlZCBi eSB0aGUNCiAgSUNNUHY2IG1lc3NhZ2UgYm9keS4gIEZvciBJQ01QdjYgZXJyb3IgbWVzc2FnZXMg KFR5cGUgPDEyOCkgdGhlIG1lc3NhZ2UNCiAgYm9keSBzaGFsbCBjb250YWluIGFzIG11Y2ggb2Yg dGhlIG9yaWdpbmFsIChvZmZlbmRpbmcpIElQIG1lc3NhZ2UNCiAgd2l0aG91dCBleGNlZWRlZCB0 aGUgbWluaW11bSBJUHY2IE1UVS4gIA0KDQogIEFzIGRlc2NyaWJlZCBpbiB0aGUgcHJlY2VkaW5n IHNlY3Rpb24gKEhlYWRlciBDb21wcmVzc2lvbiksIHRoZSBvcmlnaW5hbA0KICBJUHY2IGFuZCBU cmFuc3BvcnQgKFRDUCBvciBVRFApIGhlYWRlcnMgbWF5IGJlIGNvbXByZXNzZWQgdmlhIEhDMSBh bmQNCiAgSEMyIGVuY29kaW5nLiAgU28gdGhhdCB0aGUgZGVzdGluYXRpb24gbm9kZSBvZiBhbiBJ Q01QdjYgZXJyb3IgbWVzc2FnZQ0KICBjYW4gcHJvcGVybHkgcHJvY2VzcyB0aGUgbWVzc2FnZSB0 aGUgc291cmNlIG5vZGUgbXVzdCBkZWNvbXByZXNzIHRoZQ0KICBJUHY2IGFuZCB0cmFuc3BvcnQg aGVhZGVycyBiZWZvcmUgc2VuZGluZyB0aGUgSUNNUHY2IG1lc3NhZ2UuICBUaGlzIGlzDQogIG5l Y2Vzc2FyeSBiZWNhdXNlIHRoZSBvcmlnaW5hbCBNQUMgYWRkcmVzc2VzIGFuZCB0aGUgSEMxIGFu ZCBIQzINCiAgZW5jb2RpbmcgaGVhZGVycyB3aWxsIGJlIGxvc3QgYW5kIHRoZSByZWNpcGllbnQg d291bGQgaGF2ZSBubyBhYmlsaXR5IHRvDQogIHJlY29uc3RydWN0IHRoZSBvcmlnaW5hbCBtZXNz YWdlIG5vciBjb21wdXRlIHRoZSBwcm9wZXIgY2hlY2tzdW0uICANCg0KICBUaGUgSUNNUHY2IG1l c3NhZ2UgaXRzZWxmIGlzIGNhcnJpZWQgaW5zaWRlIGFuZCBJUHY2IHBhY2tldCBhbmQgdGhpcw0K ICBwYWNrZXQgbWF5IGJlIHRyYW5zbWl0dGVkIG92ZXIgdGhlIDZMb1dQQU4gbmV0d29yayB1dGls aXppbmcgaGVhZGVyDQogIGNvbXByZXNzaW9uLiAgSUNNUHY2IG1lc3NhZ2VzIHRoYXQgYXJlIGxh cmdlciB0aGFuIHRoZSBhdmFpbGFibGUgcGF5bG9hZA0KICBvZiB0aGUgNkxvV1BBTiBuZXR3b3Jr IHdpbGwgbmVlZCB0byBiZSBmcmFnbWVudGVkLiBBc3N1bWluZyB0aGUgbWF4aW11bQ0KICBmcmFt ZSBvdmVyaGVhZCwgbWF4aW11bSBsaW5rIGxheWVyIHNlY3VyaXR5IGFuZCBpbmNsdWRpbmcgYSA2 TG9XUEFOIE1lc2gNCiAgSGVhZGVyLCBGcmFnbWVudGF0aW9uIEhlYWRlciBhbmQgRGlzcGF0Y2gg SGVhZGVyLCBzZW5kaW5nIHRoZQ0KICB1bmNvbXByZXNzZWQgSVB2NiBhbmQgdHJhbnNwb3J0IGhl YWRlcnMgc2hvdWxkIHN0aWxsIGFsbG93IGZvciAyNSBvY3RldHMNCiAgb2YgdGhlIG9yaWdpbmFs IHBhY2tldCBwYXlsb2FkLiAgUGFja2V0cyB1c2luZyBzaG9ydCBhZGRyZXNzZXMsIG5vDQogIHNl Y3VyaXR5LCBhbmQganVzdCBhIDZMb1dQQU4gRGlzcGF0Y2ggaGVhZGVyIHdpbGwgYmUgYWJsZSB0 byBjYXJyeSA2MQ0KICBvY3RldHMgb2YgdGhlIG9yaWdpbmFsIHBhY2tldC4NCg0KICAgIA0KDQoN CiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgNmxv d3BhbiBtYWlsaW5nIGxpc3QNCiAgNmxvd3BhbkBpZXRmLm9yZw0KICBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICA2bG93cGFuIG1haWxpbmcgbGlzdA0KICA2bG93cGFuQGlldGYub3JnDQogIGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCg== ------=_NextPart_000_0018_01C73B18.78965340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+ RElWIHsNCglNQVJHSU46IDBweA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNTg2IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm ZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgYWdyZWUgd2l0aCBnYWJyaWVs LCB0aGVyZSBpcyBubyBpbnRlcmZlcmVuY2UgDQpiZXR3ZWVuIGhlYWRlciBjb21wcmVzc2lvbiBh bmQgSUNNUC4gSG93ZXZlciwgSSBiZWxpZXZlIHR3byBwb2ludHMgc2hvdWxkIGJlIA0Kbm90ZWQg d2hpY2ggbWF5IGNhdXNlIGluZm9ybWF0aW9uIGxvc3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjEuIElmIHRoZSBwcm9jZXNzaW5nIG5vZGUgaXMgbG93cGFuIGdhdGV3YXkv cm91dGVyIA0KYW5kIHRoZSBzZW50IHBhY2tldCBjb21lcyBmcm9tIEludGVybmV0IGJ1dCBub3Qg b3JpZ2luYXRlcyBieSB0aGUgZ2F0ZXdheS9yb3V0ZXIgDQppdHNlbGYsIHRoZSBJSUQgb2YgSVAg c291cmNlIGFkZHJlc3Mgc2hvdWxkbid0IGJlIGNvbXByZXNzZWQuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4yLiBJZiB0aGUgSVAgZGVzdGluYXRpb24gaXNuJ3Qg YW4gIm9uLWxpbmsiIG5vZGUgDQoodGhhdCBtZWFucyB0aGUgZGVzdGluYXRpb24gaXMgbW9yZSB0 aGFuIG9uZSBob3AgYXdheSBmcm9tIHNvdXJjZSBub2RlKSwgdGhlIElJRCANCm9mIElQIGRlc3Rp bmF0aW9uIGFkZHJlc3Mgc2hvdWxkbid0IGJlIGNvbXByZXNzZWQuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPkluIGEgd29yZCwgNmxvd3BhbiBub2RlIGNvdWxkJm5ic3A7b25s eSBjb21wcmVzcyANCnRoZSBJSUQgdGhhdCBkZXJpdmVzIGZyb20gSUVFRSA4MDIuMTUuNCBNQUMg YWRkcmVzcy4gSSB0aGluayB0aGF0IHBvaW50IHNob3VsZCANCmJlIGVtcGhhc2l6ZWQgaW4gZHJh ZnQsIGlzbid0IGl0PzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5SZWdhcmRz LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5NYXJpbzwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPEJMT0NL UVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFS R0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklH SFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5E OiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2si PjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9Z2FicmllbF9tb250ZW5lZ3JvXzIwMDBAeWFob28u Y29tIA0KICBocmVmPSJtYWlsdG86Z2FicmllbF9tb250ZW5lZ3JvXzIwMDBAeWFob28uY29tIj5n YWJyaWVsIG1vbnRlbmVncm88L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMy MzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1nZW9mZkBtdWxsaWdhbi5jb20gDQog IGhyZWY9Im1haWx0bzpnZW9mZkBtdWxsaWdhbi5jb20iPkdlb2ZmIE11bGxpZ2FuPC9BPiA7IDxB IA0KICB0aXRsZT02bG93cGFuQGxpc3RzLmlldGYub3JnIGhyZWY9Im1haWx0bzo2bG93cGFuQGxp c3RzLmlldGYub3JnIj42bG93cGFuPC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEphbnVhcnkgMTgs IDIwMDcgMzowNyANClBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFs2bG93cGFuXSBTbGlnaHQgcHJvYmxlbSB3aXRo IA0KICBmb3JtYXQgZG9jdW1lbnQ8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVYgDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBjb3VyaWVyLCBtb25hY28sIG1v bm9zcGFjZSwgc2Fucy1zZXJpZiI+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IEZPTlQtRkFNSUxZOiBjb3VyaWVyLG1vbmFjbyxtb25vc3BhY2Usc2Fucy1zZXJpZiI+SXMgDQog IHRoaXMgZXZlbiBuZWNlc3NhcnkgdG8gYmUgc2FpZD8gSUNNUCBtc2dzIHdpbGwgbmV2ZXIgYmUg c2VudCBieSBpbnRlcm1lZGlhdGUgDQogIG5vZGVzPEJSPmluIGEgbG93cGFuIG1lc2gsIGJ1dCBv bmx5IGJ5IHRoZSBJUHY2IGVuZCBub2RlcyBhcyBwYXJ0IG9mIG5vcm1hbCANCiAgSVB2NiBwcm9j ZXNzaW5nLjxCUj5UaGlzIHByb2Nlc3NpbmcgdGFrZXMgcGxhY2UgYWZ0ZXIgdGhlIGxvd3BhbiBs YXllciANCiAgZGVsaXZlcnMgcGFja2V0cyB0byB0aGU8QlI+SVB2NiBzdGFjay4gU28gYnkgdGhl IHRpbWUgdGhlIElQdjYgc3RhY2sgZ2V0cyB0aGUgDQogIHBhY2tldCwgaXQgd2lsbCBoYXZlIGJl ZW48QlI+ZGVjb21wcmVzc2VkLiBUaGlzIGlzIHRoZSBzYW1lIGZvciBsb3dwYW4gaGVhZGVyIA0K ICBjb21wcmVzc2lvbiBvciBhbnkgb3RoZXIgdHlwZTxCUj5vZiBoZWFkZXIgY29tcHJlc3Npb24u PEJSPjxCUj5TbyBJIHdvbmRlciBpZiANCiAgdGhlIHRleHQgYmVsb3cgaXMgbmVlZGVkLiBJdCB3 b3VsZCBiZSBuZWVkZWQgaWYgdGhlIGVudGl0eSBzZW5kaW5nPEJSPmJhY2sgDQogIElDTVAgbWVz c2FnZXMgd2FzIHRoZSBsb3dwYW4gbGF5ZXIuIFllcywgaXQgd291bGQgc2VlIGNvbXByZXNzZWQg DQogIGhlYWRlcnMuPEJSPkJ1dCB0aGUgZW50aXR5IGlzIHRoZSBJUHY2IHN0YWNrLCB3aGljaCBk b2VzIG5vdCBzZWUgdGhvc2UgDQogIGNvbXByZXNzZWQgaGVhZGVycy48QlI+PEJSPkNvbW1lbnRz PyBBbSBJIG1pc3NpbmcgDQogIHNvbWV0aGluZz88QlI+PEJSPi1nYWJyaWVsPEJSPjxCUj4NCiAg PERJViANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyBy b21hbixuZXcgeW9yayx0aW1lcyxzZXJpZiI+LS0tLS0gDQogIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LTxCUj5Gcm9tOiBHZW9mZiBNdWxsaWdhbiANCiAgJmx0O2dlb2ZmQG11bGxpZ2FuLmNvbSZndDs8 QlI+VG86IDZsb3dwYW4gDQogICZsdDs2bG93cGFuQGxpc3RzLmlldGYub3JnJmd0OzxCUj5TZW50 OiBXZWRuZXNkYXksIEphbnVhcnkgMTcsIDIwMDcgMTA6MzY6NTIgDQogIFBNPEJSPlN1YmplY3Q6 IFs2bG93cGFuXSBTbGlnaHQgcHJvYmxlbSB3aXRoIGZvcm1hdCBkb2N1bWVudDxCUj48QlI+DQog IDxESVY+V2hpbGUgcmV2aWV3aW5nIHRoZSBmb3JtYXQgZG9jdW1lbnQgSSByZWFsaXplZCB0aGF0 IHdlIGRpZG4ndCANCiAgZGVzY3JpYmU8QlI+aGFuZGxpbmcgb2YgSUNNUHY2IGVycm9yIG1lc3Nh Z2VzLiZuYnNwOyZuYnNwO1NpbmNlIHRoZSA2bG93cGFuIA0KICBoZWFkZXJzIG1heSBiZTxCUj5j b21wcmVzc2VkIGl0IGlzIG5lY2Vzc2FyeSB0byB1bmNvbXByZXNzIHRoZSBvcmlnaW5hbCBJUCBh bmQgDQogIHRyYW5zcG9ydDxCUj5oZWFkZXJzIGJlZm9yZSBzZW5kaW5nIHRoZSBJQ01QIGVycm9y IG1lc3NhZ2UuPEJSPjxCUj5IZXJlIGlzIG15IA0KICBwcm9wb3NlZCB0ZXh0IGZvciBhIG5ldyBz ZWN0aW9uIDEyLi4uPEJSPjxCUj4xMi4gSGFuZGxpbmcgSUNNUHY2IA0KICBtZXNzYWdlczxCUj48 QlI+SUNNUHY2IChSRkMyNDYzKSBpcyB1c2VkIHRvIHJlcG9ydCBlcnJvcnMgYW5kIGNhcnJ5IElQ IGxheWVyIA0KICBpbmZvcm1hdGlvbjxCUj5hbmQgZnVuY3Rpb25zIHN1Y2ggYXMgZGlhZ25vc3Rp Y3MuJm5ic3A7Jm5ic3A7VGhlcmUgYXJlIHR3byANCiAgZ3JvdXBzIG9mIElDTVB2NjxCUj5tZXNz YWdlczogZXJyb3IgbWVzc2FnZXMgYW5kIGluZm9ybWF0aW9uYWwgbWVzc2FnZXMuIEVhY2ggDQog IG1lc3NhZ2U8QlI+Y29uc2lzdHMgb2YgYSB0eXBlIGZpZWxkIChpZiB0aGUgaGlnaCBvcmRlciBi aXQgaXMgMCBpdCBpcyBhbiANCiAgZXJyb3I8QlI+bWVzc2FnZSksIGEgY29kZSBhbmQgY2hlY2tz dW0gZmllbGQuJm5ic3A7Jm5ic3A7VGhlc2UgZmllbGRzIGFyZSANCiAgZm9sbG93ZWQgYnkgdGhl PEJSPklDTVB2NiBtZXNzYWdlIGJvZHkuJm5ic3A7Jm5ic3A7Rm9yIElDTVB2NiBlcnJvciBtZXNz YWdlcyANCiAgKFR5cGUgJmx0OzEyOCkgdGhlIG1lc3NhZ2U8QlI+Ym9keSBzaGFsbCBjb250YWlu IGFzIG11Y2ggb2YgdGhlIG9yaWdpbmFsIA0KICAob2ZmZW5kaW5nKSBJUCBtZXNzYWdlPEJSPndp dGhvdXQgZXhjZWVkZWQgdGhlIG1pbmltdW0gSVB2NiANCiAgTVRVLiZuYnNwOyZuYnNwOzxCUj48 QlI+QXMgZGVzY3JpYmVkIGluIHRoZSBwcmVjZWRpbmcgc2VjdGlvbiAoSGVhZGVyIA0KICBDb21w cmVzc2lvbiksIHRoZSBvcmlnaW5hbDxCUj5JUHY2IGFuZCBUcmFuc3BvcnQgKFRDUCBvciBVRFAp IGhlYWRlcnMgbWF5IGJlIA0KICBjb21wcmVzc2VkIHZpYSBIQzEgYW5kPEJSPkhDMiBlbmNvZGlu Zy4mbmJzcDsmbmJzcDtTbyB0aGF0IHRoZSBkZXN0aW5hdGlvbiANCiAgbm9kZSBvZiBhbiBJQ01Q djYgZXJyb3IgbWVzc2FnZTxCUj5jYW4gcHJvcGVybHkgcHJvY2VzcyB0aGUgbWVzc2FnZSB0aGUg c291cmNlIA0KICBub2RlIG11c3QgZGVjb21wcmVzcyB0aGU8QlI+SVB2NiBhbmQgdHJhbnNwb3J0 IGhlYWRlcnMgYmVmb3JlIHNlbmRpbmcgdGhlIA0KICBJQ01QdjYgbWVzc2FnZS4mbmJzcDsmbmJz cDtUaGlzIGlzPEJSPm5lY2Vzc2FyeSBiZWNhdXNlIHRoZSBvcmlnaW5hbCBNQUMgDQogIGFkZHJl c3NlcyBhbmQgdGhlIEhDMSBhbmQgSEMyPEJSPmVuY29kaW5nIGhlYWRlcnMgd2lsbCBiZSBsb3N0 IGFuZCB0aGUgDQogIHJlY2lwaWVudCB3b3VsZCBoYXZlIG5vIGFiaWxpdHkgdG88QlI+cmVjb25z dHJ1Y3QgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugbm9yIA0KICBjb21wdXRlIHRoZSBwcm9wZXIgY2hl Y2tzdW0uJm5ic3A7Jm5ic3A7PEJSPjxCUj5UaGUgSUNNUHY2IG1lc3NhZ2UgaXRzZWxmIGlzIA0K ICBjYXJyaWVkIGluc2lkZSBhbmQgSVB2NiBwYWNrZXQgYW5kIHRoaXM8QlI+cGFja2V0IG1heSBi ZSB0cmFuc21pdHRlZCBvdmVyIHRoZSANCiAgNkxvV1BBTiBuZXR3b3JrIHV0aWxpemluZyBoZWFk ZXI8QlI+Y29tcHJlc3Npb24uJm5ic3A7Jm5ic3A7SUNNUHY2IG1lc3NhZ2VzIA0KICB0aGF0IGFy ZSBsYXJnZXIgdGhhbiB0aGUgYXZhaWxhYmxlIHBheWxvYWQ8QlI+b2YgdGhlIDZMb1dQQU4gbmV0 d29yayB3aWxsIG5lZWQgDQogIHRvIGJlIGZyYWdtZW50ZWQuIEFzc3VtaW5nIHRoZSBtYXhpbXVt PEJSPmZyYW1lIG92ZXJoZWFkLCBtYXhpbXVtIGxpbmsgbGF5ZXIgDQogIHNlY3VyaXR5IGFuZCBp bmNsdWRpbmcgYSA2TG9XUEFOIE1lc2g8QlI+SGVhZGVyLCBGcmFnbWVudGF0aW9uIEhlYWRlciBh bmQgDQogIERpc3BhdGNoIEhlYWRlciwgc2VuZGluZyB0aGU8QlI+dW5jb21wcmVzc2VkIElQdjYg YW5kIHRyYW5zcG9ydCBoZWFkZXJzIHNob3VsZCANCiAgc3RpbGwgYWxsb3cgZm9yIDI1IG9jdGV0 czxCUj5vZiB0aGUgb3JpZ2luYWwgcGFja2V0IA0KICBwYXlsb2FkLiZuYnNwOyZuYnNwO1BhY2tl dHMgdXNpbmcgc2hvcnQgYWRkcmVzc2VzLCBubzxCUj5zZWN1cml0eSwgYW5kIGp1c3QgYSANCiAg NkxvV1BBTiBEaXNwYXRjaCBoZWFkZXIgd2lsbCBiZSBhYmxlIHRvIGNhcnJ5IDYxPEJSPm9jdGV0 cyBvZiB0aGUgb3JpZ2luYWwgDQogIHBhY2tldC48QlI+PEJSPiZuYnNwOyZuYnNwOzxCUj48QlI+ PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPjZs b3dwYW4gDQogIG1haWxpbmcgbGlzdDxCUj42bG93cGFuQGlldGYub3JnPEJSPjxBIA0KICBocmVm PSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuIiANCiAgdGFy Z2V0PV9ibGFuaz5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFu PC9BPjxCUj48L0RJVj48L0RJVj48QlI+PC9ESVY+PC9ESVY+DQogIDxQPg0KICA8SFI+DQoNCiAg PFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJS PjZsb3dwYW4gbWFpbGluZyANCiAgbGlzdDxCUj42bG93cGFuQGlldGYub3JnPEJSPmh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW48QlI+PC9CTE9DS1FVT1RFPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0018_01C73B18.78965340-- --===============1203447482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1203447482==-- From 6lowpan-bounces@ietf.org Thu Jan 18 03:02:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7SDj-0007EK-Jo; Thu, 18 Jan 2007 03:02:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7SDh-0007CM-WB for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:02:02 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7S8t-0005Bj-Nq for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 02:57:05 -0500 Received: from dev20.coslabs.com (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l0I7v2kp004268; Thu, 18 Jan 2007 00:57:03 -0700 (MST) Subject: Re: [6lowpan] Slight problem with format document From: Geoff Mulligan To: gabriel montenegro In-Reply-To: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> References: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 18 Jan 2007 00:57:00 -0700 Message-Id: <1169107020.6668.75.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Gabriel, If a node within a 6lowpan network receives a packet with a ttl of 1 won't it send back an icmp error message if it was supposed to forward the packet, either if you were routing between 6lowpan nodes or between 6lowpan networks. Also couldn't an intermediate node send back a "parameter problem" icmp message. And since these are being implemented on micro-controllers is it strictly true that the layer separation is completely observed. I could see someone implementing a stack where you would not waste the limited ram space to uncompress the ip header and that the ip layer would deal with and understand the compressed headers and in this case the transport header then might still be compressed. Additionally I think that it is necessary to clarify if the checksum is run over the compressed or uncompressed ip pseudo header. I think for sake of clarity one short section (I may have been wordy) isn't bad, unless it is just wrong. geoff On Wed, 2007-01-17 at 23:07 -0800, gabriel montenegro wrote: > Is this even necessary to be said? ICMP msgs will never be sent by > intermediate nodes > in a lowpan mesh, but only by the IPv6 end nodes as part of normal > IPv6 processing. > This processing takes place after the lowpan layer delivers packets to > the > IPv6 stack. So by the time the IPv6 stack gets the packet, it will > have been > decompressed. This is the same for lowpan header compression or any > other type > of header compression. > > So I wonder if the text below is needed. It would be needed if the > entity sending > back ICMP messages was the lowpan layer. Yes, it would see compressed > headers. > But the entity is the IPv6 stack, which does not see those compressed > headers. > > Comments? Am I missing something? > > -gabriel > > ----- Original Message ---- > From: Geoff Mulligan > To: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, January 17, 2007 10:36:52 PM > Subject: [6lowpan] Slight problem with format document > > While reviewing the format document I realized that we didn't describe > handling of ICMPv6 error messages. Since the 6lowpan headers may be > compressed it is necessary to uncompress the original IP and transport > headers before sending the ICMP error message. > > Here is my proposed text for a new section 12... > > 12. Handling ICMPv6 messages > > ICMPv6 (RFC2463) is used to report errors and carry IP layer > information > and functions such as diagnostics. There are two groups of ICMPv6 > messages: error messages and informational messages. Each message > consists of a type field (if the high order bit is 0 it is an error > message), a code and checksum field. These fields are followed by the > ICMPv6 message body. For ICMPv6 error messages (Type <128) the > message > body shall contain as much of the original (offending) IP message > without exceeded the minimum IPv6 MTU. > > As described in the preceding section (Header Compression), the > original > IPv6 and Transport (TCP or UDP) headers may be compressed via HC1 and > HC2 encoding. So that the destination node of an ICMPv6 error message > can properly process the message the source node must decompress the > IPv6 and transport headers before sending the ICMPv6 message. This is > necessary because the original MAC addresses and the HC1 and HC2 > encoding headers will be lost and the recipient would have no ability > to > reconstruct the original message nor compute the proper checksum. > > The ICMPv6 message itself is carried inside and IPv6 packet and this > packet may be transmitted over the 6LoWPAN network utilizing header > compression. ICMPv6 messages that are larger than the available > payload > of the 6LoWPAN network will need to be fragmented. Assuming the > maximum > frame overhead, maximum link layer security and including a 6LoWPAN > Mesh > Header, Fragmentation Header and Dispatch Header, sending the > uncompressed IPv6 and transport headers should still allow for 25 > octets > of the original packet payload. Packets using short addresses, no > security, and just a 6LoWPAN Dispatch header will be able to carry 61 > octets of the original packet. > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 03:05:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7SGy-0008EB-FV; Thu, 18 Jan 2007 03:05:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7SGx-0008E4-Bv for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:05:23 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7SGw-0006Xv-W3 for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:05:23 -0500 Received: by an-out-0708.google.com with SMTP id c18so47825anc for <6lowpan@lists.ietf.org>; Thu, 18 Jan 2007 00:05:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mOEhsl3Z4pakTCBiG4wJ2jta6bEfl6/bCQ0S/M2tOuqjhztLMiz6jOZbUe5SIZQWwVtgpwiY8zeHwb+bFz08YQiiqBKnLx0y/1sPdFcGKxgP0zdeNgNRqCPdHrkLtkpV+AcTb7sJ2LMcu/b4Cs8xrL/soFS+5UAcGsZhcAmLNvA= Received: by 10.100.5.17 with SMTP id 17mr161934ane.1169107522607; Thu, 18 Jan 2007 00:05:22 -0800 (PST) Received: by 10.100.13.14 with HTTP; Thu, 18 Jan 2007 00:05:22 -0800 (PST) Message-ID: Date: Thu, 18 Jan 2007 17:05:22 +0900 From: "Daniel Park" To: "Mario Mao" Subject: Re: [6lowpan] Slight problem with format document In-Reply-To: <001b01c73ad5$7585da60$7fc0a8c0@netlab.cs.ecnu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> <001b01c73ad5$7585da60$7fc0a8c0@netlab.cs.ecnu.edu.cn> X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org It seems a bit implementation issue. Our format document defines four classes: [1] Prefix In-line IID In-line [2] Prefix In-line IID compressed [3] Prefix compressed IID In-line [4] Prefix compressed IID compressed Most assumtion in our scenario as of today is [4]. It means IPv6 source and destination belong to link-local scope. In your assumtion, perhaps, [1] and [2] are appropriate. In that sense, 6lowpan adoptation layer seems not meaningful. Also, 6lowpan header compression is only applied for 802.15.4 link due to the tiny bandwidth. Daniel On 1/18/07, Mario Mao wrote: > > I agree with gabriel, there is no interference between header compression > and ICMP. However, I believe two points should be noted which may cause > information loss. > > 1. If the processing node is lowpan gateway/router and the sent packet comes > from Internet but not originates by the gateway/router itself, the IID of IP > source address shouldn't be compressed. > 2. If the IP destination isn't an "on-link" node (that means the destination > is more than one hop away from source node), the IID of IP destination > address shouldn't be compressed. > > In a word, 6lowpan node could only compress the IID that derives from IEEE > 802.15.4 MAC address. I think that point should be emphasized in draft, > isn't it? > > Regards, > > Mario > > > ----- Original Message ----- > From: gabriel montenegro > To: Geoff Mulligan ; 6lowpan > Sent: Thursday, January 18, 2007 3:07 PM > Subject: Re: [6lowpan] Slight problem with format document > > > Is this even necessary to be said? ICMP msgs will never be sent by > intermediate nodes > in a lowpan mesh, but only by the IPv6 end nodes as part of normal IPv6 > processing. > This processing takes place after the lowpan layer delivers packets to the > IPv6 stack. So by the time the IPv6 stack gets the packet, it will have been > decompressed. This is the same for lowpan header compression or any other > type > of header compression. > > So I wonder if the text below is needed. It would be needed if the entity > sending > back ICMP messages was the lowpan layer. Yes, it would see compressed > headers. > But the entity is the IPv6 stack, which does not see those compressed > headers. > > Comments? Am I missing something? > > -gabriel > > ----- Original Message ---- > From: Geoff Mulligan > To: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, January 17, 2007 10:36:52 PM > Subject: [6lowpan] Slight problem with format document > > While reviewing the format document I realized that we didn't describe > handling of ICMPv6 error messages. Since the 6lowpan headers may be > compressed it is necessary to uncompress the original IP and transport > headers before sending the ICMP error message. > > Here is my proposed text for a new section 12... > > 12. Handling ICMPv6 messages > > ICMPv6 (RFC2463) is used to report errors and carry IP layer information > and functions such as diagnostics. There are two groups of ICMPv6 > messages: error messages and informational messages. Each message > consists of a type field (if the high order bit is 0 it is an error > message), a code and checksum field. These fields are followed by the > ICMPv6 message body. For ICMPv6 error messages (Type <128) the message > body shall contain as much of the original (offending) IP message > without exceeded the minimum IPv6 MTU. > > As described in the preceding section (Header Compression), the original > IPv6 and Transport (TCP or UDP) headers may be compressed via HC1 and > HC2 encoding. So that the destination node of an ICMPv6 error message > can properly process the message the source node must decompress the > IPv6 and transport headers before sending the ICMPv6 message. This is > necessary because the original MAC addresses and the HC1 and HC2 > encoding headers will be lost and the recipient would have no ability to > reconstruct the original message nor compute the proper checksum. > > The ICMPv6 message itself is carried inside and IPv6 packet and this > packet may be transmitted over the 6LoWPAN network utilizing header > compression. ICMPv6 messages that are larger than the available payload > of the 6LoWPAN network will need to be fragmented. Assuming the maximum > frame overhead, maximum link layer security and including a 6LoWPAN Mesh > Header, Fragmentation Header and Dispatch Header, sending the > uncompressed IPv6 and transport headers should still allow for 25 octets > of the original packet payload. Packets using short addresses, no > security, and just a 6LoWPAN Dispatch header will be able to carry 61 > octets of the original packet. > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > ________________________________ > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > -- Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 03:42:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Sr1-0005yW-Sm; Thu, 18 Jan 2007 03:42:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Sr0-0005yO-O8 for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:42:38 -0500 Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Sr0-0002o9-2E for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:42:38 -0500 Received: (qmail 55715 invoked by uid 60001); 18 Jan 2007 08:42:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=TQjHHIonzuVxuHy/ds0Ql7cdoANVIQDOf2pUbywZbgzPW5LNjlgZoGbOwZK8mTD/LNznpzcOwLrC115QcjWBXcIkD8l3ypOprKMfAy89qcMSdZEK8rnm2ICeTd5+UGuIIT4x+4oCtnsqlzeHkcgE3SrYf0PftMOtzUv+R2xs4Bw= ; Message-ID: <20070118084237.55713.qmail@web81910.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81910.mail.mud.yahoo.com via HTTP; Thu, 18 Jan 2007 00:42:37 PST Date: Thu, 18 Jan 2007 00:42:37 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] Slight problem with format document To: Mario Mao , Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0101021204==" Errors-To: 6lowpan-bounces@ietf.org --===============0101021204== Content-Type: multipart/alternative; boundary="0-1127534974-1169109757=:51252" --0-1127534974-1169109757=:51252 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Comment on this:=0A=0A"In a word, 6lowpan node could only compress =0A=0Ath= e IID that derives from IEEE 802.15.4 MAC address. I think that point shoul= d =0A=0Abe emphasized in draft, isn't it?"=0A=0AI think this draft talking = about IPv6 over 802.15.4, "link-layer" refers to the underlying 802.15.4 li= nk-layer, so the point above=0Aseems superfluous.=0A=0AOk, in the interest = of clarifying, I've tentatively changed this in section 10.1:=0A=0A the I= Pv6=0A bottom 64 bits can be inferred from the layer two source and=0A = destinationto this:=0A=0A the IPv6 interface identifiers =0A (bottom= 64 bits) for the source or destination addresses can be=0A inferred fr= om the layer two source and destination addresses (of course, =0A this i= s only possible for interface identifiers derived=0A from an underlying = 802.15.4 MAC address)=0A=0ADoes this work?=0A=0A-gabriel=0A=0A----- Origina= l Message ----=0AFrom: Mario Mao =0ATo: gabriel montene= gro ; Geoff Mulligan ; 6lowpan <6lowpan@lists.ietf.org>=0ASent: Wednesday, January 17, 2007 11:= 51:09 PM=0ASubject: Re: [6lowpan] Slight problem with format document=0A=0A= =0A=0A=0A=0A =0A=0ADIV {=0AMARGIN:0px;}=0A=0A=0A=0A=0A=0A=0AI agree with ga= briel, there is no interference =0A=0Abetween header compression and ICMP. = However, I believe two points should be =0A=0Anoted which may cause informa= tion loss.=0A=0A=0A =0A=0A=0A1. If the processing node is lowpan gateway/ro= uter =0A=0Aand the sent packet comes from Internet but not originates by th= e gateway/router =0A=0Aitself, the IID of IP source address shouldn't be co= mpressed.=0A=0A=0A2. If the IP destination isn't an "on-link" node =0A=0A(t= hat means the destination is more than one hop away from source node), the = IID =0A=0Aof IP destination address shouldn't be compressed.=0A=0A=0A =0A= =0A=0AIn a word, 6lowpan node could only compress =0A=0Athe IID that derive= s from IEEE 802.15.4 MAC address. I think that point should =0A=0Abe emphas= ized in draft, isn't it?=0A=0A=0A =0A=0A=0ARegards,=0A=0A=0A =0A=0A=0AMario= =0A=0A=0A =0A=0A=0A=0A=0A ----- Original Message ----- =0A=0A=0A From: = =0A=0A gabriel montenegro =0A=0A=0A To: Geoff Mulligan ; 6lowpan =0A=0A = =0A=0A=0A Sent: Thursday, January 18, 2007 3:07 =0A=0APM=0A=0A=0A Subject= : Re: [6lowpan] Slight problem with =0A=0A format document=0A=0A=0A =0A= =0A=0A=0A =0A=0A Is =0A=0A this even necessary to be said? ICMP msgs wil= l never be sent by intermediate =0A=0A nodes=0Ain a lowpan mesh, but only = by the IPv6 end nodes as part of normal =0A=0A IPv6 processing.=0AThis pro= cessing takes place after the lowpan layer =0A=0A delivers packets to the= =0AIPv6 stack. So by the time the IPv6 stack gets the =0A=0A packet, it wi= ll have been=0Adecompressed. This is the same for lowpan header =0A=0A com= pression or any other type=0Aof header compression.=0A=0ASo I wonder if =0A= =0A the text below is needed. It would be needed if the entity sending=0Ab= ack =0A=0A ICMP messages was the lowpan layer. Yes, it would see compresse= d =0A=0A headers.=0ABut the entity is the IPv6 stack, which does not see t= hose =0A=0A compressed headers.=0A=0AComments? Am I missing =0A=0A someth= ing?=0A=0A-gabriel=0A=0A=0A=0A ----- =0A=0A Original Message ----=0AFrom:= Geoff Mulligan =0A=0A =0ATo: 6lowpan =0A=0A <6lowpan= @lists.ietf.org>=0ASent: Wednesday, January 17, 2007 10:36:52 =0A=0A PM=0A= Subject: [6lowpan] Slight problem with format document=0A=0A=0A=0A While r= eviewing the format document I realized that we didn't =0A=0A describe=0Ah= andling of ICMPv6 error messages. Since the 6lowpan =0A=0A headers may be= =0Acompressed it is necessary to uncompress the original IP and =0A=0A tra= nsport=0Aheaders before sending the ICMP error message.=0A=0AHere is my =0A= =0A proposed text for a new section 12...=0A=0A12. Handling ICMPv6 =0A=0A = messages=0A=0AICMPv6 (RFC2463) is used to report errors and carry IP layer= =0A=0A information=0Aand functions such as diagnostics. There are two = =0A=0A groups of ICMPv6=0Amessages: error messages and informational messa= ges. Each =0A=0A message=0Aconsists of a type field (if the high order bit= is 0 it is an =0A=0A error=0Amessage), a code and checksum field. These = fields are =0A=0A followed by the=0AICMPv6 message body. For ICMPv6 error= messages =0A=0A (Type <128) the message=0Abody shall contain as much of t= he original =0A=0A (offending) IP message=0Awithout exceeded the minimum I= Pv6 =0A=0A MTU. =0A=0AAs described in the preceding section (Header =0A= =0A Compression), the original=0AIPv6 and Transport (TCP or UDP) headers m= ay be =0A=0A compressed via HC1 and=0AHC2 encoding. So that the destinati= on =0A=0A node of an ICMPv6 error message=0Acan properly process the messa= ge the source =0A=0A node must decompress the=0AIPv6 and transport headers= before sending the =0A=0A ICMPv6 message. This is=0Anecessary because th= e original MAC =0A=0A addresses and the HC1 and HC2=0Aencoding headers wil= l be lost and the =0A=0A recipient would have no ability to=0Areconstruct = the original message nor =0A=0A compute the proper checksum. =0A=0AThe IC= MPv6 message itself is =0A=0A carried inside and IPv6 packet and this=0Apa= cket may be transmitted over the =0A=0A 6LoWPAN network utilizing header= =0Acompression. ICMPv6 messages =0A=0A that are larger than the available= payload=0Aof the 6LoWPAN network will need =0A=0A to be fragmented. Assum= ing the maximum=0Aframe overhead, maximum link layer =0A=0A security and i= ncluding a 6LoWPAN Mesh=0AHeader, Fragmentation Header and =0A=0A Dispatch= Header, sending the=0Auncompressed IPv6 and transport headers should =0A= =0A still allow for 25 octets=0Aof the original packet =0A=0A payload. P= ackets using short addresses, no=0Asecurity, and just a =0A=0A 6LoWPAN Dis= patch header will be able to carry 61=0Aoctets of the original =0A=0A pack= et.=0A=0A =0A=0A=0A_______________________________________________=0A6lowp= an =0A=0A mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/= listinfo/6lowpan=0A=0A=0A=0A=0A=0A=0A=0A =0A=0A =0A=0A=0A=0A=0A =0A_____= __________________________________________=0A6lowpan mailing =0A=0A list= =0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan=0A=0A= =0A=0A --0-1127534974-1169109757=:51252 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Comment on this:

"In a word, 6lowpan node could only compress =0A=0Athe IID that der= ives from IEEE 802.15.4 MAC address. I think that point should =0A=0Abe emp= hasized in draft, isn't it?"

I think this draft talking about IPv6 o= ver 802.15.4, "link-layer" refers to the underlying 802.15.4 link-layer, so= the point above
seems superfluous.

Ok, in the interest of clarif= ying, I've tentatively changed this in section 10.1:

   =
the IPv6
   bottom 64 bits can be inferred from the layer two source and=

   destination
to this:

     the IPv6 i= nterface identifiers
    (bottom 64 bits) for the source= or destination addresses can be
     inferred from = the layer two source and destination addresses (of course,
  =   this is only possible for interface identifiers derived
 &nb= sp;  from an underlying 802.15.4 MAC address)

Does this work?
-gabriel

----- = Original Message ----
From: Mario Mao <mariomao@gmail.com>
To: gabriel = montenegro <gabriel_montenegro_2000@yahoo.com>; Geoff Mulligan <ge= off@mulligan.com>; 6lowpan <6lowpan@lists.ietf.org>
Sent: Wedne= sday, January 17, 2007 11:51:09 PM
Subject: Re: [6lowpan] Slight problem= with format document

=0A=0A=0A=0A =0A=0A=0A=0A=0A=0A=0A=0A
I agree with gabriel, there is no interference =0A=0Abetween heade= r compression and ICMP. However, I believe two points should be =0A=0Anoted= which may cause information loss.
=0A=0A
 
=0A=0A
1. If the processing node is lowpan gateway/router =0A=0Aand the sent pac= ket comes from Internet but not originates by the gateway/router =0A=0Aitse= lf, the IID of IP source address shouldn't be compressed.
=0A= =0A
2. If the IP destination isn't an "= on-link" node =0A=0A(that means the destination is more than one hop away f= rom source node), the IID =0A=0Aof IP destination address shouldn't be comp= ressed.
=0A=0A
 = ;
=0A=0A
In a word, 6lowpan node c= ould only compress =0A=0Athe IID that derives from IEEE 802.15.4 MAC a= ddress. I think that point should =0A=0Abe emphasized in draft, isn't it?
=0A=0A
 
= =0A=0A
Regards,
=0A=0A
=  
=0A=0A
Mario
=0A=0A
 
=0A=0A
=0A=0A
----- Original Message ----- =0A=0A
From: =0A=0A gabriel montenegro <= /div>=0A=0A = =0A=0A
Sent: Thursday, January 18, 2007 3:07 =0A=0A= PM
=0A=0A
Subject: Re: [6lowpan] Slight proble= m with =0A=0A format document
=0A=0A

=0A=0A
= =0A=0A
Is =0A=0A this even necessary to be said? ICMP msgs will ne= ver be sent by intermediate =0A=0A nodes
in a lowpan mesh, but only by = the IPv6 end nodes as part of normal =0A=0A IPv6 processing.
This proce= ssing takes place after the lowpan layer =0A=0A delivers packets to theIPv6 stack. So by the time the IPv6 stack gets the =0A=0A packet, it will= have been
decompressed. This is the same for lowpan header =0A=0A comp= ression or any other type
of header compression.

So I wonder if = =0A=0A the text below is needed. It would be needed if the entity sending<= br>back =0A=0A ICMP messages was the lowpan layer. Yes, it would see compr= essed =0A=0A headers.
But the entity is the IPv6 stack, which does not = see those =0A=0A compressed headers.

Comments? Am I missing =0A=0A = something?

-gabriel

=0A=0A
----- =0A=0A Original M= essage ----
From: Geoff Mulligan =0A=0A <geoff@mulligan.com>
T= o: 6lowpan =0A=0A <6lowpan@lists.ietf.org>
Sent: Wednesday, Janua= ry 17, 2007 10:36:52 =0A=0A PM
Subject: [6lowpan] Slight problem with f= ormat document

=0A=0A
While reviewing the format document I re= alized that we didn't =0A=0A describe
handling of ICMPv6 error messages= .  Since the 6lowpan =0A=0A headers may be
compressed it is n= ecessary to uncompress the original IP and =0A=0A transport
headers bef= ore sending the ICMP error message.

Here is my =0A=0A proposed text= for a new section 12...

12. Handling ICMPv6 =0A=0A messages
ICMPv6 (RFC2463) is used to report errors and carry IP layer =0A=0A infor= mation
and functions such as diagnostics.  There are two =0A= =0A groups of ICMPv6
messages: error messages and informational message= s. Each =0A=0A message
consists of a type field (if the high order bit = is 0 it is an =0A=0A error
message), a code and checksum field. &n= bsp;These fields are =0A=0A followed by the
ICMPv6 message body. &= nbsp;For ICMPv6 error messages =0A=0A (Type <128) the message
body s= hall contain as much of the original =0A=0A (offending) IP message
with= out exceeded the minimum IPv6 =0A=0A MTU.  

As described = in the preceding section (Header =0A=0A Compression), the original
IPv6= and Transport (TCP or UDP) headers may be =0A=0A compressed via HC1 andHC2 encoding.  So that the destination =0A=0A node of an ICMPv= 6 error message
can properly process the message the source =0A=0A node= must decompress the
IPv6 and transport headers before sending the =0A= =0A ICMPv6 message.  This is
necessary because the original M= AC =0A=0A addresses and the HC1 and HC2
encoding headers will be lost a= nd the =0A=0A recipient would have no ability to
reconstruct the origin= al message nor =0A=0A compute the proper checksum.  

The = ICMPv6 message itself is =0A=0A carried inside and IPv6 packet and thispacket may be transmitted over the =0A=0A 6LoWPAN network utilizing heade= r
compression.  ICMPv6 messages =0A=0A that are larger than t= he available payload
of the 6LoWPAN network will need =0A=0A to be frag= mented. Assuming the maximum
frame overhead, maximum link layer =0A=0A = security and including a 6LoWPAN Mesh
Header, Fragmentation Header and = =0A=0A Dispatch Header, sending the
uncompressed IPv6 and transport hea= ders should =0A=0A still allow for 25 octets
of the original packet =0A= =0A payload.  Packets using short addresses, no
security, and= just a =0A=0A 6LoWPAN Dispatch header will be able to carry 61
octets = of the original =0A=0A packet.

  


____________= ___________________________________
6lowpan =0A=0A mailing list
6low= pan@ietf.org
https://www1.ietf.org/mailman/listinfo/6= lowpan

=0A=0A

=0A=0A

=0A=0A=0A=0A

_________________________________= ______________
6lowpan mailing =0A=0A list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-1127534974-1169109757=:51252-- --===============0101021204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0101021204==-- From 6lowpan-bounces@ietf.org Thu Jan 18 04:00:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7T8O-0000VM-A1; Thu, 18 Jan 2007 04:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7T8M-0000UW-Uk for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:00:34 -0500 Received: from web81904.mail.mud.yahoo.com ([68.142.207.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7T8L-0005dO-5H for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:00:34 -0500 Received: (qmail 75008 invoked by uid 60001); 18 Jan 2007 09:00:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=VhiM+PzlmvW46mQz1xneax7/hNxvl1joSIYbsXinRArcEyXHcUHYReqWPDtkgfb4F4ZSwz+lhIIJa/rSrUbeJxS6PJKKk3Ab50PyBV0VrJF1bu5wjDOHTajW81Nc0TgOYGBz9J7E9POYxjmy0aNSuqEfyFKlYpeUq+4B2NTG8fk= ; Message-ID: <20070118090032.75006.qmail@web81904.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81904.mail.mud.yahoo.com via HTTP; Thu, 18 Jan 2007 01:00:32 PST Date: Thu, 18 Jan 2007 01:00:32 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] Slight problem with format document To: Geoff Mulligan MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1076481050==" Errors-To: 6lowpan-bounces@ietf.org --===============1076481050== Content-Type: multipart/alternative; boundary="0-1677501358-1169110832=:72910" --0-1677501358-1169110832=:72910 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable TTL (rather "Hop Count") of 1? Sure. The IPv6 layer handles that, not lowpa= n.=0AIntermediate? No. ICMP is an IPv6 function. Intermediate nodes (as in = a lowpan mesh)=0Amust not interfere with this. Now, if we wanted to define = a lowpan layer error=0Anotification mechanism (analogous to ICMP at the IP = layer), we could. But that's=0Anot ICMP, and I'd argue that we should defin= e that in a separate draft later on=0A(perhaps as part of forthcoming mesh = routing specifications).=0A=0ASure, layering may be relaxed for optimizatio= n reasons. But this is nothing=0Anew: it's done today in optimized implemen= tation regardless of lowpan. Still,=0Athe conceptual model holds, so those = are implementation details we shouldn't=0Abe concerned about in this partic= ular document. =0A=0A-gabriel=0A=0A----- Original Message ----=0AFrom: Geof= f Mulligan =0ATo: gabriel montenegro =0ACc: 6lowpan <6lowpan@lists.ietf.org>=0ASent: Wednesday,= January 17, 2007 11:57:00 PM=0ASubject: Re: [6lowpan] Slight problem with = format document=0A=0AGabriel,=0A If a node within a 6lowpan network receiv= es a packet with a ttl of 1=0Awon't it send back an icmp error message if i= t was supposed to forward=0Athe packet, either if you were routing between = 6lowpan nodes or between=0A6lowpan networks. Also couldn't an intermediate = node send back a=0A"parameter problem" icmp message.=0A=0A And since these= are being implemented on micro-controllers is it=0Astrictly true that the = layer separation is completely observed. I could=0Asee someone implementin= g a stack where you would not waste the limited=0Aram space to uncompress t= he ip header and that the ip layer would deal=0Awith and understand the com= pressed headers and in this case the=0Atransport header then might still be= compressed.=0A=0AAdditionally I think that it is necessary to clarify if t= he checksum is=0Arun over the compressed or uncompressed ip pseudo header.= =0A=0AI think for sake of clarity one short section (I may have been wordy)= =0Aisn't bad, unless it is just wrong.=0A=0A geoff=0A=0A=0A=0AOn Wed, 20= 07-01-17 at 23:07 -0800, gabriel montenegro wrote:=0A> Is this even necessa= ry to be said? ICMP msgs will never be sent by=0A> intermediate nodes=0A> i= n a lowpan mesh, but only by the IPv6 end nodes as part of normal=0A> IPv6 = processing.=0A> This processing takes place after the lowpan layer delivers= packets to=0A> the=0A> IPv6 stack. So by the time the IPv6 stack gets the = packet, it will=0A> have been=0A> decompressed. This is the same for lowpan= header compression or any=0A> other type=0A> of header compression.=0A> = =0A> So I wonder if the text below is needed. It would be needed if the=0A>= entity sending=0A> back ICMP messages was the lowpan layer. Yes, it would = see compressed=0A> headers.=0A> But the entity is the IPv6 stack, which doe= s not see those compressed=0A> headers.=0A> =0A> Comments? Am I missing som= ething?=0A> =0A> -gabriel=0A> =0A> ----- Original Message ----=0A> From: Ge= off Mulligan =0A> To: 6lowpan <6lowpan@lists.ietf.org>= =0A> Sent: Wednesday, January 17, 2007 10:36:52 PM=0A> Subject: [6lowpan] S= light problem with format document=0A> =0A> While reviewing the format docu= ment I realized that we didn't describe=0A> handling of ICMPv6 error messag= es. Since the 6lowpan headers may be=0A> compressed it is necessary to unc= ompress the original IP and transport=0A> headers before sending the ICMP e= rror message.=0A> =0A> Here is my proposed text for a new section 12...=0A>= =0A> 12. Handling ICMPv6 messages=0A> =0A> ICMPv6 (RFC2463) is used to rep= ort errors and carry IP layer=0A> information=0A> and functions such as dia= gnostics. There are two groups of ICMPv6=0A> messages: error messages and = informational messages. Each message=0A> consists of a type field (if the h= igh order bit is 0 it is an error=0A> message), a code and checksum field. = These fields are followed by the=0A> ICMPv6 message body. For ICMPv6 erro= r messages (Type <128) the=0A> message=0A> body shall contain as much of th= e original (offending) IP message=0A> without exceeded the minimum IPv6 MTU= . =0A> =0A> As described in the preceding section (Header Compression), th= e=0A> original=0A> IPv6 and Transport (TCP or UDP) headers may be compresse= d via HC1 and=0A> HC2 encoding. So that the destination node of an ICMPv6 = error message=0A> can properly process the message the source node must dec= ompress the=0A> IPv6 and transport headers before sending the ICMPv6 messag= e. This is=0A> necessary because the original MAC addresses and the HC1 an= d HC2=0A> encoding headers will be lost and the recipient would have no abi= lity=0A> to=0A> reconstruct the original message nor compute the proper che= cksum. =0A> =0A> The ICMPv6 message itself is carried inside and IPv6 pack= et and this=0A> packet may be transmitted over the 6LoWPAN network utilizin= g header=0A> compression. ICMPv6 messages that are larger than the availab= le=0A> payload=0A> of the 6LoWPAN network will need to be fragmented. Assum= ing the=0A> maximum=0A> frame overhead, maximum link layer security and inc= luding a 6LoWPAN=0A> Mesh=0A> Header, Fragmentation Header and Dispatch Hea= der, sending the=0A> uncompressed IPv6 and transport headers should still a= llow for 25=0A> octets=0A> of the original packet payload. Packets using s= hort addresses, no=0A> security, and just a 6LoWPAN Dispatch header will be= able to carry 61=0A> octets of the original packet.=0A> =0A> =0A> =0A> = =0A> _______________________________________________=0A> 6lowpan mailing li= st=0A> 6lowpan@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/6lowpan= =0A> =0A> =0A> =0A=0A=0A=0A=0A=0A --0-1677501358-1169110832=:72910 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
TTL (rather "Hop Count") of 1? Sure. The IPv6 layer h= andles that, not lowpan.
Intermediate? No. ICMP is an IPv6 function. Int= ermediate nodes (as in a lowpan mesh)
must not interfere with this. Now,= if we wanted to define a lowpan layer error
notification mechanism (ana= logous to ICMP at the IP layer), we could. But that's
not ICMP, and I'd = argue that we should define that in a separate draft later on
(perhaps a= s part of forthcoming mesh routing specifications).

Sure, layering m= ay be relaxed for optimization reasons. But this is nothing
new: it's do= ne today in optimized implementation regardless of lowpan. Still,
the co= nceptual model holds, so those are implementation details we shouldn't
b= e concerned about in this particular document.

-gabriel

----- Origina= l Message ----
From: Geoff Mulligan <geoff@mulligan.com>
To: ga= briel montenegro <gabriel_montenegro_2000@yahoo.com>
Cc: 6lowpan &= lt;6lowpan@lists.ietf.org>
Sent: Wednesday, January 17, 2007 11:57:00= PM
Subject: Re: [6lowpan] Slight problem with format document

Gabriel,
  If a node within a 6lowpan network receives a pa= cket with a ttl of 1
won't it send back an icmp error message if it was = supposed to forward
the packet, either if you were routing between 6lowp= an nodes or between
6lowpan networks. Also couldn't an intermediate node= send back a
"parameter problem" icmp message.

  And si= nce these are being implemented on micro-controllers is it
strictly true= that the layer separation is completely observed.  I could
se= e someone implementing a stack where you would not waste the limited
ram space to= uncompress the ip header and that the ip layer would deal
with and unde= rstand the compressed headers and in this case the
transport header then= might still be compressed.

Additionally I think that it is necessar= y to clarify if the checksum is
run over the compressed or uncompressed = ip pseudo header.

I think for sake of clarity one short section (I m= ay have been wordy)
isn't bad, unless it is just wrong.

 &nb= sp;  geoff



On Wed, 2007-01-17 at 23:07 -0800, gabr= iel montenegro wrote:
> Is this even necessary to be said? ICMP msgs = will never be sent by
> intermediate nodes
> in a lowpan mesh, = but only by the IPv6 end nodes as part of normal
> IPv6 processing.> This processing takes place after the lowpan layer delivers packets = to
> the
> IPv6 stack. So by the time the IPv6 stack gets the p= acket, it will
> have been
> decompressed. This is the same for lowpan h= eader compression or any
> other type
> of header compression.<= br>>
> So I wonder if the text below is needed. It would be neede= d if the
> entity sending
> back ICMP messages was the lowpan l= ayer. Yes, it would see compressed
> headers.
> But the entity = is the IPv6 stack, which does not see those compressed
> headers.
= >
> Comments? Am I missing something?
>
> -gabriel>
> ----- Original Message ----
> From: Geoff Mulligan &l= t;geoff@mulligan.com>
> To: 6lowpan <6lowpan@lists.ietf.org>=
> Sent: Wednesday, January 17, 2007 10:36:52 PM
> Subject: [6l= owpan] Slight problem with format document
>
> While reviewing= the format document I realized that we didn't describe
> handling of= ICMPv6 error messages.  Since the 6lowpan headers may be
>= compressed it is necessary to uncompress the original IP and transport
> header= s before sending the ICMP error message.
>
> Here is my propos= ed text for a new section 12...
>
> 12. Handling ICMPv6 messag= es
>
> ICMPv6 (RFC2463) is used to report errors and carry IP = layer
> information
> and functions such as diagnostics. &= nbsp;There are two groups of ICMPv6
> messages: error messages and in= formational messages. Each message
> consists of a type field (if the= high order bit is 0 it is an error
> message), a code and checksum f= ield.  These fields are followed by the
> ICMPv6 message bo= dy.  For ICMPv6 error messages (Type <128) the
> message=
> body shall contain as much of the original (offending) IP message<= br>> without exceeded the minimum IPv6 MTU.  
>
>= As described in the preceding section (Header Compression), the
> original
> IPv6 and Transport (TCP or UDP) headers may be compressed= via HC1 and
> HC2 encoding.  So that the destination node = of an ICMPv6 error message
> can properly process the message the sou= rce node must decompress the
> IPv6 and transport headers before send= ing the ICMPv6 message.  This is
> necessary because the or= iginal MAC addresses and the HC1 and HC2
> encoding headers will be l= ost and the recipient would have no ability
> to
> reconstruct = the original message nor compute the proper checksum.  
> <= br>> The ICMPv6 message itself is carried inside and IPv6 packet and thi= s
> packet may be transmitted over the 6LoWPAN network utilizing head= er
> compression.  ICMPv6 messages that are larger than the= available
> payload
> of the 6LoWPAN network will need to be f= ragmented. Assuming the
> maximum
> frame overhead, maximum lin= k layer security and including a 6LoWPAN
> Mesh
> Header, Fragmentatio= n Header and Dispatch Header, sending the
> uncompressed IPv6 and tra= nsport headers should still allow for 25
> octets
> of the orig= inal packet payload.  Packets using short addresses, no
> s= ecurity, and just a 6LoWPAN Dispatch header will be able to carry 61
>= ; octets of the original packet.
>
>  
>
= >
> _______________________________________________
> 6lowp= an mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/m= ailman/listinfo/6lowpan
>
>
>

<= br>
--0-1677501358-1169110832=:72910-- --===============1076481050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1076481050==-- From 6lowpan-bounces@ietf.org Thu Jan 18 04:37:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Thc-0004N3-SM; Thu, 18 Jan 2007 04:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Tha-0004Mw-Pz for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:36:59 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ThZ-0001ri-9s for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:36:58 -0500 Received: from dev20.coslabs.com (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l0I9aqcW004787; Thu, 18 Jan 2007 02:36:52 -0700 (MST) Subject: Re: [6lowpan] Slight problem with format document From: Geoff Mulligan To: gabriel montenegro In-Reply-To: <20070118084237.55713.qmail@web81910.mail.mud.yahoo.com> References: <20070118084237.55713.qmail@web81910.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 18 Jan 2007 02:36:50 -0700 Message-Id: <1169113011.6668.120.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Mario Mao , 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I think that is does clarify the point about deriving addresses, but i still feel we need some sort of comment on dealing with icmp messages. I'd like to hear from others. Also do we feel that we have reached consensus on the issue of header ordering? geoff On Thu, 2007-01-18 at 00:42 -0800, gabriel montenegro wrote: > Comment on this: > > "In a word, 6lowpan node could only compress the IID that derives from > IEEE 802.15.4 MAC address. I think that point should be emphasized in > draft, isn't it?" > > I think this draft talking about IPv6 over 802.15.4, "link-layer" > refers to the underlying 802.15.4 link-layer, so the point above > seems superfluous. > > Ok, in the interest of clarifying, I've tentatively changed this in > section 10.1: > > the IPv6 > bottom 64 bits can be inferred from the layer two source and > destination > to this: > > the IPv6 interface identifiers > (bottom 64 bits) for the source or destination addresses can be > inferred from the layer two source and destination addresses (of > course, > this is only possible for interface identifiers derived > from an underlying 802.15.4 MAC address) > > Does this work? > > -gabriel > > ----- Original Message ---- > From: Mario Mao > To: gabriel montenegro ; Geoff > Mulligan ; 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, January 17, 2007 11:51:09 PM > Subject: Re: [6lowpan] Slight problem with format document > > I agree with gabriel, there is no interference between header > compression and ICMP. However, I believe two points should be noted > which may cause information loss. > > 1. If the processing node is lowpan gateway/router and the sent packet > comes from Internet but not originates by the gateway/router itself, > the IID of IP source address shouldn't be compressed. > 2. If the IP destination isn't an "on-link" node (that means the > destination is more than one hop away from source node), the IID of IP > destination address shouldn't be compressed. > > In a word, 6lowpan node could only compress the IID that derives from > IEEE 802.15.4 MAC address. I think that point should be emphasized in > draft, isn't it? > > Regards, > > Mario > > ----- Original Message ----- > From: gabriel montenegro > To: Geoff Mulligan ; 6lowpan > Sent: Thursday, January 18, 2007 3:07 PM > Subject: Re: [6lowpan] Slight problem with format document > > > Is this even necessary to be said? ICMP msgs will never be > sent by intermediate nodes > in a lowpan mesh, but only by the IPv6 end nodes as part of > normal IPv6 processing. > This processing takes place after the lowpan layer delivers > packets to the > IPv6 stack. So by the time the IPv6 stack gets the packet, it > will have been > decompressed. This is the same for lowpan header compression > or any other type > of header compression. > > So I wonder if the text below is needed. It would be needed if > the entity sending > back ICMP messages was the lowpan layer. Yes, it would see > compressed headers. > But the entity is the IPv6 stack, which does not see those > compressed headers. > > Comments? Am I missing something? > > -gabriel > > ----- Original Message ---- > From: Geoff Mulligan > To: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, January 17, 2007 10:36:52 PM > Subject: [6lowpan] Slight problem with format document > > While reviewing the format document I realized that we didn't > describe > handling of ICMPv6 error messages. Since the 6lowpan headers > may be > compressed it is necessary to uncompress the original IP and > transport > headers before sending the ICMP error message. > > Here is my proposed text for a new section 12... > > 12. Handling ICMPv6 messages > > ICMPv6 (RFC2463) is used to report errors and carry IP layer > information > and functions such as diagnostics. There are two groups of > ICMPv6 > messages: error messages and informational messages. Each > message > consists of a type field (if the high order bit is 0 it is an > error > message), a code and checksum field. These fields are > followed by the > ICMPv6 message body. For ICMPv6 error messages (Type <128) > the message > body shall contain as much of the original (offending) IP > message > without exceeded the minimum IPv6 MTU. > > As described in the preceding section (Header Compression), > the original > IPv6 and Transport (TCP or UDP) headers may be compressed via > HC1 and > HC2 encoding. So that the destination node of an ICMPv6 error > message > can properly process the message the source node must > decompress the > IPv6 and transport headers before sending the ICMPv6 > message. This is > necessary because the original MAC addresses and the HC1 and > HC2 > encoding headers will be lost and the recipient would have no > ability to > reconstruct the original message nor compute the proper > checksum. > > The ICMPv6 message itself is carried inside and IPv6 packet > and this > packet may be transmitted over the 6LoWPAN network utilizing > header > compression. ICMPv6 messages that are larger than the > available payload > of the 6LoWPAN network will need to be fragmented. Assuming > the maximum > frame overhead, maximum link layer security and including a > 6LoWPAN Mesh > Header, Fragmentation Header and Dispatch Header, sending the > uncompressed IPv6 and transport headers should still allow for > 25 octets > of the original packet payload. Packets using short > addresses, no > security, and just a 6LoWPAN Dispatch header will be able to > carry 61 > octets of the original packet. > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 04:42:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Tn0-0001a6-EK; Thu, 18 Jan 2007 04:42:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Tmy-0001Zy-CA for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:42:32 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Tmw-00037Y-T8 for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:42:32 -0500 Received: by py-out-1112.google.com with SMTP id f31so66834pyh for <6lowpan@lists.ietf.org>; Thu, 18 Jan 2007 01:42:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:to:cc:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=C9QSi9JOphQXtwaLBOq6EfvUpUHcPotaMzSyirr9GEHyDEGMbC0/2p9T5YzMXeJELrFib3MKSUPx483KKcd0yjoeP0gmsAySMYySCHvfGG8g2fKUd9MRK8Xr8WK5gKWoTAoyA7y59Q6ULCw9wFx8cU77E1zu/Ebihltoi12XUmA= Received: by 10.35.134.19 with SMTP id l19mr1226143pyn.1169113350231; Thu, 18 Jan 2007 01:42:30 -0800 (PST) Received: from Maoer ( [211.144.102.58]) by mx.google.com with ESMTP id 38sm498038nzf.2007.01.18.01.42.23; Thu, 18 Jan 2007 01:42:29 -0800 (PST) Message-ID: <003301c73ae5$46b4e310$7fc0a8c0@netlab.cs.ecnu.edu.cn> To: "Daniel Park" References: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> <001b01c73ad5$7585da60$7fc0a8c0@netlab.cs.ecnu.edu.cn> Subject: Re: [6lowpan] Slight problem with format document Date: Thu, 18 Jan 2007 17:44:27 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 From: Mario Mao X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0672984389==" Errors-To: 6lowpan-bounces@ietf.org --===============0672984389== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 VG8gRGFuaWVsOg0KDQpUaGFua3MgZm9yIHlvdSB0aXBzLg0KDQpIb3dldmVyLCBJIGJlbGlldmUg dGhlIGNvbXByZXNzaW9uIGlzc3VlIGlzIG5vdCBqdXN0IGZvciBpbXBsZW1lbnRhdGlvbi4gVGhp bmtpbmcgYWJvdXQgdGhlIHJlYXNvbiB3aHkgd2UgbmVlZCB0byBidWlsZCBJUHY2IHVwcGVyICBs b3dwYW4gbm9kZSwgdGhlcmUgaXMgaGlnaCBwb3NzaWJpbGl0eSBvZiBnbG9iYWwgc2NvcGUgY3Vt bW5pY2F0aW9uLiBJbiB0aGlzIHNjZW5hcmlvLCBhbmQgY29uc2lkZXJpbmcgdGhlIGZvcm1hdCBk ZWZpbmF0aW9uLCB0aGUgY2xhc3MgWzFdIGFuZCBbNF0gY291bGQgYXBwZWFyIGF0IHRoZSBzYW1l IHRpbWUuDQoNCkZvciBleGFtcGxlLCBvbmUgcmVtb3RlIGNvbnRyb2xsIGNlbnRlciB3YW50IHRv IGFjY2VzcyBhbiBsb3dwYW4gbm9kZSwgdGhleSB3b3VsZCB1c2UgSVB2NiBnbG9iYWwgYWRkcmVz cyB0byBjb21tdW5pY2F0ZS4gV2hlbiB0aGUgSVAgcGFja2V0IHJlYWNoIHRvIDZsb3dwYW4gZ2F0 ZXdheSwgdGhpcyByb3V0aW5nIG5vZGUgd291bGQgcmVkZWxpZXZlciBpdCB0byB0aGUgaW50ZXJu YWwgbG93cGFuIG5vZGUuIE5vdywgdGhlIGFkYXB0YXRpb24gbGF5ZXIgb2YgdGhlIGdhdGV3YXkg c2hvdWxkIHVzZSBjbGFzcyBbMV0gYW5kIFs0XSBmb3IgZGVzdGluYXRpb24gYWRkcmVzcyBjb21w cmVzc2lvbiBhbmQgY2xhc3MgWzFdIGFuZCBbM10gZm9yIHNvdXJjZSBhZGRyZXNzLiBUaGF0J3Mg YWxzbyB0aGUgc2NlbmFyaW8gb2YgbXkgYXNzdW1wdGlvbiBbMV0uDQoNCklzIGl0IGJldHRlciB0 byBjbGFyaWZ5IGFsbCBwb3NzaWJsZSBzaXR1YXRpb24/IA0KDQpUbyBHYWJyaWVsOg0KDQpJIHRo aW5rIHRoZSB0aW55IGxpdGVyYWwgY2hhbmdlIHdvdWxkIHdvcmssIHRoYW5rcy4gDQoNClJlZ2Fy ZHMsDQoNCk1hcmlvDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRGFu aWVsIFBhcmsiIDxzb29ob25ncEBnbWFpbC5jb20+DQpUbzogIk1hcmlvIE1hbyIgPG1hcmlvbWFv QGdtYWlsLmNvbT4NCkNjOiAiZ2FicmllbCBtb250ZW5lZ3JvIiA8Z2FicmllbF9tb250ZW5lZ3Jv XzIwMDBAeWFob28uY29tPjsgIkdlb2ZmIE11bGxpZ2FuIiA8Z2VvZmZAbXVsbGlnYW4uY29tPjsg IjZsb3dwYW4iIDw2bG93cGFuQGxpc3RzLmlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIEphbnVh cnkgMTgsIDIwMDcgNDowNSBQTQ0KU3ViamVjdDogUmU6IFs2bG93cGFuXSBTbGlnaHQgcHJvYmxl bSB3aXRoIGZvcm1hdCBkb2N1bWVudA0KDQoNCj4gSXQgc2VlbXMgYSBiaXQgaW1wbGVtZW50YXRp b24gaXNzdWUuIE91ciBmb3JtYXQgZG9jdW1lbnQgZGVmaW5lcyBmb3VyIGNsYXNzZXM6DQo+IA0K PiBbMV0gUHJlZml4IEluLWxpbmUgSUlEIEluLWxpbmUNCj4gWzJdIFByZWZpeCBJbi1saW5lIElJ RCBjb21wcmVzc2VkDQo+IFszXSBQcmVmaXggY29tcHJlc3NlZCBJSUQgSW4tbGluZQ0KPiBbNF0g UHJlZml4IGNvbXByZXNzZWQgSUlEIGNvbXByZXNzZWQNCj4gDQo+IE1vc3QgYXNzdW10aW9uIGlu IG91ciBzY2VuYXJpbyBhcyBvZiB0b2RheSBpcyBbNF0uIEl0IG1lYW5zIElQdjYNCj4gc291cmNl IGFuZCBkZXN0aW5hdGlvbiBiZWxvbmcgdG8gbGluay1sb2NhbCBzY29wZS4gSW4geW91ciBhc3N1 bXRpb24sDQo+IHBlcmhhcHMsIFsxXSBhbmQgWzJdIGFyZSBhcHByb3ByaWF0ZS4gSW4gdGhhdCBz ZW5zZSwgNmxvd3Bhbg0KPiBhZG9wdGF0aW9uIGxheWVyIHNlZW1zIG5vdCBtZWFuaW5nZnVsLiBB bHNvLCA2bG93cGFuIGhlYWRlcg0KPiBjb21wcmVzc2lvbiBpcyBvbmx5IGFwcGxpZWQgZm9yIDgw Mi4xNS40IGxpbmsgZHVlIHRvIHRoZSB0aW55DQo+IGJhbmR3aWR0aC4NCj4gDQo+IERhbmllbA0K PiANCj4gT24gMS8xOC8wNywgTWFyaW8gTWFvIDxtYXJpb21hb0BnbWFpbC5jb20+IHdyb3RlOg0K PiA+DQo+ID4gSSBhZ3JlZSB3aXRoIGdhYnJpZWwsIHRoZXJlIGlzIG5vIGludGVyZmVyZW5jZSBi ZXR3ZWVuIGhlYWRlciBjb21wcmVzc2lvbg0KPiA+IGFuZCBJQ01QLiBIb3dldmVyLCBJIGJlbGll dmUgdHdvIHBvaW50cyBzaG91bGQgYmUgbm90ZWQgd2hpY2ggbWF5IGNhdXNlDQo+ID4gaW5mb3Jt YXRpb24gbG9zcy4NCj4gPg0KPiA+IDEuIElmIHRoZSBwcm9jZXNzaW5nIG5vZGUgaXMgbG93cGFu IGdhdGV3YXkvcm91dGVyIGFuZCB0aGUgc2VudCBwYWNrZXQgY29tZXMNCj4gPiBmcm9tIEludGVy bmV0IGJ1dCBub3Qgb3JpZ2luYXRlcyBieSB0aGUgZ2F0ZXdheS9yb3V0ZXIgaXRzZWxmLCB0aGUg SUlEIG9mIElQDQo+ID4gc291cmNlIGFkZHJlc3Mgc2hvdWxkbid0IGJlIGNvbXByZXNzZWQuDQo+ ID4gMi4gSWYgdGhlIElQIGRlc3RpbmF0aW9uIGlzbid0IGFuICJvbi1saW5rIiBub2RlICh0aGF0 IG1lYW5zIHRoZSBkZXN0aW5hdGlvbg0KPiA+IGlzIG1vcmUgdGhhbiBvbmUgaG9wIGF3YXkgZnJv bSBzb3VyY2Ugbm9kZSksIHRoZSBJSUQgb2YgSVAgZGVzdGluYXRpb24NCj4gPiBhZGRyZXNzIHNo b3VsZG4ndCBiZSBjb21wcmVzc2VkLg0KPiA+DQo+ID4gSW4gYSB3b3JkLCA2bG93cGFuIG5vZGUg Y291bGQgb25seSBjb21wcmVzcyB0aGUgSUlEIHRoYXQgZGVyaXZlcyBmcm9tIElFRUUNCj4gPiA4 MDIuMTUuNCBNQUMgYWRkcmVzcy4gSSB0aGluayB0aGF0IHBvaW50IHNob3VsZCBiZSBlbXBoYXNp emVkIGluIGRyYWZ0LA0KPiA+IGlzbid0IGl0Pw0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+ IE1hcmlvDQo+ID4NCj4gPg0KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiBG cm9tOiBnYWJyaWVsIG1vbnRlbmVncm8NCj4gPiBUbzogR2VvZmYgTXVsbGlnYW4gOyA2bG93cGFu DQo+ID4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTgsIDIwMDcgMzowNyBQTQ0KPiA+IFN1Ympl Y3Q6IFJlOiBbNmxvd3Bhbl0gU2xpZ2h0IHByb2JsZW0gd2l0aCBmb3JtYXQgZG9jdW1lbnQNCj4g Pg0KPiA+DQo+ID4gSXMgdGhpcyBldmVuIG5lY2Vzc2FyeSB0byBiZSBzYWlkPyBJQ01QIG1zZ3Mg d2lsbCBuZXZlciBiZSBzZW50IGJ5DQo+ID4gaW50ZXJtZWRpYXRlIG5vZGVzDQo+ID4gaW4gYSBs b3dwYW4gbWVzaCwgYnV0IG9ubHkgYnkgdGhlIElQdjYgZW5kIG5vZGVzIGFzIHBhcnQgb2Ygbm9y bWFsIElQdjYNCj4gPiBwcm9jZXNzaW5nLg0KPiA+IFRoaXMgcHJvY2Vzc2luZyB0YWtlcyBwbGFj ZSBhZnRlciB0aGUgbG93cGFuIGxheWVyIGRlbGl2ZXJzIHBhY2tldHMgdG8gdGhlDQo+ID4gSVB2 NiBzdGFjay4gU28gYnkgdGhlIHRpbWUgdGhlIElQdjYgc3RhY2sgZ2V0cyB0aGUgcGFja2V0LCBp dCB3aWxsIGhhdmUgYmVlbg0KPiA+IGRlY29tcHJlc3NlZC4gVGhpcyBpcyB0aGUgc2FtZSBmb3Ig bG93cGFuIGhlYWRlciBjb21wcmVzc2lvbiBvciBhbnkgb3RoZXINCj4gPiB0eXBlDQo+ID4gb2Yg aGVhZGVyIGNvbXByZXNzaW9uLg0KPiA+DQo+ID4gU28gSSB3b25kZXIgaWYgdGhlIHRleHQgYmVs b3cgaXMgbmVlZGVkLiBJdCB3b3VsZCBiZSBuZWVkZWQgaWYgdGhlIGVudGl0eQ0KPiA+IHNlbmRp bmcNCj4gPiBiYWNrIElDTVAgbWVzc2FnZXMgd2FzIHRoZSBsb3dwYW4gbGF5ZXIuIFllcywgaXQg d291bGQgc2VlIGNvbXByZXNzZWQNCj4gPiBoZWFkZXJzLg0KPiA+IEJ1dCB0aGUgZW50aXR5IGlz IHRoZSBJUHY2IHN0YWNrLCB3aGljaCBkb2VzIG5vdCBzZWUgdGhvc2UgY29tcHJlc3NlZA0KPiA+ IGhlYWRlcnMuDQo+ID4NCj4gPiBDb21tZW50cz8gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4g Pg0KPiA+IC1nYWJyaWVsDQo+ID4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0NCj4g PiBGcm9tOiBHZW9mZiBNdWxsaWdhbiA8Z2VvZmZAbXVsbGlnYW4uY29tPg0KPiA+IFRvOiA2bG93 cGFuIDw2bG93cGFuQGxpc3RzLmlldGYub3JnPg0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFy eSAxNywgMjAwNyAxMDozNjo1MiBQTQ0KPiA+IFN1YmplY3Q6IFs2bG93cGFuXSBTbGlnaHQgcHJv YmxlbSB3aXRoIGZvcm1hdCBkb2N1bWVudA0KPiA+DQo+ID4gV2hpbGUgcmV2aWV3aW5nIHRoZSBm b3JtYXQgZG9jdW1lbnQgSSByZWFsaXplZCB0aGF0IHdlIGRpZG4ndCBkZXNjcmliZQ0KPiA+IGhh bmRsaW5nIG9mIElDTVB2NiBlcnJvciBtZXNzYWdlcy4gIFNpbmNlIHRoZSA2bG93cGFuIGhlYWRl cnMgbWF5IGJlDQo+ID4gY29tcHJlc3NlZCBpdCBpcyBuZWNlc3NhcnkgdG8gdW5jb21wcmVzcyB0 aGUgb3JpZ2luYWwgSVAgYW5kIHRyYW5zcG9ydA0KPiA+IGhlYWRlcnMgYmVmb3JlIHNlbmRpbmcg dGhlIElDTVAgZXJyb3IgbWVzc2FnZS4NCj4gPg0KPiA+IEhlcmUgaXMgbXkgcHJvcG9zZWQgdGV4 dCBmb3IgYSBuZXcgc2VjdGlvbiAxMi4uLg0KPiA+DQo+ID4gMTIuIEhhbmRsaW5nIElDTVB2NiBt ZXNzYWdlcw0KPiA+DQo+ID4gSUNNUHY2IChSRkMyNDYzKSBpcyB1c2VkIHRvIHJlcG9ydCBlcnJv cnMgYW5kIGNhcnJ5IElQIGxheWVyIGluZm9ybWF0aW9uDQo+ID4gYW5kIGZ1bmN0aW9ucyBzdWNo IGFzIGRpYWdub3N0aWNzLiAgVGhlcmUgYXJlIHR3byBncm91cHMgb2YgSUNNUHY2DQo+ID4gbWVz c2FnZXM6IGVycm9yIG1lc3NhZ2VzIGFuZCBpbmZvcm1hdGlvbmFsIG1lc3NhZ2VzLiBFYWNoIG1l c3NhZ2UNCj4gPiBjb25zaXN0cyBvZiBhIHR5cGUgZmllbGQgKGlmIHRoZSBoaWdoIG9yZGVyIGJp dCBpcyAwIGl0IGlzIGFuIGVycm9yDQo+ID4gbWVzc2FnZSksIGEgY29kZSBhbmQgY2hlY2tzdW0g ZmllbGQuICBUaGVzZSBmaWVsZHMgYXJlIGZvbGxvd2VkIGJ5IHRoZQ0KPiA+IElDTVB2NiBtZXNz YWdlIGJvZHkuICBGb3IgSUNNUHY2IGVycm9yIG1lc3NhZ2VzIChUeXBlIDwxMjgpIHRoZSBtZXNz YWdlDQo+ID4gYm9keSBzaGFsbCBjb250YWluIGFzIG11Y2ggb2YgdGhlIG9yaWdpbmFsIChvZmZl bmRpbmcpIElQIG1lc3NhZ2UNCj4gPiB3aXRob3V0IGV4Y2VlZGVkIHRoZSBtaW5pbXVtIElQdjYg TVRVLg0KPiA+DQo+ID4gQXMgZGVzY3JpYmVkIGluIHRoZSBwcmVjZWRpbmcgc2VjdGlvbiAoSGVh ZGVyIENvbXByZXNzaW9uKSwgdGhlIG9yaWdpbmFsDQo+ID4gSVB2NiBhbmQgVHJhbnNwb3J0IChU Q1Agb3IgVURQKSBoZWFkZXJzIG1heSBiZSBjb21wcmVzc2VkIHZpYSBIQzEgYW5kDQo+ID4gSEMy IGVuY29kaW5nLiAgU28gdGhhdCB0aGUgZGVzdGluYXRpb24gbm9kZSBvZiBhbiBJQ01QdjYgZXJy b3IgbWVzc2FnZQ0KPiA+IGNhbiBwcm9wZXJseSBwcm9jZXNzIHRoZSBtZXNzYWdlIHRoZSBzb3Vy Y2Ugbm9kZSBtdXN0IGRlY29tcHJlc3MgdGhlDQo+ID4gSVB2NiBhbmQgdHJhbnNwb3J0IGhlYWRl cnMgYmVmb3JlIHNlbmRpbmcgdGhlIElDTVB2NiBtZXNzYWdlLiAgVGhpcyBpcw0KPiA+IG5lY2Vz c2FyeSBiZWNhdXNlIHRoZSBvcmlnaW5hbCBNQUMgYWRkcmVzc2VzIGFuZCB0aGUgSEMxIGFuZCBI QzINCj4gPiBlbmNvZGluZyBoZWFkZXJzIHdpbGwgYmUgbG9zdCBhbmQgdGhlIHJlY2lwaWVudCB3 b3VsZCBoYXZlIG5vIGFiaWxpdHkgdG8NCj4gPiByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwgbWVz c2FnZSBub3IgY29tcHV0ZSB0aGUgcHJvcGVyIGNoZWNrc3VtLg0KPiA+DQo+ID4gVGhlIElDTVB2 NiBtZXNzYWdlIGl0c2VsZiBpcyBjYXJyaWVkIGluc2lkZSBhbmQgSVB2NiBwYWNrZXQgYW5kIHRo aXMNCj4gPiBwYWNrZXQgbWF5IGJlIHRyYW5zbWl0dGVkIG92ZXIgdGhlIDZMb1dQQU4gbmV0d29y ayB1dGlsaXppbmcgaGVhZGVyDQo+ID4gY29tcHJlc3Npb24uICBJQ01QdjYgbWVzc2FnZXMgdGhh dCBhcmUgbGFyZ2VyIHRoYW4gdGhlIGF2YWlsYWJsZSBwYXlsb2FkDQo+ID4gb2YgdGhlIDZMb1dQ QU4gbmV0d29yayB3aWxsIG5lZWQgdG8gYmUgZnJhZ21lbnRlZC4gQXNzdW1pbmcgdGhlIG1heGlt dW0NCj4gPiBmcmFtZSBvdmVyaGVhZCwgbWF4aW11bSBsaW5rIGxheWVyIHNlY3VyaXR5IGFuZCBp bmNsdWRpbmcgYSA2TG9XUEFOIE1lc2gNCj4gPiBIZWFkZXIsIEZyYWdtZW50YXRpb24gSGVhZGVy IGFuZCBEaXNwYXRjaCBIZWFkZXIsIHNlbmRpbmcgdGhlDQo+ID4gdW5jb21wcmVzc2VkIElQdjYg YW5kIHRyYW5zcG9ydCBoZWFkZXJzIHNob3VsZCBzdGlsbCBhbGxvdyBmb3IgMjUgb2N0ZXRzDQo+ ID4gb2YgdGhlIG9yaWdpbmFsIHBhY2tldCBwYXlsb2FkLiAgUGFja2V0cyB1c2luZyBzaG9ydCBh ZGRyZXNzZXMsIG5vDQo+ID4gc2VjdXJpdHksIGFuZCBqdXN0IGEgNkxvV1BBTiBEaXNwYXRjaCBo ZWFkZXIgd2lsbCBiZSBhYmxlIHRvIGNhcnJ5IDYxDQo+ID4gb2N0ZXRzIG9mIHRoZSBvcmlnaW5h bCBwYWNrZXQuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+ID4g Nmxvd3BhbkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvLzZsb3dwYW4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+ID4gNmxvd3BhbkBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+ID4gNmxvd3BhbkBpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCj4g Pg0KPiA+DQo+ID4NCj4gDQo+IA0KPiAtLSANCj4gDQo+IA0KPiBEYW5pZWwgKFNvb2hvbmcgRGFu aWVsIFBhcmspDQo+IE1vYmlsZSBDb252ZXJnZW5jZSBMYWJvcmF0b3J5LCBTQU1TVU5HIEVsZWN0 cm9uaWNzLg== --===============0672984389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0672984389==-- From 6lowpan-bounces@ietf.org Thu Jan 18 04:45:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Tpj-0002Ht-Ou; Thu, 18 Jan 2007 04:45:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Tpi-0002Hm-EN for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:45:22 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Tpe-0003f1-US for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 04:45:22 -0500 Received: from dev20.coslabs.com (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l0I9jIcq004843; Thu, 18 Jan 2007 02:45:18 -0700 (MST) Subject: Re: [6lowpan] Slight problem with format document From: Geoff Mulligan To: gabriel montenegro In-Reply-To: <20070118090032.75006.qmail@web81904.mail.mud.yahoo.com> References: <20070118090032.75006.qmail@web81904.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 18 Jan 2007 02:45:16 -0700 Message-Id: <1169113516.6668.125.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I guess that I see your point but if we are not going to talk about implementation details, why do we do so at the end of section 5.3. It seems that much of that is implementation dependent. Also is the Note: in section 5 right before 5.1 actually necessary. geoff On Thu, 2007-01-18 at 01:00 -0800, gabriel montenegro wrote: > TTL (rather "Hop Count") of 1? Sure. The IPv6 layer handles that, not > lowpan. > Intermediate? No. ICMP is an IPv6 function. Intermediate nodes (as in > a lowpan mesh) > must not interfere with this. Now, if we wanted to define a lowpan > layer error > notification mechanism (analogous to ICMP at the IP layer), we could. > But that's > not ICMP, and I'd argue that we should define that in a separate draft > later on > (perhaps as part of forthcoming mesh routing specifications). > > Sure, layering may be relaxed for optimization reasons. But this is > nothing > new: it's done today in optimized implementation regardless of lowpan. > Still, > the conceptual model holds, so those are implementation details we > shouldn't > be concerned about in this particular document. > > -gabriel > > ----- Original Message ---- > From: Geoff Mulligan > To: gabriel montenegro > Cc: 6lowpan <6lowpan@lists.ietf.org> > Sent: Wednesday, January 17, 2007 11:57:00 PM > Subject: Re: [6lowpan] Slight problem with format document > > Gabriel, > If a node within a 6lowpan network receives a packet with a ttl of 1 > won't it send back an icmp error message if it was supposed to forward > the packet, either if you were routing between 6lowpan nodes or > between > 6lowpan networks. Also couldn't an intermediate node send back a > "parameter problem" icmp message. > > And since these are being implemented on micro-controllers is it > strictly true that the layer separation is completely observed. I > could > see someone implementing a stack where you would not waste the limited > ram space to uncompress the ip header and that the ip layer would deal > with and understand the compressed headers and in this case the > transport header then might still be compressed. > > Additionally I think that it is necessary to clarify if the checksum > is > run over the compressed or uncompressed ip pseudo header. > > I think for sake of clarity one short section (I may have been wordy) > isn't bad, unless it is just wrong. > > geoff > > > > On Wed, 2007-01-17 at 23:07 -0800, gabriel montenegro wrote: > > Is this even necessary to be said? ICMP msgs will never be sent by > > intermediate nodes > > in a lowpan mesh, but only by the IPv6 end nodes as part of normal > > IPv6 processing. > > This processing takes place after the lowpan layer delivers packets > to > > the > > IPv6 stack. So by the time the IPv6 stack gets the packet, it will > > have been > > decompressed. This is the same for lowpan header compression or any > > other type > > of header compression. > > > > So I wonder if the text below is needed. It would be needed if the > > entity sending > > back ICMP messages was the lowpan layer. Yes, it would see > compressed > > headers. > > But the entity is the IPv6 stack, which does not see those > compressed > > headers. > > > > Comments? Am I missing something? > > > > -gabriel > > > > ----- Original Message ---- > > From: Geoff Mulligan > > To: 6lowpan <6lowpan@lists.ietf.org> > > Sent: Wednesday, January 17, 2007 10:36:52 PM > > Subject: [6lowpan] Slight problem with format document > > > > While reviewing the format document I realized that we didn't > describe > > handling of ICMPv6 error messages. Since the 6lowpan headers may be > > compressed it is necessary to uncompress the original IP and > transport > > headers before sending the ICMP error message. > > > > Here is my proposed text for a new section 12... > > > > 12. Handling ICMPv6 messages > > > > ICMPv6 (RFC2463) is used to report errors and carry IP layer > > information > > and functions such as diagnostics. There are two groups of ICMPv6 > > messages: error messages and informational messages. Each message > > consists of a type field (if the high order bit is 0 it is an error > > message), a code and checksum field. These fields are followed by > the > > ICMPv6 message body. For ICMPv6 error messages (Type <128) the > > message > > body shall contain as much of the original (offending) IP message > > without exceeded the minimum IPv6 MTU. > > > > As described in the preceding section (Header Compression), the > > original > > IPv6 and Transport (TCP or UDP) headers may be compressed via HC1 > and > > HC2 encoding. So that the destination node of an ICMPv6 error > message > > can properly process the message the source node must decompress the > > IPv6 and transport headers before sending the ICMPv6 message. This > is > > necessary because the original MAC addresses and the HC1 and HC2 > > encoding headers will be lost and the recipient would have no > ability > > to > > reconstruct the original message nor compute the proper checksum. > > > > The ICMPv6 message itself is carried inside and IPv6 packet and this > > packet may be transmitted over the 6LoWPAN network utilizing header > > compression. ICMPv6 messages that are larger than the available > > payload > > of the 6LoWPAN network will need to be fragmented. Assuming the > > maximum > > frame overhead, maximum link layer security and including a 6LoWPAN > > Mesh > > Header, Fragmentation Header and Dispatch Header, sending the > > uncompressed IPv6 and transport headers should still allow for 25 > > octets > > of the original packet payload. Packets using short addresses, no > > security, and just a 6LoWPAN Dispatch header will be able to carry > 61 > > octets of the original packet. > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 05:20:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7UO5-0005cL-J2; Thu, 18 Jan 2007 05:20:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7UO5-0005cE-3O for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 05:20:53 -0500 Received: from web81908.mail.mud.yahoo.com ([68.142.207.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7UO4-0008OX-8m for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 05:20:53 -0500 Received: (qmail 55449 invoked by uid 60001); 18 Jan 2007 10:20:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Mq32oi5oISPZbzCqJqyU+XS/OxhwykEdLKSWuii+FiC/fs4GE0fAnakTv8rKUBCt2uijclTRxMrlnME+BQNn9R5dBZOCleCwCmgjpzz+uOyk/BXRsHD87l5k/ZSTXwfUSLaHMjLh/lSTovUYMm8RjS0v/vtX3VPO/XX143Ibq+w= ; Message-ID: <20070118102051.55447.qmail@web81908.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81908.mail.mud.yahoo.com via HTTP; Thu, 18 Jan 2007 02:20:51 PST Date: Thu, 18 Jan 2007 02:20:51 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] Slight problem with format document To: Geoff Mulligan MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1109142131==" Errors-To: 6lowpan-bounces@ietf.org --===============1109142131== Content-Type: multipart/alternative; boundary="0-2104372149-1169115651=:54629" --0-2104372149-1169115651=:54629 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable And I remember there was discussion about this being too much=0Aimplementat= ion detail when we added it. Other thoughts:=0A=0A- this is at least releva= nt, being squarely within the lowpan layer=0A- ICMP processing does not see= m nearly as relevant=0A- no IP-over-foo document deals with ICMP processing= , so we should have a very=0A good reason to do so here=0A- it is way past= time to do further tweakings. let's only do further=0A tweakings *after* = moving to IESG.=0A=0Aand yes, we have consensus, we've had it for several d= ays now. option 2 =0Afrom carsten's email was discussed, i suggested some t= ext along those lines,=0Abut finally Phil suggested it better be left out a= nd pointed out that the current text=0Aalready allows us to define differen= t behavior in the future.=0A=0AAnd yes, I've already taken care of the supe= rfluous note in the rev-09 (just now=0Asubmitted).=0A=0A=0ALet's please mov= e on to IESG as soon as it appears on the repositories.=0A=0Atnx,=0A=0A-gab= riel=0A=0A----- Original Message ----=0AFrom: Geoff Mulligan =0ATo: gabriel montenegro =0ACc: 6= lowpan <6lowpan@lists.ietf.org>=0ASent: Thursday, January 18, 2007 1:45:16 = AM=0ASubject: Re: [6lowpan] Slight problem with format document=0A=0AI gues= s that I see your point but if we are not going to talk about=0Aimplementat= ion details, why do we do so at the end of section 5.3. It=0Aseems that mu= ch of that is implementation dependent.=0A=0AAlso is the Note: in section 5= right before 5.1 actually necessary.=0A=0A geoff=0A=0A=0A=0AOn Thu, 200= 7-01-18 at 01:00 -0800, gabriel montenegro wrote:=0A> TTL (rather "Hop Coun= t") of 1? Sure. The IPv6 layer handles that, not=0A> lowpan.=0A> Intermedia= te? No. ICMP is an IPv6 function. Intermediate nodes (as in=0A> a lowpan me= sh)=0A> must not interfere with this. Now, if we wanted to define a lowpan= =0A> layer error=0A> notification mechanism (analogous to ICMP at the IP la= yer), we could.=0A> But that's=0A> not ICMP, and I'd argue that we should d= efine that in a separate draft=0A> later on=0A> (perhaps as part of forthco= ming mesh routing specifications).=0A> =0A> Sure, layering may be relaxed f= or optimization reasons. But this is=0A> nothing=0A> new: it's done today i= n optimized implementation regardless of lowpan.=0A> Still,=0A> the concept= ual model holds, so those are implementation details we=0A> shouldn't=0A> b= e concerned about in this particular document. =0A> =0A> -gabriel=0A> =0A> = ----- Original Message ----=0A> From: Geoff Mulligan = =0A> To: gabriel montenegro =0A> Cc: 6lo= wpan <6lowpan@lists.ietf.org>=0A> Sent: Wednesday, January 17, 2007 11:57:0= 0 PM=0A> Subject: Re: [6lowpan] Slight problem with format document=0A> =0A= > Gabriel,=0A> If a node within a 6lowpan network receives a packet with = a ttl of 1=0A> won't it send back an icmp error message if it was supposed = to forward=0A> the packet, either if you were routing between 6lowpan nodes= or=0A> between=0A> 6lowpan networks. Also couldn't an intermediate node se= nd back a=0A> "parameter problem" icmp message.=0A> =0A> And since these = are being implemented on micro-controllers is it=0A> strictly true that the= layer separation is completely observed. I=0A> could=0A> see someone impl= ementing a stack where you would not waste the limited=0A> ram space to unc= ompress the ip header and that the ip layer would deal=0A> with and underst= and the compressed headers and in this case the=0A> transport header then m= ight still be compressed.=0A> =0A> Additionally I think that it is necessar= y to clarify if the checksum=0A> is=0A> run over the compressed or uncompre= ssed ip pseudo header.=0A> =0A> I think for sake of clarity one short secti= on (I may have been wordy)=0A> isn't bad, unless it is just wrong.=0A> =0A>= geoff=0A> =0A> =0A> =0A> On Wed, 2007-01-17 at 23:07 -0800, gabriel mo= ntenegro wrote:=0A> > Is this even necessary to be said? ICMP msgs will nev= er be sent by=0A> > intermediate nodes=0A> > in a lowpan mesh, but only by = the IPv6 end nodes as part of normal=0A> > IPv6 processing.=0A> > This proc= essing takes place after the lowpan layer delivers packets=0A> to=0A> > the= =0A> > IPv6 stack. So by the time the IPv6 stack gets the packet, it will= =0A> > have been=0A> > decompressed. This is the same for lowpan header com= pression or any=0A> > other type=0A> > of header compression.=0A> > =0A> > = So I wonder if the text below is needed. It would be needed if the=0A> > en= tity sending=0A> > back ICMP messages was the lowpan layer. Yes, it would s= ee=0A> compressed=0A> > headers.=0A> > But the entity is the IPv6 stack, wh= ich does not see those=0A> compressed=0A> > headers.=0A> > =0A> > Comments?= Am I missing something?=0A> > =0A> > -gabriel=0A> > =0A> > ----- Original = Message ----=0A> > From: Geoff Mulligan =0A> > To: 6low= pan <6lowpan@lists.ietf.org>=0A> > Sent: Wednesday, January 17, 2007 10:36:= 52 PM=0A> > Subject: [6lowpan] Slight problem with format document=0A> > = =0A> > While reviewing the format document I realized that we didn't=0A> de= scribe=0A> > handling of ICMPv6 error messages. Since the 6lowpan headers = may be=0A> > compressed it is necessary to uncompress the original IP and= =0A> transport=0A> > headers before sending the ICMP error message.=0A> > = =0A> > Here is my proposed text for a new section 12...=0A> > =0A> > 12. Ha= ndling ICMPv6 messages=0A> > =0A> > ICMPv6 (RFC2463) is used to report erro= rs and carry IP layer=0A> > information=0A> > and functions such as diagnos= tics. There are two groups of ICMPv6=0A> > messages: error messages and in= formational messages. Each message=0A> > consists of a type field (if the h= igh order bit is 0 it is an error=0A> > message), a code and checksum field= . These fields are followed by=0A> the=0A> > ICMPv6 message body. For ICM= Pv6 error messages (Type <128) the=0A> > message=0A> > body shall contain a= s much of the original (offending) IP message=0A> > without exceeded the mi= nimum IPv6 MTU. =0A> > =0A> > As described in the preceding section (Heade= r Compression), the=0A> > original=0A> > IPv6 and Transport (TCP or UDP) he= aders may be compressed via HC1=0A> and=0A> > HC2 encoding. So that the de= stination node of an ICMPv6 error=0A> message=0A> > can properly process th= e message the source node must decompress the=0A> > IPv6 and transport head= ers before sending the ICMPv6 message. This=0A> is=0A> > necessary because= the original MAC addresses and the HC1 and HC2=0A> > encoding headers will= be lost and the recipient would have no=0A> ability=0A> > to=0A> > reconst= ruct the original message nor compute the proper checksum. =0A> > =0A> > T= he ICMPv6 message itself is carried inside and IPv6 packet and this=0A> > p= acket may be transmitted over the 6LoWPAN network utilizing header=0A> > co= mpression. ICMPv6 messages that are larger than the available=0A> > payloa= d=0A> > of the 6LoWPAN network will need to be fragmented. Assuming the=0A>= > maximum=0A> > frame overhead, maximum link layer security and including = a 6LoWPAN=0A> > Mesh=0A> > Header, Fragmentation Header and Dispatch Header= , sending the=0A> > uncompressed IPv6 and transport headers should still al= low for 25=0A> > octets=0A> > of the original packet payload. Packets usin= g short addresses, no=0A> > security, and just a 6LoWPAN Dispatch header wi= ll be able to carry=0A> 61=0A> > octets of the original packet.=0A> > =0A> = > =0A> > =0A> > =0A> > _______________________________________________=0A= > > 6lowpan mailing list=0A> > 6lowpan@ietf.org=0A> > https://www1.ietf.org= /mailman/listinfo/6lowpan=0A> > =0A> > =0A> > =0A> =0A> =0A> =0A> =0A=0A=0A= =0A=0A=0A --0-2104372149-1169115651=:54629 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
And I remember there was discussion about this being = too much
implementation detail when we added it. Other thoughts:

= - this is at least relevant, being squarely within the lowpan layer
- IC= MP processing does not seem nearly as relevant
- no IP-over-foo document= deals with ICMP processing, so we should have a very
  good reason= to do so here
- it is way past time to do further tweakings. let's only= do further
  tweakings *after* moving to IESG.

and yes, we = have consensus, we've had it for several days now. option 2
from carste= n's email was discussed, i suggested some text along those lines,
but fi= nally Phil suggested it better be left out and pointed out that the current= text
already allows us to define different behavior in the future.

And yes, I've= already taken care of the superfluous note in the rev-09 (just now
subm= itted).

=0ALet's please move on to IESG as soon as it appears on the= repositories.

tnx,

-gabriel

----- Original Me= ssage ----
From: Geoff Mulligan <geoff@mulligan.com>
To: gabrie= l montenegro <gabriel_montenegro_2000@yahoo.com>
Cc: 6lowpan <6= lowpan@lists.ietf.org>
Sent: Thursday, January 18, 2007 1:45:16 AMSubject: Re: [6lowpan] Slight problem with format document

I g= uess that I see your point but if we are not going to talk about
impleme= ntation details, why do we do so at the end of section 5.3.  Itseems that much of that is implementation dependent.

Also is the N= ote: in section 5 right before 5.1 actually necessary.

  &= nbsp; geoff



On Thu, 2007-01-18 at 01:00 -0800, gabriel = montenegro wrote:
> TTL (rather "Hop Count") of 1? Sure. The IPv6 lay= er handles that, not
> lowpan.
> Intermediate? No. ICMP is an IPv6 function. Intermediate n= odes (as in
> a lowpan mesh)
> must not interfere with this. No= w, if we wanted to define a lowpan
> layer error
> notification= mechanism (analogous to ICMP at the IP layer), we could.
> But that'= s
> not ICMP, and I'd argue that we should define that in a separate = draft
> later on
> (perhaps as part of forthcoming mesh routing= specifications).
>
> Sure, layering may be relaxed for optimi= zation reasons. But this is
> nothing
> new: it's done today in= optimized implementation regardless of lowpan.
> Still,
> the = conceptual model holds, so those are implementation details we
> shou= ldn't
> be concerned about in this particular document.
>
= > -gabriel
>
> ----- Original Message ----
> From: Ge= off Mulligan <geoff@mulligan.com>
> To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
> Cc: 6lowpan <6lowpan@= lists.ietf.org>
> Sent: Wednesday, January 17, 2007 11:57:00 PM> Subject: Re: [6lowpan] Slight problem with format document
> > Gabriel,
>   If a node within a 6lowpan network rece= ives a packet with a ttl of 1
> won't it send back an icmp error mess= age if it was supposed to forward
> the packet, either if you were ro= uting between 6lowpan nodes or
> between
> 6lowpan networks. Al= so couldn't an intermediate node send back a
> "parameter problem" ic= mp message.
>
>   And since these are being implemen= ted on micro-controllers is it
> strictly true that the layer separat= ion is completely observed.  I
> could
> see someone = implementing a stack where you would not waste the limited
> ram spac= e to uncompress the ip header and that the ip layer would deal
> with= and understand the compressed headers and in this case the
> transport h= eader then might still be compressed.
>
> Additionally I think= that it is necessary to clarify if the checksum
> is
> run ove= r the compressed or uncompressed ip pseudo header.
>
> I think= for sake of clarity one short section (I may have been wordy)
> isn'= t bad, unless it is just wrong.
>
>     ge= off
>
>
>
> On Wed, 2007-01-17 at 23:07 -0800, g= abriel montenegro wrote:
> > Is this even necessary to be said? IC= MP msgs will never be sent by
> > intermediate nodes
> > = in a lowpan mesh, but only by the IPv6 end nodes as part of normal
> = > IPv6 processing.
> > This processing takes place after the lo= wpan layer delivers packets
> to
> > the
> > IPv6 s= tack. So by the time the IPv6 stack gets the packet, it will
> > h= ave been
> > decompressed. This is the same for lowpan header compres= sion or any
> > other type
> > of header compression.
= > >
> > So I wonder if the text below is needed. It would b= e needed if the
> > entity sending
> > back ICMP messages= was the lowpan layer. Yes, it would see
> compressed
> > he= aders.
> > But the entity is the IPv6 stack, which does not see th= ose
> compressed
> > headers.
> >
> > Com= ments? Am I missing something?
> >
> > -gabriel
> = >
> > ----- Original Message ----
> > From: Geoff Mul= ligan <geoff@mulligan.com>
> > To: 6lowpan <6lowpan@lists= .ietf.org>
> > Sent: Wednesday, January 17, 2007 10:36:52 PM> > Subject: [6lowpan] Slight problem with format document
> &= gt;
> > While reviewing the format document I realized that we di= dn't
> describe
> > handling of ICMPv6 error messages.  Since = the 6lowpan headers may be
> > compressed it is necessary to uncom= press the original IP and
> transport
> > headers before sen= ding the ICMP error message.
> >
> > Here is my proposed= text for a new section 12...
> >
> > 12. Handling ICMPv= 6 messages
> >
> > ICMPv6 (RFC2463) is used to report er= rors and carry IP layer
> > information
> > and functions= such as diagnostics.  There are two groups of ICMPv6
> >= ; messages: error messages and informational messages. Each message
>= > consists of a type field (if the high order bit is 0 it is an error> > message), a code and checksum field.  These fields ar= e followed by
> the
> > ICMPv6 message body.  For = ICMPv6 error messages (Type <128) the
> > message
> > = body shall contain as much of the original (offending) IP message
> > withou= t exceeded the minimum IPv6 MTU.  
> >
> > As = described in the preceding section (Header Compression), the
> > o= riginal
> > IPv6 and Transport (TCP or UDP) headers may be compres= sed via HC1
> and
> > HC2 encoding.  So that the d= estination node of an ICMPv6 error
> message
> > can properl= y process the message the source node must decompress the
> > IPv6= and transport headers before sending the ICMPv6 message.  This> is
> > necessary because the original MAC addresses and the= HC1 and HC2
> > encoding headers will be lost and the recipient w= ould have no
> ability
> > to
> > reconstruct the o= riginal message nor compute the proper checksum.  
> > <= br>> > The ICMPv6 message itself is carried inside and IPv6 packet an= d this
> > packet may be transmitted over the 6LoWPAN network utili= zing header
> > compression.  ICMPv6 messages that are l= arger than the available
> > payload
> > of the 6LoWPAN n= etwork will need to be fragmented. Assuming the
> > maximum
>= ; > frame overhead, maximum link layer security and including a 6LoWPAN<= br>> > Mesh
> > Header, Fragmentation Header and Dispatch He= ader, sending the
> > uncompressed IPv6 and transport headers shou= ld still allow for 25
> > octets
> > of the original pack= et payload.  Packets using short addresses, no
> > secur= ity, and just a 6LoWPAN Dispatch header will be able to carry
> 61> > octets of the original packet.
> >
> > &= nbsp;
> >
> >
> > ___________________________= ____________________
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www1.ietf.org/mailman/listinfo/6lo= wpan
> >
> >
> >
>
>
>= ;
>


--0-2104372149-1169115651=:54629-- --===============1109142131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1109142131==-- From 6lowpan-bounces@ietf.org Thu Jan 18 11:24:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7a3r-000839-SA; Thu, 18 Jan 2007 11:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7a3q-00082y-UJ for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 11:24:22 -0500 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7a3p-0002a6-NM for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 11:24:22 -0500 Received: by an-out-0708.google.com with SMTP id c18so122902anc for <6lowpan@lists.ietf.org>; Thu, 18 Jan 2007 08:24:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o2JrfdZfJaSyF5eYsESv/dKeW3ez2nMruvADo1fv3uyaK7Dn2zAi3a8aNK/jufhOxyNV7Cr9fhF4IhWCvjNvoS8FpK429A0xH3fSpjpS3w7hVhSwAFz2wtSjPOn9ZNI3P1vFvsm+87ydZyVJtGeuTFBSnQfnLhxP9KwuJacO08E= Received: by 10.100.132.16 with SMTP id f16mr249855and.1169137461362; Thu, 18 Jan 2007 08:24:21 -0800 (PST) Received: by 10.100.13.14 with HTTP; Thu, 18 Jan 2007 08:24:21 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 01:24:21 +0900 From: "Daniel Park" To: "Mario Mao" Subject: Re: [6lowpan] Slight problem with format document In-Reply-To: <003301c73ae5$46b4e310$7fc0a8c0@netlab.cs.ecnu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070118070728.17982.qmail@web81914.mail.mud.yahoo.com> <001b01c73ad5$7585da60$7fc0a8c0@netlab.cs.ecnu.edu.cn> <003301c73ae5$46b4e310$7fc0a8c0@netlab.cs.ecnu.edu.cn> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Mario, My comment are inline: On 1/18/07, Mario Mao wrote: > To Daniel: > > Thanks for you tips. > > However, I believe the compression issue is not just for implementation. Thinking about the reason why we need to build IPv6 upper lowpan node, there is high possibility of global scope cummnication. In this scenario, and considering the format defination, the class [1] and [4] could appear at the same time. > > For example, one remote controll center want to access an lowpan node, they would use IPv6 global address to communicate. When the IP packet reach to 6lowpan gateway, this routing node would redeliever it to the internal lowpan node. Now, the adaptation layer of the gateway should use class [1] and [4] for destination address compression and class [1] and [3] for source address. That's also the scenario of my assumption [1]. > > Is it better to clarify all possible situation? If we are considering global communication, there is no common prefix between source address and destionation address comparing with link-local addresses [fe80::/64], thus [1] or [3] is in use. In that sense, 6lowpan header compression is less meaningful than link-local communication. Or need more study on this case. Daniel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 18 15:50:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eD2-0007Zp-US; Thu, 18 Jan 2007 15:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eCw-0007TN-Oy for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eCw-00060T-5V for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1982932A9E; Thu, 18 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7eCv-0004Pf-Uf; Thu, 18 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-09.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.15.4 Networks Author(s) : G. Montenegro, et al. Filename : draft-ietf-6lowpan-format-09.txt Pages : 31 Date : 2007-1-18 This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-format-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-format-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-18104559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-18104559.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --NextPart-- From 6lowpan-bounces@ietf.org Wed Jan 24 09:10:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ipe-0007Fn-Kt; Wed, 24 Jan 2007 09:10:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ipd-0007B0-JD for 6lowpan@ietf.org; Wed, 24 Jan 2007 09:10:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ipX-0007xl-5w for 6lowpan@ietf.org; Wed, 24 Jan 2007 09:10:33 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Jan 2007 15:10:26 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0OEAPtn000547 for <6lowpan@ietf.org>; Wed, 24 Jan 2007 15:10:25 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0OEADCW029972 for <6lowpan@ietf.org>; Wed, 24 Jan 2007 15:10:25 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 15:10:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jan 2007 15:09:56 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC035DAE12@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hops left in format document Thread-Index: Acc/wVMv7jgOapP9SWaikje9I4/ktg== From: "Pascal Thubert \(pthubert\)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 24 Jan 2007 14:10:04.0186 (UTC) FILETIME=[580D67A0:01C73FC1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=170; t=1169647826; x=1170511826; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20Hops=20left=20in=20format=20document |Sender:=20; bh=6R0Wp//xAPn4lcEQK01auKII7wV1SIhZD+X8LBpwvUE=; b=XFf+e3JXWSYk7NEN3uaKjiH/v3nPk74a4Buons8+GymOqIXM/bv+wwoHqsmrWvUdwQjVPDvh dX4O0aMMnCcnRCwWBLsEVFIojaDXwXXOSaiNEa30YZQ3+lms1SGuBobg; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [6lowpan] Hops left in format document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear Authors: A typo is left since the header changes: Page 10, the "hop left" is still described as a "6-bit field" though the text following is correct. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jan 24 10:21:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jwW-0007HG-NA; Wed, 24 Jan 2007 10:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jwW-0007HB-1o for 6lowpan@ietf.org; Wed, 24 Jan 2007 10:21:44 -0500 Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9jwQ-0006j5-FY for 6lowpan@ietf.org; Wed, 24 Jan 2007 10:21:44 -0500 Received: (qmail 74680 invoked by uid 60001); 24 Jan 2007 15:21:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=weiPmz88g634Ncq+2WjSKpfNq0muLngIFML0Eb2Y44iI4BA5qeXNJ+Pua/Z/T5/PZ/2+1ZdIof1aO0R20i/jEmQVdnNszsSZsjLJEb2ZcbucHrNyQz/eBw15msdMb8nG4Ho8CeQtUJAmay9zjcqYOry+Vry5WjFEv4tfTC2eol4= ; Message-ID: <20070124152137.74678.qmail@web81910.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81910.mail.mud.yahoo.com via HTTP; Wed, 24 Jan 2007 07:21:37 PST Date: Wed, 24 Jan 2007 07:21:37 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] Hops left in format document To: "Pascal Thubert \(pthubert\)" , 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0530479818==" Errors-To: 6lowpan-bounces@ietf.org --===============0530479818== Content-Type: multipart/alternative; boundary="0-1669050499-1169652097=:73772" --0-1669050499-1169652097=:73772 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Thanks, I've corrected this in my copy so it'll be there for the next=0Aver= sion.=0A=0A----- Original Message ----=0AFrom: Pascal Thubert (pthubert) =0ATo: 6lowpan@ietf.org=0ASent: Wednesday, January 24, 20= 07 6:09:56 AM=0ASubject: [6lowpan] Hops left in format document=0A=0ADear A= uthors:=0A=0AA typo is left since the header changes: Page 10, the "hop lef= t" is=0Astill described as a "6-bit field" though the text following is cor= rect.=0A=0APascal=0A=0A_______________________________________________=0A6l= owpan mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listi= nfo/6lowpan=0A=0A=0A=0A=0A --0-1669050499-1169652097=:73772 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Thanks, I've corrected this in my copy so it'll be th= ere for the next
version.

----- Original Message ----
= From: Pascal Thubert (pthubert) <pthubert@cisco.com>
To: 6lowpan@i= etf.org
Sent: Wednesday, January 24, 2007 6:09:56 AM
Subject: [6lowpa= n] Hops left in format document

Dear Authors:

A typo is = left since the header changes: Page 10, the "hop left" is
still describe= d as a "6-bit field" though the text following is correct.

Pascal
_______________________________________________
6lowpan mailing lis= t
6lowpan@ietf.org
https://www1.ietf.= org/mailman/listinfo/6lowpan

--0-1669050499-1169652097=:73772-- --===============0530479818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0530479818==-- From 6lowpan-bounces@ietf.org Wed Jan 24 22:48:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9vae-0001OZ-Lm; Wed, 24 Jan 2007 22:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9vad-0001OT-7l for 6lowpan@ietf.org; Wed, 24 Jan 2007 22:47:55 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9vab-0001aS-Uh for 6lowpan@ietf.org; Wed, 24 Jan 2007 22:47:55 -0500 Received: by nf-out-0910.google.com with SMTP id l36so790585nfa for <6lowpan@ietf.org>; Wed, 24 Jan 2007 19:47:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=m+ah9JYKgO5UTbT4fYyahT8EVhT5cyOyiej7s6GqteN2Bv7/2MGMfMz3yo5Vd6zgrkUQ2LvVh+P6fA3fQJlegbVY1gs6XL8lW6lerPqN29FQ/ZN0JKdZ6JSQXcYJ5CqLJ7XoIXFJUj/vj5BiCtGIOW4JW61HQzWwjNG3waBas/E= Received: by 10.82.162.14 with SMTP id k14mr716991bue.1169696872657; Wed, 24 Jan 2007 19:47:52 -0800 (PST) Received: by 10.82.182.18 with HTTP; Wed, 24 Jan 2007 19:47:52 -0800 (PST) Message-ID: <43b91d370701241947v3e502179y245e6959860f4ded@mail.gmail.com> Date: Wed, 24 Jan 2007 19:47:52 -0800 From: "Samita Chakrabarti" To: "gabriel montenegro" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 6lowpan@ietf.org, dculler@archrock.com Subject: [6lowpan] 6lowpan-format-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Gabriel and all, Finally I had a chance to read the latest version of the draft. It looks good with the new style of format. A few minor comments for the authors' consideration: 1) Section 5.3 - the fragmentation format has 3bits + 10bits + 11bits fields for first fragment sub-header and 3+10+11+8 for the subsequent fragments. Defining data structure, parsing and casting will require some clever bit-field operations. I wonder if the fragmentation part has been implemented and if the document can say a cautionary word about any byte alignment issues that the implemntors should take care in the implementation as the fragmented packet will appear on the wire. For example, implementation A's compiler puts a byte after the first-fragment declaration and before the data, while implemention B does not do any padding. 2) Section 8 - Unicast address mapping. The second paragraph actually refers to SLLA/TLLA option from RFC2461. It is a bit confusing for the section heading, please add another sub-heading before this paragraph: 8.1 Source and Destination Link Layer Address Option mapping 3) Section 11.1 Lowpan-BCO option Should we re-word the section header as "LowPan Broadcast (LOWPAN_BCO)" or similar ? Why do we call this an "option" ? We are not calling mesh-header or fragment-header as options. Also, do we add the sequence number in order to avoid broadcasting duplicate packets from the same sender or originator in mesh? Please add a line on why we are adding the sequence number in this case. Sorry for the late review, but these issues do not stop this draft to move forward for the AD review. Nice job! Regards, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jan 25 21:22:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGjI-0006DB-Df; Thu, 25 Jan 2007 21:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGjH-0006D6-6H for 6lowpan@ietf.org; Thu, 25 Jan 2007 21:22:15 -0500 Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAGjE-0002Fu-KU for 6lowpan@ietf.org; Thu, 25 Jan 2007 21:22:15 -0500 Received: (qmail 9370 invoked by uid 60001); 26 Jan 2007 02:22:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=n+nvEloBmzCB24IT9GKNojCUkKKkXcy2jShDvVpq7kozGcq5n+IFkqLM+U/y3unKxjC4mC23Yz/07CUDZitZOh2vCdZItboQqMTRD6i7iuFvtEGDTNPAGBYSE0AMunv1NBHdVKpztAfr4dyRQEAGi6sw9pEjkouDOg8Z5WwewFE= ; Message-ID: <20070126022212.9368.qmail@web81907.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81907.mail.mud.yahoo.com via HTTP; Thu, 25 Jan 2007 18:22:12 PST Date: Thu, 25 Jan 2007 18:22:12 -0800 (PST) From: gabriel montenegro To: Samita Chakrabarti MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 6lowpan@ietf.org, dculler@archrock.com Subject: [6lowpan] Re: 6lowpan-format-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0956427765==" Errors-To: 6lowpan-bounces@ietf.org --===============0956427765== Content-Type: multipart/alternative; boundary="0-936638056-1169778132=:8035" --0-936638056-1169778132=:8035 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Thanks Samita for the review, and specially for making it clear that these= =0Anits should not delay going to IESG.=0A=0AHopefully, we will go soon to = IESG, but the chairs have not said anything=0Aabout this.=0A=0AChairs?=0A= =0AAbout your comments:=0A=0A1. Not sure what to do here. Are you saying th= at parsing is somehow trickier now=0A than it was before the header chang= e? The WG adopted the new header cuz there=0A was consensus that things w= ould be better, not worse. Are you saying they are=0A worse? Beyond this,= being careful in the implementation about bit fields etc=0A is, well, pa= rt of the implementation, so I'm not sure what to do here (or if=0A we ne= ed to do anything). Perhaps if you suggest some text it'll be easier to see= ?=0A=0A2. Not sure why we need to add yet another sub-title for such a shor= t=0A section. This is patterned after section 6 of:=0A=0A http://t= ools.ietf.org/html/rfc2464=0A=0A which itself does not have such sub-titl= e.=0A Besides, the paragraph before the diagram clearly states already=0A= that this is:=0A=09"The Source/Target Link-layer Address option"=0A=0A = which seems pretty explicit. Left it as it is.=0A3. reworded to "LoWPAN Br= oadcast" =0A=0Athanks,=0A=0A-gabriel=0A=0A----- Original Message ----=0AFro= m: Samita Chakrabarti =0ATo: gabriel montenegro =0ACc: dculler@archrock.com; jhui@archrock.com;= nandakishore.kushalnagar@intel.com; 6lowpan@ietf.org=0ASent: Wednesday, Ja= nuary 24, 2007 7:47:52 PM=0ASubject: 6lowpan-format-09=0A=0AHi Gabriel and = all,=0A=0AFinally I had a chance to read the latest version of the draft. I= t=0Alooks good with=0Athe new style of format.=0A=0AA few minor comments f= or the authors' consideration:=0A=0A1) Section 5.3 - the fragmentation for= mat has 3bits + 10bits + 11bits=0Afields for=0A first fragment sub-heade= r and 3+10+11+8 for the subsequent fragments.=0A Defining data structure= , parsing and casting will require some=0Aclever bit-field=0A operations= . I wonder if the fragmentation part has been=0Aimplemented and if the=0A = document can say a cautionary word about any byte alignment issues that= =0A the implemntors should take care in the implementation as the fragme= nted=0A packet will appear on the wire. For example, implementation A's = compiler=0A puts a byte after the first-fragment declaration and before = the=0Adata, while implemention B does not do any padding.=0A=0A2) Section 8= - Unicast address mapping. The second paragraph actually refers to=0A SL= LA/TLLA option from RFC2461. It is a bit confusing for the section heading,= =0A please add another sub-heading before this paragraph:=0A 8.1 So= urce and Destination Link Layer Address Option mapping=0A=0A3) Section 11.1= Lowpan-BCO option=0A Should we re-word the section header as "LowPan Br= oadcast=0A(LOWPAN_BCO)" or similar ?=0AWhy do we call this an "option" ? W= e are not calling mesh-header or=0Afragment-header=0Aas options.=0A=0A Al= so, do we add the sequence number in order to avoid broadcasting duplicate= =0A packets from the same sender or originator in mesh? Please add a line= on why=0A we are adding the sequence number in this case.=0A=0ASorry for= the late review, but these issues do not stop this draft to=0Amove forward= for=0Athe AD review. Nice job!=0A=0ARegards,=0A-Samita=0A=0A=0A=0A=0A --0-936638056-1169778132=:8035 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Thanks Samita for the review, and specially for makin= g it clear that these
nits should not delay going to IESG.

Hopefu= lly, we will go soon to IESG, but the chairs have not said anything
abou= t this.

Chairs?

About your comments:

1. Not sure what = to do here. Are you saying that parsing is somehow trickier now
 &n= bsp; than it was before the header change? The WG adopted the new header cu= z there
   was consensus that things would be better, not wors= e. Are you saying they are
   worse? Beyond this, being carefu= l in the implementation about bit fields etc
   is, well, part= of the implementation, so I'm not sure what to do here (or if
 &nb= sp; we need to do anything). Perhaps if you suggest some text it'll be easier to see?
2. Not sure why we need to add yet another sub-title for such a short
&= nbsp;  section. This is patterned after section 6 of:

&nb= sp;       http://tools.ietf.org/html/rfc2464
<= br>   which itself does not have such sub-title.
   = Besides, the paragraph before the diagram clearly states already
 &= nbsp; that this is:
=09"The Source/Target Link-layer Address option=
"

   which seems pretty explicit. Left it as it is.
3. rewo= rded to "LoWPAN Broadcast"

thanks,

-gabriel

-= ---- Original Message ----
From: Samita Chakrabarti <samitac2@gmail.c= om>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com><= br>Cc: dculler@archrock.com; jhui@archrock.com; nandakishore.kushalnagar@intel.co= m; 6lowpan@ietf.org
Sent: Wednesday, January 24, 2007 7:47:52 PM
Subj= ect: 6lowpan-format-09

Hi Gabriel and all,

Finally I had= a chance to read the latest version of the draft. It
looks good withthe new style of format.

A few minor  comments for the au= thors' consideration:

1)  Section 5.3 - the fragmentation = format has 3bits + 10bits + 11bits
fields for
    = ;first fragment sub-header and 3+10+11+8 for the subsequent fragments.
&= nbsp;   Defining data structure, parsing and casting will re= quire some
clever bit-field
    operations. I won= der if the fragmentation part has been
implemented and if the
 &= nbsp;  document can say a cautionary word about any byte alignmen= t issues that
    the implemntors should take care i= n the implementation as the fragmented
    packet will ap= pear on the wire. For example, implementation A's compiler
  &= nbsp; puts a byte after the first-fragment declaration and before the<= br>data, while implemention B does not do any padding.

2) Section 8 = - Unicast address mapping. The second paragraph actually refers to
 = ;  SLLA/TLLA option from RFC2461. It is a bit confusing for the sectio= n heading,
   please add another sub-heading before this parag= raph:
       8.1 Source and Destination Li= nk Layer Address Option mapping

3) Section 11.1 Lowpan-BCO option    Should we re-word the section header as "LowPan Br= oadcast
(LOWPAN_BCO)"  or similar ?
Why do we call this an = "option" ? We are not calling mesh-header or
fragment-header
as optio= ns.

   Also, do we add the sequence number in order to avo= id broadcasting duplicate
   packets from the same sender or ori= ginator in mesh? Please add a line on why
   we are adding the= sequence number in this case.

Sorry for the late review, but these = issues do not stop this draft to
move forward for
the AD review. Nice= job!

Regards,
-Samita

--0-936638056-1169778132=:8035-- --===============0956427765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0956427765==-- From 6lowpan-bounces@ietf.org Thu Jan 25 21:27:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGoH-0000F1-Hc; Thu, 25 Jan 2007 21:27:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGoF-0000DR-Jq for 6lowpan@ietf.org; Thu, 25 Jan 2007 21:27:23 -0500 Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAGoE-00033G-0l for 6lowpan@ietf.org; Thu, 25 Jan 2007 21:27:23 -0500 Received: (qmail 79369 invoked by uid 60001); 26 Jan 2007 02:27:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=YEY+anU4lVQcpYX2pGLaYdZyFujU1v2iNh3VdFFU607IAvrX87V08TYSAQWKz2J/vfYlutn++16sJfSIPcaceN/sGPweOqtPViJEczzM9pi4rijz9WkHgSdEqCTBRP/P2hYRInPLY8Wv5r7At1vrLDcPpqyvtG4eejCeehaR65c= ; Message-ID: <20070126022721.79367.qmail@web81906.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81906.mail.mud.yahoo.com via HTTP; Thu, 25 Jan 2007 18:27:21 PST Date: Thu, 25 Jan 2007 18:27:21 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] Re: 6lowpan-format-09 To: gabriel montenegro , Samita Chakrabarti MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 6lowpan@ietf.org, dculler@archrock.com X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971654886==" Errors-To: 6lowpan-bounces@ietf.org --===============0971654886== Content-Type: multipart/alternative; boundary="0-1157552645-1169778441=:79340" --0-1157552645-1169778441=:79340 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable forgot one more thing. on #3, good point about explaining the sequence numb= er =0A(actually, Ian had suggested this, but it fell through the cracks). T= his is=0Awhat it looks like now:=0A=0A11.1. LoWPAN Broadcast=0A=0A Addit= ional mesh routing functionality is encoded using a routing=0A header imm= ediately following the Mesh header. In particular, a=0A broadcast header= consists of a LOWPAN_BC0 dispatch followed by a=0A sequence number field= . The sequence number is used to detect=0A duplicate packets (and hopefu= lly suppress them).=0A-gabriel=0A=0A----- Original Message ----=0AFrom: gab= riel montenegro =0ATo: Samita Chakrabart= i =0ACc: 6lowpan@ietf.org; dculler@archrock.com=0ASent:= Thursday, January 25, 2007 6:22:12 PM=0ASubject: [6lowpan] Re: 6lowpan-for= mat-09=0A=0AThanks Samita for the review, and specially for making it clear= that these=0Anits should not delay going to IESG.=0A=0AHopefully, we will = go soon to IESG, but the chairs have not said anything=0Aabout this.=0A=0AC= hairs?=0A=0AAbout your comments:=0A=0A1. Not sure what to do here. Are you = saying that parsing is somehow trickier now=0A than it was before the hea= der change? The WG adopted the new header cuz there=0A was consensus that= things would be better, not worse. Are you saying they are=0A worse? Bey= ond this, being careful in the implementation about bit fields etc=0A is,= well, part of the implementation, so I'm not sure what to do here (or if= =0A we need to do=0A anything). Perhaps if you suggest some text it'll be= easier to see?=0A=0A2. Not sure why we need to add yet another sub-title f= or such a short=0A section. This is patterned after section 6 of:=0A=0A = http://tools.ietf.org/html/rfc2464=0A=0A which itself does not have= such sub-title.=0A Besides, the paragraph before the diagram clearly sta= tes already=0A that this is:=0A=09"The Source/Target Link-layer Address o= ption"=0A=0A which seems pretty explicit. Left it as it is.=0A3. reworded= to "LoWPAN Broadcast" =0A=0Athanks,=0A=0A-gabriel=0A=0A----- Original Mess= age ----=0AFrom: Samita Chakrabarti =0ATo: gabriel mont= enegro =0ACc:=0A dculler@archrock.com; j= hui@archrock.com; nandakishore.kushalnagar@intel.com; 6lowpan@ietf.org=0ASe= nt: Wednesday, January 24, 2007 7:47:52 PM=0ASubject: 6lowpan-format-09=0A= =0AHi Gabriel and all,=0A=0AFinally I had a chance to read the latest versi= on of the draft. It=0Alooks good with=0Athe new style of format.=0A=0AA few= minor comments for the authors' consideration:=0A=0A1) Section 5.3 - the= fragmentation format has 3bits + 10bits + 11bits=0Afields for=0A first = fragment sub-header and 3+10+11+8 for the subsequent fragments.=0A Defin= ing data structure, parsing and casting will require some=0Aclever bit-fiel= d=0A operations. I wonder if the fragmentation part has been=0Aimplement= ed and if the=0A document can say a cautionary word about any byte align= ment issues that=0A the implemntors should take care in the=0A implement= ation as the fragmented=0A packet will appear on the wire. For example, = implementation A's compiler=0A puts a byte after the first-fragment decl= aration and before the=0Adata, while implemention B does not do any padding= .=0A=0A2) Section 8 - Unicast address mapping. The second paragraph actuall= y refers to=0A SLLA/TLLA option from RFC2461. It is a bit confusing for t= he section heading,=0A please add another sub-heading before this paragra= ph:=0A 8.1 Source and Destination Link Layer Address Option mapping= =0A=0A3) Section 11.1 Lowpan-BCO option=0A Should we re-word the section= header as "LowPan Broadcast=0A(LOWPAN_BCO)" or similar ?=0AWhy do we call= this an "option" ? We are not calling mesh-header or=0Afragment-header=0Aa= s options.=0A=0A Also, do we add the sequence number in order to avoid=0A= broadcasting duplicate=0A packets from the same sender or originator in = mesh? Please add a line on why=0A we are adding the sequence number in th= is case.=0A=0ASorry for the late review, but these issues do not stop this = draft to=0Amove forward for=0Athe AD review. Nice job!=0A=0ARegards,=0A-Sam= ita=0A=0A=0A=0A=0A=0A_______________________________________________=0A6low= pan mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinf= o/6lowpan=0A=0A=0A=0A=0A --0-1157552645-1169778441=:79340 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
forgot one more thing. on #3, good point about explai= ning the sequence number
(actually, Ian had suggested this, but it fell= through the cracks). This is
what it looks like now:

11.1. =
 LoWPAN Broadcast

   Additional mesh routing functionality is encode=
d using a routing
   header immediately following the Mesh header.  In p=
articular, a
   broadcast header consists of a LOWPAN_BC0 dispatch follo=
wed by a
   sequence number field.  The sequence number is used to detec=
t
   duplicate packets (and hopefully suppress them).

-gabriel<= br>
----- Original Message ----
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
To: Samita Chakrabarti <sa= mitac2@gmail.com>
Cc: 6lowpan@ietf.org; dculler@archrock.com
Sent:= Thursday, January 25, 2007 6:22:12 PM
Subject: [6lowpan] Re: 6lowpan-fo= rmat-09

Thanks Samita for the review, and specially fo= r making it clear that these
nits should not delay going to IESG.
Hopefully, we will go soon to IESG, but the chairs have not said anything<= br>about this.

Chairs?

About your comments:

1. Not sur= e what to do here. Are you saying that parsing is somehow trickier now
&= nbsp;  than it was before the header change? The WG adopted the new he= ader cuz there
   was consensus that things would be better, n= ot worse. Are you saying they are
   worse? Beyond this, being= careful in the implementation about bit fields etc
   is, well, part of the = implementation, so I'm not sure what to do here (or if
   we n= eed to do=0A anything). Perhaps if you suggest some text it'll be easier to= see?

2. Not sure why we need to add yet another sub-title for such = a short
   section. This is patterned after section 6 of:
<= br>        http://tools.ietf.o= rg/html/rfc2464

   which itself does not have s= uch sub-title.
   Besides, the paragraph before the diagram cl= early states already
   that this is:
=09"The Source/T=
arget Link-layer Address option"

   which seems pretty explicit. Lef=
t it as it is.
3. reworded to "LoWPAN Broadcast"

thanks,
-gabriel

----- Original Message ----
From: Samita C= hakrabarti <samitac2@gmail.com>
To: gabriel montenegro <gabriel= _montenegro_2000@yahoo.com>
Cc:=0A dculler@archrock.com; jhui@archroc= k.com; nandakishore.kushalnagar@intel.com; 6lowpan@ietf.org
Sent: Wednes= day, January 24, 2007 7:47:52 PM
Subject: 6lowpan-format-09

= Hi Gabriel and all,

Finally I had a chance to read the latest versio= n of the draft. It
looks good with
the new style of format.

A = few minor  comments for the authors' consideration:

1)&nbs= p; Section 5.3 - the fragmentation format has 3bits + 10bits + 11bits<= br>fields for
    first fragment sub-header and 3+10= +11+8 for the subsequent fragments.
    Defining dat= a structure, parsing and casting will require some
clever bit-field
&= nbsp;   operations. I wonder if the fragmentation part has b= een
implemented and if the
    document can say a= cautionary word about any byte alignment issues that
   =  the implemntors should take care in the=0A implementation as the frag= mented
    packet will appear on the wire. For examp= le, implementation A's compiler
    puts a byte afte= r the first-fragment declaration and before the
data, while implemention= B does not do any padding.

2) Section 8 - Unicast address mapping. = The second paragraph actually refers to
   SLLA/TLLA option fr= om RFC2461. It is a bit confusing for the section heading,
   = please add another sub-heading before this paragraph:
   =     8.1 Source and Destination Link Layer Address Option map= ping

3) Section 11.1 Lowpan-BCO option
    Sh= ould we re-word the section header as "LowPan Broadcast
(LOWPAN_BCO)"&nb= sp; or similar ?
Why do we call this an "option" ? We are not calli= ng mesh-header or
fragment-header
as options.

   Als= o, do we add the sequence number in order to avoid=0A broadcasting duplicat= e
   packets from the same sender or originator in mesh? Pleas= e add a line on why
   we are adding the sequence number in th= is case.

Sorry for the late review, but these issues do not stop thi= s draft to
move forward for
the AD review. Nice job!

Regards,<= br>-Samita

____________________________= ___________________
6lowpan mailing list
6lowpan@ietf.org
https:= //www1.ietf.org/mailman/listinfo/6lowpan

--0-1157552645-1169778441=:79340-- --===============0971654886== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0971654886==-- From 6lowpan-bounces@ietf.org Mon Jan 29 20:59:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBiHX-0003X7-Eq; Mon, 29 Jan 2007 20:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBiHW-0003X1-Ud for 6lowpan@ietf.org; Mon, 29 Jan 2007 20:59:34 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBiHU-0000JZ-HG for 6lowpan@ietf.org; Mon, 29 Jan 2007 20:59:34 -0500 Received: by nf-out-0910.google.com with SMTP id l36so53723nfa for <6lowpan@ietf.org>; Mon, 29 Jan 2007 17:59:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fgjkwCUPAjXvIKjHurf2uz6cp+q4vRrKLvoymsogADsh8eGNiYaHIL/+ffMSlqjPCesgD42tFPYrBmTOwwyUe8i/p/ycLiniWLnkpgcGzKGsRnWpB+P/3MQx1xMA+jEMXfhTr4fPXmDHXsj1MfZkoFLKe9oygrYnfWitfAa1A2I= Received: by 10.82.175.2 with SMTP id x2mr220438bue.1170122369358; Mon, 29 Jan 2007 17:59:29 -0800 (PST) Received: by 10.82.182.11 with HTTP; Mon, 29 Jan 2007 17:59:29 -0800 (PST) Message-ID: <43b91d370701291759k19bb136s574a0a658c5e1f8c@mail.gmail.com> Date: Mon, 29 Jan 2007 17:59:29 -0800 From: "Samita Chakrabarti" To: "gabriel montenegro" In-Reply-To: <20070126022212.9368.qmail@web81907.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070126022212.9368.qmail@web81907.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: 6lowpan@ietf.org, dculler@archrock.com Subject: [6lowpan] Re: 6lowpan-format-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Gabriel, Please see my comments in-line. > About your comments: > > 1. Not sure what to do here. Are you saying that parsing is somehow trickier > now > than it was before the header change? The WG adopted the new header cuz > there > was consensus that things would be better, not worse. Are you saying they > are > worse? Beyond this, being careful in the implementation about bit fields > etc > is, well, part of the implementation, so I'm not sure what to do here (or > if > we need to do anything). Perhaps if you suggest some text it'll be easier > to see? > I actually like the new header changes. I particularly picked the fragment sub-header because it has got 11bits, 10bits and 3 bits for the first fragment. This particular one is not 32bit-word aligned and parsing and casting etc. will require some bit operations. In embedded systems at the low-level, this might be a common practice, but I was thinking if we could have some sort of text for the implementors in general. What do folks think about something like the following ? --- The fields and header segments, described in this document, are not always byte-aligned or 32-bit word aligned. The implementors of this document are responsible for sending and processing the data on the wire according to the specification for interoperability among different implementations. ---- > 2. Not sure why we need to add yet another sub-title for such a short > section. This is patterned after section 6 of: > > http://tools.ietf.org/html/rfc2464 > > which itself does not have such sub-title. > Besides, the paragraph before the diagram clearly states already > that this is: > "The Source/Target Link-layer Address option" > > which seems pretty explicit. Left it as it is. > If purpose of this section is to describe mapping of an unicast IPv6-address to IEEE802.15.4 link-layer address, then it is very helpful if the first sentence says that. ( like rfc2464). In that case, we can move the address resolution text at the end of the section. Currently, it is a bit confusing. Thanks for the prompt response and update. -Samita > > ----- Original Message ---- > From: Samita Chakrabarti > To: gabriel montenegro > Cc: dculler@archrock.com; jhui@archrock.com; > nandakishore.kushalnagar@intel.com; 6lowpan@ietf.org > Sent: Wednesday, January 24, 2007 7:47:52 PM > Subject: 6lowpan-format-09 > > Hi Gabriel and all, > > Finally I had a chance to read the latest version of the draft. It > looks good with > the new style of format. > > A few minor comments for the authors' consideration: > > 1) Section 5.3 - the fragmentation format has 3bits + 10bits + 11bits > fields for > first fragment sub-header and 3+10+11+8 for the subsequent fragments. > Defining data structure, parsing and casting will require some > clever bit-field > operations. I wonder if the fragmentation part has been > implemented and if the > document can say a cautionary word about any byte alignment issues that > the implemntors should take care in the implementation as the fragmented > packet will appear on the wire. For example, implementation A's compiler > puts a byte after the first-fragment declaration and before the > data, while implemention B does not do any padding. > > 2) Section 8 - Unicast address mapping. The second paragraph actually refers > to > SLLA/TLLA option from RFC2461. It is a bit confusing for the section > heading, > please add another sub-heading before this paragraph: > 8.1 Source and Destination Link Layer Address Option mapping > > 3) Section 11.1 Lowpan-BCO option > Should we re-word the section header as "LowPan Broadcast > (LOWPAN_BCO)" or similar ? > Why do we call this an "option" ? We are not calling mesh-header or > fragment-header > as options. > > Also, do we add the sequence number in order to avoid broadcasting > duplicate > packets from the same sender or originator in mesh? Please add a line on > why > we are adding the sequence number in this case. > > Sorry for the late review, but these issues do not stop this draft to > move forward for > the AD review. Nice job! > > Regards, > -Samita > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan