Subject: draft submission

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 12 Aug 2003 17:58:18 +0800

Dear David and Patrick, 
 
 Attached is an Internet-Draft that I submit to ForCES WG. Please help to 
 put into the draft archive. Thank you.
 
 Best Regards,
 
 Weiming Wang

---

From: Alex Audu <[email-masked]>
Date: Wed, 13 Aug 2003 09:50:23 -0500

I like the ideas proposed in this draft a lot. It mirrors some code we wrote
in house that maps a service to flows and functional blocks in the flows
(according to IEEE P1520 specs).

An issue however is you may be assuming that resources in the FE are not
limited, and that you can configure them arbitrarily.  But you can't assume
the FE will have a classifier with up to M outputs for example. So you need
a way to query the capabilities of the resources available in the FE before
you configure the topology.

On further reading, I see that you have the TopologyRequest() to query the
FE for its available resources.  This is really good. I like it!

Cheers,
Alex.

"Wang,Weiming" wrote:

>   ------------------------------------------------------------------------
>                                               Name: draft-wang-forces-model-topology-00.txt
>    draft-wang-forces-model-topology-00.txt    Type: Plain Text (text/plain)
>                                           Encoding: quoted-printable

---

From: Weiming Wang <[email-masked]>
Date: Wed, 13 Aug 2003 23:33:10 +0800

Hi Alex, 

Thank you for your comments. You are absolutely right that we need to query the resources befoer we begin to deploy the topology. Actually I have been thinking of resource repesentation, which I think, like the topology, is another important and tough aspect for ForCES protocol to go ahead. Since this is a little away from the sepcific topic of topology, I did not include it in. But reasonably, it should be mentioned in the draft. I will do this. Thank you.

weiming

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Aug 2003 15:46:55 -0400

>  put into the draft archive. Thank you.

  I like the explicit labelling of connections, and the thought you've
put into the protocol between the CE and FE.  Abstracting the connection
labels is also good.  It means that the representation of data between
FE's does not necessarily have to be the same as is used by CE->FE
communication.

  Other comments:

Section 5:

  the classification rules should be explicitly described as "this is
semantically what we mean".  Defining a classification language is
outside of the scope of ForCES.

  I disagree with the "drop packet" result of classification.  The FE
model has an explicit "dropper" block which should be used here.  The
reason is that even within your model, there is NO way to tell the
classifier to drop the packet.  There IS, however, a way to configure a
packet dropper, and then to tell the classifier to send the packet out
the "PkfGID" which goes to the dropper.

  This simplifies both the model, and the requirements for the CE->FE
protocol.  In addition, some vendors may CHOOSE to implement the packet
dropper within their classifier, but others may not.  The model should
map to both implementations, which means that the "dropper" block must
be external to the classifier.

  In addition, if you want to know how many packets are dropped, you may
want a "meter" block between the output of the classifier, and the input
of the dropper.  If the dropper is implicitely inside of the classifier,
then such metering becomes difficult to manage and configure.

  You also talk about the "match block".  I'm still unclear as to why
this block is so useful, in that you claim it's good for anything.  If
so, why define other blocks?    Why not just define a "match" block
which does everything?  And once you've done that, how do you configure
the internals of the "match" block?

  The whole point of the FE logical block model is to NOT "unify
operations of blocks".  Those operations MUST be kept explicitely
separate, in order to permit the model to be independent of vendor
implementations.

  Even the "match" block you propose can be decomposed into other
blocks, as defined in the FE Model document.  So the "match" block is
explicitely redundant with them, and I don't see why we would gain
anything by using it.

  Alan DeKok.

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 14 Aug 2003 15:10:21 +0800

Hi Alan,

Thank you for your valuable comments.

In reply,

On 2, 3, and 4,  I appreciate your idea that we should be careful to let a classifier
 to do drop operation, for some classifier block may not support this operation or 
dropped packets need to be metered. It would  be better and more compatible to 
vendors to have a dropper put at the classifier output to do this. So I will change 
the example scenario in the draft a little. But though it actually belongs to model work, 
I still like to have a little discussion with you that if it is possible or needed to let all 
drop functions  done by dropper blocks? For e.m., in an ERD or RED supported 
queue, shall we just state the drop policy to the queue or will we put a dropper 
outside of the queue to do it. The same case may be also for schedulers. 

On 1,  my intention on using classifier rules is just let CE  to tell a classifier what to 
and how to do its job. Therefore the rules are only used as a kind of information transfering 
method to let the classifier to know the info. In more common words, rules are just 
a kind of attribute expression way.  It has nothing to do with how a classifier should 
internally act, nor is it a classification language. 

