Subject: [forces] Update for NH definition

From: "Chuanhuang Li" <[email-masked]>
Date: Sun, 1 May 2011 21:57:30 +0800

Hi, all
    The following is the definition update for NH according Jamal's suggestion text 
and previous discussion. The main changes are listed in the "update record" part.
According the discussion, the directly connected hosts problem should leave out of the model,
so the "NextHopOption" element defined in NH table was removed.

two comments: 
1:Since "L3PortID" metadata will be used to dispatch packet to different encapsulator, then can 
we change group output to single output? In this case, A BasicMetadataDispatch must connect after 
NH. The RedirectOut LFB will be regarded as a special Encapsulator, and be assigned a special L3PortID to it.  
2:If a BasicMetadataDispatch connects after NH, is MediaEncapInfoIndex also valid?  

****
IPv4NextHop LFB Definition:

update record:
1) 12-27,2010 
   Deleted the capability: MaxOutPutPorts (email discussion subject: Port group number,12-22,2010)
2) 05-01,2011 
   (email discussion subject: Re: NH review WAS(Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue)
   Renaming OutputLogicalPortID to L3PortID for readability.
   Renaming EncapOutputIndex to LFBOutputSelectIndex.
   Add "MediaEncapInfoIndex" in IPv4NextHopTable.
   Remove "NextHopOption" from IPv4NextHopTable.
   Add "MediaEncapInfoIndex" as the output metadata.
   Modified synoposis and simple description.

Name: IPv4NextHop 
Synopsis：The LFB abstracts the process of next hop nformation application to IPv4 packets. It receives 
an IPv4 packet with an associated next hop ID, and uses the ID as the nextHop table index to look up a next 
hop to find some appropriate output information from the LFB. These information contains: L3PortID,NextHopIPAddress, 
MTU, MediaEncapInfoIndex. 

description:
Incoming "HopSelector" metadata is used as an index to lookup the table. Data processing involves the forwarding TTL 
decrement and checksum recalculation. On successful data processing the packet is sent out an LFB-port from within 
the LFB port group "SuccessOut" as selected by LFBOutputSelectIndex value of the matched table entry. 
The packet is sent to a downstream LFB instance alongside with new metadata: L3PortID, MediaEncapInfoIndex, 
NextHopIPAddress.

If there is more than one media Encapsulator, a BasicMetadataDispatch may connect after IPv4NextHop. BasicMetadataDispatch 
use L3PortID to dispatch to different Encapsulator. 

If there is some definite encapsulator, user also can use the Port group to distribute. 

Execption packet will go out from the ExceptionOut port. There are some execptions will be generated. such as, 
The NexthopID is invalid; The MTU for outgoing interface is less than the packet size; ICMP packet needs to be 
generated.

Possible relationship with other LFBs:

                               +--------+      +-----------------+ 
                               |        |----->|  RedirectOut    |----->
      +-----+                  |        |      +-----------------+
      |     |--------------+   |        |  
  --->| LPM |    +-----+   |-->|NextHop |      +-----------------+
      |     |--->| ECMP|---+   |        |----->|EtherEncapsulator|----->
      +-----+    +-----+       |        |      +-----------------+
                               +--------+

                               +--------+      +-----------------+ 
                               |        |----->|  RedirectOut    |----->
      +-----+                  |        |      +-----------------+
      |     |--------------+   |        |      +---+
  --->| LPM |    +-----+   |-->|NextHop |      |   |-----> 
      |     |--->| ECMP|---+   |        |----->|   | 
      +-----+    +-----+       |        |      |   |
                               +--------+      |   |----->
                                               +---+
                                         BasicMetadataDispatch
----

Inputs：
PktsIn, single input
frameExpected: IPv4Unicast  
metadataExpected: HopSelector /*Nexthop index ID.*/

Outputs:
SuccessOut, group output
frameProduced: IPv4Unicast
metadataProduced: L3PortID, NexthopIPv4Addr, MediaEncapInfoIndex(availability="conditional")

ExceptionOut, single output
frameProduced: IPv4Unicast
metadataProduced: ExceptionID    
/*ExceptionID Type. these will be mergered with the defition of ExceptionID in other LFBs. 
    7 - The HopSelector is invalid.
    8 - The MTU for outgoing interface is less than the packet size. (The packet need be fragmented.)  
    9 - ICMP packet needs to be generated. 
*/

----
----
Components:
(default access property is read-write)

name: IPv4NextHopTable
type: IPv4NextHopTableType
array of:
{
  L3PortID, /*The Logical Output Port ID. The ID indicates what port to the neighbor is as defined by L3.*/
  MTU,    /*Maximum Transmission Unit for out going port.It is for desciding whether the packet need fragmentation.*/
  NexthopIPAddr, /*Next hop IPv4 address.*/
  LFBOutputSelectIndex, /*indicate which LFB port we are selecting to go to the downstream LFB instance.*/
  MediaEncapInfoIndex /*the index for media encap table in Media encap LFB.*/  
}

----
----
Capabilities: 
none

----
----
Events:
none
----
----

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 2 May 2011 00:08:40 +0800

Hi, all
   The following is the update of definition outline for EtherEncapsulation. According previous discussion, the changes 
are more. Only simple LFB description is posted, and  more description will be appeared in the text. 

One comment:
L2 bridging will appear before EtherEncap. EtherMACOut will be connected after EtherEncap 
and it expects "PHYPortID" metadata. So I think "L2PortID" defined in EncapTable can be modified 
to "PHYPotID" directly, and output metadata is also PHYPortID(not L2PortID). what's your opinion?

****
EtherEncapsulator LFB Definition:

update record:
1) 05-01, 2011. More contents were changed. (email discussion subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re:LFB LPM issue)
   Removed two output ports: PakcetNoARPOut, PakcetNoNbrOut
   Removed ARP/ND table.
   Added EncapTable.
   Merged VlanOutTable into EncapTable.
   Modified the input and output metadatas.
   Modified synoposis and simple description.

