Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
From: Stephen Farrell <[email-masked]>
To: Manikantan Ramadas <[email-masked]>
Cc: DTNRG <[email-masked]>
Date: Tue, 28 Jun 2005 11:24:26 +0100
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Hi Mani,

On the limits thing. I don't mind what figures
we use, but have a slight preference for a smaller
"SHOULD NOT emit" and a somewhat bigger "MUST be
able to decode". I'd probably have a hard time
justifying it though:-)

As for specific things like LTP extensions - I wasn't
saying that every single use of SDNV has to have
associated limits, but rather that for some cases, we
can usefully refine the general limits. Code that only
enforces the general limits remains conformant, so
long as all the specific cases are smaller than the
general limit, which is only sensible. Not that big
a deal, but maybe useful for some heuristic firewall
rules or stuff like that.

Stephen.

Manikantan Ramadas wrote:

> Hi Stephen,
> 
> On Mon, Jun 27, 2005 at 03:56:35PM +0100, Stephen Farrell wrote:
> 
>>I like this too.
>>
> 
>   Good.
>   
> 
>>I agree that if we base on ASN.1, then we should (re-)define
>>the scheme in our documents - ASN.1 encoding just has too
>>many potential wrinkles to handle referencing (e.g. see
>>the "ASN.1 notes" appendix to RFC 3280 [1]).
>>
> 
> 
>   Yep, this just reinforces my impression of how huge a beast ASN.1 is.
>   
> 
>>Without (I hope) being too pedantic, I think the encoding
>>scheme you're referring to isn't for OIDs, but for OID
>>arcs - an OID is actually a sequence of arcs, with an
>>overall TAG (0x06) and a length, at least in BER/DER.
>>But that's just a nit resulting in an additional word
>>in our specs, i.e. "The SDNV encoding scheme is based
>>on the ASN.1 scheme for encoding Object Identitifer arcs."
> 
> 
>   Ok. I shall take your word on this one. I didn't spend more than 1/2 hours
> reading on ASN.1's encoding scheme. Lets reference ASN.1 specifics properly
> as you suggest.
> 
> 
>>As it turned out, almost no-one supported arcs bigger
>>than 32 bits in their PKI code, so the above mentioned
>>RFC includes a restriction to not go there.
>>
> 
>    
> 
>>As you guys said, the scheme is good for 3/4 byte values,
>>but not so good for bigger things like signatures/keys.
>>Perhaps digests and MACs are on the edge (where values
>>are about 20/32 bytes long), but the flexibility is good
>>for things like nonces (in mainly collision-resistant
>>contexts) or identifiers where different implementations
>>might have very different scaling requirements. If we do
>>do this, we should however impose some limits on the max
>>values we expect code to generate and be able to accept
>>using this scheme. In general I'd suggest that code
>>SHOULD NOT generate more than 64 octet-long encoded
>>SDNVs but MUST be able too decode up to 1024 byte
>>encodings. (No, I've no justification at all for those
>>numbers:-)
> 
> 
>   Any specific reason why you want to allow decoding upto 1024 byte values?
> Its good to be "liberal in what we accept", but 1024 byte encoding has a 128
> byte overhead which seems too much to me. For the places where we use SDNVs
> (in LTP at least) allowing an atmost limit of 64 octets seems sufficient
> even for decoding. This would of course restrict the size of any "length"
> parameter encoded to be atmost 2^56 (65536 TB), which means the "V" in a TLV
> could be atmost this size,  which seems plenty at least
> for a few decades [at the cost of making one of those famous last-word
> statements, of course :-)] 
> 
> 
>>For particluar fields using SDNVs, it may
>>also make sense to impose more fine-grained limits.
>>
>>Having to define these limits is a disadvantage of
>>changing from the last scheme, but worth taking the
>>hit IMO.
>>
> 
>   Yep. But as you say, it may not be that big a deal, at least for the
> fields we have in mind for encoding in SDNVs in the LTP draft.
> 
> 
>>And for our LTP extension scheme, we still have to
>>have a straight TLV with the L encoded as an SDNV, using
>>at least an octet, even if V is short (e.g. also a single
>>octet). For LTP extensions, I'd tighten the limits
>>above so that the encoded SDNV (which encodes the
>>extension value length), MUST be at most 3 bytes
>>(~16MB extension value). Note that this means that
>>implementations therefore have to be able to decode
>>that SDNV, but (say if they've only a total of
>>8MB of memory), they may not actually be able to
>>handle the entire extension value, but they still
>>remain conformant.
>>
> 
>   I understand your point, but just feel that having to define the maximum
> size SDNV permissible for each and every SDNV field would make the spec.
> unnecessarily tedious. I would rather have them be soft-limits defined with
> a SHOULD, citing reasonable atmost values for the fields, and let
> the protocol either silently discard the packet if it found found an SDNV
> field too large to handle and bump up an error-counter, or alternately send a
> protocol specific mechanism to indicate peer of this problem.
> 
> - Mani.
> 

Date: Mon, 27 Jun 2005 17:33:49 -0400
From: Manikantan Ramadas <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Sender: [email-masked]

Hi Stephen,

On Mon, Jun 27, 2005 at 03:56:35PM +0100, Stephen Farrell wrote:
> 
> I like this too.
>
  Good.
  
> I agree that if we base on ASN.1, then we should (re-)define
> the scheme in our documents - ASN.1 encoding just has too
> many potential wrinkles to handle referencing (e.g. see
> the "ASN.1 notes" appendix to RFC 3280 [1]).
> 

  Yep, this just reinforces my impression of how huge a beast ASN.1 is.
  
> Without (I hope) being too pedantic, I think the encoding
> scheme you're referring to isn't for OIDs, but for OID
> arcs - an OID is actually a sequence of arcs, with an
> overall TAG (0x06) and a length, at least in BER/DER.
> But that's just a nit resulting in an additional word
> in our specs, i.e. "The SDNV encoding scheme is based
> on the ASN.1 scheme for encoding Object Identitifer arcs."

  Ok. I shall take your word on this one. I didn't spend more than 1/2 hours
reading on ASN.1's encoding scheme. Lets reference ASN.1 specifics properly
as you suggest.

> As it turned out, almost no-one supported arcs bigger
> than 32 bits in their PKI code, so the above mentioned
> RFC includes a restriction to not go there.
> 
   
> As you guys said, the scheme is good for 3/4 byte values,
> but not so good for bigger things like signatures/keys.
> Perhaps digests and MACs are on the edge (where values
> are about 20/32 bytes long), but the flexibility is good
> for things like nonces (in mainly collision-resistant
> contexts) or identifiers where different implementations
> might have very different scaling requirements. If we do
> do this, we should however impose some limits on the max
> values we expect code to generate and be able to accept
> using this scheme. In general I'd suggest that code
> SHOULD NOT generate more than 64 octet-long encoded
> SDNVs but MUST be able too decode up to 1024 byte
> encodings. (No, I've no justification at all for those
> numbers:-)

  Any specific reason why you want to allow decoding upto 1024 byte values?
Its good to be "liberal in what we accept", but 1024 byte encoding has a 128
byte overhead which seems too much to me. For the places where we use SDNVs
(in LTP at least) allowing an atmost limit of 64 octets seems sufficient
even for decoding. This would of course restrict the size of any "length"
parameter encoded to be atmost 2^56 (65536 TB), which means the "V" in a TLV
could be atmost this size,  which seems plenty at least
for a few decades [at the cost of making one of those famous last-word
statements, of course :-)] 

> For particluar fields using SDNVs, it may
> also make sense to impose more fine-grained limits.
> 
> Having to define these limits is a disadvantage of
> changing from the last scheme, but worth taking the
> hit IMO.
>
  Yep. But as you say, it may not be that big a deal, at least for the
