Subject: FW: [issue32] Packet Redirect

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 13 Jul 2005 08:48:24 -0700

FYI...format of the Redirect TLV on which we seem to be reaching a
concensus.

-----Original Message-----

I agree with this format for Redirect TLV as well. Should we consider
this issue closed? Any other comments on this?

Thanks
Hormuzd

-----Original Message-----
From: Wang,Weiming [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2005 7:43 AM
To: Robert Haas; Khosravi, Hormuzd M; avri doria; Putzolu, David;
Patrick Droz; [email-masked]; [email-masked]; Joel M. Halpern
Subject: Re: [issue32] Packet Redirect

Are you supposing the format as:

Redirect TLV
    LFB class ID
    LFB Insatnce ID
    Meta-Data TLV
    Redirct Data TLV

I can agree with this well. The only thing is then how the meta-Data TLV
should be defined here? Still using Path-Data format or using constant
fields ? If constant fields, then it seems quite identical to that was
showed below. 

Sorry to all, I'v to go first.

Thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [issue32] Packet Redirect

> I think the Packet Data TLV you have here is the wrapper to carry the 
> packet meta-data?
> If so, the only question I have is whether it might be simpler and
more 
> general to just treat the port as part of the meta-data rather than 
> assigning it a separate field.  After all, that information will
generally 
> be used / provided by some other LFB than the redirect LFB.
> 
> Yours,
> Joel
> 
> At 10:00 AM 7/13/2005, Wang,Weiming wrote:
> >Sorry, the following LFB Type should be Type = Redirect instead of
LFBselect.
> >
> >----- Original Message -----
> >From: <mailto:[email-masked]>Wang,Weiming
> >To: <mailto:[email-masked]>Robert Haas ; 
> ><mailto:[email-masked]>Khosravi, Hormuzd M ; 
> ><mailto:[email-masked]>avri doria ; <mailto:[email-masked]>Joel
M. 
> >Halpern ; <mailto:[email-masked]>Putzolu, David ; 
> ><mailto:[email-masked]>Patrick Droz ; 
> ><mailto:[email-masked]>[email-masked] ; 
> ><mailto:[email-masked]>[email-masked]
> >Sent: Wednesday, July 13, 2005 9:58 PM
> >Subject: Re: [issue32] Packet Redirect
> >
> >Hi all,
> >
> >I may only have half an hour for the meeting owing to some urgent 
> >business. I ask to take first
> >some minutes of  the call meeting to discuss the packet redirect
message 
> >and try to solve it quickly?
> >
> >After quite a lot discussion, I try to summary it as in the following

> >format for packet redirect message:
> >
> >         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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |        Type = LFBselect       |               Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                          LFB Class ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                        LFB Instance ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |                          Port Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         .
.
> >         |                       Packet Data TLV
|
> >         .
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >Packet Data TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |        Type = Packet TYpe     |               Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         .
.
> >         |                          Packet Data
|
> >         .
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >Thanks,
> >Weiming

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 16 Jul 2005 23:04:14 -0700

Weiming,

This looks very good to me. Except for the one detail being discussed
with Joel, this issue looks closed to me.

Thanks for the good work!
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: Friday, July 15, 2005 6:26 AM
To: [email-masked]
Subject: Re: [FORCES] [issue32] Packet Redirect

Hi all,

I tried to compose a text for the update of the redirect message part in
the attachment, based on our current discussions . Pls send coments on. 

Thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 07, 2005 10:38 AM
Subject: Re: [issue32] Packet Redirect

> There is a whole section on meta-data in the model document.
> I would expect most meta-data fields to be 32 bits.
> The CE can choose to use a meta-data classifier and multiple meta-data

> fields in order to steer the packet to the right LFB.  And the CE will
know 
> what meta-data field the LFB will use for selecting among its ports.
> 
> 
> This relates to a larger question for the list...
> We NEED an LFB library.
> Please!
> To do this, we need folks to actually write definitions of LFBs.
> (I think we have an editor who is likely to be willing to pull things 
> together.  At least I hope so.)
> There are a lot of LFBs that need writing.
> If this WG doesn't start producing them, it won't happen.
> 
> 
> To get back to your question Weiming, given a set of LFB definitions
and 
> the meta-data they use, I can better specify what the CE will send / 
> receive.  But in  an abstract sense, since it will be information
flowing 
> between the redirect LFB and the eventual interface LFB, the way the
model 
> prescribes to carry that information is as meta-data.  This is the
same 
> meta-data that will need, for example, to come out of
longest-prefix-match 
> and next-hop resolution LFBs.  After all, they need to be able to
direct 
> packets to be shipped out specific interfaces, with specific headers,
etc.
> 
> Yours,
> Joel
> 
> At 10:27 PM 7/6/2005, Wang,Weiming wrote:
> >A very simple question then, how many bits we then can assign to the 
> >meta-data like the port number ?
> >
> >thanks,
> >weiming
> >
> >
> >To: "Weiming Wang" <[email-masked]>;
<[email-masked]>
> >Sent: Thursday, July 07, 2005 4:09 AM
> > > After some discussion, the operational data may be simpler than I
had been
> > > thinking.
> > > We can simply attach (in some reasonable TLV format) all the
meta-data.
> > > So packets from the CE come with meta-data, and the CE gets all
the
> > > meta-data from the FE associated with a packet.
> > > That ensures that all the necessary information is available,
without
> > > making the redirect LFBs complex.
> > >
> > > Yours,
> > > Joel
> > >
> > > At 10:44 AM 7/6/2005, Weiming Wang wrote:
> > > >Joel,
> > > >
> > > >I tend to agree with your idea below except the index.  Could you
give
> > > >more details on its necessity? Thanks.
> > > >As a result, the agreeable format to me seems like:
> > > >
> > > >Redirect TLV, whith contains
> > > >     LFB class ID
> > > >     LFB instance ID
> > > >     operation TLV (REPORT), which contains Path-Data
> > > >     Packet TLV
> > > >
> > > >We further define that that Path-Data should supply enough
information 
> > for
> > > >the followed packet. At least it should include information about
the 
> > port
> > > >number the redirect packet is input(sink LFB) or is output
(source LFB),
> > > >and the redirect packet type. How this is defined is left to
model where
> > > >redirect LFBs and the attributes are defined.
> > > >
> > > >We need to solve this a little sooner.
> > > >
> > > >thoughts?
> > > >
> > > >Thanks,
> > > >Weiming
> > > >
> > > >Subject: Redirect Message
> > > >
> > > >
> > > > > Based on discussion, and based on my earlier message that
specific
> > > > protocol
> > > > > messages may have different top level TLVs, here is a
description 
> > of the
> > > > > contents of a redirect message.
> > > > >
> > > > > A redirect message will contain a redirect TLV.
> > > > > A redirect TLV consists of three fixed fields, and meta-data
TLV, 
> > and the
> > > > > packet.
> > > > > The fixed fields are
> > > > > o the LFB Class ID of the redirect source or redirect sink LFB
on 
> > the FE
> > > > > associated with this packet
> > > > > o the LFB Instance ID of the redirect source or redirect sink
LFB on
> > > > the FE
> > > > > associated with this packet
> > > > > o an index within that LFB to identify configured properties
of the 
> > packet.
> > > > >
> > > > > The meta-data TLV contains dynamic information needed by the
FE or 
> > CE to
> > > > > process the packet.  This will need to be spelled out in more 
> > detail.  It
> > > > > may need to use path encoding.
> > > > >
> > > > > Following this will be the packet.
> > > > >
> > > > > Yours,
> > > > > Joel
> > >

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 17 Jul 2005 15:08:44 -0700

Yes, that sounds good to me.

Thanks
Hormuzd

-----Original Message-----

Anyway, I suppose we may close the #32 issue on the whole, only leaving
above question for some more discussion.

Thanks,
Weiming

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 23 Jul 2005 22:26:56 -0700

Yes, absolutely. LFB design cannot be done in seclusion, the designer
has to think about other LFBs in the system that will work in
conjunction with each other to provide a certain functionality. As per
the ForCES charter, for the first rev of the model, lfb library, we
should target LFBs to provide IPv4 forwarding and QoS functionality. We
had discussed this long time back at the NPF and even at an IETF meeting
I remember and Steve/Zsolt had a list of about 20 LFBs that were needed
for this (IPv4 forwarding, Diffserv, Packet redirection, Ports, etc).

regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern

Just for completeness, I do have one other concern.  If we make the 
meta-data ID fixed, then the LFB designer has to figure out what id
makes 
sense for any meta-data he generates, and what ids are assigned for 
meta-data he wants.  This means that the process of defining an LFB is
now 
intertwined much more tightly with the definition of other existing or
new 
LFB definitions.

Yours,
Joel