Name: EtherEncapsulator
Synopsis：An LFB that performs packets ethernet L2 encapsulation.   
Packet uses the input metadata "MediaEncapInfoIndex" as the index to search the EncapTable. It will get DstMac, SrcMac, VlanID and L2PortID information. 
Packet which can't find the encapsulation information(MediaEncapInfoIndex is assigned, but invalid) will go out from ExceptionOut. 

simple Description:
Packets alongside metadata are received on this LFB via the "EncapIn" input LFB. The upstream LFB classes maybe the different NextHop LFBs such as 
IPv4NextHop and IPv6NextHop or maybe BasicMetadataDispatch or even L2 bridging (which is out of scope in this document).
If the Input metadata VlanPriority is non-zero, the packet will have a VLAN tag, whatever the value of VlanID is(zero or non-zero). If VlanPriority and the 
VlanID are all zero, there is no VLAN tag to this packet.                                      

----
Inputs：
EncapIn, single input
frameExpected: IPv4, IPv6 
metadataExpected: MediaEncapInfoIndex, VlanPriority (optional, defaultValue:0) 
 
Outputs:
SuccessOut, single output
frameProduced: EthernetII
metadataProduced: L2PortID 

ExceptionOut, single output
frameProduced: IPv4, IPv6
metadataProduced: ExceptionID, MediaEncapInfoIndex, VlanPriority (availability="conditional") 
/*ExceptionID Type. these can be mergered with the defition of ExceptionID in IPv4Validator. 
    10 - packet can't find encapsulation information.
*/

----
----
Components:

name: EncapTable
type: EncapTableType
ArpTableType:
array of:
{
  DstMac, 
  SrcMac,
  VlanID,
  L2PortID
}
 
----
----
Capabilities: 
none 
----
----
Events:
none
----
******

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 1 May 2011 13:16:44 -0400

Hi Chuanhuang,

I am hoping the authors will resolve these discussions;
(I didnt respond to the last posting from Evangelos or your next one).

