From fausto.vieira at uab.cat Sat Dec 1 12:52:00 2007 From: fausto.vieira at uab.cat (Fausto Vieira) Date: Sat, 01 Dec 2007 13:52:00 +0100 Subject: Header extension format differences between RFC4326 and draft-ietf-ipdvb-ule-ext-04.txt Message-ID: <475158F0.3050705@uab.cat> Hello all, I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my question has probably been raised before: Why is it that for the timestamp extension header, the format is: 0 7 15 23 31 +---------------+---------------+---------------+---------------+ | 0x03 | 0x01 | time stamp HI | +---------------+---------------+---------------+---------------+ | time stamp LO | Type | +---------------+---------------+---------------+---------------+ Figure 7 The format of the 32-bit Timestamp Extension Header where the HLEN (0x03) is at the start of the extension header, when in the RFC4326 the extension headers are defined as: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0|H-LEN| H-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Structure of ULE Next-Header Field Where it is stated that the H-Type is 8-bit and not 16-bit. To my knowledge, Ethertype should always be 16-bit. However, my question is: What is the meaning of the 0x01 byte in the Timestamp Header? Is this the 1 microsecond resolution value or is this some type of byte alignment? Many thanks Fausto Vieira From Knut.Eckstein at esa.int Sat Dec 1 14:08:51 2007 From: Knut.Eckstein at esa.int (Knut.Eckstein at esa.int) Date: Sat, 1 Dec 2007 15:08:51 +0100 Subject: Knut Eckstein is not in the office Message-ID: I will be out of the office starting 30/11/2007 and will not return until 03/12/2007. I will respond to your message as soon as I return. From gorry at erg.abdn.ac.uk Sun Dec 2 05:17:08 2007 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sat, 01 Dec 2007 21:17:08 -0800 Subject: Header extension format differences between RFC4326 and draft-ietf-ipdvb-ule-ext-04.txt In-Reply-To: <475158F0.3050705@uab.cat> References: <475158F0.3050705@uab.cat> Message-ID: <47523FD4.4020300@erg.abdn.ac.uk> Hello Fausto, See the answer in-line. Hope this clarifies things for you, best wishes, gorry Fausto Vieira wrote: > Hello all, > > I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my > question has probably been raised before: > > Why is it that for the timestamp extension header, the format is: > > 0 7 15 23 31 > +---------------+---------------+---------------+---------------+ > | 0x03 | 0x01 | time stamp HI | > +---------------+---------------+---------------+---------------+ > | time stamp LO | Type | > +---------------+---------------+---------------+---------------+ > > Figure 7 The format of the 32-bit Timestamp Extension Header > > where the HLEN (0x03) is at the start of the extension header, when in > the RFC4326 the extension headers are defined as: > The first byte, 0x03, contains the HLEN - i.e in this case, 3 16-bit words, from RFC4326: "3 Indicates an Optional Extension Header of length 6B (Type + 4B)" The IANA has assigned the H-Type of 1 decimal to the timestamp option: http://www.iana.org/assignments/ule-next-headers The entry is: Type Name H-LEN Reference ------ -------------------------- ----- --------- 257 Time-Stamp 3 [RFC-ietf-ipdvb-ule-ext-01.txt] This is a bit cryptic, but entries for Optional Extensions are recorded as 256+H-Type, or in hex 0x1hh where hh is the H-Type. So, the next field is 0x01. This and the previous byte together forms the 16-bit value that identifies this Extension Header. > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0 0|H-LEN| H-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Structure of ULE Next-Header Field > > > Where it is stated that the H-Type is 8-bit and not 16-bit. To my > knowledge, Ethertype should always be 16-bit. > RFC4326 states: "The H-Type is a one-byte field that is either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions." - so this forms the second byte of an extension header. > However, my question is: > What is the meaning of the 0x01 byte in the Timestamp Header? > Is this the 1 microsecond resolution value or is this some type of byte > alignment? > See above. > > Many thanks > > Fausto Vieira > > From bnocker at cosy.sbg.ac.at Sun Dec 2 12:45:37 2007 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Sun, 02 Dec 2007 13:45:37 +0100 Subject: Header extension format differences between RFC4326 and draft-ietf-ipdvb-ule-ext-04.txt In-Reply-To: <475158F0.3050705@uab.cat> References: <475158F0.3050705@uab.cat> Message-ID: <4752A8F1.5080609@cosy.sbg.ac.at> Hello Fausto, Fausto Vieira wrote: > Hello all, > > I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my > question has probably been raised before: > > Why is it that for the timestamp extension header, the format is: > > 0 7 15 23 31 > +---------------+---------------+---------------+---------------+ > | 0x03 | 0x01 | time stamp HI | > +---------------+---------------+---------------+---------------+ > | time stamp LO | Type | > +---------------+---------------+---------------+---------------+ > > Figure 7 The format of the 32-bit Timestamp Extension Header > > where the HLEN (0x03) is at the start of the extension header, when in > the RFC4326 the extension headers are defined as: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0 0|H-LEN| H-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Structure of ULE Next-Header Field > > > Where it is stated that the H-Type is 8-bit and not 16-bit. To my in RFC4326 as above. > knowledge, Ethertype should always be 16-bit. The introduction of "5. Extension Headers" in RFC4326 reads: A ULE Extension Header is identified by a 16-bit value in the Type field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN field, and an 8-bit H-Type field, as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0|H-LEN| H-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So, the H-Type field is NOT the Ethertype. Instead the 5+3+8 corresponds to Ethertype, whose values less then 1536 are "(ab)used" for ULE extension headers. Actually RFC4326 "5. Extension Headers" starts with this explanation: This section describes an extension format for the ULE encapsulation. In ULE, a Type field value less than 1536 decimal indicates an Extension Header. These values are assigned from a separate IANA registry defined for ULE. > However, my question is: > What is the meaning of the 0x01 byte in the Timestamp Header? First, in binary, the 0x03 reads 00000011 or in above syntax 00000 + 011 standing for (again according to RFC4326) an optional extension of length 6 Bytes consisting of Type + 4 bytes. The H-LEN Assignment is described below: 0 Indicates a Mandatory Extension Header 1 Indicates an Optional Extension Header of length 2B (Type only) 2 Indicates an Optional Extension Header of length 4B (Type + 2B) 3 Indicates an Optional Extension Header of length 6B (Type + 4B) 4 Indicates an Optional Extension Header of length 8B (Type + 6B) 5 Indicates an Optional Extension Header of length 10B (Type + 8B) >=6 The combined H-LEN and H-TYPE values indicate the EtherType of a PDU that directly follows this Type field. The H-LEN value indicates the total number of bytes in an Optional Extension Header (including the 2B Type field). Secondly, the 0x01 is to be interpreted according to RFC4326 as: The H-Type is a one-byte field that is either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions. The set of currently permitted values for both types of Extension Headers are defined by an IANA Registry (section 15). Registry values for Optional Extensions are specified in the form H=1 (i.e., a decimal number in the range 256-511), but may be used with an H-Length value in the range 1-5 (see example in section 5.3). "4. IANA Considerations" of draft-ietf-ipdvb-ule-ext-04.txt reads: Type Name H-LEN Reference 257: Timestamp 3 Section 3.3 I guess the confusion results from the fact that the binary representation of the Timestamp optional header is 00000 011 00000001 whose decimal representation is 769. Instead, it is just interpreted differently, because the range of optional headers is 256-511 where the 0x01 (H-Type) is indicating type 257. Before that, H-LEN=3 is indicating 6 bytes length of which 4B are for the timestamp value and 2B for the Type. > Is this the 1 microsecond resolution value or is this some type of byte > alignment? No, not at all, although the resolution is 1 microsecond. The 0x01 is the optional header of type 0x01 or 257. draft-ietf-ipdvb-ule-ext-04.txt further defines it as: The extension carries a 32-bit value (time stamp HI plus time stamp LO). The specified resolution is 1 microsecond. The value therefore indicates the number of 1 microsecond ticks past the hour in Universal Time when the PDU was encapsulated. This value may be earlier than the time of transmission due for example to Packing, queuing and other Encapsulator processing. The value is right-justified to the 32-bit field. Systems unable to insert timestamps at the specified resolution may use an arbitrary (and varying) value to pad the unused least-significant bits. The last two bytes carry a 16-bit Type field that indicates the type of payload carried in the SNDU, or the presence of a further Next-Header ([RFC4326], Section 4.4). > > Many thanks > Fausto Vieira Hope that helped further, Bernhard From fausto.vieira at uab.cat Sun Dec 2 13:12:14 2007 From: fausto.vieira at uab.cat (Fausto Vieira) Date: Sun, 02 Dec 2007 14:12:14 +0100 Subject: Header extension format differences between RFC4326 anddraft-ietf-ipdvb-ule-ext-04.txt In-Reply-To: <47523FD4.4020300@erg.abdn.ac.uk> References: <475158F0.3050705@uab.cat> <47523FD4.4020300@erg.abdn.ac.uk> Message-ID: <4752AF2E.10603@uab.cat> Hello Gorry, Many thanks for the explanation. I just have one follow up question: Is the 257 (0x0101) the Next-header Type that appears in the Type field before the Timestamp extension (probably in the ULE header)? Couldn't there be a problem if the Next-header Type field (257) and the H-type (1+256) don't match? Best regards Fausto Gorry Fairhurst wrote: > Hello Fausto, > > See the answer in-line. Hope this clarifies things for you, > > best wishes, > > gorry > > > Fausto Vieira wrote: >> Hello all, >> >> I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my >> question has probably been raised before: >> >> Why is it that for the timestamp extension header, the format is: >> >> 0 7 15 23 31 >> +---------------+---------------+---------------+---------------+ >> | 0x03 | 0x01 | time stamp HI | >> +---------------+---------------+---------------+---------------+ >> | time stamp LO | Type | >> +---------------+---------------+---------------+---------------+ >> >> Figure 7 The format of the 32-bit Timestamp Extension Header >> >> where the HLEN (0x03) is at the start of the extension header, when >> in the RFC4326 the extension headers are defined as: >> > The first byte, 0x03, contains the HLEN > - i.e in this case, 3 16-bit words, from RFC4326: > "3 Indicates an Optional Extension Header of length 6B (Type + 4B)" > > The IANA has assigned the H-Type of 1 decimal to the timestamp option: > http://www.iana.org/assignments/ule-next-headers > > The entry is: > Type Name H-LEN Reference > ------ -------------------------- ----- --------- > 257 Time-Stamp 3 [RFC-ietf-ipdvb-ule-ext-01.txt] > > This is a bit cryptic, but entries for Optional Extensions are > recorded as 256+H-Type, or in hex 0x1hh where hh is the H-Type. > > So, the next field is 0x01. This and the previous byte together forms > the 16-bit value that identifies this Extension Header. > >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 0 0|H-LEN| H-Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 7: Structure of ULE Next-Header Field >> >> >> Where it is stated that the H-Type is 8-bit and not 16-bit. To my >> knowledge, Ethertype should always be 16-bit. >> > RFC4326 states: > "The H-Type is a one-byte field that is either one of 256 Mandatory > Header Extensions or one of 256 Optional Header Extensions." > - so this forms the second byte of an extension header. > >> However, my question is: >> What is the meaning of the 0x01 byte in the Timestamp Header? >> Is this the 1 microsecond resolution value or is this some type of byte >> alignment? >> > See above. >> >> Many thanks >> >> Fausto Vieira >> >> > > From gorry at erg.abdn.ac.uk Sun Dec 2 16:34:13 2007 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sun, 02 Dec 2007 08:34:13 -0800 Subject: Header extension format differences between RFC4326 anddraft-ietf-ipdvb-ule-ext-04.txt In-Reply-To: <4752AF2E.10603@uab.cat> References: <475158F0.3050705@uab.cat> <47523FD4.4020300@erg.abdn.ac.uk> <4752AF2E.10603@uab.cat> Message-ID: <4752DE85.1050001@erg.abdn.ac.uk> No - each H-Type is only specified for the HLEN values described in the IANA registry, e.g. in this case 0x0101 would simply be invalid and ignored by the receiver (it would skip these bytes without interpreting them). GVorry Fausto Vieira wrote: > Hello Gorry, > > Many thanks for the explanation. > I just have one follow up question: > Is the 257 (0x0101) the Next-header Type that appears in the Type field > before the Timestamp extension (probably in the ULE header)? > > Couldn't there be a problem if the Next-header Type field (257) and the > H-type (1+256) don't match? > > Best regards > > Fausto > > > Gorry Fairhurst wrote: >> Hello Fausto, >> >> See the answer in-line. Hope this clarifies things for you, >> >> best wishes, >> >> gorry >> >> >> Fausto Vieira wrote: >>> Hello all, >>> >>> I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my >>> question has probably been raised before: >>> >>> Why is it that for the timestamp extension header, the format is: >>> >>> 0 7 15 23 31 >>> +---------------+---------------+---------------+---------------+ >>> | 0x03 | 0x01 | time stamp HI | >>> +---------------+---------------+---------------+---------------+ >>> | time stamp LO | Type | >>> +---------------+---------------+---------------+---------------+ >>> >>> Figure 7 The format of the 32-bit Timestamp Extension Header >>> >>> where the HLEN (0x03) is at the start of the extension header, when >>> in the RFC4326 the extension headers are defined as: >>> >> The first byte, 0x03, contains the HLEN >> - i.e in this case, 3 16-bit words, from RFC4326: >> "3 Indicates an Optional Extension Header of length 6B (Type + 4B)" >> >> The IANA has assigned the H-Type of 1 decimal to the timestamp option: >> http://www.iana.org/assignments/ule-next-headers >> >> The entry is: >> Type Name H-LEN Reference >> ------ -------------------------- ----- --------- >> 257 Time-Stamp 3 [RFC-ietf-ipdvb-ule-ext-01.txt] >> >> This is a bit cryptic, but entries for Optional Extensions are >> recorded as 256+H-Type, or in hex 0x1hh where hh is the H-Type. >> >> So, the next field is 0x01. This and the previous byte together forms >> the 16-bit value that identifies this Extension Header. >> >>> 0 1 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0 0 0 0 0|H-LEN| H-Type | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Figure 7: Structure of ULE Next-Header Field >>> >>> >>> Where it is stated that the H-Type is 8-bit and not 16-bit. To my >>> knowledge, Ethertype should always be 16-bit. >>> >> RFC4326 states: >> "The H-Type is a one-byte field that is either one of 256 Mandatory >> Header Extensions or one of 256 Optional Header Extensions." >> - so this forms the second byte of an extension header. >> >>> However, my question is: >>> What is the meaning of the 0x01 byte in the Timestamp Header? >>> Is this the 1 microsecond resolution value or is this some type of byte >>> alignment? >>> >> See above. >>> >>> Many thanks >>> >>> Fausto Vieira >>> >>> >> >> > > From gorry at erg.abdn.ac.uk Sun Dec 2 18:07:03 2007 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sun, 02 Dec 2007 10:07:03 -0800 Subject: ipdvb status update December 2007 Message-ID: <4752F447.5020207@erg.abdn.ac.uk> We did not request a meeting slot at IETF-70 (since the documents mostly do not require WG discussion this time). So here instead is a brief update on current activities. 1) ULE Security Requirements This document completed a review by DVB, a WGLC and a secdir review. The document was revised following the WGLC and is now being revised by the authors following the secdir comments. The new draft should provide a stronger more clear requirements section. 2) Extension Header Formats This document completed a review by DVB and a WGLC. The document has been submitted to the IESG by the WG Sectary (Martin will be the document Shepherd). 3) DVB-RCS MIB http://tools.ietf.org/wg/ipdvb/draft-combes-ipdvb-mib-rcs-01.txt I reviewed this, and suggested various places where things could be improved, and more work was needed. The authors now have a version of the RCS MIB that they would like guidance upon whether this seems like it is in a good format. My understanding is that the authors intend to freeze this specification (updated with any feedback) until 1Q2008, and then perform some implementation work. They then plan to update this and submit to our AD for a formal MIB Doctor review. 4) Security Extension Header There are two known implementations of variants of the Spec, - one in a test platform, one in a product. There is work on an open-source client. There is renewed interest to progress the draft: http://tools.ietf.org/wg/ipdvb/draft-cruickshank-ipdvb-sec-03.txt This work depends upon the succesful completion of (2). 5) We revised some of the milestone dates to: Dec 2007 Submit ULE Security Requirements to IESG Dec 2007 Progress the Encapsulation RFC along the IETF standards track Nov 2007 Submit Extension Header Formats to IESG for publication as PS Martin and I will be meeting this week to discuss progress, issues and any new work of which we are aware. If you would like to meet us, find out more, or tell us any ipdvb news, please be sure to get in touch. We'd love to hear from you Gorry & Martin (ipdvb WG Chair) ------------------------------- From gorry at erg.abdn.ac.uk Mon Dec 3 15:10:52 2007 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 03 Dec 2007 07:10:52 -0800 Subject: ipdvb status update December 2007 - errata In-Reply-To: <4752F447.5020207@erg.abdn.ac.uk> References: <4752F447.5020207@erg.abdn.ac.uk> Message-ID: <47541C7C.4040105@erg.abdn.ac.uk> There are two updates to this list (thanks michael and stephane for noting this). In (2) revision draft-combes-ipdvb-mib-rcs-02.txt has recently been submitted and will be published by the end of this week. In (4) I forgot to include a URL to the second draft: http://www.ietf.org/internet-drafts/draft-noisternig-ipdvb-ulesec-00.txt Best wishes, Gorry Gorry Fairhurst wrote: > > We did not request a meeting slot at IETF-70 (since the documents mostly > do not require WG discussion this time). So here instead is a brief > update on current activities. > > 1) ULE Security Requirements > This document completed a review by DVB, a WGLC and a secdir review. > > The document was revised following the WGLC and is now being revised by > the authors following the secdir comments. The new draft should provide > a stronger more clear requirements section. > > 2) Extension Header Formats > > This document completed a review by DVB and a WGLC. > The document has been submitted to the IESG by the WG Sectary > (Martin will be the document Shepherd). > > 3) DVB-RCS MIB > http://tools.ietf.org/wg/ipdvb/draft-combes-ipdvb-mib-rcs-01.txt > > I reviewed this, and suggested various places where things could be > improved, and more work was needed. The authors now have a version of > the RCS MIB that they would like guidance upon whether this seems like > it is in a good format. My understanding is that the authors intend to > freeze this specification (updated with any feedback) until 1Q2008, and > then perform some implementation work. They then plan to update this and > submit to our AD for a formal MIB Doctor review. > > > 4) Security Extension Header > There are two known implementations of variants of the Spec, - one in a > test platform, one in a product. There is work on an open-source client. > There is renewed interest to progress the draft: > http://tools.ietf.org/wg/ipdvb/draft-cruickshank-ipdvb-sec-03.txt > This work depends upon the succesful completion of (2). > > > 5) We revised some of the milestone dates to: > > Dec 2007 Submit ULE Security Requirements to IESG > Dec 2007 Progress the Encapsulation RFC along the IETF standards track > Nov 2007 Submit Extension Header Formats to IESG for publication as PS > > Martin and I will be meeting this week to discuss progress, issues and > any new work of which we are aware. If you would like to meet us, find > out more, or tell us any ipdvb news, please be sure to get in touch. > > We'd love to hear from you > > Gorry & Martin > (ipdvb WG Chair) > ------------------------------- > > > > > >