fields we have in mind for encoding in SDNVs in the LTP draft.

> And for our LTP extension scheme, we still have to
> have a straight TLV with the L encoded as an SDNV, using
> at least an octet, even if V is short (e.g. also a single
> octet). For LTP extensions, I'd tighten the limits
> above so that the encoded SDNV (which encodes the
> extension value length), MUST be at most 3 bytes
> (~16MB extension value). Note that this means that
> implementations therefore have to be able to decode
> that SDNV, but (say if they've only a total of
> 8MB of memory), they may not actually be able to
> handle the entire extension value, but they still
> remain conformant.
> 
  I understand your point, but just feel that having to define the maximum
size SDNV permissible for each and every SDNV field would make the spec.
unnecessarily tedious. I would rather have them be soft-limits defined with
a SHOULD, citing reasonable atmost values for the fields, and let
the protocol either silently discard the packet if it found found an SDNV
field too large to handle and bump up an error-counter, or alternately send a
protocol specific mechanism to indicate peer of this problem.

- Mani.

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Mon, 27 Jun 2005 16:36:44 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Sender: [email-masked]

Scott,

> I think we should both refer to the ASN.1 standard and also provide a 
> brief recap in the LTP and Bundle Protocol specs for the convenience of 
> the reader, with the caveat that anyone who wants to be sure to be 
> ASN.1-conformant has got to go to the source documents.  

Not sure 'bout that - which year's ASN.1 and which document(s) will
you use? I've been playing with this stuff, sometimes in
excruciating detail, for years now and couldn't tell you off the
top of my head (its a bit of a moving target due to a number of
things, e.g. ISO trying to make ASN.1 base specs free, new
encoding rules, changes to the language, etc.)

 > But we don't
> want to give the impression that we're starting our own branch of ASN.1 
> variants; if we're going to go with that standard, let's commit to it 
> properly.

We're not committing to ASN.1 - if we were then all of the bundling
and LTP PDUs would be defined that way and we'd have to have appendices
with ASN.1 modules (identified using registered OIDs btw) and lots
of other stuff. We're cherry-picking one very, very tiny bit of
the distinguished encoding rules for OID arcs, that's all. The
reference to the ASN.1 specs is informative and not normative.

Stephen.

Date: Mon, 27 Jun 2005 08:20:21 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Sender: [email-masked]

Michael Demmer wrote:

>In spite of the fact that I proposed the SDNV design that we agreed
>upon, I too am throwing my weight behind the ASN.1 encoding. I agree
>with Mani's conjecture that most of the values that we'll be
>representing will be fewer than four octets in length, hence the ASN.1
>standard offers efficiency advantages.
>
>I also agree with Jacob that knowing the total length based on the
>first octet is not a significant concern.
>  
>
Yep, I agree with this too.  It's a nice design.

>If we do decide to adopt this encoding, one question at hand is
>whether we want to simply reference the ASN.1 standard or explicitly
>spell out the encoding in the Bundle Protocol Specification (and
>possibly the LTP spec).
>
>I'd personally lean towards the latter since it keeps our
>specification self-contained, so someone reading it doesn't need to go
>dig through the myriad of ASN.1 documents to find the encoding.  It
>also keeps us a bit more insulated from potential changes to those
>other specifications, though I have no idea as to whether or not
>that's even a real concern.
>  
>
I think we should both refer to the ASN.1 standard and also provide a 
brief recap in the LTP and Bundle Protocol specs for the convenience of 
the reader, with the caveat that anyone who wants to be sure to be 
ASN.1-conformant has got to go to the source documents.  But we don't 
want to give the impression that we're starting our own branch of ASN.1 
variants; if we're going to go with that standard, let's commit to it 
properly.

Scott

Date: Mon, 27 Jun 2005 15:56:35 +0100
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: Manikantan Ramadas <[email-masked]>, DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Sender: [email-masked]

I like this too.

I agree that if we base on ASN.1, then we should (re-)define
the scheme in our documents - ASN.1 encoding just has too
many potential wrinkles to handle referencing (e.g. see
the "ASN.1 notes" appendix to RFC 3280 [1]).

Without (I hope) being too pedantic, I think the encoding
scheme you're referring to isn't for OIDs, but for OID
arcs - an OID is actually a sequence of arcs, with an
overall TAG (0x06) and a length, at least in BER/DER.
But that's just a nit resulting in an additional word
in our specs, i.e. "The SDNV encoding scheme is based
on the ASN.1 scheme for encoding Object Identitifer arcs."
As it turned out, almost no-one supported arcs bigger
than 32 bits in their PKI code, so the above mentioned
RFC includes a restriction to not go there.

As you guys said, the scheme is good for 3/4 byte values,
but not so good for bigger things like signatures/keys.
Perhaps digests and MACs are on the edge (where values
are about 20/32 bytes long), but the flexibility is good
for things like nonces (in mainly collision-resistant
contexts) or identifiers where different implementations
might have very different scaling requirements. If we do
do this, we should however impose some limits on the max
values we expect code to generate and be able to accept
using this scheme. In general I'd suggest that code
SHOULD NOT generate more than 64 octet-long encoded
SDNVs but MUST be able too decode up to 1024 byte
encodings. (No, I've no justification at all for those
numbers:-) For particluar fields using SDNVs, it may
also make sense to impose more fine-grained limits.

Having to define these limits is a disadvantage of
changing from the last scheme, but worth taking the
hit IMO.

And for our LTP extension scheme, we still have to
have a straight TLV with the L encoded as an SDNV, using
at least an octet, even if V is short (e.g. also a single
octet). For LTP extensions, I'd tighten the limits
above so that the encoded SDNV (which encodes the
extension value length), MUST be at most 3 bytes
(~16MB extension value). Note that this means that
implementations therefore have to be able to decode
that SDNV, but (say if they've only a total of
8MB of memory), they may not actually be able to
handle the entire extension value, but they still
remain conformant.

Stephen.

[1] http://www.ietf.org/rfc/rfc3280.txt

Michael Demmer wrote:

>>  This encoding scheme falls under ASN.1 encoding
>>of object IDs, I think. They also have a separate encoding scheme for length
>>parameters. I read about this scheme from Dr.Comer's TCP/IP Illustrated
>>Vol.II (Design/Implementation), and understand that the ASN.1 standards
>>overall is a huge beast designed as a generic standard for various purposes.
>>I tend to agree with you that (assuming we have a consensus on this scheme),
>>we are better of saying to the tune of :
>>
>>"The SDNV encoding scheme is based on the ASN.1 scheme for encoding Object
>>IDs.." and then spell out what it is with a few examples. I think the scheme
>>itself is simple enough to comprehend. 
> 
> 
> This sounds good to me.
> 
> 
>>I don't know if we can add the following in any of the specs. 
>>But I think it would be useful if we also add a note that the ASN.1 SDNV
>>scheme is suboptimal for encoding very large numbers - 1024 bit RSA public
>>keys for example, since 1/8th of the length is consumed for making it
>>variable in size. For encoding variable length quantities
>>that could typically be more than 64 bit long (a double or a long long), the
>>overhead becomes killing and we are better off having a length field
>>specified as an SDNV with the data of the specified length following.
> 
> 
> Agreed as well. 
> 
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Sun, 26 Jun 2005 12:47:48 -0700
From: Michael Demmer <[email-masked]>
To: Manikantan Ramadas <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Mail-Followup-To: Manikantan Ramadas <[email-masked]>, DTNRG <[email-masked]>
Sender: [email-masked]

