Subject: [forces] IPv4UcastLPM - LFBlib readability suggestions

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 3 Jun 2011 00:29:03 +0300

Greetings to all,

Here is the readability suggestion for the IPv4UcastLPM.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 3 Jun 2011 00:29:32 +0300

Greetings to all,

Here is the readability suggestion for the IPv6UcastLPM.

Regards,
Evangelos Haleplidis.

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 6 Jun 2011 16:05:27 +0800

Hi all, 

Followed is the update of the description text for IPv4UcstLPM LFB based on Evangelos's version. Pls review it again. 

One editorial note is raised on the ECMP/RPF output port. 

thanks,
Weiming

---------- 
1.1.1. IPv4UcastLPM
 
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match (LPM) process. 
 
This LFB also provides facilities to support users to implement equal-cost multi-path routing (ECMP) or reverse path forwarding (RPF). However, this LFB itself does not provide ECMP or RPF. To fully implement ECMP or RPF, additional specific LFBs, like a specific ECMP LFB or an RPF LFB, will have to be defined. This work may be done in the future version of the document.
 
1.1.1.1. Data Handling
 
This LFB performs the IPv4 unicast LPM table looking up. 
It always expects as input IPv4 unicast packets from one singleton input known as "PktsIn". Then the LFB uses the destination IPv4 address of every packet as index to look up the IPv4 prefix table and generate a hop selector as the matching result. This result will associate to the packet as a metadatum to output to downstream LFBs, and will usually be used there as an index to find more next hop information. 
 
Three singleton output ports are defined to output LPM results. 
 
The first singleton output known as "NormalOut", which will output IPv4 unicast packets that has passed the LPM lookup and got a hop selector as the lookup result. The hop selector is associated with the packet as a metadatum. Followed the normal output of the LPM LFB  is usually a next hop application LFB, like an IPv4NextHop LFB.  
 
The second singleton output known as "ECMPOut" is defined to provide support for users wishing to implement ECMP or RPF. 
 
An ECMP flag is defined in the LPM table to enable the LFB to support ECMP. When a table entry is created with the flag set true, it indicates this table entry is for ECMP only. A packet, which has passed through this prefix lookup, will always output from "ECMPOut" output port, with the hop selector being its lookup result. The output will usually directly go to a downstream ECMP processing LFB, where the hop selector can usually further generate optimized one or multiple next hop routes by use of ECMP algorithms. 
 
A default route flag is defined in the LPM table to enable the LFB to support a default route, and RPF also. When set true, the table entry is identified a default route and as a forbidden route for RPF also. In this case, a packet which has passed through this prefix lookup will also output via "ECMPOut" to a downstream specific RPF LFB.(Editorial note: how will the output be followed if we require both  ECMP and RPF LFBs?)
 
The final singleton output is known as "ExceptionOut" and is defined to allow exception packets to output here. Exceptions include cases like:
   o Packets can not find any routes in the prefix table. 
 
1.1.1.2. Components
 
This LFB has two components.
   
The IPv4PrefixTable component is defined as an array component of the LFB. Each row of the array contains an IPv4 adrress, a Prefix length, a Hop Selector, an ECMP flag and a Default Route flag. The LFB uses the destination IPv4 address of every input packet as index to look up this table to get a hop selector as the result. The ECMP flag is for the LFB to support ECMP.  
The default route flag is for the LFB to support a default route and for RPF. As described in the data handling section of the LFB, when a packet passes through table look up with these flags set, it will output via "ECMPOut" port. 
 
The IPv4UcastLPMStats component is a struct component which collects statistics information, including the total number of input packets received, the IPv4 packets forwarded by this LFB and the number of IP datagrams discarded due to no route found. 
 
1.1.1.3. Capabilities
 
This LFB does not have a list of capabilities. 
   
1.1.1.4. Events
   
This LFB does not have any events specified.
----------

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 6 Jun 2011 16:07:11 +0800

