One document matched: draft-blake-forces-attrib-00.txt
ForCES Working Group S. Blake
Internet-Draft Z. Haraszti
Expires: January 10, 2005 Modular Networks
July 12, 2004
Some Possible Extensions of the Current LFB Model
draft-blake-forces-attrib-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The ForCES Forwarding Element Model [Model] defines a model and
schema for representing Logical Functional Block (LFB) classes and
their operational and capability attributes. The operational
attributes of LFB instances within a Forwarding Element (FE) are
manipulated by the ForCES protocol [ForCES] to configure the
operation of the FE. The model assumes that any particular LFB
attribute is owned and accessed exclusively by a single LFB instance.
While this is a simple and clean restriction, we observe that it
imposes some complications when defining LFBs. This memo addresses
Blake & Haraszti Expires January 10, 2005 [Page 1]
Internet-Draft Possible LFB Model Extensions July 2004
these complications and proposes that the restriction be re-examined.
1. Introduction
The ForCES Forwarding Element Model [Model] defines a model and XML
schemas for representing Forwarding Elements (FEs) and the Logical
Functional Block (LFB) classes that are used to model the FE's
datapath. Attributes and capabilities of the FE such as LFB
topology, LFB topology configurability, neighbor information, etc.,
can be represented by the FE schema. LFB operational and capability
attributes such as flags, tables, and maximum ranges of other
attributes, can be represented by the LFB class schema. LFB classes
are modeled as flat entities (e.g., non-hierarchical, non-nested).
The operational attributes of LFB instances are manipulated by the
ForCES protocol [ForCES] to configure the operation of the FE
(ignoring for the moment the possibility of reconfiguring the LFB
topology, which is an FE attribute). [Model] defines a scheme
wherein LFB attributes are defined exclusively per-LFB class. As a
consequence, an attribute of a LFB instance (such as a table entry)
is owned and accessed exclusively by a single LFB instance, and can
be manipulated (e.g., read or written) by the protocol in messages
addressed specifically to that LFB (or potentially to a subset of all
LFBs of that class).
The intent of [Model] is to define LFB classes such that each
represents "a fine-grained, logically separable and well-defined
packet processing operation in the datapath." As the authors have
attempted to define a comprehensive family of LFBs, they have
observed that this intent is occassionally in conflict with the
restriction that LFB attributes are owned, accessed, and configured
exclusively per-LFB instance.
This memo gives a few examples of problems encountered while
attempting to define a comprehensive set of LFB classes, and
discusses some possible extensions of the LFB class model that would
simplify the process of defining LFB classes.
2. LFB Class Examples
The following three examples illustrate complications that were
encountered when attempting to define LFB classes.
2.1 LPM Classifier and Next Hop LFBs
Normal IP destination address-based forwarding is represented in
[Model] by a sequence of two LFBs: a Classifier LFB supporting
Longest Prefix Match (LPM) on the IP destination address (either IPv4
Blake & Haraszti Expires January 10, 2005 [Page 2]
Internet-Draft Possible LFB Model Extensions July 2004
or IPv6), along with a Next Hop LFB, which resolves the next hop
information associated with the best-matching prefix entry,
potentially by selecting between multiple equal-cost paths.
There is an additional function that is often performed by edge
routers: network ingress filtering [RFC2827], which is used to
confirm that a packet arrived on an expected interface, and hence the
packet's source address is unlikely to have been spoofed. This
function is often implemented by performing a forwarding search on
the packet's source IP address S, and confirming that the packet's
incoming interface is (one of) the path(s) that a packet with
destination address S would be forwarded on. In detail, an LPM
search in the forwarding prefix database is performed using S, and
the (set of) associated next hop(s) is compared against the packet's
incoming interface to determine whether the is a match.
A natural LFB representation of this function would be a sequence of
LPM classifier and Next Hop Comparison LFBs. The former would
perform a search using the packet's source address. The latter would
perform a comparison of the packet's incoming interface id
(represented as metadata) against a set of one or more next hop
attributes. This pair of LFBs would be separate from the LPM
Classifier/ Next Hop LFB pair used for destination-address
forwarding. A complication of this representation is that the two
new LFBs require the exact same attribute configuration as the ones
used for destination address-based forwarding. Since LFB attributes
cannot be shared, the attributes for these LFBs must be configured
separately, in sync with the configuration of the other pair. This
introduces extra ForCES protocol exchanges which adds extra
complexity to the CE software. It also introduces the opportunity to
misconfigure the two pairs of LFBs, which might lead to indeterminate
results, especially if the attributes are actually shared in the FE
implementation (e.g., by a common memory database).
An alternative, partially described in [Model], is to define the LPM
Classifier and the Next Hop LFBs in such a way that they can handle
both the destination and source address LPM searches (LPM Classifier)
and the normal next hop match and next hop comparison functions (Next
Hop). This introduces a loop in the LFB topology, along with
additional inputs and outputs for each LFB. It also complicates the
definition of the LFBs, which no longer perform fine-grained,
logically separable functions.
2.2 ARP and L2 Address Resolution LFBs
The ARP (Neighbor Discovery) function is occasionally offloaded to a
FE. ARP is used to populate the L2 address resolution table for the
router's interfaces (when static entries are not defined). [Model]
Blake & Haraszti Expires January 10, 2005 [Page 3]
Internet-Draft Possible LFB Model Extensions July 2004
defines a L2 Address Resolution LFB, which is used to determine the
L2 destination address for an outgoing packet. This LFB owns the L2
address resolution table as a table of attributes. This is
problematic, since an ARP LFB would need to configure this table, and
the position of this LFB in the topology may not be adjacent to the
L2 Address Resolution LFB.
2.3 Interface MIB counter handling
The Interfaces Group MIB [RFC2863] defines a set of counters that are
maintained on every IP (sub-)interface. Some of these counters
(e.g., ifInUcastPkts/ifInMulticastPkts/ifInBroadcastPkts and
ifInErrors) are exclusive (no packet may cause both of these to be
incremented). To support this requirement, the relevant LFBs must be
defined so that there is a common decision point to increment one or
the other of these counters.
This issue is partially handled in [Model] by defining an IP
Interface LFB which contains all of the Interfaces Group MIB counters
as attributes and includes all of the necessary IP header
verification functions needed to determine whether a received packet
is in error. Such an LFB would be quite complicated, especially
considering all of the IP option (extension header) processing that
may need to be performed to fully verify that a received packet is
not in error. Ideally, the verification functions would be split
into separate LFBs. However, the outcome of these functions is to
update the interface counters, which are attributes of the IP
Interface LFB as currently defined. From a ForCES model and protocol
perspective, it is desirable to have a single LFB which hosts the
complete set of interface counters (at least per-direction).
3. Problem Statement
In reflecting on the previous examples (along with others), the
authors determined that complexities occur due to lack of support in
[Model] of one or more of the following features:
1. Efficient, bundled configuration of multiple LFBs
2. Attribute sharing between LFBs
3. Inter-LFB control
The problems which might be solved by supported the listed features
are inter-related, and could possibly be solved by a common extension
to the model, or a small number of extensions. Note that there are
work-arounds to each of the examples mentioned in Section 2, however,
they are either inefficient or ugly.
Blake & Haraszti Expires January 10, 2005 [Page 4]
Internet-Draft Possible LFB Model Extensions July 2004
3.1 Bundled Configuration of LFBs
There is a common paradox between the simultaneous goals of:
o good functional separation between LFBs (e.g., high granularity),
and
o efficient, one-step configuration of a certain function, which
begs for a single, complex LFB.
In the absence of support for LFB attribute sharing, it may be
necessary for the ForCES model and protocol to support the
simultaneous configuration of attributes in multiple LFBs, to assure
consistency, and to simplify the CE software utilizing the ForCES
protocol.
3.2 Attribute Sharing Between LFBs
There is another common paradox between the simultaneous goals of:
o clean, logical LFB topology graph, which reflects the order of
packet processing, promoting high-granularity LFBs, and
o the need to share attributes between multiple forwarding
functions, promoting low-granularity/higher-complexity LFBs.
If a LFB could access attributes owned by and configured for another
LFB, then this paradox could be resolved. Another alternative would
be to define certain attributes as FE-level attributes, and allow
multiple LFBs to access them, but this would potentially complicate
the FE model.
3.3 Inter-LFB Control
As shown in Section 2.2, one LFB may need to configure the attributes
of another LFB (if they are not shared). This can be modeled by
defining special control metadata that flows with packets between the
affected LFBs, but this solution has the potential to be quite ugly.
Another alternative would be to introduce inter-LFB control paths in
the LFB topology, but this is a significant extension to the model.
4. Possible Model Extensions
A solution to the issues illustrated above will likely require
extending [Model]. Ideally, a single, simple extension to the model
would be sufficient to address these issues (and potentially other
issues that haven't been encountered yet).
Any proposed extension should not significantly complicate the model
nor the ForCES protocol definition or usage, and it should not
Blake & Haraszti Expires January 10, 2005 [Page 5]
Internet-Draft Possible LFB Model Extensions July 2004
complicate the definition of LFBs that do not pose any of these
problems. Further, use of any proposed extension should be optional.
Non-explicit solutions (e.g., those involving hidden relationships
between LFBs that are not exposed by the model) are undesirable,
since they impede interoperability between CEs and FEs, and
potentially between FEs sourced from multiple vendors.
The following proposed extensions may satisfy one or more of the
three features listed in Section 3:
o Dispatcher (proxy) LFB: a dispatcher LFB, not in the datapath
topology, would be the configuration point for the protocol, and
would directly configure two or more LFBs in the topology.
Solves: Bundled configuration.
o Protocol messages addressing multiple LFBs: ForCES protocol
messages could be defined to simultaneously configure multiple
LFBs (of different classes). Solves: Bundled configuration.
o Nested LFBs: A LFB could be composed of multiple LFBs in an
internal graph, each sharing attributes of the parent LFB.
Solves: Bundled configuration, Shared attributes.
o FE-level attributes, accessible to some or all LFBs in a FE: Some
attributes accessed by LFBs could be defined as FE-level
attributes. Solves: Shared attributes.
o Resource "soft-links"/LFBs "exporting" certain attributes to other
LFBs: Mechanisms in the model could be defined to allow LFB
instances to export attributes, and allow other LFB instances to
link to those attributes (e.g., ln -s in Unix). Solves: Shared
attributes.
o Decoupling nodes in the LFB topology from LFB instances: One LFB
instance may show up in the topology as two or more nodes.
Solves: Shared attributes, Inter-LFB control.
o Configuration/control channels between LFBs: The model could be
extended to support configuration/control channels between LFBs,
which show up in the LFB topology. Solves: Bundled configuration,
Shared attributes, Inter-LFB control.
The proposed extensions listed above are not an exhaustive list. The
authors encourage input from the ForCES working group to evaluate and
extend this list.
5. Summary
The ForCES model [Model] will likely need one or more extensions to
address the problems discussed in this memo. These extensions should
be backwards compatible additions, with little or no effect on mature
LFB definitions (few of these exist at the moment, however). Sharing
of attributes between LFBs should be optional in many cases, but it
must be explicitly visible to the CE; otherwise, the configuration
Blake & Haraszti Expires January 10, 2005 [Page 6]
Internet-Draft Possible LFB Model Extensions July 2004
model of the FE is potentially indeterminate. Further analysis of
these problems and the proposed solutions is needed.
6. Acknowledgements
The authors would like to thank Anurag Bhargava, Ho-yen Chang, Arthur
Davis, Peter Denz, Reda Haddad, and Stephen Nadas, for many hours of
brainstorming with the authors, which revealed the issues presented
in this memo.
7 References
[Model] Yang, L., Halpern, J., Gopal, R., Dekok, A., Haraszti, Z.,
Blake, S. and E. Deleganes, "ForCES Forwarding Element
Functional Model", draft-ietf-forces-model-02 (work in
progress), February 2004.
[ForCES] Doria, A., Dong, L., Gopal, R., Haas, R., Salim, J.,
Khosravi, H. and W. Wang, "ForCES Protocol Specification",
draft-doria-forces-protocol-00 (work in progress), June
2004.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
Authors' Addresses
Steven Blake
Modular Networks
First Flight Venture Center
2 Davis Drive
PO Box 12076
Research Triangle Park, NC 27709
USA
Phone: +1 919 765-0027 x2016
EMail: slblake@modularnet.com
Blake & Haraszti Expires January 10, 2005 [Page 7]
Internet-Draft Possible LFB Model Extensions July 2004
Zsolt Haraszti
Modular Networks
First Flight Venture Center
2 Davis Drive
PO Box 12076
Research Triangle Park, NC 27709
USA
Phone: +1 919 765-0027 x2017
EMail: zsolt@modularnet.com
Blake & Haraszti Expires January 10, 2005 [Page 8]
Internet-Draft Possible LFB Model Extensions July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blake & Haraszti Expires January 10, 2005 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-21 07:49:37 |