On 5,6,7,  It is true that I have not had the "match block" part very clearly written 
owing to the space limit. Actually this part does not fit in the draft very well, so I have 
an intention to move it away from the next update draft. I think if the idea did have some 
meaning, it should be in the model attribute scope instead of topology. My fundamental 
openion to propose a "match block" is that,  in the final ForCES protocol, we may need 
to associate every block with a specific protocol message. This may make protocol look 
quite redundant, and users may also feel a little boring to go through the protocol. What 
I intend to do is try to unify the representation of block attributes in some way, so as to shorten the 
protocol in text, while without loosing the protocol ablility. A rule based match block 
seems able to unify some of the blocks like a classifier, a forwarding engine from 
perspective of abstractive attribute representation. It actually can not do 'anything'.  And 
also I think this unifying has no limitation to different implementations of vendors, we can 
still use different ways to implement them. When using a "match block" to express different
functions of the block, we only need to use a tag to indicate it, while every other part of the 
message keeps same. New functions can be defined just by expanding the tag definition. 
No intention we should make to decompose it back to its original blocks. 

Thank you again for your detailed comments. I really appreciate it.

weiming

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Aug 2003 11:36:23 -0400

> outside of the queue to do it. The same case may be also for schedulers.

  We could put the dropper outside of the queue block, for the same
reasons why it's outside of the classifier block.

  My experience working with models of network devices is that anything
which is *implicit* in the model creates problems later.  I would rather
start off the model by making everything explicit, and then, through
practice, decide which parts may be OK if they're implicit.

  So I'm not opposed to a dropper block being inside a classifier
block.  I'm opposed to *starting* the model that way.

> internally act, nor is it a classification language.

  That point needs to be made clear in the draft.

> My fundamental
> quite redundant, and users may also feel a little boring to go through the protocol.

  I'm not sure what you mean by that.  Every logical block should
probably be addressed in the protocol.  The protocol can be generalized
to address multiple blocks in a similar manner.  I'm opposed to having
the *blocks* generalized, because the whole purpose of having blocks is
that they describe specific functions.

> What
> perspective of abstractive attribute representation.

  I don't see why.

> It actually can not do 'anything'.  And
> still use different ways to implement them.

  I disagree.  The more functionality you put into one block, the more
difficult you it is to have that block model a vendor implementation.

> When using a "match block" to express different

  I'm not sure what you mean by that.  You seem to have some ideas which
aren't coming across well.

  Alan DeKok.

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 15 Aug 2003 16:14:16 +0800

I'm interested in this discussion though it's not so related to topology. Hope it of some help for model work.

>   That point needs to be made clear in the draft.

OK, thank you.

> aren't coming across well.
 
Followed is the message format to mount a 'match block' to FE, which  I used in my experimental platform
(work still in progress), to uniformly represent block attributes of classifiers, filters, forwarders, NATs, etc.

       ==========================================================================

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

~      <GRMP Protocol Header with MessageType='MountBlock'>     ~

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|       FE-ID                   |         Msg-Tag               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      BlockType='MatchBlock'   |     ThisBlockInstanceID       +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      IngressNumber            |     EgressNumber              +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~               <List of Ingress PkfIDs>                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~               <List of Egress PkfIDs>                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type='MatchBlock-Role'    |             Length            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Value= <MatchBlockRoleTag>                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Type='MatchBlock-Policy'  |             Length            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|ConflictPolicy |            Reserved                           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Type='MatchBlock-AddRule' |             Length            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                    Value= <RuleFormat>                        ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                                                               ~

~               <More AddRule or other TLVs>                    ~
~                                                               ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where, 

GRMP: the protocol name defined.

FE-ID,Msg-Tag,... to PkfIDs: Please see the topology draft Section 4.3.1.

MatchBlock-Role TLV: an attribute to present the role of this match 

                     block that acts in the mounted place.

MatchBlockRoleTag:

      = 0: this is a generic match block

      = 1: a classifer

      = 2: a filter

      = 3: a forwarder

      = 4: a NAT

      ...

(This tag may act as informatin for FE implementation layer to select 

most suitable implementation method based on the role).

MatchBlock-Policy TLV: an attribute to present policies related to matching.

   ConflictPolicy: =0 : (default) Longest Prefix Matching(LPM)

                   =255: No conflict policy

Matchblock-AddRule TLV: an attribute to add a rule to the match block. 

