Subject: RE: [manet] Re: MANET definition of a neighbor

From: "DANIEL BYRNE" <[email-masked]>
Date: Sun, 7 May 2006 13:17:44 -0500

"...That is why I feel a cross-layer approach will win out in the end.
The physical and link layers will have information that is normally
hidden from the routing layer that will be needed to evaluate potential
links, but the MANET protocol will have the job of finding an optimal
network solution."

True, the routing protocol could use information attained by lower
layers.  A mechanism to pass information up the stack is needed, or the
protocol needs to be multi-layer aware. However, the later causes
problems when there are changes in technologies.  Maybe a new stack
architecture is needed for MANETS where protocols can still partition
layer specific items yet share cross applicable information.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Joe Carey <[email-masked]>
Date: Sun, 07 May 2006 12:34:10 -0600

Daniel's post prompts me to ask a question of the list.  Perhaps 
somebody in the 802.11s world would care to comment on this.

In a traditional OSI network model, there's the PHY layer, the LINK 
layer and the NETWORK layer.

It appears from my limited exposure that the 802.11s protocol - and many 
vendors proprietary implementations of mesh - that they are attempting 
to implement multi-hop mesh networks at the LINK layer.  This seems to 
be exactly the wrong way to partition the problem; it would seem that 
the store-and-forward nature of mesh networking, including multiple 
links, should remain at layer 3 (the IP layer), where most current 
implementations have it.  However, these are smart people with a lot of 
experience.  So what is motivating this?

If I've misunderstood the problem, please correct me.

Thanks,

joe

---

From: Fred Baker <[email-masked]>
Date: Mon, 8 May 2006 14:58:35 -0700

On May 7, 2006, at 11:34 AM, Joe Carey wrote:

> It appears from my limited exposure that the 802.11s protocol - and  
> many vendors proprietary implementations of mesh - that they are  
> attempting to implement multi-hop mesh networks at the LINK layer.   
> This seems to be exactly the wrong way to partition the problem; it  
> would seem that the store-and-forward nature of mesh networking,  
> including multiple links, should remain at layer 3 (the IP layer),  
> where most current implementations have it.  However, these are  
> smart people with a lot of experience.  So what is motivating this?

To answer this, we have to go back to about 1985 when IEEE wanted to  
get involved with bridging networks and that was ostensibly ANSI's job.

As you say, the original layered reference model worked on some  
pretty basic questions:

The physical layer answers the question "what physically connects two  
or more systems, and how do we send signals across it?"

The link layer answers the question set "how do I interpret those  
signals as zero/one, manage link reliability and rate of delivery (if  
that is an issue), turn them into distinct frames if it is a framed  
protocol, etc,to enable two physically connected systems to exchange  
data?"

The network layer answers the question "given that I have a set of  
systems that are not physically connected en mesh but which form a  
set of interconnected systems in a graph, how do I logically connect  
and in fact deliver data from any system in the network to any other?"

In the original Ethernet specification (and therefore in 802.3) there  
was a physical layer way to do this, using repeaters. But they had a  
fundamental problem, or maybe a couple. Any time that any electrical  
energy was placed on a coax, it went throughout the various coaxes,  
and so one got more systems on the network but no additional  
capacity. Also, any problem anywhere in the coax potentially affected  
other areas as well, and so on. Oh, and there was a timing thing -  
the minimum frame size in Ethernet was calculated from the amount of  
time required to ensure that if any two devices in the network spoke  
they would both see a collision and do the right thing. Various  
products improved that situation, but bottom line they needed some  
kind of gateway between coaxes.

Now, in a strictly layer-theory sense, the right solution to this was  
to subdivide the network layer into an upper and a lower sublayer  
(which I call the Internet and Intranet Layers). The layer cake now  
looks like this:

N              +---------------------------------------+
  e     Internet|           IP and things like it       |
L t            +---------------------------------------+
   a w          +-----------+ +-----------+ +-----------+
    y o Intranet|  802.1    | |   ATM VC  | |Frame Relay|
     e r        +-----------+ +-----------+ +-----------+
      r k       +-----------+ +-----------+ +-----------+
                |+---------+| |           | |           |
                ||  LLC    || |   ATM     | |  HDLC     |
        Link    |+---------+| |   Framing | |           |
        Layer   ||  MAC    || |           | |           |
                |+---------+| |           | |           |
                +-----------+ +-----------+ +-----------+
                +-----------+ +-----------+ +-----------+
        Physical|  Coax etc | |  Fiber etc| |DS1/DS3/etc|
                +-----------+ +-----------+ +-----------+