>   This encoding scheme falls under ASN.1 encoding
> of object IDs, I think. They also have a separate encoding scheme for length
> parameters. I read about this scheme from Dr.Comer's TCP/IP Illustrated
> Vol.II (Design/Implementation), and understand that the ASN.1 standards
> overall is a huge beast designed as a generic standard for various purposes.
> I tend to agree with you that (assuming we have a consensus on this scheme),
> we are better of saying to the tune of :
> 
> "The SDNV encoding scheme is based on the ASN.1 scheme for encoding Object
> IDs.." and then spell out what it is with a few examples. I think the scheme
> itself is simple enough to comprehend. 

This sounds good to me.

> I don't know if we can add the following in any of the specs. 
> But I think it would be useful if we also add a note that the ASN.1 SDNV
> scheme is suboptimal for encoding very large numbers - 1024 bit RSA public
> keys for example, since 1/8th of the length is consumed for making it
> variable in size. For encoding variable length quantities
> that could typically be more than 64 bit long (a double or a long long), the
> overhead becomes killing and we are better off having a length field
> specified as an SDNV with the data of the specified length following.

Agreed as well. 

-m

Date: Sun, 26 Jun 2005 15:43:30 -0400
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Sender: [email-masked]

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Mike,

On Sun, Jun 26, 2005 at 11:16:23AM -0700, Michael Demmer wrote:
>=20
> In spite of the fact that I proposed the SDNV design that we agreed
> upon, I too am throwing my weight behind the ASN.1 encoding. I agree
> with Mani's conjecture that most of the values that we'll be
> representing will be fewer than four octets in length, hence the ASN.1
> standard offers efficiency advantages.
>
  Good.
 =20
> I also agree with Jacob that knowing the total length based on the
> first octet is not a significant concern.
>=20
  Yep.
 =20
> If we do decide to adopt this encoding, one question at hand is
> whether we want to simply reference the ASN.1 standard or explicitly
> spell out the encoding in the Bundle Protocol Specification (and
> possibly the LTP spec).
>=20
> I'd personally lean towards the latter since it keeps our
> specification self-contained, so someone reading it doesn't need to go
> dig through the myriad of ASN.1 documents to find the encoding.  It
> also keeps us a bit more insulated from potential changes to those
> other specifications, though I have no idea as to whether or not
> that's even a real concern.

  This encoding scheme falls under ASN.1 encoding
of object IDs, I think. They also have a separate encoding scheme for length
parameters. I read about this scheme from Dr.Comer's TCP/IP Illustrated
Vol.II (Design/Implementation), and understand that the ASN.1 standards
overall is a huge beast designed as a generic standard for various purposes.
I tend to agree with you that (assuming we have a consensus on this scheme),
we are better of saying to the tune of :

"The SDNV encoding scheme is based on the ASN.1 scheme for encoding Object
IDs.." and then spell out what it is with a few examples. I think the scheme
itself is simple enough to comprehend.=20

I don't know if we can add the following in any of the specs.=20
But I think it would be useful if we also add a note that the ASN.1 SDNV
scheme is suboptimal for encoding very large numbers - 1024 bit RSA public
keys for example, since 1/8th of the length is consumed for making it
variable in size. For encoding variable length quantities
that could typically be more than 64 bit long (a double or a long long), the
overhead becomes killing and we are better off having a length field
specified as an SDNV with the data of the specified length following.

- Mani.

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--KsGdsel6WgEHnImy
Content-Type: application/pgp-signature
Content-Disposition: inline

--KsGdsel6WgEHnImy--

Date: Sun, 26 Jun 2005 11:16:23 -0700
From: Michael Demmer <[email-masked]>
To: Jakob Eriksson <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Mail-Followup-To: Jakob Eriksson <[email-masked]>, DTNRG <[email-masked]>
Sender: [email-masked]

In spite of the fact that I proposed the SDNV design that we agreed
upon, I too am throwing my weight behind the ASN.1 encoding. I agree
with Mani's conjecture that most of the values that we'll be
representing will be fewer than four octets in length, hence the ASN.1
standard offers efficiency advantages.

I also agree with Jacob that knowing the total length based on the
first octet is not a significant concern.

If we do decide to adopt this encoding, one question at hand is
whether we want to simply reference the ASN.1 standard or explicitly
spell out the encoding in the Bundle Protocol Specification (and
possibly the LTP spec).

I'd personally lean towards the latter since it keeps our
specification self-contained, so someone reading it doesn't need to go
dig through the myriad of ASN.1 documents to find the encoding.  It
also keeps us a bit more insulated from potential changes to those
other specifications, though I have no idea as to whether or not
that's even a real concern.

-mike

> I've tried to stay out of the SDNV discussion before, but now that 
> there's a sympathizer, I guess I'll chime in ;-). I second Mani's 
> motion.
> 
> The only reason I can think of, at the moment, that SDNV's would be 
> better is that you know how long the number is after looking at the 
> first octet. With ASN.1-style numbers, you have to scan the entire 
> number to figure out how long it is. I sincerely doubt that this is a 
> big deal though.
> 
> - Jakob
> 
> On Jun 24, 2005, at 4:08 PM, Manikantan Ramadas wrote:
> 
> >Hi folks,
> >
> >  Sorry to bring up yet another discussion on SDNVs when you all 
> >thought it
> >was over with :-) I was just about beginning to update our LTP 
> >specification
> >draft (which is expiring shortly) when I went ahead and read what the 
> >ASN.1
> >standard for representing variable length objects was. It offers
> >advantages over our last SDNV-consensus that seem hard to ignore.
> >
> >Summarizing our last-agreed-upon SDNV scheme : we had the first 4 MSB 
> >bits of
> >the first octet of the SDNV act as the discriminant. If the first MSB 
> >bit
> >was 0, then the following 7 bits stored the value (0-127); if the
> >first MSB bit was 1, the value v found from
> >the remaining 3 bits of the discriminant told us the length, and the
> >value was found by concatenating the 4 LSB bits of the first octet
> >with the following v+1 octets. So, the SDNV as a whole was atmost 9 
> >octets
> >long encoding a value atmost 2^68 -1.
> >
> >Please bear with me for being pedantic here..
> >
> >The ASN.1 scheme is conceptually even simpler. An ASN.1 variable could 
> >be
> >infinitely long. Each octet has its MSB bit consumed for indicating
> >whether it is the last octet (MSB=0) of the variable or not (MSB=1).
> >
> >To give few examples :
> >
> >
> >    0xABC : 1010 1011 1100 is represented as
> >            {100 1010 1} {0 011 1100}
> >
> >    0x1234 : 0001 0010 0011 0100 is represneted as
> >            {100000  00}  {1 01 0010 0} {0 011 0100}
> >
> >Note that decimal 127 : 0x7F is still represented in one octet as 
> >{0111 1111}
> >
> >Essentially all this ASN.1 scheme does differently is to distribute 
> >the load
> >of variable-length-capability to every octet, which offers benefits if 
> >the
> >length of the variable is relatively low (< 4 octets for example).
> >This small table illustrates how the ASN.1 scheme fares with our
> >current SDNV consensus :
> >
> >Octets        Maximum Value Supported
> >consumed      SDNV-current      ASN.1
> >--------      ------------     -------
> >    1            127              127
> >    2            2^12-1 (4095)    2^14-1 (16383)
> >    3            2^20-1 (~1MB)    2^21-1 (~2MB)
> >    4            2^28-1 (256MB)   2^28-1 (256MB)
> >    5            2^36-1 (64GB)    2^35-1 (32GB)
> >    6            2^44-1           2^42-1
> >    7            2^52-1           2^49-1
> >    8            2^60-1           2^56-1
> >    9            2^68-1           2^63-1
> >
> >Obviously we lose performance if our typical values are above 2^35 = 
> >32 GB.
> >Basically, it all depends on what we want to optimize.
> >For representing 32-bit integer values, which in my opinion are the
> >"typical" values of the fields in protocol headers where SDNVs are 
> >used, the
> >ASN.1 scheme seems more attractive. In LTP we use them for block 
> >length,
> >block offset, various sequence numbers and such. An added advantage is 
> >that
> >such an SDNV scheme can encode a value, in theory, infinitely long.
> >
> >What do you guys think?
> >
> >- Mani.
> >
> >
> >-- 
> >"'Beauty is truth, truth beauty,'--that is all
> >  Ye know on earth, and all ye need to know." - John Keats
> >____________________________________________________________________
> >
> >* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
> >____________________________________________________________________
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> Jakob Eriksson
> Ph.D. Candidate
> http://www.cs.ucr.edu/~jeriksson
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] Representing SDNVs using ASN.1 notation
Date: Fri, 24 Jun 2005 16:36:17 -0700
To: DTNRG <[email-masked]>
Sender: [email-masked]