Please follow the format such as the one posted by Evangelos,
what you are posting is too formal. It is useful to make the posting
the same way as it would show up in the draft.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 3 May 2011 21:34:53 +0800

Jamal, 
The outline is only an assistent file conducting to write XML definitions in the draft and also the description text as you said . We have always been using the file to work.  I don't think this contradicts our current work.

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: Update for NH definition

Hi Chuanhuang,

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Thu, 5 May 2011 21:47:43 +0800

Hi, Evangelos
     About the PHYPortID component, i think the description in the text can be 
modefied like this:

   The PHYPortID component is an unique identification for physical port. 
   It is defined as "read-only". Its value is enumerated by FE. The component 
   will be used to produce metadata to associate every Ethernet packet this 
   LFB receives from the media and is going to hand to later LFBs for further 
   processing.

Yours,
Chuanhuang

======= 2011-04-27 04:58:08 Haleplidis Evangelos, wrote: =======

>Greetings to all,
>
>After Jamal's suggestion I took his initiative and completed the etherphycop
>definition.
>
>Please take a look and comment, in the meantime I'll start working on the
>EtherMacIn.
>
>About Jamal's comments:
>
>XXX: It may make sense to have each of Components, Capabilities and Events
>on its own section?
>
>I think it is more readable this way and also following the same format as
>the model RFC provides consistency.
>
>XXX: I copied this from the draft but i think it may be wrong. The xml says
>this component is read-only. And i remember we had a very long discussion
>(refer to how one would map a port name to the PHY on how this ID is to be
>used).
>
>Well, even the text says that: " is defined so the CE can assign an ID ".
>Since the CE can assign the ID then it must be read-write. I think we should
>change it in the XML.
>
>XXX: Should we be discussing all the components, capabilities and events?
>i.e why the brief description below? Either that or the XML synopsis needs
>to be a lot more descriptive.
>
>I think we should be discussing ALL components/capabilities/events.
>It's more readable this way. Someone not familiar with xml may want to read
>and understand in this way of reading instead of looking around in the xml.
>
>Also there is a typo in the xml definition of the EtherPhyCop. In the
>synopsis of the DuplexModeChanged there is a "speed." in the end that is not
>supposed to be there.
>
>Regards,
>Evangelos Haleplidis.
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Jamal Hadi Salim
>> Sent: Tuesday, April 26, 2011 2:01 PM
>> To: [email-masked]
>> Cc: Chuanhuang Li; wmwang; Joel M. Halpern
>> Subject: [forces] LFBlib readability suggestions
>> 
>> to the authors,
>> 
>> As i have whined before, the general draft text is hard to read.
>> I think making things a little more formal as in the example LFB in RFC
>> 5812 section 8 will go a long way to improve readability.
>> 
>> I have attempted to redo the EtherPHYCop section, I didnt go 100% with
>> the RFC5812 format but please take a look in particular the "XXX"
>> and cross reference with:
>> - the text that exists right now in the draft
>> - the xml (and also to make sure it is well described)
>> - the formal scheme to describe things as i laid it out. The model
>> draft LFB example in section 8 is a good start.
>> 
>> cheers,
>> jamal
>

---

From: "Chuanhuang Li" <[email-masked]>
Date: Thu, 5 May 2011 22:09:31 +0800

Hi,Haleplidis

    I think we need remove some words like "editorial note..." in our final text :
In this LFB:
(Editorial note: 
   need more discussions here on if the L2 output is the same as normal output).

According the discussion,  L2BridgingPathOut will output the same packet that 
as in the NormalPathOut output.  (Discussion email, time: 10-28,2010, 
subject:Re: Definition of EtherMACIn LFB)

Yours,
Chuanhuang	

======= 2011-05-01 06:28:24 Haleplidis Evangelos, wrote: =======

>Greetings to all,
>
>Here is the readability suggestion for the EtherMacIn.
>
>I hope I have more within the week.
>
>Regards,
>Evangelos Haleplidis.
>

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Mon, 9 May 2011 17:35:34 +0300

Greetings to all,

Here is the readability suggestion for the EtherClassifier.

