Subject: RE: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 4 Mar 2004 13:15:15 -0800

I believe layer 2 protocol is the same in both models (internet and
OSI).
Common example is Ethernet. May be the use of the word "interconnect"
was confusing.
What I mean is that the ForCES protocol should be able to run directly
over layer 2
protocols like ethernet. This might be useful in some in-box scenarios.

Let me know if you have any other questions.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:[email-masked]] 
Sent: Thursday, March 04, 2004 12:56 PM
To: Khosravi, Hormuzd M
Cc: [email-masked]
Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team
Administrivia

Hormuzd,

I don't understand this requirement (reproduced below):

------------------------------------------------------------------------
The ForCES protocol will run directly over layer 2 interconnects. It can
either use additional TLVs or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.
------------------------------------------------------------------------

Can you explain this?  Which L2 are you refering to? (Internet Protocol
layer 2 or OSI layer2). 

Regards,
Alex.

Khosravi, Hormuzd M wrote:

>Here is a starter list of common high level ideas/features/principles
>that I believe we all agree on...
>
>All ForCES protocol messages should consist of a fixed size header and
>variable size payload fields. Further, the protocol header is made up
of
>CE ID, FE ID fields in addition to other fields (TBD)
>
>All ForCES protocol messages should be 32-bit aligned.
>
>The ForCES protocol payload consists of a number of variable size TLVs
>i.e. all ForCES messages must use TLV encoding.
>
>The FE ID field in the protocol header is assigned or allocated by the
>CE.
>
>The ForCES protocol/model must support the discovery of static
>capabilities of an FE. The protocol/model may also support dynamic
>capabilities when they are supported by the FEs.
>
>The ForCES protocol should support logical addressing for multicast in
>addition to unicast. The FE ID, CE ID fields in the header will be used
>for addressing FEs, CEs.
>
>The ForCES protocol should have separate channels/connections/(any
other
>terminology ?) for data and control messages. By data messages we mean
>control protocol packets such as OSPF, RIP packets, etc. which need to
>be redirected from FE to CE or forwarded from CE to FE. By control
>messages we mean all other control/capability/configuration messages.
>
>The ForCES protocol will mandate a minimum set of transports for data
>and control connections/channels for interoperability reasons.
>
>The ForCES protocol will take advantage of underlying transports/
>interconnects to provide features such as reliability, security to keep
>the protocol design itself simple.
>
>The ForCES protocol will run directly over layer 2 interconnects. It
can
>either use additional TLVs or encapsulation headers or transports such
>as TIPC to provide the missing functionality such as reliability,
>fragmentation, etc.
>
>This is just a starting list, we should continue adding to this one as
>we discuss more ideas.
>Pls feel free to give comments or make any changes to the text above.
>
>
>BTW note to the list-admin, [email-masked] address is not working.
>
>Regards
>Hormuzd
>
>-----Original Message-----
>From: Khosravi, Hormuzd M 
>Sent: Tuesday, March 02, 2004 4:55 PM
>To: [email-masked]'
>Cc: Putzolu, David; [email-masked]; [email-masked];
>[email-masked]; Steve Blake; Robert Haas;
>[email-masked]; [email-masked]; Wang,Weiming; Patrick Droz;
>jeff pickering; [email-masked]; Deleganes, Ellen M; [email-masked];
>[email-masked]; [email-masked]
>Subject: RE: ForCES Protocol Analysis Design Team Administrivia
>
>Hi Jamal, All
>
>I briefly chatted with David, Patrick regarding our deliverables by
>March 20th and I got a feeling that they are looking for whether we can
>merge the protocols and what are the high level design features that we
>all agree on.
>I think most of us already agree that we can achieve a merge if we work
>towards it. I would suggest that we first try to get all the high level
>features list out and agree on it, then proceed to the details.
>
>So in that spirit I would suggest to postpone getting into details such
>as length of bits in the header, what the format is, etc for now and
>quickly come up with a list of common ideas. Some of the items below
>that we all seem to agree on may be a good start.
>
>
>regards
>Hormuzd
>
>
>
>_______________________________________________
>Forces-protocol mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/forces-protocol
>  
>

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 Mar 2004 16:47:43 -0500

Hormuzd,
heres some text for application addressing

----
Source and Destination IDs:

These are application level identifiers. They could be used
to address the following:
- an LFB on the FE,
- a set of LFBs on an FE
- a set of LFBs on different FEs 
- proxies for LFBs,
- proxies for control application in the form on the CEs, 
- the FE,
- a set of FEs
- all FEs
- the CE.
- a set of CEs
- all CEs

The above shows need for having the ID being able to be IDed
as unicast, broadcast or multicast.

For clarity, i could create a diagram of what we used.

I will post the header i posted earlier next. Or maybe we should 
stick to resolving this first.
Hopefully we can get to a good way to beat the several issues, i am
doing this to hopefuly come to a style that we can use to beat the
issues.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Fri, 05 Mar 2004 15:03:40 -0600

Hi Hormuzd,

If ForCES run directly over L2, we are suggesting it acts like the 
network (OSI) or
Internet layer (IP). That means it validates, routes, and demultiplexes 
amongst various
transports/applications  (amongst other functions). Is that what we want 
here?

Regards,
Alex.