Hi all,

update of IPv6UcastLPM description based on Evangelos's version.

thanks,
Weiming

------------- 
1.1.1. IPv6UcastLPM
 
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match (LPM) process. The definition of this LFB is similar to the IPv4UcastLPM LFB except that all IP addresses refer to IPv6 addresses.

1.1.1.1. Data Handling
 
This LFB performs the IPv6 unicast LPM table looking up. 
It always expects as input IPv6 unicast packets from one singleton input known as "PktsIn". Then the LFB uses the destination IPv6 address of every packet as index to look up the IPv6 prefix table and generate a hop selector as the matching result. This result will associate to the packet as a metadatum to output to downstream LFBs, and will usually be used there as an index to find more next hop information. 

The first singleton output known as "NormalOut", which will output IPv6 unicast packets that has passed the LPM lookup and got a hop selector as the lookup result. The hop selector is associated with the packet as a metadatum. Followed the normal output of the LPM LFB  is usually a next hop application LFB, like an IPv6NextHop LFB.  

 
A default route flag is defined in the LPM table to enable the LFB to support a default route, and RPF also. When set true, the table entry is identified a default route and as a forbidden route for RPF also. In this case, a packet which has passed through this prefix lookup will also output via "ECMPOut" to a downstream specific RPF LFB. (Editorial note: how will the output be followed if we require both ECMP and RPF LFBs?)

1.1.1.2. Components

The IPv6PrefixTable component is defined as an array component of the LFB. Each row of the array contains an IPv6 adrress, a Prefix length, a Hop Selector, an ECMP flag and a Default Route flag. The LFB uses the destination IPv6 address of every input packet as index to look up this table to get a hop selector as the result. The ECMP flag is for the LFB to support ECMP.  
The default route flag is for the LFB to support a default route and for RPF. As described in the data handling section of the LFB, when a packet passes through table look up with these flags set, it will output via "ECMPOut" port. 
 
The IPv6UcastLPMStats component is a struct component which collects statistics information, including the total number of input packets received, the IPv6 packets forwarded by this LFB and the number of IP datagrams discarded due to no route found. 
 
1.1.1.3. Capabilities

1.1.1.4. Events
   
-----------

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 6 Jun 2011 20:47:57 +0800

Comment on the Editorial note:
This is a question we haddn't considered in previous discussion.
If LPM LFB supports RPF function, then we need define a seperate RPF 
packets input port and an RPF output port. But LPM itself does not provide 
ECMP or RPF function in our current definition. If FE need to support RPF, 
RPF LFB will be added before LPM. So, i think we needn't to say in the text: 
"default route flag is defined for loose RPF. "

Yours,
Chuanhuang

======= 2011-06-06 15:52:59 Wang,Weiming, wrote: =======

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 23 Jun 2011 23:40:43 +0300

Greetings to all,

Here is the readability suggestion for the EtherEncapsulator.

It is based on Chuanhuang's version. I made some changes and also tried to
maintain consistency with the other sections.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 23 Jun 2011 23:41:34 +0300

Greetings to all,

Here is the readability suggestion for the IPv4NextHop.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 23 Jun 2011 23:42:53 +0300

Greetings to all,

Here is the readability suggestion for the IPv6NextHop.

It is a copy from the IPv4 section, with IPv4 changed to IPv6 and also
removed the text regarding TTL altering.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 28 Jun 2011 21:59:24 +0300

Greetings to all,

Here is the readability suggestion for the RedirectIn.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 28 Jun 2011 21:59:49 +0300

Greetings to all,

Here is the readability suggestion for the RedirectOut.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 28 Jun 2011 22:01:28 +0300

Greetings to all,

Here is the readability suggestion for the BasicMetadataDispatch.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 28 Jun 2011 22:00:18 +0300

Greetings to all,

Here is the readability suggestion for the GenericScheduler.

Regards,
Evangelos Haleplidis.