Regards,
Evangelos Haleplidis.

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 12 May 2011 11:03:12 +0800

Hi all, 

I have tried to modify the description on the EtherPHYCop LFB as attachment based on Chuanhuang's suggestion. 

If you all have no objections, I'l incorparate the description just as the attachement file into the next version draft.

thanks,
Weiming

----- Original Message ----- 
From: "Chuanhuang Li" <[email-masked]>

> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 19 May 2011 20:13:17 +0300

Greetings to all,

Here is the readability suggestion for the EtherMacOut.

Regards,
Evangelos Haleplidis.

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 20 May 2011 09:49:28 +0800

Hi, Evangelos

Some comments about EtherMacOut text:
1: "The LFB is expected to receive all types of Ethernet packets, via a 
	singleton input known as "EtherPktsIn" (Editorial note: do we need
	another input for L2 bridging	input?), "
The editorial note can be removed. We needn't define another input port.
According RFC5812, there are three ways to model fan-in. The one is 
"Implicit multiplexing via a single input" .  If  the packets from the upstream 
LFBs are similar in frametype and accompanying metadata, and require similar 
processing, we can use this simplest way.  

2: "(Editorial note:
	Ethernet encapsulation LFB actually generate logical port ID metadata, 
	how has it been changed to physical port ID?). "
Now, the encapsulation LFB will generate L2PortID metadata, according the discussion with Jamal and Joel.

This is also my question, Please see email: "Update for EtherEncapsulator definition",05-01-2001.
I repost the question as follows:
"L2 bridging will appear before EtherEncap. EtherMACOut will be connected after EtherEncap 
and it expects "PHYPortID" metadata. So I think "L2PortID" defined in EncapTable can be modified 
to "PHYPotID" directly, and output metadata is also PHYPortID(not L2PortID). what's your opinion?"

Yours,
Chuanhuang

======= 2011-05-20 01:04:04 Haleplidis Evangelos, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 23 May 2011 21:18:24 +0800

Hi Evangelos and all,

Followed is the EtherMACIn LFB description that I have modified based on Evangelos' version and am going to put in draft. The key modification is removal of the editorial note and correction of some typoes.  

thanks,
Weiming

-----------
1.1.1. EtherMACIn
 
EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. This LFB describes Ethernet processing functions like MAC address locality check, deciding if the Ethernet packets should be bridged, providing Ethernet layer flow control, etc.
 
1.1.1.1.Data Handling
   
The LFB is expected to receive all types of Ethernet packets, via a singleton input known as "EtherMACIn", which are usually output from some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside with a metadatum indicating the physical port ID that the packet comes.
   
The LFB is defined with two separate singleton outputs.  All Output packets are in Ethernet format, as received from the physical layer LFB and cover all types of Ethernet packets.
   
The first singleton output is known as "NormalPathOut". It usually outputs   Ethernet packets to some LFB like an EtherClassifier LFB for further L3   forwarding process alongside with a PHYPortID metadata indicating which   physical port the packet came from.
 
The second singleton output is known as "L2BridgingPathOut". Although the LFB library this document defines is basically to meet typical router functions, it will attempt to be forward compatible with future router functions. The "L2BridgingPathOut" is defined to meet the requirement that L2 bridging functions may be optionally supported simultaneously with L3 processing and some L2 bridging LFBs that may be defined in the future. If the FE supports L2 bridging, the CE can enable or disable it by means of a "L2BridgingPathEnable" component in the FE. If it is enabled, by also instantiating some L2 bridging LFB instances following the L2BridgingPathOut, FEs are expected to fulfill L2 bridging functions. L2BridgingPathOut will output packets exactly the same as that in the NormalPathOut output.
 
This LFB can be set to work in a Promiscuous Mode, allowing all packets   to pass through the LFB without being dropped. Otherwise, a locality check will be performed based on the local MAC addresses. All packets that do not pass through the locality check will be dropped.
   
