Subject: [arch-d] Defining terms

From: Fred Baker <[email-masked]>
Date: Mon, 6 Mar 2006 15:02:24 -0800

OK, so this takes off on one of the many topics we have been  
discussing...

There are a variety of papers that have tried to define the concept  
of a 'session" in a network that is connectionless at the network  
layer. I'm not sure what the orgiginal document is, although I am  
sure that it vastly predates RFC 1144, which is the oldest RFC that  
seems to use the terms "shared state" and "fate sharing". But bottom  
line, while the internet layer has no concept of what we now call a  
"virtual circuit" or "virtual channel", it has been long recognized  
that the applications and the transports in question have to have  
some degree of shared state to enable them to function, and that in  
the event that something goes completely south there is a necessity  
for "fate sharing" - all systems retaining the shared state have to  
at some point decide that it is for nought and delete it.

I would therefore define a "session" as the shared state in the end  
systems and in the network, whatever it may be, which directly or  
indirectly reflects the state of two or more communicating  
applications. In Flow RED (http://www.icir.org/floyd/red.html#flow),  
this would include information stored in network nodes, and it  
generally includes keys associated with security associations,  
sequence numbers etc in TCP and SCTP, and the various addresses that  
are used by endpoints in a multihomed route.

I would suggest that we start out with a rational definition of the  
various layers. I include a questioned layer, which I think Tony is  
alluding to, and the ISO and XNS Session models, which have some  
history. I suspect that we will have various comments on these  
architecturally, and when we get this part of the question sorted  
out, we will have a better notion of what further we might want to say.

physical layer:
The physical layer is the lowest communication layer, consisting of  
the physical medium of communication and the means of signaling over  
it. It is responsible for defining the physical means of sending  
data, interfacing between network media and devices, and defining the  
media's optical, electrical and mechanical characteristics. Examples  
of this include a fiber optic link, in which the means of signaling  
is transmission of photons of a known frequency in a known pattern,  
and the reception of those photons, or a radio link, in which the  
"medium" is electromagnetic space, and the signaling is performed by  
electromagnetic effects conveyed in that space.

link layer:
The link layer defines the procedures for operating physical  
communication links. It encodes network layer data as physical layer  
signals, and recovers and decodes these signals at the receiving end.  
It also manages rate of flow and errors on the link, which at minimum  
means reporting statistics, and may include FEC, retransmission, or  
other techniques. Examples of this include HDLC, Ethernet, and so on.

Network layer:
The communication layer that builds networks out of link layer  
relationships and enables systems to communicate information between  
systems that are not directly connected at the link layer. The  
network layer contains at least two major sublayers, and these may be  
implemented recursively.

Intranet Layer:
The Intranet layer is the lower sublayer of the network layer. It  
connects systems that are under common administration, are intended  
to be connected in a simple manner, and generally applies no  
administrative policy within the network. Examples of this include X. 
25, Frame Relay, ATM, MPLS, IEEE 802.1 Transparent Bridging, IEEE  
802.1/802.5 Source-Route Bridging, and IEEE 802.11 wireless networking.

Internet Layer:
The Internet layer is the upper sublayer of the network layer. It may  
be used to connect systems under common administration and  
implementing common policy, but is also commonly used to connect  
systems under different administration or with differing  
administrative policy. Internet nodes include the internet layer in  
hosts or in routers, and each support at least one address by which  
they are reachable by their administration. In the Internet, IPv4 and  
IPv6 are examples of the Internet layer.

<should we describe IPsec as a layer? What is it? As I am about to  
describe transport, it is a sublayer of the transport layer, although  
IPv6 incorporates it and other end-system to end-system capabilities  
like fragmentation and reassembly into IPv6. Are these functions of a  
session management layer? Is the session management layer in fact the  
lowest end-2-end communications layer?>

Transport layer:
The transport layer is the lowest layer that runs end to end. It may  
be viewed as the end-to-end counterpart to the link layer, enabling  
applications running in end systems to communicate effectively across  
the network connecting them. "Effective communication" are  
application concepts; many applications call for reliable sequential  
delivery of data within a transaction, and a subset can handle  
transactions in arbitrary order. TCP and SCTP are examples of  
protocols which run at the Transport layer; there are other examples.  
UDP is not an example of a transport, although it may be considered  
an example of the multiplexing sublayer of the transport, as the  
methods used to make communication effective are implemented in the  
application.

Session Layer:
As defined by ISO, the session layer manages user sessions and  
dialogues, controls establishment and termination of logic links  
between users, and reports upper layer errors. As defined by Xerox  
Network Systems, the middleware application Courier provided a Remote  
Procedure Call service in which incoming sessions were all referred  
to Courier and transferred from there to other applications a deemed  
appropriate through AAA policy and parameter acquisition procedures.

Application Layer:
In the Internet, the application generally includes the ISO concept  
of the presentation layer, which deals with encoding and deciding  
data. This is the communication layer or program that directly serves  
the user, whether directly or remotely.

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

---

From: Tony Li <[email-masked]>
Date: Mon, 06 Mar 2006 17:13:20 -0800

> dialogues, controls establishment and termination of logic links between
> users, and reports upper layer errors. As defined by Xerox Network
> Systems, the middleware application Courier provided a Remote Procedure
> Call service in which incoming sessions were all referred to Courier and
> transferred from there to other applications a deemed appropriate
> through AAA policy and parameter acquisition procedures.

IMHO, the session layer should be responsible for authentication and
security at a level above the transports.  As a primary example, I'll
point you to the interesting situation that the X window system has with
authentication, and the games that we play with SSH tunneling.  If a
user has an existing session open with another host, then an application
should be able to inherit appropriate authentication credentials from
the session layer without a separate interactive authentication step.

My $.02,
Tony

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Mar 2006 17:52:15 -0800

On Mar 6, 2006, at 5:13 PM, Tony Li wrote:
>> Network Systems, the middleware application Courier provided a  
>> Remote Procedure Call service in which incoming sessions were all  
>> referred to Courier and transferred from there to other  
>> applications a deemed appropriate through AAA policy and parameter  
>> acquisition procedures.
>
> IMHO, the session layer should be responsible for authentication  
> and security at a level above the transports.  As a primary  
> example, I'll point you to the interesting situation that the X  
> window system has with authentication, and the games that we play  
> with SSH tunneling.  If a user has an existing session open with  
> another host, then an application should be able to inherit  
> appropriate authentication credentials from the session layer  
> without a separate interactive authentication step.

Hmm. The place I expected you to respond was:

> describe transport, it is a sublayer of the transport layer,  
> although IPv6 incorporates it and other end-system to end-system  
> capabilities like fragmentation and reassembly into IPv6. Are these  
> functions of a session management layer? Is the session management  
> layer in fact the lowest end-2-end communications layer?>

That question was partly a "how do we sort out the session management  
stuff, which in IPv6 includes fragmentation and assembly of messages  
and the IPsec header of IPv6?", and partly a response to your query  
"Do we want this flexibility in the transport protocol?  Or should it  
be in a lower layer?", supported by your later comment

On Mar 6, 2006, at 4:08 PM, Tony Li wrote:
>> Next question is "same layer or one in between". I would tend to  
>> think of the one in between as being an API demultiplexing layer,  
>> which sounds to me like a sublayer of the transport. That's not a  
>> firm position, but my current hunch, and squares with the current  
>> SCTP implementation.
>
> Interesting.  My preferences would be to have this be wholly  
> underneath transport, as I would hate to have to recreate this  
> functionality separately for each transport protocol.  UDP based  
> traffic should be able to take advantage of these mechanisms too.

 From this, I conclude that your position includes two of the following:

  * we need a AAA layer above transport that sets up and tears down  
sessions
    securely regardless of the transport used
  * we need for the lowest end to end layer to be the upper reaches  
of the
    network layer, handling session management issues in the way IPv6  
does
  * we need for the lowest end to end layer to be a session  
management layer
    between the network and transport layers, handling session  
management in
    the way IPsec does in an IPv4 implementation

Care to comment further?

Personally, if there is a session management sublayer in the network  
layer, or a session management layer between network and transport,  
or (as I posited it) a session management sublayer built into the  
demultiplexing function of the transport, I think we have separated  
the network layer from transport. That was what I thought we had set  
out to acheive. I tend to think that anything above transport wants  
to be a pretty identifiable setup protocol+application (Courier comes  
to mind, and SIP has some of those characteristics) or should be  
available to the application through an API.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 07 Mar 2006 01:10:36 +0100

At 00:02 07/03/2006, Fred Baker wrote:
>while the internet layer has no concept of what we now call a

Fred,
I said I am interested in usage architecture.I will therefore word it 
differently and generalise. But I think we agree. The user is 
interested in some form of virtual circuit switch. He understant 
connexions as whate vehicle the data, and the session as what 
provides him with the circuit service he needs. Let say the 
connexions are what the network provides and the session what the user sees.

>are used by endpoints in a multihomed route.

So, this definition is OK with me. However probably not 
architecturally general enough. For example a user will accept 
different connexions through different technologies within a session.

>I would suggest tFrom [email-masked] Mon Mar 06 21:58:19 2006
Date: Tue, 07 Mar 2006 01:10:36 +0100
To: Fred Baker <[email-masked]>,[email-masked]
From: "JFC (Jefsey) Morfin" <[email-masked]>
Subject: Re: [arch-d] Defining terms
Cc: 

At 00:02 07/03/2006, Fred Baker wrote:
>while the internet layer has no concept of what we now call a

Fred,
I said I am interested in usage architecture.I will therefore word it 
differently and generalise. But I think we agree. The user is 
interested in some form of virtual circuit switch. He understant 
connexions as whate vehicle the data, and the session as what 
provides him with the circuit service he needs. Let say the 
connexions are what the network provides and the session what the user sees.

>are used by endpoints in a multihomed route.

So, this definition is OK with me. However probably not 
architecturally general enough. For example a user will accept 
different connexions through different technologies within a session.

>out, we will have a better notion of what further we might want to say.

As usage oriented, I will add a few layers:

Dioptres layers
all the dioptres in the physical layer. These are the computer 
systems, the different kind of techologies, the impact of external 
changes. For example crossing a boarder (rates, law, language, etc.)

>Application Layer:

I consider the users system as part of the network architecture.
1. this makes three different main layers:
     - infrastructure - basic service to the data - interconnexion
     - superstructure - value added services to the enveloppe - 
interoperability
     - metastrucuture - extended services to the content - interintelligibility
2. this makes subnetwork layers to be considered.
     - intranets at infrastructural layer (you noted it)
     - externet at superstructural layer (external network look-alike 
using the network resources)
     - sets (spaces of exchanges, trust and services) at 
metastructural layer - what users perceive as relational/service network.
3. I will add the ENSM (extended network system model) upper layers:

Interapplications layer
Manage relations independently from the network technologies and the 
way their similar applications behave. Assist in preparing a uniform 
interintelligibility

Agent layer
Assitance to the user in interfacing the applications.

User
Users and communities. Their common understanding of the way to use 
the system is the system brainware. Digital cultures varies (most 
probably increasingly) among nations, languages, cultures, 
communities, ages, etc.

Communicating structures
Many factors modify the communications strategies and abilities of a 
structure. A communications architecture must have the necessary 
parameters to adapt.

Society
The way the society perceives, develops and rule its digital 
ecosystem has an obvious impact in its communications solutions. (ex. WSIS)

Maintenance, Operations and Brainware (consensual usage ways) are not 
layers as such but they must be embedded in the architecture.

Different elements must be considered as part of an architecture:
- security and trust
- multilingualism - independence from and equal support of every 
language, culture, etc
- user identification, privacy and empowerment (control of his global 
network zone)
- statistics and billing
- evolution and transition

jfc

---

From: Tony Li <[email-masked]>
Date: Tue, 07 Mar 2006 00:07:57 -0800

>  * we need a AAA layer above transport that sets up and tears down sessions
>  * we need for the lowest end to end layer to be the upper reaches of the
>    network layer, handling session management issues in the way IPv6 does
>  * we need for the lowest end to end layer to be a session management layer
>    between the network and transport layers, handling session management in

At first blush, I would tend toward the third bullet, and also include
that the transport endpoint is defined in terms of the session layer, so
that it's possible to have session layer mobility, complete with
connection migration.

Note that I'm not certain that the session layer belongs "between" the
network layer and transport layer.  It is certainly a functionality
provided to the transport and independent of the network, but it's
ancillary, not a pre-requisite for operations.  In much the same way,
the routing subsystem is an adjunct of the network layer, not closely
coupled to it.  More generally, what we think of as network layering
should probably be more of a lattice than a stack.

Tony

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Mar 2006 02:07:01 -0800

> should probably be more of a lattice than a stack.

OK, no problem. Give me better words for my discussion.

---

From: Scott W Brim <[email-masked]>
Date: Tue, 7 Mar 2006 09:21:06 -0500

> are used by endpoints in a multihomed route.

This is a great start, but I think it needs to be refined.

Elsewhere people have come up with the concept that a "session" is a
relationship -- not a pipe, not a flow of packets -- created to align
state information.  To do so it may use one or multiple communication
events.  A successful session could be as simple as "are you there?"
with a response.

Neither is a session the state information itself.  I think these
terms will be more useful in the future if you distinguish the
relationship between the endpoints -- the "session" -- from the
"session state" which reflects the relationship in the participants
and intermediate nodes.

How is a session different from a connection?  Just barely.  A TCP
"connection" can be used by HTTP for one exchange, then allowed to lie
fallow, then used for a different one.  That's one "flow" from the
point of view of the network but multiple communications events from
the point of view of the applications.  One possible difference
between session and connection might be that in a connection the
participating endpoints are the same for all communication flows,
while in a "session" involving multiple communication events,
different parties could be involved in different ones.  You don't buy
it?  In that case, really, the only difference I know of is that
"connection" is used for lower layers, L4 and below, while "session"
is used for L5 and above.

The important thing about a session is not how information is carried,
but that there is a relationship between participants for the purpose
of communications.  Sessions can be based on connectionless or
connection-oriented underlying technology -- once you separate it from
"connection" that doesn't matter.  They can be unicast or multicast.
They can but need not be assisted by intermediaries like SIP proxies.

> out, we will have a better notion of what further we might want to

Do we really need these absolutist layer definitions?  They came out
in 1978 (?) and were almost immediately considered inadequate for
describing the real world.  The GII replacement concepts came out in
the early-to-mid-80s, and were themselves mostly replaced in the 90s,
and yet the IETF is still using the simple model.  Real networks can
have so many layers, including multiple which one might call physical,
multiple which might be called session, etc.  The important
characteristic of a layer is not where it sits absolutely, but the
services it offers to layers above and the services it asks of the
layers below, plus how its endpoints are identified (and I don't mean
physical endpoints).  

As an example ...

> lowest end-2-end communications layer?>

If IPsec has its own endpoint identifiers, then very probably yes.  As
far as I know you can't say you want a tunnel to a particular tunnel
endpoint identifier, just to an IP address, so the answer is no.  A
tunnel is just a virtual link in the layer in which it is embedded.
IPv6 was right to embed it downward.  

On the other hand, as an example of the opposite, MPLS pseudowires
were not a layer -- just links -- until recently, when multi-segment
PWs were introduced.  Now you have an independent endpoint identifier
space, you can switch on them, you can even do routing.  MS-PWs are a
layer in their own right.  I believe grid middleware may also be a
layer.  In fact, Web Services probably is.  Instead of using an
absolutist model and saying there is *a* layer which is the MS-PW or
Parlay or WS layer, you allow for the possibility of many layers, and
you refer to them by their identifier space in a particular
instantiation.

All layers can potentially do things like fragmentation.  They are
universal capabilities.  You have fragmentation in Web Services.  In a
particular instantiation you want coordinated behavior between your
layers, just as you want coordination in mobility and restoration of
connectivity.  So far we seem to let all the layers define their own
functionality and then turn off what we don't want when implementing.  

Things like fragmentation are not a separate layer themselves, they
are "adaptation".  They are the massaging the layer does to the
information it is supposed to carry, at the edge of the service it
provides, in order to be able to do so.  

>    sessions securely regardless of the transport used
>    of the network layer, handling session management issues in the 
>    way IPv6 does
>    management layer between the network and transport layers,
>    handling session management in the way IPsec does in an
>    IPv4 implementation

Again, all layers can potentially do AAA for the resources they
manage.  You have AAA for use of your DSL link.  In this case you need
AAA for "above transport" but it would not be a separate layer.  I
believe what you call "session management" is "adaptation" to the
layer in question, not another layer.

One final thought: while messing about with terminology, let's be sure
to leave room for role-based functionality and not get too programmed
into layerist thinking.

swb

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Mar 2006 09:41:00 -0800

On Mar 7, 2006, at 6:21 AM, Scott W Brim wrote:
> Do we really need these absolutist layer definitions?

I think so. Yes, they are inadequate. In a private email to John  
Leslie, who was trying to nail down the distinction between the  
physical and the link layers, I wound up considering a DS1 interface.  
Think about pulse code modulation, clock recovery, framing, data  
carried, and so on. Placing the exact boundary between the two is "a  
leetle tough". That said, in teasing them apart and defining at least  
the general model, we clarify our thought. In this discussion, I have  
gleaned that Tony is interested in a layer above the transport that  
has a stated function, and I think he is also interested in a layer  
somewhere between the upper part of the network layer and the lower  
part of the transport layer, and maybe it's a layer in its own right,  
that accomplishes certain things. Nailing down those concepts lets us  
go to the next step with some clarity.

I'm not working on absolutes here, or at least I don't think I am.  
I'm working on clarity.

> to leave room for role-based functionality and not get too programmed

OK. Care to kick out some text we can pick apart?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Mar 2006 11:56:17 -0600

At the risk of horrifying a few real engineers...

From: "Fred Baker" <[email-masked]>
Sent: Tuesday, March 07, 2006 11:41 AM
Subject: Re: [arch-d] Defining terms

> In a private email to John  Leslie, who was trying to nail down the 
> distinction between the  physical and the link layers, I wound up 
> considering a DS1 interface.  Think about pulse code modulation, clock 
> recovery, framing, data  carried, and so on. Placing the exact boundary 
> between the two is "a  leetle tough". That said, in teasing them apart and 
> defining at least  the general model, we clarify our thought.

My model for the physical layer is that the physical layer tops out when you 
can tell the zeros from the ones - this is the realm of digital 
communications...

Thanks,

Spencer, who was enough of a software guy that I started out assuming you 
could tell the zeros from the ones - which is actually a lot harder than it 
seems like it would be, to software guys!

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Mar 2006 13:00:46 -0800

On Mar 7, 2006, at 9:56 AM, Spencer Dawkins wrote:

> My model for the physical layer is that the physical layer tops out  
> when you can tell the zeros from the ones - this is the realm of  
> digital communications...

ah, yes, but which zeroes and which ones? On a T-1 etc, framing the  
link is generally considered to be one of the services of the  
particular physical layer. That physical layer has a number of sub- 
layers.

This is getting a bit afield of where we need to go, I think. :-)

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 07 Mar 2006 22:56:03 +0100

