Subject: RE: Forces-GSMP overlap

From: Tom Scott <[email-masked]>
Date: Thu, 15 Feb 2001 18:47:50 -0500

Hormuzd et al.,

In addition to the overlap between ForCES and GSMP, it would also be
valuable to map overlaps with ieee-pin.org and msforum.org. And it all
seems to come under the aegis of the abstract state machines (formerly
evolving algebras) at:

http://www.eecs.umich.edu/gasm
http://www.uni-paderborn.de/cs/asm/

Call it the Turing switch.

-- TT

-------- Original Message --------
Subject: RE: Forces-GSMP overlap
Date: Thu, 15 Feb 2001 13:17:19 -0800
From: "Khosravi, Hormuzd M" <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]'" <[email-masked]>, [email-masked]

Hi All,

Jerry had sent out an interesting mail on ForCES-GSMP overlap
sometime back and I think that's a useful discussion to have
on both the mailing lists in context with the ForCES charter
discussion and the GSMP charter update. IMHO GSMP and ForCES
both seem to be applicable for a similar framework. GSMP is
more focused on label-switches (ATM,MPLS) whereas ForCES is
focused on IP switches/routers. Thus the underlying model 
which is being controlled is quite different in both cases.

It would be nice to know the views of other members on the
mailing lists on this issue. This is an important discussion 
to have before the March IETF meeting.

Thanks,
Hormuzd.

-----Original Message-----
From: Jaroslaw Sydir [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 9:27 AM
To: [email-masked]; [email-masked]
Subject: Forces-GSMP overlap 

Hello folks. At the FORCES BOF and the GSMP WG meeting last week there
was discussion about a potential overlap in the proposed work of the
two
groups, specifically with respect to the control of IP devices. I
believe that although some overlap exists, it is not the case that
both
groups are aiming to do exactly the same thing.

I think that the two groups are approaching the problem at two
different
levels. FORCES is approaching the problem at a lower level. At this
level can be defined protocols between the FEs and CEs (forces
terminology). These protocols would allow the FEs and CEs to discover
each other and allow the CE to program the FEs. In this model, it is
possible that the CE be in a physically separate location from the FE,
but in practice its not clear that it makes sense to build a network
element without even a minimal control entity. It does make sense to
build an NE with a minimal CE which speaks the CE-FE protocols and
acts
as a GSMP slave (or whatever NE control protocol you wish to use).

This brings up the higher level protocol, which is the focus of the
GSMP
WG. This higher level protocol is a protocol for controlling a
complete
NE. This is the purpose of GSMP (for switched devices). This type of
protocol provides the flexibility to deploy the control plane on or
off
board the network elements. It is this level of protocol that the GSMP
WG would produce for IP devices under the "extend to deal with IP
routers" item in the proposed charter.

Now, even though the two groups are talking about two slightly
different
sets of protocol, I believe that some of the primitives (objects,
TLVs...) used by the two protocols might be the same. Specifically
they
should both deal with the creation/configuration of fileters, meters,
schedulers, queues, etc. So I think that the work can go on in two
groups, but that the groups should coordinate their efforts in
defining
these low level primitives.

Jerry Sydir

---

From: "tom worster" <[email-masked]>
Date: Sat, 17 Feb 2001 00:30:27 -0500

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tom Scott
> 
> In addition to the overlap between ForCES and GSMP

personally, i see no overlap. gsmp controls l2 switches;
forces wants to control l3 forwarders. you can generalise
these to one thing if you want but gsmp did not do so and 
forces does not appear to plan to do so.

c u
fsb

---

From: ad <[email-masked]>
Date: Sat, 17 Feb 2001 10:48:54 -0500 (EST)

Hi Tom,

> forces does not appear to plan to do so.

That is one way of looking at it.  But I don't agree that there is
anything inherent in GSMP that makes it L2 specific.  It switches on
labels.  If it is switching on an L2 label, then we can call it a L2
switch. If the label is an L3 label, then we can call it a forwarder if
you wish.  As far as I can tell GSMP is agnostic about what abstracted
layer the label exists at. If a field or a set of fields can be identified
and standardized as a label, it can switch on it.  I think this layer
indifference is actually one of the strngths of GSMP; especially in a
world where layer stacking and layer inversion are so prevalent.

So, personally, I do no see that the difference between L2 and L3 is
critical in this discussion. For example, the current GSMP protocol allows
the use a FEC as a label in an MPLS edge switch. Though the intent of the
FEC label is to allow one to switch from a FEC to a MPLS label, there is
no restriction against switching from FEC to FEC; though I do think that
support in the rest of the protocol for that sort of switching, or is it
forwarding, is weak at the moment.  E.g. there is no support for
expressing policies that would apply to the treatment of those FECs.

a.

-- 

Avri Doria
+1 401 663 5024

---

From: "tom worster" <[email-masked]>
Date: Sun, 18 Feb 2001 12:49:03 -0500

On Behalf Of ad
> switch. If the label is an L3 label, then we can call it a 
> forwarder if you wish. 

avri,

gsmp's forwarding is strictly based on the 
exact match algorithm running on one or more
labels. forces needs to deal with combinations
of much more complex algorithms (e.g. generalised 
protocol parsing decision graphs, qos classifier
decision graphs and forwarding decisions which
together use exact matches, mask and match, 
arithmetic range matches, longest prefix matches, 
and perhaps some others). also gsmp provides
label swapping while forces has to do various, 
some rather complex, packet manipulations. so 
while i accept that it is possible in theory to 
generalise gsmp's functional model to fit the 
forces requirements, i do not see that this is 
the most practical approach to developing a 
functional model for forces. 

on the other hand it is likely that a decent
forces functional model could do what gsmp's 
can do. in that sense, perhaps there is overlap.

in my previous email i acknowledged the possibility
of such generalisations. but none of this relates 
directly to the point i wanted to make in that
email. which was that the gsmp wg and the proposed 
forces wg do not appear to have any charter 
conflict in the areas of application support or 
problem statement.

> As far as I can tell GSMP is agnostic about what abstracted

forces is going to need a lot more than label 
operations (exact match on labels and label 
swapping) to solve their problem.

c u
fsb

---

From: [email-masked] (Joachim Buerkle)
Date: Sun, 25 Feb 2001 17:52:27 +0000

I fully agree with Avri.
I also see GSMP independent of the Layer.
Joachim

- - - - - - - - - - - - - - -

---

From: "tom worster" <[email-masked]>
Date: Sun, 25 Feb 2001 16:39:24 -0500

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joachim Buerkle
> I also see GSMP independent of the Layer.

my comments on l2 v l3 were mistaken. the technical
difference between gsmp and forces is between label
switching and generalised parsing. 

c u
fsb

---

From: "Avri Doria" <[email-masked]>
Date: Sun, 25 Feb 2001 23:06:24 -0500

(Including Forces in the conversation)

> switching and generalised parsing.

Since i think that most switches need to parse to get the label they
are switching on, i expect that this is not really the crux of the
issue.  I think it boils down to the complexity of the rule
that one needs to express the the action to take per packet
or per flow. GSMP is well suited to the implicit simple rules 
pertaining to a label, service factors, and adaptations.

Once more work has been done on the Forces model we will discover 
how complex the rules need to be and whether they are too complex
for the GSMP structure and require something else, like complex
data/rule/role modeling in a PIB, or something else altogether.

My view of the relation is that Forces denotes a technical problem 
that remains to be understood and solved, while GSMP is a solution
for some class of problems.
More then that remains to be determined.

a.

-- 

Avri Doria
+1 401 663 5024