I've tried to stay out of the SDNV discussion before, but now that 
there's a sympathizer, I guess I'll chime in ;-). I second Mani's 
motion.

The only reason I can think of, at the moment, that SDNV's would be 
better is that you know how long the number is after looking at the 
first octet. With ASN.1-style numbers, you have to scan the entire 
number to figure out how long it is. I sincerely doubt that this is a 
big deal though.

- Jakob

On Jun 24, 2005, at 4:08 PM, Manikantan Ramadas wrote:

> Hi folks,
>
>   Sorry to bring up yet another discussion on SDNVs when you all 
> thought it
> was over with :-) I was just about beginning to update our LTP 
> specification
> draft (which is expiring shortly) when I went ahead and read what the 
> ASN.1
> standard for representing variable length objects was. It offers
> advantages over our last SDNV-consensus that seem hard to ignore.
>
> Summarizing our last-agreed-upon SDNV scheme : we had the first 4 MSB 
> bits of
> the first octet of the SDNV act as the discriminant. If the first MSB 
> bit
> was 0, then the following 7 bits stored the value (0-127); if the
> first MSB bit was 1, the value v found from
> the remaining 3 bits of the discriminant told us the length, and the
> value was found by concatenating the 4 LSB bits of the first octet
> with the following v+1 octets. So, the SDNV as a whole was atmost 9 
> octets
> long encoding a value atmost 2^68 -1.
>
> Please bear with me for being pedantic here..
>
> The ASN.1 scheme is conceptually even simpler. An ASN.1 variable could 
> be
> infinitely long. Each octet has its MSB bit consumed for indicating
> whether it is the last octet (MSB=0) of the variable or not (MSB=1).
>
> To give few examples :
>
>
>     0xABC : 1010 1011 1100 is represented as
>             {100 1010 1} {0 011 1100}
>
>     0x1234 : 0001 0010 0011 0100 is represneted as
>             {100000  00}  {1 01 0010 0} {0 011 0100}
>
> Note that decimal 127 : 0x7F is still represented in one octet as 
> {0111 1111}
>
> Essentially all this ASN.1 scheme does differently is to distribute 
> the load
> of variable-length-capability to every octet, which offers benefits if 
> the
> length of the variable is relatively low (< 4 octets for example).
> This small table illustrates how the ASN.1 scheme fares with our
> current SDNV consensus :
>
> Octets        Maximum Value Supported
> consumed      SDNV-current      ASN.1
> --------      ------------     -------
>     1            127              127
>     2            2^12-1 (4095)    2^14-1 (16383)
>     3            2^20-1 (~1MB)    2^21-1 (~2MB)
>     4            2^28-1 (256MB)   2^28-1 (256MB)
>     5            2^36-1 (64GB)    2^35-1 (32GB)
>     6            2^44-1           2^42-1
>     7            2^52-1           2^49-1
>     8            2^60-1           2^56-1
>     9            2^68-1           2^63-1
>
> Obviously we lose performance if our typical values are above 2^35 = 
> 32 GB.
> Basically, it all depends on what we want to optimize.
> For representing 32-bit integer values, which in my opinion are the
> "typical" values of the fields in protocol headers where SDNVs are 
> used, the
> ASN.1 scheme seems more attractive. In LTP we use them for block 
> length,
> block offset, various sequence numbers and such. An added advantage is 
> that
> such an SDNV scheme can encode a value, in theory, infinitely long.
>
> What do you guys think?
>
> - Mani.
>
>
> -- 
> "'Beauty is truth, truth beauty,'--that is all
>   Ye know on earth, and all ye need to know." - John Keats
> ____________________________________________________________________
>
> * Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
> ____________________________________________________________________
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

Date: Fri, 24 Jun 2005 19:08:59 -0400
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Representing SDNVs using ASN.1 notation
Sender: [email-masked]

Hi folks,

  Sorry to bring up yet another discussion on SDNVs when you all thought it
was over with :-) I was just about beginning to update our LTP specification
draft (which is expiring shortly) when I went ahead and read what the ASN.1
standard for representing variable length objects was. It offers
advantages over our last SDNV-consensus that seem hard to ignore.

Summarizing our last-agreed-upon SDNV scheme : we had the first 4 MSB bits of
the first octet of the SDNV act as the discriminant. If the first MSB bit
was 0, then the following 7 bits stored the value (0-127); if the
first MSB bit was 1, the value v found from
the remaining 3 bits of the discriminant told us the length, and the
value was found by concatenating the 4 LSB bits of the first octet
with the following v+1 octets. So, the SDNV as a whole was atmost 9 octets
long encoding a value atmost 2^68 -1.

Please bear with me for being pedantic here..

The ASN.1 scheme is conceptually even simpler. An ASN.1 variable could be
infinitely long. Each octet has its MSB bit consumed for indicating
whether it is the last octet (MSB=0) of the variable or not (MSB=1).

To give few examples :

    0xABC : 1010 1011 1100 is represented as
            {100 1010 1} {0 011 1100}

    0x1234 : 0001 0010 0011 0100 is represneted as     
            {100000  00}  {1 01 0010 0} {0 011 0100}
            
Note that decimal 127 : 0x7F is still represented in one octet as {0111 1111}

Essentially all this ASN.1 scheme does differently is to distribute the load
of variable-length-capability to every octet, which offers benefits if the
length of the variable is relatively low (< 4 octets for example).
This small table illustrates how the ASN.1 scheme fares with our
current SDNV consensus :

Octets        Maximum Value Supported                            
consumed      SDNV-current      ASN.1
--------      ------------     -------
    1            127              127
    2            2^12-1 (4095)    2^14-1 (16383)
    3            2^20-1 (~1MB)    2^21-1 (~2MB)
    4            2^28-1 (256MB)   2^28-1 (256MB)
    5            2^36-1 (64GB)    2^35-1 (32GB)
    6            2^44-1           2^42-1
    7            2^52-1           2^49-1
    8            2^60-1           2^56-1
    9            2^68-1           2^63-1
    
Obviously we lose performance if our typical values are above 2^35 = 32 GB.
Basically, it all depends on what we want to optimize. 
For representing 32-bit integer values, which in my opinion are the 
"typical" values of the fields in protocol headers where SDNVs are used, the
ASN.1 scheme seems more attractive. In LTP we use them for block length,
block offset, various sequence numbers and such. An added advantage is that
such an SDNV scheme can encode a value, in theory, infinitely long. 

What do you guys think?

- Mani.

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Fri, 24 Jun 2005 10:51:42 -0600
From: gtmbht <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] turbo code modules
Sender: [email-masked]

Hello all,

I was wondering if there are any turbo code modules for encoding and decoding 
a certain number of bits that have been provided?

Thank You

Gautam Bhatia

----------------------------------------------------------------------
Gautam Bhatia
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins CO - 80523
Tel:(970)-215-6316
Email: [email-masked]
----------------------------------------------------------------------

