Subject: [forces] I-D Action:draft-ietf-forces-lfb-lib-03.txt

From: [email-masked]
Date: Wed, 01 Dec 2010 17:30:23 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF.

	Title           : ForCES Logical Function Block (LFB) Library
	Author(s)       : W. Wang, et al.
	Filename        : draft-ietf-forces-lfb-lib-03.txt
	Pages           : 90
	Date            : 2010-12-01

This document defines basic classes of Logical Function Blocks (LFBs)
used in the Forwarding and Control Element Separation (ForCES).  It
is defined according to ForCES FE model [RFC5812] and ForCES protocol
[RFC5810] specifications.  These basic LFB classes are scoped to meet
requirements of typical router functions and considered as the basic
LFB library for ForCES.  Descriptions of individual LFBs are
presented and detailed XML definitions are included in the library.
Several use cases of the defined LFB classes are also proposed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-lfb-lib-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 2 Dec 2010 09:38:28 +0800

Greetings to the list.

As indicated,  the 03 version of the lfb lib draft is updated. Key changes include:
. incorparate Jamal's proposals on the introduction section, including the scope of the library, the groupings and the sample case. 
. incorparate Jamal's text on the week host model.
. change the description text and xml file on the EtherPHYCop and EtherMACIn/Out LFBs regarding the issue of adminstatus and operastatus.
. removed the incorrect reference of RFCs in IPv4validator and IPv6validator description text.

Comments are definitely welcomed. 

thanks a lot.
Weiming

P.S., Jamal, could you help to forward this message to the list if my account still does not work? thanks.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 02, 2010 9:30 AM
Subject: [forces] I-D Action:draft-ietf-forces-lfb-lib-03.txt

> implementation to automatically retrieve the ASCII version of the

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

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 15 Dec 2010 09:46:56 -0500

Message from Weiming.

cheers,
jamal

---------- Forwarded message ----------
From: Wang,Weiming <[email-masked]>
Date: Wed, Dec 15, 2010 at 1:21 AM
Subject: Re: [forces] I-D Action:draft-ietf-forces-lfb-lib-03.txt
To: "Wang,Weiming" <[email-masked]>, Jamal Hadi Salim
<[email-masked]>, [email-masked]

Seasons Greetings to the list.

We have made some progress since last version, but we hesitate to
release a new version considering reader's consistency. So, we'd like
to post some changes to the list first for comments.

Below is the modified NextHop LFB text, whichincorparated dissusions
among authors on 'local flag' issue.  Because there are quite amount
of text change, I have not used  errata ( of v03) mode to post the
text, rather a whole section substitution. It is recommened to read
the whole section to know the changes.

thanks,
Weiming

--------
 5.2.3. IPv4NextHop

This LFB abstracts the process of next hop information application to
IPv4 packets.

The LFB receives an IPv4 packet with an associated next hop ID, and
uses the ID to look up a next hop table to find an appropriate output
port from the LFB. Simultaneously, the LFB also implements TTL
operation and checksum recalculation of every IPv4 packet received.

Input of the LFB is a singleton one which expects to receive IPv4
unicast packets and hop selector metadata from an upstream LFB.
Usually, the upstream LFB is directly an IPv4UnicastLPM LFB,while it
is possible some other upstream LFB may be applied. For instance, when
ECMP is supported, the upstream LFB may be some specific ECMP LFB.

The next hop ID in hop selector metadata of a packet is then used as
an index to look up a next hop table defined in the LFB. Via this
table and the next hop index, important information for forwarding the
packet is found. Every next hop table entry includes the following
information:
. output logical port ID, which will be used by downstream LFBs to
find proper output port.
. next hop option, which decides if packets with next hop of this
table entry are destinated to locally attached hosts or not.  Locally
attached hosts are hosts in the same subnet with this router. Next hop
option is marked as 'forwarded to locally attached host' if the next
hop entry is for locally attached hosts delivery. All other next hop
entry will be marked with 'normal forwarding'. If a data packet passes
through next hop entries with its next hop option marked with
forwarded to locally attached host, the next hop IP address metadata
associated with the data packet when output from the LFB will be
forced to set to the destination IP address of the data packet. If a
data packet passes through a next hop entry with its option being
normal forwarding, the next hop IP address metadata at output will be
set to the next hop IP address as indicated by this next hop entry.
Advantage to define this next hop option for locally attached hosts
is, in this way, the next hop entry number may be greatly reduced in
the case there are a vast number of locally attached hosts.
. next hop IP address, which will be used by downstream LFB to find
proper output port IP address for this packet. Note that when next hop
option is set to 'forwarded to locally attached host', this entry
field becomes invalid. In this case the next hop IP address is
assigned directly by destination IP address of the data packet pass
through this entry check.
. encapsulation output index, which is used by data packet to find
proper output of this LFB. Usually, this index can be used to indicate
which encapsulation followed the LFB may be applied to data packets
pass through this next hop entry check and to classify the packets to
different instance of a group output port. Moreover, this index can
also be used to purely indicate output port instance to act as a
classifier based on next hop IDs. For instance, a next hop table entry
can be defined with its encapsulation output index being directed to
an output port which is followed with LFBs that will redirect data
packets to Control Element(CE). A next hop entry can also be defined
for some data packets that need special local processing of the
Forwarding Element(FE). In this case it is not really acting as an
encapsulation index, rather a pure output index.

As a result, the LFB are defined with two output ports. One is for
success output and another is for exception output. Success output is
a group output, with an index to indicate which output instance in the
group is adopted.  The index is  exactly the encapsulation output
index described above. Downstream LFBs connected to the success output
group may be various LFBs for encapsulation like LFBs for Ethernet
encapsulation and for PPP encapsulation, various LFBs for local
processing, and LFBs for redirecting packets to CE for processing.
Next hop table uses the encapsulation output index to indicate which
port instance in the output group a packet should go.

Every port instance of the success output group will produce metadata
of output logical port ID and next hop IP address for every output
packet. These metadata will be used by downstream LFBs to further
implementing forwarding or local processing. Note that for next hop
option marked as local host processing, the next hop IP address
metadata for the packet is exactly substituted with the destination IP
address of the packet.

The exception output of the LFB is a singleton output. It outputs
packets with exceptional cases. An exception ID further indicates the
exception reasons. Exception may happen when a hop selector is found
invalid, or ICMP packets need to be generated (Editorial note: more
discussions here), etc. The exception ID is also produced as a
metadata by the output to be transmitted to a downstream LFB.

There are also some other components defined in the LFB for various
purposes. See section 6 for detailed XML definitions of the LFB.
-----------

----- Original Message -----
From: "Wang,Weiming" <[email-masked]>

> P.S., Jamal, could you help to forward this message to the list if my account still does not work? thanks.
 >