Subject: [forces] comments #18

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 21 Aug 2011 10:34:20 -0400

Another long one - similar in spirit to earlier one

-----
56) Section 7.2

Figure 2 shows the processing path for ARP protocol in the case the
CE implements the ARP processing function. By no means is this
the only way ARP processing could be achieved; as an example
ARP processing could happen at the FE - but that discussion is out
of scope for this use case.

There are two ways ARP processing could be triggered in the CE
as illustrated in figure 2:

o ARP packets arriving from outside of the NE
o IPV4 packets failing to resolve within the FE

ARP packets from network interfaces are filtered out by EtherClassifier
LFB. The classified ARP packets and associated metadata are then sent
downstream to the RedirectOut LFB(section XXX) to be transported to CE.

The EtherEncap LFB, as described earlier, receives packets that
need Ethernet L2 encapsulating. When the EtherEncap LFB fails
to find the necessary L2 Ethernet information to encapsulate
the packet with, it outputs the packet to its ExceptionOut
LFB port. Downstream to EtherEncap LFB's ExceptionOut LFB port is
the RedirectOut LFB which transports the packet to the CE (see
Section XXX for details).

To achieve its goal, the CE needs to generate ARP request and
response packets and send them to external (to the NE) networks.
ARP request and response packets from the CE are redirected to an
FE via a RedirectIn LFB(section XXX).

As was the case with forwarded IPv4 packets, outgoing ARP packets are also
encapsulated to Ethernet format by the EtherEncap LFB, and then
dispatched to different interfaces via a BasicMetadataDispatch LFB.
The BasicMetadataDispatch LFB dispatches the packets according to
the L3PortID metadatum included in every ARP packet sent from CE.
----

cheers,
jamal