Date: Wed, 15 Jun 2005 09:12:00 -0700
To: gtmbht <[email-masked]>, [email-masked]
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] length of turbo codes
Sender: [email-masked]

--============_-1093270574==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

No easy answer since it depends on your appplication - you have to 
trade off bit efficiency (coding overhead) versus energy per bit 
considerations, etc.

Try Googling on "LDPC codes JPL" and look at some of the CCSDS papers there!
http://www.ldpc-codes.com/index.html is good too..

Leigh

At 9:36 AM -0600 6/14/05, gtmbht wrote:
>Hello all,
>
>Can someone please tell me what the optimum length and rate of turbo codes
>would be for deep space links?( or what would the block size of inner and
>outer code would be)
>
>Thank You
>
>Gautam Bhatia
>
>----------------------------------------------------------------------
>Gautam Bhatia
>Department of Electrical and Computer Engineering
>Colorado State University
>Fort Collins CO - 80523
>Tel:(970)-215-6316
>Email: [email-masked]
>----------------------------------------------------------------------
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------
--============_-1093270574==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [dtn-interest] length of turbo
codes</title></head><body>
<div>No easy answer since it depends on your appplication - you have
to trade off bit efficiency (coding overhead) versus energy per bit
considerations, etc.</div>
<div><br></div>
<div>Try Googling on &quot;<font face="Lucida Grande" size="+1"
color="#000000">LDPC codes JPL&quot;</font><font color="#000000"> and
look at some of the CCSDS papers</font> there!</div>
<div><font face="Lucida Grande" size="+1"
color="#000000">http://www.ldpc-codes.com/index.html</font> is good
too..</div>
<div><br></div>
<div>Leigh</div>
<div><br></div>
<div><br></div>
<div>At 9:36 AM -0600 6/14/05, gtmbht wrote:</div>
<blockquote type="cite" cite>Hello all,<br>
<br>
Can someone please tell me what the optimum length and rate of turbo
codes<br>
would be for deep space links?( or what would the block size of inner
and<br>
outer code would be)<br>
<br>
Thank You<br>
<br>
Gautam Bhatia<br>
<br>
----------------------------------------------------------------------<br
>
Gautam Bhatia<br>
Department of Electrical and Computer Engineering<br>
Colorado State University<br>
Fort Collins CO - 80523<br>
Tel:(970)-215-6316<br>
Email: [email-masked]<br>
----------------------------------------------------------------------<br
>
<br>
_______________________________________________<br>
dtn-interest mailing list<br>
[email-masked]<br>
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div
>--------------------------------------------------------------------<br
>
J. Leigh
Torgerson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<br>
Jet Propulsion Laboratory - Communications Systems Research Sec.
331<br>
NASA Space Communications Protocol Standards (SCPS) Project CTM<br>
(818)
393-0695&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp; (818) 393-4643 fax<br>
--------------------------------------------------------------------</div
>
</body>
</html>
--============_-1093270574==_ma============--