This LFB can perform Ethernet layer flow control. This is usually implemented cooperatively by the EtherMACIn LFB and the EtherMACOut LFB.   The flow control is further distinguished by Tx flow control and Rx flow   control, separately for sending process and receiving process flow   controls. 
   
1.1.1.2. Components
        
The AdminStatus component is defined for CE to administratively manage    the status of the LFB. The CE may administratively startup or shutdown    the LFB by changing the value of AdminStatus. The default value is set to 'Down'.
 
The LocalMACAddresses component specifies the local MAC addresses based    on which locality checks will be made. This component is an array of MAC   addresses, and of 'read-write' access permission.
   
An L2BridgingPathEnable component captures whether the LFB is set to work as a L2 bridge. An FE that does not support bridging will internally set this flag to false, and additionally set the flag property as read-only. The default value for is 'false'.
   
The PromiscuousMode component specifies whether the LFB is set to work as in a promiscuous mode. The default value for is 'false'.
   
The TxFlowControl component defines whether the LFB is performing flow control on sending packets. The default value for is 'false'.
 
The RxFlowControl component defines whether the LFB is performing flow contron on receiving packets. The default value for is 'false'.   
   
A struct component, MACInStats, defines a set of statistics for this LFB, including the number of received packets and the number of dropped packets. 
   
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: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 27 May 2011 17:13:40 +0300

Greetings to all,

Here is the readability suggestion for the IPv4Validator.

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 27 May 2011 17:14:12 +0300

Greetings to all,

Here is the readability suggestion for the IPv6Validator.

Regards,
Evangelos Haleplidis.

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 27 May 2011 23:01:02 +0800

Hi all,

Followed is the update of the description on EtherMACOut LFB based on Evangelos' readability version. Key modifying is on some alias components. Pls check reveiw it. 

Note that the issue on the input metadatum "PHYPortID" is still under discussion.

thanks,
Weiming

-----------
1.1.1. EtherMACOut 
 
EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. This LFB describes Ethernet packet output process. Ethernet output functions are closely related to Ethernet input functions, therefore many components defined in this LFB are as aliases of EtherMACIn LFB components.
 
1.1.1.1. Data Handling
 
The LFB is expected to receive all types of Ethernet packets, via a singleton input known as "EtherPktsIn", which are usually output from an Ethernet encapsulation LFB, alongside with a metadatum indicating the physical port ID that the packet will go through. 
  
The LFB is defined with a singleton output. All Output packets are in Ethernet format, possibly with various Ethernet types, alongside with a metadatum indicating the physical port ID the packet is to go through. This output links to a downstream LFB that is usually an Ethernet physical LFB like EtherPHYcop LFB. 
 
This LFB can perform Ethernet layer flow control. This is usually implemented cooperatively by the EtherMACIn LFB and the EtherMACOut LFB.   The flow control is further distinguished by Tx flow control and Rx flow   control, separately for sending process and receiving process flow control. 
 
Note that as a base definition, functions like multiple virtual MAC layers are not supported in this LFB version. It may be supported in the future by defining a subclass or a new version of this LFB.
   
1.1.1.2. Components
        
The AdminStatus component is defined for CE to administratively manage the status of the LFB. The CE may administratively startup or shutdown the LFB by changing the value of AdminStatus. The default value is set to 'Down'. Note that this component is defined as an alias of the AdminStatus component in the EtherMACIn LFB. This infers that an EtherMACOut LFB usually coexists with an EtherMACIn LFB, both of which share the same administrative status management to CE. Alias properties as defined in the ForCES FE model (RFC 5812) are used to declare the alias target.
 
The MTU component defines the maximum transmission unit.
        
The TxFlowControl component defines whether the LFB is performing flow control on sending packets. The default value for is 'false'. Note that this component is defined as an alias of TxFlowControl component in the EtherMACIn LFB.
 
The RxFlowControl component defines whether the LFB is performing flow   control on receiving packets. The default value for is 'false'. Note that this component is defined as an alias of RxFlowControl component in the EtherMACIn LFB.  
   
A struct component, MACOutStats, defines a set of statistics for this LFB, including the number of transmitted packets and the number of dropped packets. 
   
