inline...
----- Original Message ----
From: Soohong Daniel Park <[EMAIL PROTECTED]>
To: 6lowpan <[email protected]>
Sent: Tuesday, April 11, 2006 11:36:09 PM
Subject: [6lowpan] Couple of questions from packet format document
From: Soohong Daniel Park <[EMAIL PROTECTED]>
To: 6lowpan <[email protected]>
Sent: Tuesday, April 11, 2006 11:36:09 PM
Subject: [6lowpan] Couple of questions from packet format document
Gabriel - While going through our packet format document,
a couple of questions happen in my side...Please clarify them.
[1] In section 9.1, this document says " the packet length
can be inferred from the layer two"...
I am not sure how it can be inferred from the layer two.
gab> good catch. Reworded as follows:
...the packet length
can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4
PPDU) or from the "datagram_size" field in the fragment header (if present),
[2] In section 9.2, UDP source/destination port is obtained
by calculating: P + short_port value. P is a predetermined
port number with value TBD. The short_port is expressed
as a 4-bit value which is carried "in-line" (Section 9.3.2).
I am not sure what you mean by short_port. I can't
see any relevant mention in Section 9.3.2.
gab> They just go inline as indicated in that section. The only difference is that instead of
taking 16 bits they take 4 bits. Added this to clarify:
If either the
source or destination ports are in "short_port" notation (as indicated
in the compressed UDP header), then instead of taking 16 bits, the inline
port numbers take 4 bits.
gab> I also added the IANA section to ask for assignment of this port number P for use
with short_port notation.
PS, just curious whether we should consider IPv6
extension from the Next Header perspective.
gab> not sure what you mean here. perhaps something you can bring up during WG last call.
Thanks,
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
a couple of questions happen in my side...Please clarify them.
[1] In section 9.1, this document says " the packet length
can be inferred from the layer two"...
I am not sure how it can be inferred from the layer two.
gab> good catch. Reworded as follows:
...the packet length
can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4
PPDU) or from the "datagram_size" field in the fragment header (if present),
[2] In section 9.2, UDP source/destination port is obtained
by calculating: P + short_port value. P is a predetermined
port number with value TBD. The short_port is expressed
as a 4-bit value which is carried "in-line" (Section 9.3.2).
I am not sure what you mean by short_port. I can't
see any relevant mention in Section 9.3.2.
gab> They just go inline as indicated in that section. The only difference is that instead of
taking 16 bits they take 4 bits. Added this to clarify:
If either the
source or destination ports are in "short_port" notation (as indicated
in the compressed UDP header), then instead of taking 16 bits, the inline
port numbers take 4 bits.
gab> I also added the IANA section to ask for assignment of this port number P for use
with short_port notation.
PS, just curious whether we should consider IPv6
extension from the Next Header perspective.
gab> not sure what you mean here. perhaps something you can bring up during WG last call.
Thanks,
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