Date: Wed, 15 Jun 2005 09:03:57 -0700
To: gtmbht <[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: RE: [dtn-interest] loss models for space links
Cc: [email-masked]
Sender: [email-masked]

--============_-1093271058==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Yes Gautam - turbo codes and Reed-Solomon codes are used to achieve 
the error rates we need for deep space comms. Other coding techniques 
and families are also being explored of course.

The noise on deep space links is basically just gaussian noise with 
performance impacts to the signal strength as a function of weather. 
We don't usually have to worry about multipath or other such problems 
common to terresterial links.

try looking at http://deepspace.jpl.nasa.gov/advmiss/ and 
http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/ for good 
references on deep space link design and operation.

There is a section in 810-005 titled Telemetry General Information 
that would be a good place to start. Regarding Turbo Codes, it says 
"Turbo codes provide near Shannon-limit performance with bandwidth 
expansions from slightly more than 2 to slightly more than 6. Block 
sizes of 1784, 3568, 7136, and 8920 symbols are accommodated. The 
smaller block sizes are intended for lower data rates while using 
larger block sizes as the data rate increases reduces coding 
overhead. Their principal disadvantages are the amount of processing 
that must be done to decode them and the presence of an error floor 
at a Frame Error Rate of about 10-6. The decoding complexity results 
in increased latency and limits the rate to that established by 
number of frames that can be in process at any time and the 
processing time for each frame."

We're currently doing a lot of work with LDPC codes (Google = good)

Hope this helps!

Leigh

At 10:30 AM -0600 6/8/05, gtmbht wrote:
>Mr. Torgerson,
>
>Thanks for your help.
>
>I was wondering, is Turbo Coding the technique that is used for encoding and
>decoding that leads to such low BERs? According to some of the papers that I
>have read on IPN networks, the raw bit error rate on the IPN backbone comes
>close to 10E-2. So, does it mean that when special coding techniques are used
>on very noisy channels, the BER improves? Also, afer searching for a while, I
>was unable to find any statistical models appropriate to the link budget
>including frequency & weather. Would it be possible for you to forward me any
>information on these models if you happen to know any?
>
>Thank You
>
>Gautam
>
>>===== Original Message From Leigh Torgerson <[email-masked]> =====
>>Hi Gautam -
>>
>>Generally speaking our modeling folks tell me "The
>>black out periods are usually on the order of several hours (but not tens of
>>hours), and depending on link engineering it is reasonable to assume
>>something between 10% to 1% of the passes will experience some form of
>>outage that affect the whole pass or a large portion of the pass."
>>
>>The error encoding is such that either there is little loss (10E-6
>>BER) or bursty losses where long sections go missing (seconds in
>>duration).
>>
>>Bit errors are stochastic processes - the effect on these errors on
>>loss depends on the type or error-correcting coding, the length of
>>frames, etc. Also the frequency in use has a bearing on the matter..
>>X-band has less loss due to atmospheric effects than Ka-band for
>>example.
>>
>>When we simulate this, we apply random bit errors (with a statistical
>>model appropriate to the link budget including frequency & weather)
>>to models of the actual ECC and frame lengths involved. There are
>>probably some good papers out on this - I just don't have the
>>references at my fingertips..will put that in my list of things to do!
>>
>>Hope this helps.
>>
>>>Hello all,
>>>
>>>Can anyone please direct me to some loss models for deep space  networks
>(for
>>>example what are the durations of blackouts on the mars earth channels and
>>>what are the probabilities?).
>>>
>>>Thank you
>>>
>>>Gautam Bhatia
>>>
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
>>--
>>--------------------------------------------------------------------
>  >J. Leigh Torgerson                           [email-masked]
>>Jet Propulsion Laboratory - Communications Systems Research Sec. 331
>>NASA Space Communications Protocol Standards (SCPS) Project CTM
>>(818) 393-0695                                   (818) 393-4643 fax
>>--------------------------------------------------------------------
>
>----------------------------------------------------------------------
>Gautam Bhatia
>Department of Electrical and Computer Engineering
>Colorado State University
>Fort Collins CO - 80523
>Tel:(970)-215-6316
>Email: [email-masked]
>----------------------------------------------------------------------

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------
--============_-1093271058==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: [dtn-interest] loss models for space
links</title></head><body>
<div>Yes Gautam - turbo codes and Reed-Solomon codes are used to
achieve the error rates we need for deep space comms. Other coding
techniques and families are also being explored of course.</div>
<div><br></div>
<div>The noise on deep space links is basically just gaussian noise
with performance impacts to the signal strength as a function of
weather. We don't usually have to worry about multipath or other such
problems common to terresterial links.</div>
<div><br></div>
<div>try looking at<font face="Lucida Grande" size="+1"
color="#000000"> http://deepspace.jpl.nasa.gov/advmiss/</font>
and<font face="Lucida Grande" size="+1" color="#000000">
http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/</font> for good
references on deep space link design and operation.</div>
<div><br></div>
<div>There is a section in 810-005 titled Telemetry General
Information that would be a good place to start. Regarding Turbo
Codes, it says &quot;<font face="Times" size="+1"
color="#000000">Turbo codes provide near Shannon-limit performance
with bandwidth expansions from slightly more than 2 to slightly more
than 6. Block sizes of 1784, 3568, 7136, and 8920 symbols are
accommodated. The smaller block sizes are intended for lower data
rates while using larger block sizes as the data rate increases
reduces coding overhead. Their principal disadvantages are the amount
of processing that must be done to decode them and the presence of an
error floor at a Frame Error Rate of about 10</font><font
face="Times" size="-1" color="#000000">-6</font><font face="Times"
size="+1" color="#000000">. The decoding complexity results in
increased latency and limits the rate to that established by number of
frames that can be in process at any time and the processing time for
each frame.</font>&quot;</div>
<div><br></div>
<div>We're currently doing a lot of work with LDPC codes (Google =
good)</div>
<div><br></div>
<div>Hope this helps!</div>
<div><br></div>
<div>Leigh</div>
<div><br></div>
<div><br></div>
<div>At 10:30 AM -0600 6/8/05, gtmbht wrote:</div>
<blockquote type="cite" cite>Mr. Torgerson,<br>
<br>
Thanks for your help.<br>
<br>
I was wondering, is Turbo Coding the technique that is used for
encoding and<br>
decoding that leads to such low BERs? According to some of the papers
that I<br>
have read on IPN networks, the raw bit error rate on the IPN backbone
comes<br>
close to 10E-2. So, does it mean that when special coding techniques
are used<br>
on very noisy channels, the BER improves? Also, afer searching for a
while, I<br>
was unable to find any statistical models appropriate to the link
budget<br>
including frequency &amp; weather. Would it be possible for you to
forward me any<br>
information on these models if you happen to know any?<br>
<br>
Thank You<br>
<br>
Gautam<br>
<br>
&gt;===== Original Message From Leigh Torgerson
&lt;[email-masked]&gt; =====<br>
&gt;Hi Gautam -<br>
&gt;<br>
&gt;Generally speaking our modeling folks tell me &quot;The<br>
&gt;black out periods are usually on the order of several hours (but
not tens of<br>
&gt;hours), and depending on link engineering it is reasonable to
assume<br>
&gt;something between 10% to 1% of the passes will experience some
form of<br>
&gt;outage that affect the whole pass or a large portion of the
pass.&quot;<br>
&gt;<br>
&gt;The error encoding is such that either there is little loss
(10E-6<br>
&gt;BER) or bursty losses where long sections go missing (seconds
in<br>
&gt;duration).<br>
&gt;<br>
&gt;Bit errors are stochastic processes - the effect on these errors
on<br>
&gt;loss depends on the type or error-correcting coding, the length
of<br>
&gt;frames, etc. Also the frequency in use has a bearing on the
matter..<br>
&gt;X-band has less loss due to atmospheric effects than Ka-band
for<br>
&gt;example.<br>
&gt;<br>
&gt;When we simulate this, we apply random bit errors (with a
statistical<br>
&gt;model appropriate to the link budget including frequency &amp;
weather)<br>
&gt;to models of the actual ECC and frame lengths involved. There
are<br>
&gt;probably some good papers out on this - I just don't have the<br>
&gt;references at my fingertips..will put that in my list of things to
do!<br>
&gt;<br>
&gt;Hope this helps.<br>
&gt;<br>
&gt;&gt;Hello all,<br>
&gt;&gt;<br>
&gt;&gt;Can anyone please direct me to some loss models for deep
space&nbsp; networks<br>
(for<br>
&gt;&gt;example what are the durations of blackouts on the mars earth
channels and<br>
&gt;&gt;what are the probabilities?).<br>
&gt;&gt;<br>
&gt;&gt;Thank you<br>
&gt;&gt;<br>
&gt;&gt;Gautam Bhatia<br>
&gt;&gt;<br>
&gt;&gt;_______________________________________________<br>
&gt;&gt;dtn-interest mailing list<br>
&gt;&gt;[email-masked]<br>
&gt;&gt;http://mailman.dtnrg.org/mailman/listinfo/dtn-interest<br>
&gt;<br>
&gt;<br>
&gt;--<br>
&gt;-----------------------------------------------------------------<span
></span>---</blockquote>
<blockquote type="cite" cite>&gt;J. Leigh
Torgerson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<br>
&gt;Jet Propulsion Laboratory - Communications Systems Research Sec.
331<br>
&gt;NASA Space Communications Protocol Standards (SCPS) Project
CTM<br>
&gt;(818)
393-0695&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp; (818) 393-4643 fax<br>
&gt;-----------------------------------------------------------------<span
></span>---<br>
<br>
----------------------------------------------------------------------<br
>
Gautam Bhatia<br>
Department of Electrical and Computer Engineering<br>
Colorado State University<br>
Fort Collins CO - 80523<br>
Tel:(970)-215-6316<br>
Email: [email-masked]<br>
---------------------------------------------------------------------<span
></span>-</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div
>--------------------------------------------------------------------<br
>
J. Leigh
Torgerson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<br>
Jet Propulsion Laboratory - Communications Systems Research Sec.
331<br>
NASA Space Communications Protocol Standards (SCPS) Project CTM<br>
(818)
393-0695&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp; (818) 393-4643 fax<br>
--------------------------------------------------------------------</div
>
</body>
</html>
--============_-1093271058==_ma============--

Date: Tue, 14 Jun 2005 09:36:13 -0600
From: gtmbht <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] length of turbo codes
Sender: [email-masked]

Hello all,

Can someone please tell me what the optimum length and rate of turbo codes 
would be for deep space links?( or what would the block size of inner and 
outer code would be)

Thank You

Gautam Bhatia

----------------------------------------------------------------------
Gautam Bhatia
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins CO - 80523
Tel:(970)-215-6316
Email: [email-masked]
----------------------------------------------------------------------

Date: Mon, 13 Jun 2005 09:17:04 -0700
From: Michael Demmer <[email-masked]>
To: Ryutaro Ishimoto <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] sending a bundle
Mail-Followup-To: Ryutaro Ishimoto <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

First of all, please direct future questions related specifically to
the reference implementation to the dtn-users mailing list.

The main logic is in DTN2/servlib/routing/BundleRouter.cc, where it
consults the route table in response to various events (i.e. a new
bundle arrived, a new contact arrived, etc) and then enqueues the
bundle on a particular next hop destination.

However, we are in the process of refactoring this logic slightly to
accomodate running multiple dynamic routing algorithms at the same
time, so the interface will be changing in the next release of DTN2.

-m

> Hi, could someone tell me which file contains the code that a
> node determines the next hop to send the bundle?  I want to do some tests
> where I want DTN to read in my routing table(at this point, just a file)
> right before it sends out the bundle.  This test is just to see where it
> should get the next hop information when dynamic routing becomes
> available.  Thanks in advance!
> 
> Ryu
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 13 Jun 2005 08:47:32 -0700 (PDT)
From: Ryutaro Ishimoto <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] sending a bundle
Sender: [email-masked]

Hi, could someone tell me which file contains the code that a
node determines the next hop to send the bundle?  I want to do some tests
where I want DTN to read in my routing table(at this point, just a file)
right before it sends out the bundle.  This test is just to see where it
should get the next hop information when dynamic routing becomes
available.  Thanks in advance!

Ryu

Date: Sun, 12 Jun 2005 12:43:29 -0700 (PDT)
From: Yun <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN2 documentation
Sender: [email-masked]