1.1.1.3. Capabilities

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

---

From: "Chuanhuang Li" <[email-masked]>
Date: Tue, 31 May 2011 16:25:32 +0800

Hi, Evangelos

	One comments on ValidatorID's description text:
This metadata's definition is lost in XML file.  I will modify it right now. 
According the previous discussion email, the definition will be as follows:
/*ValidateErrorID Type 
   0 - other
   1 - Packet size reported is less than 20 bytes
   2 - Packet with version!= 4 
   3 - Packet with header length < 5
   4 - Packet with total length field < 20 
   5 - Packet with invalid checksum
   6 - Packet with source address equal to 255.255.255.255 
   7 - Packet with source address 0 
   8 - Packet with source address of form {127, <any>} 
   9 - Packet with source address in Class E domain 
*/

 Yours,
Chuanhuang

======= 2011-05-27 22:11:09 Haleplidis Evangelos, wrote: =======

---

From: "Chuanhuang Li" <[email-masked]>
Date: Tue, 31 May 2011 16:29:32 +0800

Hi, Evangelos

	The same as IPv4Validator, one comment on ValidateErrorID:
the value should be:
/*ValidateErrorID Type 
   0 - other
   1 - Packet size reported is less than 40 bytes.
   2 - Packet with version != 6 
   3 - Packet with multicast source address (the MSB of the source address is 0xFF) 
   4 - Packet with destination set to 0 or ::1
   5 - Packet with source address set to loopback (::1)
*/

And I think we need specify in the text: this ValidateErrorID is merged with that in the IPv4Validator.*/

Yours,
Chuanhuang

======= 2011-05-27 22:04:46 Haleplidis Evangelos, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 1 Jun 2011 10:02:21 +0800

Hi all, 

Below is the latest update of the EtherMACOut LFB description. 

Note that the input physical port ID metadata  is still under disussion, so an editorial note just leaves there.

thanks,
Weiming

-------------- 
1.1.1. EtherMACOut 

1.1.1.1. Data Handling
 
The LFB is expected to receive all types of Ethernet packets, via a singleton input known as "EtherPktsIn", which are usually output from an Ethernet encapsulation LFB, alongside with a metadatum indicating the physical port ID that the packet will go through(editorial note: need more discussion on the port ID being physical layer or L2 layer). 

 
   
1.1.1.2. Components
        
The AdminStatus component is defined for CE to administratively manage the status of the LFB. The CE may administratively startup or shutdown the LFB by changing the value of AdminStatus. The default value is set to 'Down'. Note that this component is defined as an alias of the AdminStatus component in the EtherMACIn LFB. This infers that an EtherMACOut LFB usually coexists with an EtherMACIn LFB, both of which share the same administrative status management by CE. Alias properties as defined in the ForCES FE model (RFC 5812) will be used by CE to declare the target component this alias refers, which include the target LFB class and instance IDs as well as the path to the target component. Whereas, these properties are set by CE only when a system runs, which are outside the XML definitions of this LFB.

 

1.1.1.3. Capabilities

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 1 Jun 2011 11:39:42 +0800

Hi all, 

Below is the latest  update for the LFB description. Pls review and comment. 

thanks,
Weiming\

----------- 
1.1.1. IPv4Validator
 
The IPv4Validator LFB performs IPv4 packets validation according to RFC 1812. 
 
1.1.1.1. Data Handling
 
This LFB performs IPv4 validation according to RFC 1812. Then the IPv4 packet will be output to the corresponding port regarding of the validation result, whether the packet is a unicast or a multicast one, an exception has occurred or the validation failed.
 
This LFB always expects, as input, packets which have been indicated as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There is no specific metadata expected by the input of the LFB. 
 
Note that, as a default provision of RFC 5812, in FE model, all metadata produced by upstream LFBs will pass through all downstream LFBs by default without being specified by input port or output port. Only those metadata that will be used(consumed) by an LFB will be explicitly marked in input of the LFB as expected metadata. For instance, in this LFB, even there is no specific metadata expected, metadata like PHYPortID produced by some upstream physical layer LFBs will always pass through this LFB. In some cases, if some component in the LFB may use the metadata, it actually still can use it   regardless of whether the metadata has been expected or not.
 