However, that had problems with what we now call "political  
correctness"; IEEE 802.1 would have had to go off to ANSI, since ANSI  
was accredited to handle network layer problems and send the results  
off to ITU. And in this sense, a "bridged Ethernet" (as we called it  
then) was clearly a certain kind of network, just like an ATM, Frame  
Relay, or X.25 network was. But someone decided that since a bridged  
Ethernet worked off the MAC header, it could be called "MAC Layer  
Bridging", and sidestep the issue - and do the work in IEEE.

It has been that way for 20-odd years now.

That said, trust me, you are absolutely correct. In point of fact, we  
are using pretty standard network layer approaches to solve a pretty  
standard network layer question: "how do we make systems that are not  
physically interconnected but form a graph to be able to talk with  
each other over virtual connections overlaid on the underlying  
physical network". And the real picture is in fact a lot like the one  
I describe above.

Don't tell anyone. This is our little secret....

---

From: Fred Baker <[email-masked]>
Date: Mon, 8 May 2006 23:14:01 -0700

Let me go a step further in the discussion. You have asked whether it  
is wacko to use link layer networks, as they are called. The answer  
is "maybe". The reason why...

The Internet Layer is designed for conscious management: one assigns  
IP addresses by whatever means to devices, names things, talks about  
what routers are neighbors of others, and all that kind of thing.  
This is because the Internet Layer is designed to be the interface  
between things that one traverses consciously. We don't necessarily  
want to advertise all of the subnets in our domain into that other  
domain, but we might want to advertise an aggregate of them, or we  
might want to send that other domain a default route, or something.  
We might check that datagrams coming out of that domain are using  
addresses we believe are within it, and drop all others. We might not  
believe things it tells us. We might not accept all traffic that  
comes from it. Bottom line, we use routing to separate between things  
that at one time or another, for one reason or another, we want to  
separate. Maybe for management reasons, security reasons,  
administrative reasons, dumb reasons, good reasons, whatever reasons.

The Intranet Layer is designed to connect things that should normally  
be thought of as connected. I might have five guy in one building and  
five guys in another who are in the same department and I want to  
think of them as logically co-located; if I do, I put them on the  
same VLAN. I might have several buildings that I want to consider as  
"one campus", and I join them together in my network to make them  
appear that way.

When we first developed the concept that we now call 802.1 bridged  
LANs, we had a number of customers that built really large networks,  
like 10 and 15 thousand users. They had a number of problems, and we  
wound up building in interesting features to allow network managers  
to decide a lot of things.  "We don't necessarily want to advertise  
all of the MAC Addresses in our domain into that other domain, but we  
might want to advertise some of them. We might check that datagrams  
coming out of that domain are using addresses we believe are within  
it, and drop all others. We might not accept all traffic that comes  
from it. Bottom line, we use routing to separate between things that  
at one time or another, for one reason or another, we want to  
separate. Maybe for management reasons, security reasons,  
administrative reasons, dumb reasons, good reasons, whatever  
reasons." Think about it. In such cases, 20 years ago we learned the  
hard way that the right way to solve that kind of problem was  
actually to *use* the layered architecture, and let the Internet  
Layer do that kind of thing.

That said, there were a lot of people at the time who hated  
"bridges", because they thought that one should ONLY use the Internet  
layer. And in practice we have found it useful to use the Intranet  
layer when what we really wanted to connect things that one wants  
administratively treat as connected.

So to directly answer your question - 'is it wacko to build "link  
layer networks" instead of Internet layer networks?'... The answer is  
"if they cross an administrative or network management boundary, yes,  
that's wacko, and if they are within a manageable domain, no that's  
not wacko at all."