--0-1768419249-1118605409=:30861
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi!
Thanks Melissa and Jeff for help with running DTN2. 
I am done with all the examples provided in the tutorials, but there are still a lot of important issues not mentioned, such as topology setup and routing. Could anyone provide more information about these? 
If I could do anything to contribute to the documentation and tutorial, I am willing to help. 
Thanks!
 
Yun

---------------------------------
Discover Yahoo!
 Find restaurants, movies, travel & more fun for the weekend. Check it out!
--0-1768419249-1118605409=:30861
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Hi!</DIV>
<DIV>Thanks Melissa and Jeff for help with running DTN2. </DIV>
<DIV>I&nbsp;am done with&nbsp;all the examples provided in the tutorials, but there are still a lot of important issues not mentioned, such as topology setup and routing. Could anyone provide more information about these? </DIV>
<DIV>If I could do anything to contribute to the documentation and tutorial, I am willing to help. </DIV>
<DIV>Thanks!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yun</DIV><p>
		<hr size=1>Discover Yahoo!<br> 
Find restaurants, movies, travel & more fun for the weekend. <a href="http://us.rd.yahoo.com/evt=32658/*http://discover.yahoo.com/weekend.html">Check it out!</a>
--0-1768419249-1118605409=:30861--

Date: Fri, 10 Jun 2005 10:48:36 +0200 (MEST)
From: Anders Lindgren <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] New routing draft
Sender: [email-masked]

All,  

A new Internet-Draft for the PRoPHET probabilistic routing protocol for
intermittently connected networks is available from the on-line
Internet-Drafts directories at:
http://www.ietf.org/internet-drafts/draft-lindgren-dtnrg-prophet-00.txt
The I-D announcement can be found below. This is the first version of the
draft, and all comments on it are most welcome and appreciated.

/Anders

-------------------
Begin forwarded message:

From: [email-masked]
Date: 9 juni 2005 21.51.54 MET
To: [email-masked]
Subject: I-D ACTION:draft-lindgren-dtnrg-prophet-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Probabilistic Routing Protocol for Intermittently
 		       	  Connected Networks
 	Author(s)	: A. Lindgren, A. Doria
 	Filename	: draft-lindgren-dtnrg-prophet-00.txt
 	Pages		: 35
 	Date		: 2005-6-9

 This document describes a routing protocol for intermittently
   connected networks, where there is no guarantee that a fully
   connected path between source and destination exists at any time,
   rendering traditional routing protocols unable to deliver messages
   between hosts.  These networks are special cases of networks where
   the Delay-Tolerant Network architecture[1] is applicable.  We define
   PRoPHET, a Probabilistic Routing Protocol using History of Encounters
   and Transitivity for intermittently connected networks.  The document
   presents an architectural overview followed by the protocol
   specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lindgren-dtnrg-prophet-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-lindgren-dtnrg-prophet-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
 	"FILE /internet-drafts/draft-lindgren-dtnrg-prophet-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
 	feature, insert the command "ENCODING mime" before the "FILE"
 	command.  To decode the response(s), you will need "munpack" or
 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
 	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
 	up into multiple messages), so check your local documentation on
 	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[email-masked]>

 _______________________________________________
 I-D-Announce mailing list
 [email-masked]
 https://www1.ietf.org/mailman/listinfo/i-d-announce

From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Date: Thu, 9 Jun 2005 10:48:40 -0400
Subject: [dtn-interest] New security draft
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0063_01C56CE0.CC7CC410
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

All, 
 
A new Internet-Draft for the DTN Bundle Security Protocol Specification is
available from the on-line Internet-Drafts directories. Here is the URL for
the I-D announcement:
 <http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg05403.html>
http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg05403.html

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

------=_NextPart_000_0063_01C56CE0.CC7CC410
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D991494214-09062005>All,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D991494214-09062005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D991494214-09062005>A new =
Internet-Draft=20
for the DTN Bundle Security Protocol Specification is available from the =
on-line=20
Internet-Drafts directories. Here is <FONT size=3D2>the URL&nbsp;for the =
I-D=20
announcement:</FONT></SPAN></FONT></DIV>
<DIV><FONT><SPAN class=3D991494214-09062005>
<P><A=20
href=3D"http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg054=
03.html"><U><FONT=20
color=3D#0000ff><FONT face=3DArial=20
size=3D2>http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg05=
403.html</FONT></U></FONT></A></P>
<P><SPAN class=3D991494214-09062005><FONT face=3DArial=20
size=3D2>-susan</FONT></SPAN></P></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0063_01C56CE0.CC7CC410--

Date: Tue, 7 Jun 2005 08:59:48 -0700
To: gtmbht <[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] loss models for space links
Cc: [email-masked]
Sender: [email-masked]

Hi Gautam -

Generally speaking our modeling folks tell me "The
black out periods are usually on the order of several hours (but not tens of
hours), and depending on link engineering it is reasonable to assume
something between 10% to 1% of the passes will experience some form of
outage that affect the whole pass or a large portion of the pass."

The error encoding is such that either there is little loss (10E-6 
BER) or bursty losses where long sections go missing (seconds in 
duration).

Bit errors are stochastic processes - the effect on these errors on 
loss depends on the type or error-correcting coding, the length of 
frames, etc. Also the frequency in use has a bearing on the matter.. 
X-band has less loss due to atmospheric effects than Ka-band for 
example.

When we simulate this, we apply random bit errors (with a statistical 
model appropriate to the link budget including frequency & weather) 
to models of the actual ECC and frame lengths involved. There are 
probably some good papers out on this - I just don't have the 
references at my fingertips..will put that in my list of things to do!

Hope this helps.

>Hello all,
>
>Can anyone please direct me to some loss models for deep space  networks (for
>example what are the durations of blackouts on the mars earth channels and
>what are the probabilities?).
>
>Thank you
>
>Gautam Bhatia
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------

Date: Mon, 6 Jun 2005 13:29:25 -0600
From: gtmbht <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] loss models for space links
Sender: [email-masked]

Hello all,

Can anyone please direct me to some loss models for deep space  networks (for 
example what are the durations of blackouts on the mars earth channels and 
what are the probabilities?).

Thank you

Gautam Bhatia

Date: Mon,  6 Jun 2005 12:12:58 -0400
From: Yang Chen <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Compilation problem with the latest DTN2 CVS
Sender: [email-masked]

hi,

I am trying to run the DTN2 code on Mandrake 9 Linux (HaCom OpenBrick mini PC).
(tcl8.4.9, BerkeleyDB.4.3, tclreadline-2.1.0, installation with root)
I used the latest CVS and found the following problem during compiling:

in these two files
DTN2/daemon/dtnd.cc
DTN2/sim/dtnsim.cc

oasys::TclCommandInterp::init(argv[0]); caused the error since the 
TclCommandInterp::init() has been modified in the TclCommand.cc/h 
(DTN2/oasys/tclcmd) compared to the previous version (in DTN-2.1.1.tgz as 
TclCommandInterp::init(char* objv0, bool no_default_cmds = false) )

I changed the oasys::TclCommandInterp::init(argv[0]); to 
oasys::TclCommandInterp::init(); and the compilation finished successfully.

But I am not sure whether this might cause some problems later on. So I turned 
back to DTN-2.1.1.tgz version.
unzip
sh configure -C
make

The following error occurs during "make install":
error while loading shared libraries: libdb_cxx-4.3.so

However, this file exists at /usr/local/BerkeleyDB.4.3/lib/ and this directory 
has been added to LD_LIBRARY_PATH. And I configured the BerkeleyDB with the --
enable-cxx option.

Thx for attention and any information is appreciated.

-Yang