Four output ports are defined to output various validation results. 
 
All validated IPv4 unicast packets will be output at the singleton port known as "IPv4UnicastOut". All validated IPv4 multicast packets will be output at the singleton port known as "IPv4MulticastOut" port. There is no metadata specifically required to produce at these output ports. 
 
A singleton port known as "ExceptionOut" is defined to output packets which have been validated as exception packets. An exception ID metadatum is produced to indicate what has caused the exception. Currently defined exception types include:
 
o Packet with destination address equal to 255.255.255.255
o Packet with expired TTL
o Packet with header length more than 5 words
o Packet IP head including Router Alert options
 
Note that, although TTL is checked in this LFB for validity, operations to TTL like TTL decreasing will be made only in a followed forwarding LFB.
 
The final singleton port known as "FailOut" is defined for all packets which have failed the validation process. A validate error ID is associated to every failed packet to indicate the reason. Currently defined reasons include:
 
   . Packet size reported is less than 20 bytes
   . Packet with version is not IPv4 
   . Packet with header length < 5
   . Packet with total length field < 20 
   . Packet with invalid checksum
   . Packet with source address equal to 255.255.255.255 
   . Packet with source address 0 
   . Packet with source address of form {127, <any>} 
   . Packet with source address in Class E domain.

1.1.1.2. Components
 
This LFB has only one struct component, the IPv4ValidatorStatisticsType,   which defines a set of statistics for validation process, including the number of bad header packets, the number of bad total length packets, the number of bad TTL packets, and the number of bad checksum packets.
 
1.1.1.3. Capabilities

1.1.1.4. Events

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 1 Jun 2011 11:41:29 +0800

Hi  all,

Below is the latest update for this LFB description. Pls comment. 

thanks,
Weiming 
 
---------
1.1.1. IPv6Validator
 
The IPv6Validator LFB performs IPv6 packets validation according to RFC 2460. 
 
1.1.1.1. Data Handling
 
This LFB performs IPv6 validation according to RFC 2460. Then the IPv6 packet will be output to the corresponding port regarding of the validation result, whether the packet is a unicast or a multicast one, an exception has occurred or the validation failed.
 
This LFB always expects, as input, packets which have been indicated as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. There is no specific metadata expected by the input of the LFB. 
 
Similar to the IPv4validator LFB, IPv6Validator has also defined four output ports to output packets for various validation results. 
 
All validated IPv6 unicast packets will be output at the singleton port known as "IPv6UnicastOut". All validated IPv6 multicast packets will be output at the singleton port known as "IPv6MulticastOut" port. There is no metadata specifically required to produce at these output ports. 
 
A singleton port known as "ExceptionOut" is defined to output packets which have been validated as exception packets. An exception ID metadata is produced to indicate what caused the exception. Currently defined exception types include:
 
   o Packet with hop limit to zero
   o Packet with a link-local destination address
   o Packet with a link-local source address
   o Packet with destination all-routers
   o Packet with destination all-nodes
   o Packet with next header set to Hop-by-Hop

  . Packet size reported is less than 40 bytes
  . Packet with version is not IPv6 
  . Packet with multicast source address (the MSB of the source address is 0xFF) 
  . Packet with destination address set to 0 or ::1
  . Packet with source address set to loopback (::1).
 
Note that in the base type library, definitions for exception ID and validate error ID metadata are applied to both IPv4Validator and IPv6Validator LFBs, i.e., the two LFBs share the same medadata definition, with different ID assignment inside. 
 
1.1.1.2. Components
 
This LFB has only one struct component, the IPv6ValidatorStatisticsType,   which defines a set of statistics for validation process, including the number of bad header packets, the number of bad total length packets, and the number of bad hop limit packets.
 
1.1.1.3. Capabilities

1.1.1.4. Events

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