Re: About carring information in the next header value

[Juan Rodriguez Hervella <jrh@it.uc3m.es>]

On Wednesday 29 October 2003 20:40, mbagnulo@ing.uc3m.es wrote:

[snipped]

> Anyway, i guess the most efficient option is the one presented in noid,
> that uses the nextheader
> and the flow label fields to carry the inforamtion in data packets.
> I have a doubt about how the next header values are defined.
> My first question is: do you define 2 values of next header for the
> every ulp protocol,
> covering the rewrite ok set and the rewrite ok not set, is this correct?

I think so, but only for the well-known UPL protocols and the others
are managed using a cuople of values + an extra extension header
which carries the actual UPL value.

> So you are not defining two values for the values of next header that
> define an extension header,
> like routing header, hop by hop, etc. why is that, is becasue there are
> not enough next
> header values?

I don't think so, I think that it is because it's only interesting to define
new values for the well-known upper layer values.

If you define new values for hop by hop, routing header, etc, routers already
in the market won't be able to process this new values and they will throw
away the packets.

> the problem with doing so, is that when an extension header is
> included, the site exit routers
> will have to parse all the extension headers until they find the ulp
> next header. Wouldn't this
> be a problem for efficiency? Perhaps this is not a very common case,
> though.

It's not going to be the common case, I agree with you. 
RFC 2460 specifies that:

"extension headers are not examined or processed
 by any node along a packet's delivery path, until the packet reaches
 the node"

There is an exception, the hop-by-hop header.

So I agree with you that this should be more elaborated. 

> Addtionally, I guess that you would like to preserve the values
> currently defined for ulp, at
> least fot compatibility with legacy hosts, 

There is no compatibility problem with legacy host.

If hosts implement NOID, they will interact perfectly. On
the other hand, if a host doesn't implement NOID, it will
send and receive "normal" packets. It will send normal
packets because it doesn't know anything about NOID,
and it will receive normal packets because the peer
demultiplexes on wheter a packet is an M6 packet.


>but i am not sure if this is
> accomplished now as
> currently defined in section 6 of the noid doc.
> I guess it would make more sense to define currently assigned ULP
> values to the case when
> the rewrite bit is not set, since legacy host would not recognize
> packets with modifed locators.

That's not possible, because the new protocols values are
used for two reasons:

1. To still know what's up the IP layer (the normal use of the next protocol
field)

2. To know if the peer has NOID capabilities.

You can not find out if the peer knows about NOID when the
rewrite bit isn't set, if you use what you're telling.

[snipped]

Erik, I like your draft but I think this is useful once both
peers have already obtained the state. I don't know if somebody else
has asked you this, but I think this draft is weak on the stablishment
of the states, because until you aren't able to re-write, you still have
all the problems the muli6 WG is trying to solve.

Cheers!


-- 
JFRH