Date: Sat, 4 Jun 2005 00:51:38 -0700 (PDT)
From: Ryutaro Ishimoto <[email-masked]>
To: Jakob Eriksson <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] ad hoc multihop scenario
Sender: [email-masked]

Thanks for your help Jakob!

Basically, for what I want to do, I don't want to use the configuration
file to specify the static links.  I want the nodes to dynamically figure
out the links by communicating among themselves.  Link state routing
definitely sounds like a possible solution to this.  Is there any
documentation on this?  I would love to find out more details about this
feature.  Thanks!

Ryu

On Thu, 2 Jun 2005, Jakob Eriksson wrote:

> Hi Ryu,
>
> There's a link state routing protocol coming into the CVS "any moment
> now". That one will do what you're looking for.
>
> - Jakob
>
> On Jun 2, 2005, at 4:55 PM, Ryutaro Ishimoto wrote:
>
> > Hi, I have recently began to play around with DTN and I was wondering
> > if
> > DTN has a multihop routing capabilty.  I want to set up something like:
> >
> > Wireless nodes, A - B - C where A and B, and B and C can hear each
> > other.
> > I want to send a bundle from A to C via B.
> >
> > My config for A would have B as it's routing peer, B would have A and
> > C as
> > its routing peers, and C would have B as its routing peer.  I am
> > trying to
> > get more laptops to do this test in an ad hoc mode, but please let me
> > know
> > if this set up is correct to accomplish this task.  Thanks!
> >
> > Ryu
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> Jakob Eriksson
> Ph.D. Candidate
> http://www.cs.ucr.edu/~jeriksson
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Fri, 3 Jun 2005 10:16:42 -0700
From: Michael Demmer <[email-masked]>
To: piero <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] custody transfer
Mail-Followup-To: piero <[email-masked]>, [email-masked]
Sender: [email-masked]

> Hi I'm Piero from Italy.
> I didn't understand whether custody transfer is already implemented or
> not.
> Thanks

No -- it's not currently implemented in the reference implementation.

-m

From: piero <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Date: Fri, 03 Jun 2005 17:07:38 +0200
Subject: [dtn-interest] custody transfer
Sender: [email-masked]

--=-lb4a6wEX495JEAFHrqAq
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi I'm Piero from Italy.
I didn't understand whether custody transfer is already implemented or
not.
Thanks

--=-lb4a6wEX495JEAFHrqAq
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
Hi I'm Piero from Italy.<BR>
I didn't understand whether custody transfer is already implemented or not.<BR>
Thanks
</BODY>
</HTML>

--=-lb4a6wEX495JEAFHrqAq--

From: Jakob Eriksson <[email-masked]>
Subject: Re: [dtn-interest] ad hoc multihop scenario
Date: Thu, 2 Jun 2005 18:54:44 -0700
To: [email-masked]
Sender: [email-masked]

Hi Ryu,

There's a link state routing protocol coming into the CVS "any moment 
now". That one will do what you're looking for.

- Jakob

On Jun 2, 2005, at 4:55 PM, Ryutaro Ishimoto wrote:

> Hi, I have recently began to play around with DTN and I was wondering 
> if
> DTN has a multihop routing capabilty.  I want to set up something like:
>
> Wireless nodes, A - B - C where A and B, and B and C can hear each 
> other.
> I want to send a bundle from A to C via B.
>
> My config for A would have B as it's routing peer, B would have A and 
> C as
> its routing peers, and C would have B as its routing peer.  I am 
> trying to
> get more laptops to do this test in an ad hoc mode, but please let me 
> know
> if this set up is correct to accomplish this task.  Thanks!
>
> Ryu
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
Jakob Eriksson
Ph.D. Candidate
http://www.cs.ucr.edu/~jeriksson

Date: Thu, 2 Jun 2005 16:55:24 -0700 (PDT)
From: Ryutaro Ishimoto <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] ad hoc multihop scenario
Sender: [email-masked]

Hi, I have recently began to play around with DTN and I was wondering if
DTN has a multihop routing capabilty.  I want to set up something like:

Wireless nodes, A - B - C where A and B, and B and C can hear each other.
I want to send a bundle from A to C via B.

My config for A would have B as it's routing peer, B would have A and C as
its routing peers, and C would have B as its routing peer.  I am trying to
get more laptops to do this test in an ad hoc mode, but please let me know
if this set up is correct to accomplish this task.  Thanks!

Ryu

Date: Thu, 2 Jun 2005 12:26:28 -0700
From: Michael Demmer <[email-masked]>
To: Yun <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN compile
Mail-Followup-To: Yun <[email-masked]>, [email-masked]
Sender: [email-masked]

(Note -- I replied to the dtn-users list, since that's where this sort
of discussion should take place. Please direct specific questions on
the reference implementation to that list).

-m

> Hi all,
>  
> I am trying to install DTN package on Windows machine with cygwin. I did the configure successfully, but when I compile it, it shows:
> gcc -I.. -I../servlib   -I/usr/local/BerkeleyDB.4.3/include  -g -fno-inline  -c
> dtn_types_xdr.c -o dtn_types_xdr.o
> In file included from dtn_types_xdr.c:6:
> dtn_types.h:9:21: rpc/rpc.h: No such file or directory
> dtn_types.h:67:21: rpc/rpc.h: No such file or directory
> In file included from dtn_types_xdr.c:6:
> dtn_types.h:112: error: parse error before "u_int"
> dtn_types.h:112: warning: no semicolon at end of struct or union
> dtn_types.h:112: warning: no semicolon at end of struct or union
> ....
> and a lot of errors similarly. 
> Could anyone help me about this situation? 
> Thank you!
>  
> Yun
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 

Date: Thu, 2 Jun 2005 12:02:19 -0700 (PDT)
From: Yun <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN compile
Sender: [email-masked]

--0-1033935492-1117738939=:38787
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all,
 
I am trying to install DTN package on Windows machine with cygwin. I did the configure successfully, but when I compile it, it shows:
gcc -I.. -I../servlib   -I/usr/local/BerkeleyDB.4.3/include  -g -fno-inline  -c
dtn_types_xdr.c -o dtn_types_xdr.o
In file included from dtn_types_xdr.c:6:
dtn_types.h:9:21: rpc/rpc.h: No such file or directory
dtn_types.h:67:21: rpc/rpc.h: No such file or directory
In file included from dtn_types_xdr.c:6:
dtn_types.h:112: error: parse error before "u_int"
dtn_types.h:112: warning: no semicolon at end of struct or union
dtn_types.h:112: warning: no semicolon at end of struct or union
....
and a lot of errors similarly. 
Could anyone help me about this situation? 
Thank you!
 
Yun

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-1033935492-1117738939=:38787
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am trying to install DTN package on Windows machine with cygwin. I did the configure successfully, but when I compile it, it shows:</DIV>
<DIV>gcc -I.. -I../servlib&nbsp;&nbsp; -I/usr/local/BerkeleyDB.4.3/include&nbsp; -g -fno-inline&nbsp; -c<BR>dtn_types_xdr.c -o dtn_types_xdr.o<BR>In file included from dtn_types_xdr.c:6:<BR>dtn_types.h:9:21: rpc/rpc.h: No such file or directory<BR>dtn_types.h:67:21: rpc/rpc.h: No such file or directory<BR>In file included from dtn_types_xdr.c:6:<BR>dtn_types.h:112: error: parse error before "u_int"<BR>dtn_types.h:112: warning: no semicolon at end of struct or union<BR>dtn_types.h:112: warning: no semicolon at end of struct or union</DIV>
<DIV>....</DIV>
<DIV>and a lot of errors similarly. </DIV>
<DIV>Could anyone help me about this situation? </DIV>
<DIV>Thank you!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yun</DIV><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 
--0-1033935492-1117738939=:38787--