RuleFormat:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         PacketFromNum       |           Reserved              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                <List of Packet Input PkfIDs>                  ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         MatchFieldNum       |           Reserved              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                <FieldFormat for Match Field #1>               ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                                                               ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                <FieldFormat for Match Field #N>               ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                      <ActionFormat>                             ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where, 

   PacketFromNum: number of input ports this rule get packets for processing.

   MatchFieldNum: number of fields the rule is to match.

FieldForamt:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|OP |T|C|    Reserved         |            Length               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                FieldStartPoint/FieldName                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                    FieldMatchLength                           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                     FieldMatchMask                            ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                FieldMatchPattern/PatternArea                  ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where,

OP  =00---default "AND" matching field

=01---Reserved

=10---reserved 

=11---"NOR" field

T   =0---using bit location as match start point

    =1---using well-known IP packet field name is match position

FieldName=0: "IPv4DestAdd" --- Destination IPv4 IP address field

    =1:"IPv4TOS" or "DSCP"---match TOS field
    =2:"IPv4SourceAdd"---Source IP address field
    ...

C   =0---using explicit pattern to match

    =1---using pattern area to match

ActionForamt:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   ActionTag   |  Reserved     |        Length                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                <Output port PkfIDs/NATTransformedAdd          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ActionTag=0: "OUTPUT"---put to listed output PkFlow

=1: "DROP"---drop the packet

=2: "NAT"

         ...

 =======================================================================

Besides, just as Gupta said  " we call a collection of rules a classifier". 

( http://www.cs.rpi.edu/~yener/TEACHING/IP_Spring03/readings/classification_tutorial_01.pdf )

The match block I used may be better to give a name just a "classifier".  

I have also read one of your article on specifical classifier processing module and got valuable 

knowledge on current classifier implementation.

weiming

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Aug 2003 10:10:40 -0400

"Wang,Weiming" <[email-masked]> wrote:
> Followed is the message format to mount a 'match block' to FE, which
> I used in my experimental platform (work still in progress), to
> uniformly represent block attributes of classifiers, filters,
>  forwarders, NATs, etc.
...
>                  = 0: this is a generic match block

  Why?  What's wrong with having separate blocks for filter, classifier,
forwarder, NAT, etc.

  I still don't understand why you think it's necessary to put the
functionality of 4 or more blocks into one "super-block".  Why not just
use the 'BlockType' field to represent filter, classifier, forwarder,
NAT, etc.  You will lose nothing in either your model or protocol by
doing this.  Instead, both model & protocol will become simpler.

  The match block, and the associated protocol message is 100% redundant
with other blocks, and other protocol messages.  It's therefore
unnecessary, and should be discarded.

...
> The match block I used may be better to give a name just a "classifier".

  Then why not call it a classifier?  What value does it add over the
Classifier Block, given in Section 5 of the model draft?

  Alan DeKok.

---

From: Weiming Wang <[email-masked]>
Date: Sat, 16 Aug 2003 00:14:45 +0800

Hi Alan,

I think we may  need to be close to end of the discussion, for what I just want to state is only the idea
that a set of functional blocks currently defined in FE model are generically  exactly the same
and can be manipulated in the same way by protocol from the PERSPECTIVE of ForCES 
PROTOCOL LAYER. There are their individual pros and cons to unify them or to seperate
them in model representation. I have already stated the pros for unification. Even if the model group thinks it's better 
to seperate them from the block name, I hope at least from the attribute point of view, you may consider
using more uniform expressions like rules for such a set of blocks, it will benifit. 

Regards,

weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Aug 2003 15:52:58 -0400

Actually, I would be very disappointed if there were a distinct protocol
message in the Forces protocol for each type of block.  That would be an
unnecessarily complex protocol, and would distinctly limit extensibility.

Rather, I would hope (and expect) that all blocks will use a basically
common protocol messaqing, with different attributes (and methods, still
under discussion) being invoked by the same structure.
That is, I would hope and expect that there will be
a common mecahnisms to send requests and response among FE and CE components
a common way to indicate the FE block or FE topology element being manipulated
a common set of operations, such as
    get attribute
    set attribute
    create entity
    destroy entity
    interconnect output port A of FELB1 with input port B of FELB2
    get list of entities
    and a number of other operations independent of the block types
Attributes names, attibute values, etc will be carried in a standardized
fashion.  (Whether XML, ASN1, or something else.)
This, when we create and extend a block library, the CE and the FE control
components will be able to use the same protocol mechanisms to manipulate
new blocks.

Yours,
Joel M. Halpern