At 18:56 07/03/2006, Spencer Dawkins wrote:

>>considering a DS1 interface.  Think about pulse code modulation, 
>>clock recovery, framing, data  carried, and so on. Placing the 
>>exact boundary between the two is "a  leetle tough". That said, in 
>>teasing them apart and defining at least  the general model, we 
>>clarify our thought.
>
>Spencer, who was enough of a software guy that I started out 
>assuming you could tell the zeros from the ones - which is actually 
>a lot harder than it seems like it would be, to software guys!

Not only to software guys. Not only for hardware/infrastructure 
people (cf. Fred Baker's remark). Please remember the problem of 
defining the ancillary services and the role left to the FCC to 
define the boarder.

I would say it is when you can change the 0 and 1 without changing 
what is necessary for the infrastructure to deliver properly.
jfc

---

From: John Leslie <[email-masked]>
Date: Mon, 20 Mar 2006 09:22:02 -0500

> events.  A successful session could be as simple as "are you there?"

   I see a benefit to thinking of "session" as a relationship between
endpoints. I'm not quite sure either Fred or Scott have stated this
distinctly enough.

   Fred is talking "shared state" which, I suppose, is correct; but it
tends to direct our attention to details of connection(s) which I think
deserve to be considered a different layer. IMHO, "session" may or
may not imply an ordering in information transmitted over different
connections.

   Scott talks of a "session" being "created to align state information."
I do not see that either as the "purpose" of a "session" or even a
necessary function of a "session". IMHO, a "session" should identify
endpoints which are processes invoked by users without regard to the
path over which information will flow between them.

   (Whether or not a "session" implies ordering of data communicated
might well be implementation-dependent.)

> "session state" which reflects the relationship in the participants

   I agree with Scott.

> How is a session different from a connection?  Just barely.

   I think we can draw a fairly clear distinction, actually.

   A "connection" is something maintained in a fully automated manner,
without messy interactions. Our network must find a way to route packets
from one end to the other. Thus, the endpoints of a connection must be
machine-comprehensible addresses, most often globally unique.

   A "session" is something created in response to human action. In
all likelihood, it depends upon rather messy DNS processes to resolve
to IP addresses which routers can use. If conditions change so that
those IP addresses no longer serve the necessary function, the human(s)
creating the "session" would generally prefer that some further DNS
magic makes the change transparent.

>  A TCP "connection" can be used by HTTP for one exchange, then allowed
> to lie fallow, then used for a different one.

   Agreed.

> That's one "flow" from the point of view of the network but multiple
> communications events from the point of view of the applications.

   True, but in practice all the communications events are likely to
represent the same "session".

> One possible difference between session and connection might be that
> in a connection the participating endpoints are the same for all
> communication flows, while in a "session" involving multiple
> communication events, different parties could be involved in different
> ones.

   I think I've missed Scott's point here.

   "Participating endpoints" could mean a number of things. IMHO, we
can correctly talk of "participating endpoints" for both "connections"
and "sessions", and mean quite different things.

> You don't buy it? In that case, really, the only difference I know of
> is that "connection" is used for lower layers, L4 and below, while
> "session" is used for L5 and above.

   Alas! We can't accept that kind of definition. ;^(

--
John Leslie <[email-masked]>

---

From: John Day <[email-masked]>
Date: Tue, 21 Mar 2006 12:48:39 -0500

For starters, you might take a look at the concept of connection in delta-t.