Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Mon, 20 Mar 2006 09:37:40 -0500

Perfect example where L2 and L3 are meaningless at least to me.
/jim 

> -----Original Message-----
> From: John Day [mailto:[email-masked]] 
> Sent: Saturday, March 18, 2006 9:33 AM
> To: Jari Arkko; John Day
> Cc: [email-masked]
> Subject: Re: [arch-d] Defining terms
> 
> At 16:22 +0200 2006/03/18, Jari Arkko wrote:
> >That it is cost-effective for local (perhaps L2) mechanisms to
> >handle local movements, so that the global (perhaps L3) mechanisms
> >do not handle to deal with too many events.
> 
> Couldn't agree more.
> 
> John
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
> 

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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 20 Mar 2006 13:02:42 -0800

I don't know to what extent this discussion is based on words or whether
we are seeing an actual disagreement about concepts.

However, assuming the latter, I think that the key operative difference,
from my knot-hole, has to do with the state machines used by the
communicating peers/nodes. 

Specifically, L2 differs from L3 in that the state machine used by the
IP Layer protocol is different than the state machine that is used for
whatever the underlying L2 protocol may be (e.g., ATM, Ethernet, etc.).

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]] 
Sent: Monday, March 20, 2006 6:38 AM
To: John Day; Jari Arkko
Cc: [email-masked]
Subject: RE: [arch-d] Defining terms

Perfect example where L2 and L3 are meaningless at least to me. /jim 

> >That it is cost-effective for local (perhaps L2) mechanisms to handle

> >local movements, so that the global (perhaps L3) mechanisms do not 
> >handle to deal with too many events.
> 
> Couldn't agree more.
> 
> John
> 
> Architecture-discuss mailing list [email-masked]

---

From: John Day <[email-masked]>
Date: Mon, 20 Mar 2006 09:52:07 -0500

>Perfect example where L2 and L3 are meaningless at least to me.

Layer 2 and 3 as traditionally described have very different scopes. 
This is a very significant difference.

hitecture-discuss

---

From: John Day <[email-masked]>
Date: Mon, 20 Mar 2006 09:52:07 -0500

---

From: Scott W Brim <[email-masked]>
Date: Tue, 21 Mar 2006 09:03:23 -0600

> This is a very significant difference.

Some confusion comes from an assumption of coupling of functionality
and protocol, while in fact protocols, particularly connectionless
ones, are reusable in different roles.  For example we can see IP as
part of both the traditional L2 and L3 in some access networks.
(Please don't ask me to define access network :-p.)

swb

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 21 Mar 2006 09:14:35 -0600

> ones, are reusable in different roles.

I agree.

As far as I can see, real "layering" boundaries are formed by whom  
the protocol is used to communicate with.  If your protocol talks to  
a "middle box", your layer is "below" the "end-to-end" layer, which  
talks beyond the middle box.  Of course, almost always there are  
different kinds of middle boxes, including bridges, routers, NATs,  
firewalls, and application level gateways.

But that's all trivial.

A major source of complication seems to be the desire to introduce  
new kinds of middle boxes without creating new "layers".  NAT is a  
good example of what can happen.

Other, perhaps less appreciated phenomena that seem to require  
layering are mobility and multi-path communication.  Mobility  
requires indirection:  you have to have separate stable identifiers  
(so that you can name your peer) and dynamic, location specific  
identifiers.  From an architectural point of view, supporting such  
indirection within a single name space seems to lead to messy  
problems.  Having two distinct name spaces leads to cleaner  
solutions, but at the same time create a new layer.  More or less the  
same applies to multi-path communication, but in the spatial rather  
than temporal dimension.

 From that point of view, Mobile IP is a good example of what happens  
when you add mobility without modifying your layering.

--Pekka N.

---

From: Scott W Brim <[email-masked]>
Date: Tue, 21 Mar 2006 09:53:01 -0600

On Tue, Mar 21, 2006 10:13:58AM -0500, John Day allegedly wrote:
> Could you elaborate?  I have no clue what you are talking about.  ;-)
> 
> A case can be made that IP is a subnet access protocol since that is 
> what its addresses name.  I have always found it amusing that 
> Ethernet addresses potentially had more scope than IP addresses.

For example, there is a 3G wireless scenario -- which others can
describe better than I -- where IP is used to support an IPsec tunnel
purely in the "access network", and user IP runs over this.  What
"layer" is the underlying IP?

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 21 Mar 2006 10:39:22 -0600

> Saltzer, Jerry. "On the Naming and Binding of Network Destinations"  
> in Local Computer Networks, edited by P. Ravasio et al. P North- 
> Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498.

Re-reading is always helpful, even the fifth time. :-)

A difficulty is created by one man's names being other man's  
addresses.  As Scott pointed out, in modern networks layering tends  
to get blurred, for example, due to replicated usage of the same  
protocols.  What are the relevant middle boxes (whether they are  
"routers" or whatever) becomes a function of how people deploy the  
protocols rather than how they are implemented in the stack of the  
end host.  Messy, I'd say, but part of the reality.  Consequently,  
layering tends to become more a network configuration(1) concept more  
than stack architecture concept.

(1) Note that what we in the IETF usually consider as network  
configuration is often referred by telecom people (e.g. in 3GPP) as  
network architecture.  Hence, beware of the different connotations of  
"architecture".

--Pekka N.

---

From: <[email-masked]>
Date: Tue, 21 Mar 2006 18:42:48 +0200

>For example, there is a 3G wireless scenario -- which others 
>can describe better than I -- where IP is used to support an 
>IPsec tunnel purely in the "access network", and user IP runs 
>over this.  What "layer" is the underlying IP? 

Would this be the same as an IP-in-IP tunnel?  