On May 8, 2006, at 2:58 PM, Fred Baker wrote:
>> It appears from my limited exposure that the 802.11s protocol -  
>> and many vendors proprietary implementations of mesh - that they  
>> are attempting to implement multi-hop mesh networks at the LINK  
>> layer.  This seems to be exactly the wrong way to partition the  
>> problem; it would seem that the store-and-forward nature of mesh  
>> networking, including multiple links, should remain at layer 3  
>> (the IP layer), where most current implementations have it.   
>> However, these are smart people with a lot of experience.  So what  
>> is motivating this?
>
> To answer this, we have to go back to about 1985 when IEEE wanted  
> to get involved with bridging networks and that was ostensibly  
> ANSI's job.
>
> The physical layer answers the question "what physically connects  
> two or more systems, and how do we send signals across it?"
>
> signals as zero/one, manage link reliability and rate of delivery  
> (if that is an issue), turn them into distinct frames if it is a  
> framed protocol, etc,to enable two physically connected systems to  
> exchange data?"
>
> set of interconnected systems in a graph, how do I logically  
> connect and in fact deliver data from any system in the network to  
> any other?"
>
> In the original Ethernet specification (and therefore in 802.3)  
> there was a physical layer way to do this, using repeaters. But  
> they had a fundamental problem, or maybe a couple. Any time that  
> any electrical energy was placed on a coax, it went throughout the  
> various coaxes, and so one got more systems on the network but no  
> additional capacity. Also, any problem anywhere in the coax  
> potentially affected other areas as well, and so on. Oh, and there  
> was a timing thing - the minimum frame size in Ethernet was  
> calculated from the amount of time required to ensure that if any  
> two devices in the network spoke they would both see a collision  
> and do the right thing. Various products improved that situation,  
> but bottom line they needed some kind of gateway between coaxes.
>
> Now, in a strictly layer-theory sense, the right solution to this  
> was to subdivide the network layer into an upper and a lower  
> sublayer (which I call the Internet and Intranet Layers). The layer  
> cake now looks like this:
>
>
> correctness"; IEEE 802.1 would have had to go off to ANSI, since  
> ANSI was accredited to handle network layer problems and send the  
> results off to ITU. And in this sense, a "bridged Ethernet" (as we  
> called it then) was clearly a certain kind of network, just like an  
> ATM, Frame Relay, or X.25 network was. But someone decided that  
> since a bridged Ethernet worked off the MAC header, it could be  
> called "MAC Layer Bridging", and sidestep the issue - and do the  
> work in IEEE.
>
> That said, trust me, you are absolutely correct. In point of fact,  
> we are using pretty standard network layer approaches to solve a  
> pretty standard network layer question: "how do we make systems  
> that are not physically interconnected but form a graph to be able  
> to talk with each other over virtual connections overlaid on the  
> underlying physical network". And the real picture is in fact a lot  
> like the one I describe above.
>

---

From: Christian Kuhtz <[email-masked]>
Date: Thu, 11 May 2006 10:28:22 -0400

So presently, the joint SeeMESH/WiMesh proposal adopted in Denver by  
TGs does exactly what is described below, it is a link layer  
approach.  In fact, 802.11s charter (the PAR) specifically requires  
it to be a LAN segment (and we can certainly all debate whether  
that's a good idea).  Whether this proposal will ever see the light  
in its current form remains to be seen.  In fact, it does actually  
prescribe specific IP(!) based routing mechanisms (AODV-RM) as a  
lowest common denominator protocol.

 From a carrier point of view, an IP only mesh is likely the wrong  
answer, it needs to have the fundamental ability to carry traffic  
from a number of virtual networks.  And we can certainly debate and  
argue how that should be done.  Something that looks like a VLAN may  
not be an altogether bad approach, although I think I need some  
convincing as to how that's really going to work at scale (and at  
all, really).

If it's more of a network layer solution (and I'm specifically not  
limiting this to pure IP), it might be a good idea to discuss just  
how those would work at scale and cost effectively.  There certainly  
is a good bit of perception always that network layer increases cost  
and complexity.

Anyone here going to be in Jax next week?  I'd love to get us service  
provider types talking about these things.  Up to this point, the  
authors of the proposal in TGs have made guesses about carrier needs,  
rather than having any actual involvement (this isn't my deduction,  
it's a statement made to several people in Denver by the authors of  
the proposal).

Best regards,
Christian

PS: There's an assertion in Joe's original email that most  
implementations in use today are at IP.  Not sure I agree with that,  
I think what you see is hybrid approaches (link layer and network  
layer), and TGs current proposal is fundamentally the same. 802.11 is  
a fundamentally PHY/MAC based technology.  If you want something  
else, it probably should be defined outside of the 802 LMSC.