John

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Mar 2006 08:46:36 -0800

See RFC 3884 for the differences ;-)

Joe

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 21 Mar 2006 19:42:10 +0100

>See RFC 3884 for the differences ;-)

I suggest that discussing architecture (to also have confusion with 
"configurations") means never alluding to an RFC, ISO standard, etc. 
Because they talk of a specific and past approach.
jfc

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Mar 2006 19:34:55 -0500

Pekka Nikander <[email-masked]> wrote:
> the protocol is used to communicate with.

   This should be a good way to look at it. It used to be that layer
one talked to the same wire, layer two talked to a network connected
by wires, and layer three talked to anything on the network of
networks.

   It's becoming more difficult to think that way. We now are asked
to accept that layer one may be the "ether" carrying radio waves. We
generally think of layer two as including "ethernets" connected only
by switches (which actually behave quite differently than a network
connected by wires). And layer three now suffers from any number of
"middleboxes" such as NATs.

> If your protocol talks to a "middle box", your layer is "below"
> the "end-to-end" layer, which talks beyond the middle box.

   I'm afraid this way of looking at it isn't workable. It is
correct to say that a layer talks beyond any middleboxes (which
actually includes ethernet switches on an ethernet. Alas, it is
no longer correct to say that communication with a "middlebox"
is necessarily at a lower "layer". :^(

> Of course, almost always there are different kinds of middle boxes,
> including bridges, routers, NATs, firewalls, and application level
> gateways.

   I agree these are all "middleboxes".

> good example of what can happen.

   In fact, NATs arose to "solve" several problems, which could not
be practically solved by introducing a new layer. Most of the folks
implementing them knew they were implementing kludges. The customers
only knew that these boxes "helped" with the problems.

> layering are mobility and multi-path communication.

   I quite agree these would benefit from adding layer(s).

> Mobility requires indirection:  you have to have separate stable
> identifiers (so that you can name your peer) and dynamic, location
> specific identifiers.

   I agree we need stable identifiers; I'm not sure "indirection"
is the only option for deriving location-specific identifiers.

>  From an architectural point of view, supporting such indirection
> within a single name space seems to lead to messy problems.

   Agreed.

> Having two distinct name spaces leads to cleaner solutions, but at
> the same time create a new layer. More or less the same applies to
> multi-path communication, but in the spatial rather than temporal
> dimension.

   Agreed.

> when you add mobility without modifying your layering.

   Ouch! ;^)

--
John Leslie <[email-masked]>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Mar 2006 17:58:36 -0800

Hi -

> From: "John Leslie" <[email-masked]>
> To: "Pekka Nikander" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, March 21, 2006 4:34 PM
> Subject: Re: [arch-d] Layers (was Re: Defining terms)
>
...

Another way to think of a layer is in terms of its interface definitions.
A layer provides a set of services.  A protocol is defined in terms of
syntax and procedures which, when implemented, carry out those
services.  However, a protocol may need to use some services
(e.g., send bits) of another layer, which by convention we speak of
as being "lower" in the "stack."

An important point is that any layer capable of providing the necessary
services could, in some configuration or another, make sense as a
"service provider" for some upper layer protocol.  This
is exactly what we see in tunneling, VPNs, etc.  The only protocols
that don't need the services of a "lower" layer are those of the physical
layer, and even in this case one may have reason to implement something
simulating a particular physical layer, in order to satisfy the service
requirements of some higher protocol.

The "classical" layers are just convenient packages of services that
have proven useful, and, in a chicken-and-egg way, have served to
characterize the protocols used to implement those services.
The ones  most interesting here still end up being
   - hop-to-hop (data link)
   - hop-by-hop (network)
   - endsysteminterface-to-endsysteminterface (transport)
   - endsystem-to-endsystem (session)
   - application-to-application (application)

Taking this view, it's perfectly reasonable to run an application
protocol directly over an appropriate data link protocol in a point-to-point
network, if that protocol provides the necessary services.  (Or you can
imagine pass-through services replacing all the intervening layers, but
I think doing so reduces the generality of the approach.)  A key point is
that one can think of the binding between layers and protocols as
something quite dynamic.  With some protocols it works beautifully
(we implemented this approach in the late 1980s) but gets ugly in
the case of TCP/IP due to the way the headers are laid out.

Randy

---

From: John Day <[email-masked]>
Date: Tue, 21 Mar 2006 10:13:58 -0500

Take care,
John

---

From: John Day <[email-masked]>
Date: Tue, 21 Mar 2006 11:08:42 -0500

>solutions, but at the same time create a new layer.  More or less 
>the same applies to multi-path communication, but in the spatial 
>rather than temporal dimension.

I suggest you read this, if you haven't:

Saltzer, Jerry. "On the Naming and Binding of Network Destinations" 
in Local Computer Networks, edited by P. Ravasio et al. P 
North-Holland Publishing Company, pp 311-317, 1982, republished as 
RFC 1498.

It contains most everything you need.  The problem in the Internet is 
it is missing half of the minimum required addressing architecture. 
Tends to make things difficult.

>when you add mobility without modifying your layering.

Mobility is not really a big problem, just dynamic multi-homing.

Take care,
John

---

From: John Day <[email-masked]>
Date: Tue, 21 Mar 2006 10:13:58 -0500

Take care,
John

---

From: John Day <[email-masked]>
Date: Tue, 21 Mar 2006 11:08:42 -0500

Take care,
John

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 09:09:36 -0500

>>  when you add mobility without modifying your layering.

Actually mobility and multipath require a full addressing 
architecture. It is not so much a problem of not enough layers as not 
enough naming and addressing.  According to Salzter, half of what we 
need is missing.

Ouch, Ouch. ;-)

John